Fórum Root.cz
Hlavní témata => Server => Téma založeno: Petr 25. 08. 2012, 07:43:25
-
Dobré ráno přeji všem. Předem se omlovám za "Lamacky" dotaz. Jde mi o to, že mam dennodeně utoky na vps o prolomení root hesla, to by mi ani tak nevadilo, heslo je ok, ale kvůli toho mi padají servry. No a mám dotaz kde nastuddovat jak třeba blokovat ip adresu jak se třeba skusí lognout během chvilky na roota? Našel sem članky nějaké iptables sem jakž, takž pochopil, ale to je tak vše. Opravdu v linu se moc nevyznám, teda učím se, nejraději bych byl pokud by mě někdo nasměroval na nějakou literaturu(nechci hotové řešení, potřebuju to pochopit)
-
Koukněte třeba na fail2ban.
-
A nebo změňte ssh port na něco jiného než 22, pokud se teda nepřipojujete z lokace za firewallem který vám nedovolí připojit se na jiné než standardní porty. Ale i tak můžete zkusit třeba 8080...
-
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.
-
Jistě mam ssh standartně na 22, ale to mi tak nevadí ty snahy, heslo je dostatečně silné jen mě štvou ty snahy, podle ip adres jdou utoky ze zahraničí ne z čr/sk. Jen dodám opravdu nejsem dobry v ůinu pořád se učím, ale co sekundu nebo možna i méně je pokus se lognout na jiny port jde mi o to jak by se někdo pokoušel o toto tak hned do banu
-
fail2ban
-
Nějak mi nedochází souvislost s padáním serverů. Můžete to prosím nějak rozvést?
-
- 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
- Pokud to jde, povol na firewallu port 22 jenom z vyjmenovaných adres
- Pokud to nejde (dynamické IP a podobně), popřemýšlej např. o OpenVPN
- Pokud Tě nějaká IP moc štve, blokni ji ručně. Jakékoliv automatické blokování je IMHO asking for troubles
-
…Jen dodám opravdu nejsem dobry v ůinu…
No, řekl bych, že nejsi sám, já například pojem ůin četl poprvé v životě v tvém příspěvku ;D
Ale k věci. Kromě fail2ban můžeš zkusit také denyhosts, což je více jednoúčelový prográmek, v podstatě ho stačí nainstalovat a hotovo. Pozor na to, že pokud se spleteš v hesle několikrát po sobě, budeš také bez milosti odříznut. Další možností je používat SSH klíče a zakázat přihlašování heslem (http://www.root.cz/clanky/jak-se-prihlasovat-na-ssh-bez-zadavani-hesla/). Dále můžeš zakázat přihlašování na roota (a používat su/sudo) a nakonec i přesunout na jiné číslo portu.
Nejlépe ale všechno zkombinovat, tedy začít používat SSH klíče, vypnout přihlašování na roota a nainstalovat automatický banner, s nastavením whitelistu, abys měl jistotu, že některé adresy nikdy nezabanuje.
-
- 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
- Pokud to jde, povol na firewallu port 22 jenom z vyjmenovaných adres
- Pokud to nejde (dynamické IP a podobně), popřemýšlej např. o OpenVPN
- Pokud Tě nějaká IP moc štve, blokni ji ručně. Jakékoliv automatické blokování je IMHO asking for troubles
Urcite bych vypnul PermitRootLogin.
Port bych nemenil. To je imho blbost. U web serveru taky kazdy nechava vychozi 80 a spousta lidi porad zkousi hadat hesla k webovym aplikacim...
Proc by treba uzivatel pri pristupu na SFTP musel vyplnovat jiny port?
Zajimave by bylo pouze prihlasovani pomoci klicu.
Blokovani IP je hezka vec, ale sposta lidi ma dynamickou IP.
Urcite se vyplati pri nekolika spatnych pokusech o prihlaseni na par minut zablokovat IP.
Napr. denyhost (http://www.root.cz/clanky/blokujte-ssh-utoky-pomoci-denyhosts/). Ja pouzivam fail2ban (https://help.ubuntu.com/community/Fail2ban), blokuji IP na 10 minut.
Na webu pouzivam blacklist (http://www.okean.com/thegoods.html) IP (htaccess) pro cinu a vetsinu spamu v diskuzich to odchyti. Na SSH by se to urcite taky vyplatilo - na tom webu jsou i sestavene iptables prikazy.
-
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.
- 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í.
-
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 ...
-
Děkuju všem za ochotu pohrahu si s tím. Ale opravdu děkuju za ochotu. A tam nějaky překlep neřeště.
-
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ýší.
-
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?
-
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.
-
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
-
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.
-
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.
-
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]
-
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í :)
-
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í)
-
Tak jo, tak to myslím můžeme uzavřít s tím, že PermitRootLogin No je lepší než drátem do voka :)
-
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ě.
-
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é.
-
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.
-
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 :-)
-
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.
-
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?
-
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?
-
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?
Niekedy to nahodou moze fungovat, ale komplexne sa to bude robit tazko. Ked si raz root napriklad patchne SSHd, aby prihlasilo uzivatela test123 s jeho klucom ako roota a v tomto pripade nelogovalo spojenie, tak tomu v 99% IDS nepomoze. Podobne sa da uprava spravit v kerneli (co taky ICMP packet, ktory pri vhodnom stringu v pakete spusti shellcode dalej v pakete, pricom nepojde o buffer overflow?). Alebo pri spojeni na port x stiahne a spusti shellcode z nejakej adresy. Alebo uprava cronu, ktory bude automaticky patchovat sshd, aby umoznil pristup zlemu uzivatelovi. Alebo patchnuty apache, ktory spusti POST poziadavok na vhosta napriklad black-hat.nonexistent. Nejaka obfuskacia sa da tiez implementovat. Moznosti implementacie zakerneho kodu je vela - IDS ma sancu len v par vybranych pripadoch.
-
Niekedy to nahodou moze fungovat, ale komplexne sa to bude robit tazko. Ked si raz root napriklad patchne SSHd, aby [...]
Nevím, jestli mluvíme o tom samým, ale já mám namysli HIDS na úrovní filesystému - tj. nejjednodušeji realizovaný tak, že mám někde bezpečně uložené fingerprinty toho, jak mají soubory vypadat. Něco na způsob tohodle: http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html - System State Comparison, ale spíš něco pořádnějšího, provázaného s cfg mgmt, jako např. http://rsug.itd.umich.edu/software/radmind/
Čili sshd si patchnout může, ale při nejbližším checku to bude odhaleno.
Samozřejmě může nějak docílit, že jeho patch se dostane do oficiálního čistého stavu systému, ale to už je zas trochu o něčem jiným - otázka politik atp. atd. - ale to pořád neznamená, že by platilo "jednou root, navždy root".
-
IDS je vam na nic pokial system nekontrolujete offline. Informacie pochadzaju sice z Windows worldu, ale technika je univerzalna.
Mas exploit co ti umozni spustit kod, nahodis si nieco na style meterpreter (bezi len v pamati, nic nejde na disk) a putsis dalsi eploit - rootkit. Sice modifikujes filesystem, ale rootkit sa postara o to aby jeho modifikacie na filesysteme a proces zostali neviditelnymi.
Pravdaze by sa zmeny objavili pri offline testoch - nabootovat live linux a scan... Ale to je hardcore a nikto to nerobi :)
Cize IDS/IPS/NIDS/whatever je sice lepsie mat nez nemat, ale pravidlo raz rootom, naveky rootom je imho zakladna dogma ktorej sa treba drzat,
-
Niekedy to nahodou moze fungovat, ale komplexne sa to bude robit tazko. Ked si raz root napriklad patchne SSHd, aby [...]
Nevím, jestli mluvíme o tom samým, ale já mám namysli HIDS na úrovní filesystému - tj. nejjednodušeji realizovaný tak, že mám někde bezpečně uložené fingerprinty toho, jak mají soubory vypadat. Něco na způsob tohodle: http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html - System State Comparison, ale spíš něco pořádnějšího, provázaného s cfg mgmt, jako např. http://rsug.itd.umich.edu/software/radmind/
Čili sshd si patchnout může, ale při nejbližším checku to bude odhaleno.
Vy pravidelně vyndaváte ze všech serverů disky a na nezávislém počítači je kontrolujete na změny? :o :o :o Jak řešíte, co se stane při vyhození lidí, kteří mají přístup k těmto kontrolám?
Mohu vás ubezpečit, že tohle většina firem nedělá.
-
IDS je vam na nic pokial system nekontrolujete offline.
Vy pravidelně vyndaváte ze všech serverů disky a na nezávislém počítači je kontrolujete na změny?
Pánové, psal jsem "správně naimplementované IDSko". To znamená naimplementované tak, aby se nedalo snadno obejít.
Pokud jde o to, jak rootovi zamezit, aby mohl modifikovat kernel, tak může jít například o tahle opatření (konkrétní implementace samozřejmě záleží na organizaci):
0. "běžný správce" roota nepotřebuje. Systém modifikuje výhradně pomocí patchů commitnutých skrz change management => všechny změny jsou archivované, nikdo si nelajzne commitnout backdoor, protože riskuje vězení
1. "běžný root" má přístup jenom k jailu. Z něj je výrazně složitější (ne-li nemožné) s kernelem manipulovat => člověk, který má přístup i k hostu, se tak často nemění a má přísnější režim
2. sysctl kern.securelevel=1
3. MAC, např. Capsicum
-
Ani Jail ani GRSecurity ani SELinux ti nepomozu ak ma utocnik vhodny exploit po ruke. V momente ked ti bezi tvoj kod na urovni kernelu (exploit), zavedies si hoci vlastny modul (na urovni kernelu) a vsetky bezpecnostne prvky obides napriklad tym ze ich mozes aj vypnut.
-
0. "běžný správce" roota nepotřebuje. Systém modifikuje výhradně pomocí patchů commitnutých skrz change management => všechny změny jsou archivované, nikdo si nelajzne commitnout backdoor, protože riskuje vězení
Nesuhlasim, backdoor moze byt len "bug" v programe pridany este niekedy davno, ktoreho si nikto nevsimne. Nieco na styl C-ckovskeho
if (geteuid() == 0 || dobryuser() && kopec_dalsich_veci_aby_bol_koniec_riadku_daleko() && dalsie_veci() && ma_prava = 1) {
sprav_nebezpecnu_akciu();
}
alebo mozno klasicky priklad v PHP
// male tagy pre XHTML
$vstup = preg_replace('|<([^>])>(.*?)</\1>|e','"<$1>" . strtolower("$2") . "</$1>"', $vstup);
Alebo moze ist aj o nedostatocnu kontrolu uploadovanych suborov (ked tam je aspon nejaka kontrola, tak to malokto skuma podrobnejsie). To by som chcel vidiet, ako u tohto niekomu dokazete umysel.
Viem, ze napriklad PHP cesta sa da trochu zabezpecit pomocou MAC, ale stale bude deravy aspon ten 1 web, ak to ma fungovat.
1. "běžný root" má přístup jenom k jailu. Z něj je výrazně složitější (ne-li nemožné) s kernelem manipulovat => člověk, který má přístup i k hostu, se tak často nemění a má přísnější režim
Ano, ale potom uz sa da tazko hovorit o tom, nakolko je to root. Je to len nejaky jail root. Ani ja v Linuxe a na Solarise nedavam capability tym, ktori ich nepotrebuju. Lenze ide potom o roota? "Jednou rootem porad rootem" plati, ale obycajne neplati "jednou user porad user" - a prave preto sa odoberaju capability a pridava sa MAC atd. Efektivne uid 0 v principe nic neznamena - dokonca root (uid 0) bez capabilities ma na Solarise menej prav ako bezny uzivatel s default capabilities.
2. sysctl kern.securelevel=1
To samo osebe nestaci + obycajne musi byt aj niekto, kto dokaze robit hlbsie zmeny, napr. nastavit pf (a o tom sa asi bavime, viz vyssie).
-
@PCNity: jeste jednou: kern.securelevel=1
To samo osebe nestaci + obycajne musi byt aj niekto, kto dokaze robit hlbsie zmeny, napr. nastavit pf (a o tom sa asi bavime, viz vyssie).
Jiste, jenze pokud ma nekdo opavneni menit napr. /etc/pf.conf, tak je dobry, aby to nedelal prihlasenim se pod roota + vim, ale mohl to udelat _jenom_ pres vyse zmineny cfg mgmt. Asi dost tezko bude do pf.conf propasovavat backdoor toho typu, co jsi napsal.
Jinak co se tyce zranitelnosti obecne, tak muzou byt dvojiho typu:
1. admin ho tam vedome propasuje
2. pochazi z upstreamu
Ad 2 - pokud ji zneuziju, pak to vubec nesouvisi s tim, jestli jsem na stroji nekdy byl nebonebyl root
Ad 1 - zmena je evidovana a vim, ze se na ni driv nebo pozdeji prijde. Ze jsem to mohl udelat nekdy davno, to neni argument. Ja mam napr. IDS data v GITu, takze kdybych zjistil, ze k utoku doslo skrze spatne nastaveny PF, muzu si prohlidnout historii zmen, ktery se nad pf.conf udaly.
Chapej, ja netvrdim, ze je mozne udelat neporazitelny system, jenom rikam, ze je mozny udelat zmeny takovy, ze to, ze jsi nekdy nekde byl root, ti k utoku vyrazne nepomuze. Koneckoncu kdyby to byla tak dogmaticka pravda, jak tvrdis, mohlo by vubec existovat IT napr. v bankach?
-
Jeste bych to mozna napsal jinak: neni nutne predpokladat, ze "skutecnych rootu" (tj. uzivatelu, schopnych se na system prihlasit a delat cokoli) musi byt mnoho a budou se casto stridat.
Casto stridat se muzou/musi jenom rutinni admini - a ti takova prava min nemusi.
Vlastne se vubec nemusime bavit o technickych prostredcich, ale muzeme rict, ze cilem je, aby pocet lidi, kteri muzou do systemu vlozit backdoor, byl behem desitek let natolik maly, ze nikdo z nich by si netroufl tam ten backdoor dat, protoze by vedel, ze podezrelych je malo.
-
Ad 1 - zmena je evidovana a vim, ze se na ni driv nebo pozdeji prijde. Ze jsem to mohl udelat nekdy davno, to neni argument. Ja mam napr. IDS data v GITu, takze kdybych zjistil, ze k utoku doslo skrze spatne nastaveny PF, muzu si prohlidnout historii zmen, ktery se nad pf.conf udaly.
A co ked ide o "bug", ako som spominal alebo na ten styl? Nemusi ist prave o pf.conf, ale aj keby islo - dokazete umysel? Ten PHP kod je taky typicky pripad toho, ze nemusi ist o chybu viditelnu na prvy pohlad, C kod je backdoor rovnakeho typu, aky sa raz niekto pokusal pridat do Linux kernelu.
Vlastne aj ten, kto takyto bug zneuzije, nemusi byt vobec admin. Admin sa lahko zamaskuje tym, ze najskor skusi par inych neexistujucich bugov a "nahodou" natrafi na tento bug - ak pojde cez proxy, tak je sanca na vypatranie nizka.
Koneckoncu kdyby to byla tak dogmaticka pravda, jak tvrdis, mohlo by vubec existovat IT napr. v bankach?
Nerobil som tam, neviem, ale ide to napriklad tak, ze pri zmene adminov (tych, co maju plneho roota) sa robi komplet audit, vratane offline kontroly systemu - ak nie rovno reinstall.
Jeste bych to mozna napsal jinak: neni nutne predpokladat, ze "skutecnych rootu" (tj. uzivatelu, schopnych se na system prihlasit a delat cokoli) musi byt mnoho a budou se casto stridat.
Casto stridat se muzou/musi jenom rutinni admini - a ti takova prava min nemusi.
Ano, ale mne prave robi problem vymena tychto skutocnych rootov; s osekanymi uzivatelmi obycajne nebyva problem (ak nie je diera v kerneli alebo v nejakej aplikacii, vdaka comu by ziskali skutocneho roota).
Vlastne se vubec nemusime bavit o technickych prostredcich, ale muzeme rict, ze cilem je, aby pocet lidi, kteri muzou do systemu vlozit backdoor, byl behem desitek let natolik maly, ze nikdo z nich by si netroufl tam ten backdoor dat, protoze by vedel, ze podezrelych je malo.
Tak toto je teda "uzasny" pristup. A co spominane "bugy"? To, ci si niekto trufne, je len vec toho cloveka a nijak to nezvysi bezpecnost. Pri pristupe "nikto si netrufne, lebo ho (mozno) vypatrame a potom mu znicime zivot" by FBI nemusela pouzivat vobec ziadne hesla - nastastie sa to tak nerobi.
-
A co ked ide o "bug", ako som spominal alebo na ten styl?
No pokud je to bug, tak potom nezalezi na tom, jestli utocnik byl nebo nebyl driv rootem.
Abysme si rozumeli, znovu opakuju, co se snazim naznacit: podle me se daji udelat opatreni, ktera vyrazne snizi pravdepodobnost toho, ze nekomu zjednodussi utok to, ze nekdy byl adminem.
Nemusi ist prave o pf.conf, ale aj keby islo - dokazete umysel?
No tak budu mit v ruce tohle:
1. zaznam, ze clovek X 14.1.2004 zmenil konfiguraci tak, ze se system stal zranitelnym.
2. clovek X 27.8.2012 teto zranitelnosti zneuzil
To by bylo dokazovani z me strany. Posuzoval by to soud. Podle me zhruba tak stejne jako kdyz si nekdo v patek otevre okynko od hajzlu, aby jim v sobotu do firmy vlezl a odnesl si kopirku :)
Nerobil som tam, neviem, ale ide to napriklad tak, ze pri zmene adminov (tych, co maju plneho roota) sa robi komplet audit, vratane offline kontroly systemu - ak nie rovno reinstall.
Je to mozny, nevim. Kazdopadne pokud by se delal napr. offline check, neni to samo o sobe dukaz, ze teze "jednou rootem navzdy rootem" NEPLATI?
Ano, ale mne prave robi problem vymena tychto skutocnych rootov
Pokud by byly procesy managementu dobre navrzene, byl by pocet nutnych zasahu skutecne neomezeneho uzivatele naprosto minimalni - a snadno proveritelny. Nehlede na to, ze na tehle pozici by meli delat dobre provereni lidi, to je asi zaklad.
To, ci si niekto trufne, je len vec toho cloveka a nijak to nezvysi bezpecnost. Pri pristupe "nikto si netrufne, lebo ho (mozno) vypatrame a potom mu znicime zivot" by FBI nemusela pouzivat vobec ziadne hesla - nastastie sa to tak nerobi.
Mozna to zni blbe, ale takhle to proste v praxi chodi v mnoha oblastech lidske cinnosti. Jaka mam opatreni proti tomu, aby do skolky nevbehl clovek s puskou a vsechny deti nepostrilel? V podstate zadna - verime proste tomu, ze to nikdo neudela, protoze vi, ze bude chycen a sankce bude vysoka. Kdybych skutecne ucinna opatreni chtel zavest, musela by skolka mit deteknci ramy nebo radeji body scanner, po zuby ozbrojenou ochranku atd. atd. - a porad by to neresilo situaci, ze nekdo do skolky vjede tankem ;)
Tim chci rict, ze ma smysl delat jenom takova opatreni, ktera jsou umerna situaci - riziko vzdycky jenom snizujeme, nikdy ho neni mozny stoprocentne eliminovat. Potom uz mi nezbyva, nez doufat, ze se to nestane casteji, nez mam v analyze rizik.
...a v neposledni rade pokud jsem vetsi firma, tak jsem hlavne proti takove _malo pravdepodobne_ situaci pojisteny :)