Blokace IP útočníků na VPS

[Mirek Prýmek]

Se zakázaným rootem se přihlásím jako uživatel, musím přes to SSH spustit su/sudo, tomu nějak předat heslo, které *musí být někde uložené* a až přes to spustit potřebný skript.

Nebo mít v sudo nastaveno, že přesně tenhle skript můžu přesně z tohodle uživatele pouštět pod rootem bez hesla. To je překvápko

Nastavit "PermitRootLogin" na "no" je naprostá kravina, která reálnou bezpečnost systému vůbec nezvýší.

Imho to není tak nebo onak, ale je to "v nějakém systému tak, v jiném onak". Bezpečnost přece nazávisí na spoustě proměnných okolo.

[Reklama]

[Petr Janda]

Na rozdíl od změny portu je zakázání roota celkem standardní nastavení. Rozbije spoustu věcí = heslo je napsané v nějakých skriptech? OOPS ...

Co prosím? S povoleným rootem se normálně klíčem k přihlásím jako root a udělám co potřebuju. Se zakázaným rootem se přihlásím jako uživatel, musím přes to SSH spustit su/sudo, tomu nějak předat heslo, které *musí být někde uložené* a až přes to spustit potřebný skript. Nastavit "PermitRootLogin" na "no" je naprostá kravina, která reálnou bezpečnost systému vůbec nezvýší.

No konečně mi to někdo pořádně vysvětlil ... Teď abych pověsil klávesnici na hřebík a zalezl do studené uličky ... Sudo se dá nastavit tak, aby heslo nechtělo. Pro PermitRootLogin No hovoří:

• Pokud je přihlášení roota povolené, zná případný útočník polovinu z toho, co potřebuje (už. jméno), chybí jen heslo
• Heslo může "leaknout" - buďto ho někdo uhodne, nebo získá např. sociálním inženýrstvím
• V SSHd může být chyba (viz např. nedávný problém s generováním klíčů na Debianu)
• Chrání Tě to před sebou samým (pokud si do profilu nedáš sudo su - :-) )

No a kromě toho:

• Praví se to ve všech hardening guidech
• Chtějí to všichni bezpečáci a auditoři

[Petr Janda]

Prosím poučte mě teda mam ssh hesslo na root jena ja, pak proftpd kde maj přístup jen určití lidé, do určitych složek, je v v tom problém?

V zásádě v tom problém není. Jen pokud jsou ty FTP účty klasické "shellové", musíš si uvědomit, že se ti uživatelé můžou přihlásit i přes SSH a pak zkoušet nějaké "nasty tricks" (lokální exploity na eskalaci práv a tak). Já bych to řešil tak, že bych ssh povolil jen pro určitou skupinu uživatelů (AllowGroups v sshd_config), případně by ti uživatelé pro ftp mohli být "virtuální".
Otázkou je, jestli by nestálo za to nastavit pro přístup přes FTP chroot, tak aby "viděli" jen ty svoje složky.
Jo - jméno a heslo se při přístupu přes FTP přenáší nešifrovaně - takže je otázka, jestli nezvážit spíš scp/sftp případně FTP via TLS.
No a já bych tedy zakázal přihlášení roota přes ssh, udělal bych si tam normální účet a administroval to přes sudo.

[Mirek Prýmek]

Pokud je přihlášení roota povolené, zná případný útočník polovinu z toho, co potřebuje (už. jméno), chybí jen heslo

To neni tak uplne pravda. Jednak login neni "polovina", protoze heslo by melo jit vyrazne hur uhodnout, jednak login je vicemene verejny udaj (kde jsou ty casy, kdy mail uzivatel@x znamenal "uzivatel na stroji x").

Heslo může "leaknout" - buďto ho někdo uhodne, nebo získá např. sociálním inženýrstvím

Moc mě nenapadá, jak by mohlo leaknout heslo bez toho, aby zaroven leaknul login

V SSHd může být chyba (viz např. nedávný problém s generováním klíčů na Debianu)

...napriklad takova, ze PermitRootLogin bude ignorovat Tohle je poměrně nesmyslný argument, zvlášť když sshd obvykle běží pod rootem...

Chrání Tě to před sebou samým (pokud si do profilu nedáš sudo su - :-)
[/list]
Tohle je asi jedinej fakt relevantni argument (viz niz). Neni to tak dlouho, co se tady kdosi divil, ze si na roota dal heslo root a nekdo mu to hacknul

No a kromě toho:

Spíš bych jako hlavní argument dal pravidlo "secure by default" - pokud pro vzdalene prihlasovani na roota neni vazny duvod, je lepsi to mit vypnuty.

[Petr Janda]

Pokud je přihlášení roota povolené, zná případný útočník polovinu z toho, co potřebuje (už. jméno), chybí jen heslo

To neni tak uplne pravda. Jednak login neni "polovina", protoze heslo by melo jit vyrazne hur uhodnout, jednak login je vicemene verejny udaj (kde jsou ty casy, kdy mail uzivatel@x znamenal "uzivatel na stroji x").

No nevím, já mám v logu "Authentication failure for user root", for user test, for user games, ale for <myuser> nikdy.

Heslo může "leaknout" - buďto ho někdo uhodne, nebo získá např. sociálním inženýrstvím

Moc mě nenapadá, jak by mohlo leaknout heslo bez toho, aby zaroven leaknul login

• Administrátorská hesla mají tendenci povalovat se v různých obálkách v různých podivných trezorech
• Pokud to adminuje víc lidí a všichni znají rootovo heslo ...

V SSHd může být chyba (viz např. nedávný problém s generováním klíčů na Debianu)

...napriklad takova, ze PermitRootLogin bude ignorovat Tohle je poměrně nesmyslný argument, zvlášť když sshd obvykle běží pod rootem...

... nebo taková, že projde autentizace, i když by neměla a zarazí se to až na PermitRootLogin ...
[/list]

[Reklama]

[Mirek Prýmek]

No nevím, já mám v logu "Authentication failure for user root", for user test, for user games, ale for <myuser> nikdy.

Jasně. Útoky script kiddies nijak nevylučují to, co jsem psal.

Administrátorská hesla mají tendenci povalovat se v různých obálkách v různých podivných trezorech

No to je jednak samo o sobě daleko prekérnější než povolený root login, jednak pokud bude potřeba přihlásit se přes jiný než rootovský účet, tak na tom papírku ten login nejspíš bude napsaný taky, ne?

Pokud to adminuje víc lidí a všichni znají rootovo heslo ...

...tak nepomůže ani mantra Na Nachma Nachman Meuman http://goo.gl/aTUZB  , natož PermitRootLogin Protože tak jako tak se všichni nějak k rootovi musí umět dostat, takže je jedno, který z těch hesel leakne, nebo jestli leakne jedno heslo, který používají všichni.

... nebo taková, že projde autentizace, i když by neměla a zarazí se to až na PermitRootLogin ...

S takovou logikou můžeme další a další vrstvy zabezpečení přidávat do aleluia, protože vždycky existuje možnost, že v něčem bude chyba a zarazí se to až na té poslední

[Petr Janda]

Administrátorská hesla mají tendenci povalovat se v různých obálkách v různých podivných trezorech

No to je jednak samo o sobě daleko prekérnější než povolený root login, jednak pokud bude potřeba přihlásit se přes jiný než rootovský účet, tak na tom papírku ten login nejspíš bude napsaný taky, ne?

Spíš ne, předpokládá se, že se v nejhorším dostaneš ke konzoli.

Pokud to adminuje víc lidí a všichni znají rootovo heslo ...

...tak nepomůže ani mantra Na Nachma Nachman Meuman http://goo.gl/aTUZB  , natož PermitRootLogin Protože tak jako tak se všichni nějak k rootovi musí umět dostat, takže je jedno, který z těch hesel leakne, nebo jestli leakne jedno heslo, který používají všichni.

Ne tak docela:

• V logu bude, že se přihlásil Franta Admin a ne hromadný root
• Někdy je jednodušší zrušit jeden účet, než distribuovat nové rootovo heslo (třeba když Frantu Admina vyrazí)

[Mirek Prýmek]

Tak jo, tak to myslím můžeme uzavřít s tím, že PermitRootLogin No je lepší než drátem do voka

[Petr Janda]

Tak jo, tak to myslím můžeme uzavřít s tím, že PermitRootLogin No je lepší než drátem do voka

Rezavým určitě.

[Jenda]

Změna portu moc nepomáhá, to už lepší je riskovat několik neúspěšných pokusů o zadání hesla na ssh na standardním portu, než nechat volný průběh na portu vyšším.

To je divný, mně změna portu pomohla dost. Je to téměř nepoužívaný čtyřčíselný port.

Měli bychom se držet standardů ... Pokud máš to SSH jen pro sebe, tak OK, ale pokud tam máš i jiné uživatele (třeba taky SCP/SFTP pro aktualizaci webů), dostáváš se do problémů. Stejně Ti to pomůže maximálně od script-kiddies, pokud se někdo bude vážně snažit, tohle ho fakt nezastaví.

• Zakaž přihlášení roota přes ssh (PermitRootLogin = no v sshd_config) - tak se Ti tam nepřihlásí ani v případě prolomení hesla

Už psal, že heslo má dobré (a pokud by měl slabé, má řešit slabé heslo a ne nějaké nesmyslné obfuskace). V čem PermitRootLogin No pomůže? Akorát to rozbije spoustu věcí typu zálohování.

Na rozdíl od změny portu je zakázání roota celkem standardní nastavení. Rozbije spoustu věcí = heslo je napsané v nějakých skriptech? OOPS ...

Standardní nastavení: E_NO_ARGUMENT. Standardní je mít nešifrovaný disk, provozovat Windows a spousta dalších věcí.

Rozbije spoustu věcí: zálohovací skript si tahá rsyncem / k sobě. Jestli je tam heslo nebo klíč je celkem lhostejné.

[Jenda]

Pokud je přihlášení roota povolené, zná případný útočník polovinu z toho, co potřebuje (už. jméno), chybí jen heslo

Pokud máte uhodnutelné heslo, měl byste řešit uhodnutelné heslo, a ne sypat kolem počítače krájenou cibuli a zapalovat hromničky. Pokud nastavíte heslo na roota "původní heslo"+"uživatelské jméno" (operátor + zde značí normální concat stringů), odolnost máte úplně stejnou.

Heslo může "leaknout" - buďto ho někdo uhodne, nebo získá např. sociálním inženýrstvím

Zatímco jméno ne. Aha.

V SSHd může být chyba (viz např. nedávný problém s generováním klíčů na Debianu)

No hurá, konečně alespoň jeden zajímavý argument.

Chrání Tě to před sebou samým (pokud si do profilu nedáš sudo su - :-) )

Jak mě to chrání? Pokud dělám něco, k čemu potřebuju roota, stejně se su- nu.

No a kromě toho:

• Praví se to ve všech hardening guidech
• Chtějí to všichni bezpečáci a auditoři

Žerme hovna, miliony much se nemohou mýlit.

V logu bude, že se přihlásil Franta Admin a ne hromadný root

Jednak pokud se přihlásí útočník, tak ten řádek z logu prostě smaže, jednak moje sshd vypisuje do logu Accepted public key <jenda> from <ip> for user root.

Někdy je jednodušší zrušit jeden účet, než distribuovat nové rootovo heslo (třeba když Frantu Admina vyrazí)

Jednak pokud máte admina na stálo, tak by sakra měl mít klíč a ne nějaké heslo, jednak pokud se bojíte, že vás naštvaný vyhozený vyownuje, tak to udělá tak jako tak. Jednou rootem, pořád rootem, jak se praví v jedné reklamě na prací prášek.

[JmJ]

Na rozdíl od změny portu je zakázání roota celkem standardní nastavení. Rozbije spoustu věcí = heslo je napsané v nějakých skriptech? OOPS ...

Co prosím? S povoleným rootem se normálně klíčem k přihlásím jako root a udělám co potřebuju. Se zakázaným rootem se přihlásím jako uživatel, musím přes to SSH spustit su/sudo, tomu nějak předat heslo, které *musí být někde uložené* a až přes to spustit potřebný skript. Nastavit "PermitRootLogin" na "no" je naprostá kravina, která reálnou bezpečnost systému vůbec nezvýší.

Lol :-)

[Mirek Prýmek]

Jednou rootem, pořád rootem, jak se praví v jedné reklamě na prací prášek.

Ovšem jenom tehdy, když organizace nemá správně naimplementované IDSko.

[Jenda]

Jednou rootem, pořád rootem, jak se praví v jedné reklamě na prací prášek.

Ovšem jenom tehdy, když organizace nemá správně naimplementované IDSko.

O RLY? IDS odhalí backdoor, nebo v mírnějším případě úmyslnou chybu konfigurace umožňující vzdálené převzetí shellu?

[Mirek Prýmek]

O RLY? IDS odhalí backdoor, nebo v mírnějším případě úmyslnou chybu konfigurace umožňující vzdálené převzetí shellu?

No a ne snad?