Blokace IP útočníků na VPS

[PJ]

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.

[Reklama]

[Mirek Prýmek]

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".

[PCnity]

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,

[Jenda]

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? 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á.

[Mirek Prýmek]

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

[Reklama]

[PCnity]

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.

[PJ]

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

Kód: [Vybrat]

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

Kód: [Vybrat]

// 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).

[Mirek Prýmek]

@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?

[Mirek Prýmek]

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.

[PJ]

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.

[Mirek Prýmek]

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