IPv6 - Pověry a fakta

[Sten]

…

Firewall se v některých případech hodí a mám jej i na serverech. Například i na bránění floodování webserveru (při floodu dočasně přesměruje požadavky na statickou stránku s HTTP 509) nebo protože některé služby na serveru jsou jenom pro použití mezi spolupracujícími servery (typicky různé backendy nebo MySQL). Ale souhlasím s tím, že firewall má tohle řešit až na konci, ne někde po cestě, tam má router maximálně používat reverse path filter.

[Reklama]

[Tomáš Crhonek]

Ano, ostatní služby na serveru nemají co dělat. Ale co když se tam omylem dostanou? Typický příklad: děravý webserver (např. za pomoci PHP) umožní útočníkovi cosi spustit - a útočník zkusí buď odchozí síťové spojení, nebo naslouchat na nějakém portu. V tomto případě je firewall který tomu zabrání prostě nutnost.

Už přímo z tohoto komentáře je vidět, že problém je opět jinde. Na server se služba jen tak omylem nedostane. A pokud ano, tak se správci zruší pracovní smlouva (a to záměrně, ne omylem).

Děravý webserver je skoro totéž. Asi nechceme provozovat děravý webserver, že ano. Souhlasím, že zde firewall s nějakou detekcí může pomoci v nalezení problému. Ale nezabrání mu.

Nejsem proti firewallu, spravuji jich hodně, ale nesmí se brát jako první a hlavně ani jako jediná bariéra.

[firewall]

Ano, ostatní služby na serveru nemají co dělat. Ale co když se tam omylem dostanou?

To je argument jak noha

Takhle vytržené z kontextu je to vážně argument jak noha. Nevytrhávejte prosím z kontextu, viz pokračování:

Typický příklad: děravý webserver (např. za pomoci PHP) umožní útočníkovi cosi spustit - a útočník zkusí buď odchozí síťové spojení, nebo naslouchat na nějakém portu. V tomto případě je firewall který tomu zabrání prostě nutnost.

Tak jako tak zkusí odchozí spojení - a tomu zabránit je v podstatě nemožné.

To není pravda, je to naopak velmi jednoduché: iptables -A OUTPUT -m owner --uid-owner apache -j DROP

[Mirek Prýmek]

To není pravda, je to naopak velmi jednoduché: iptables -A OUTPUT -m owner --uid-owner apache -j DROP

Ok, každý máme jiný způsob práce. Pokud myslíš, že má smysl mít firewall, kde budeš vyjmenovávat všechny uživatele, kteří nemají komunikovt ven, a že udržování takového firewallu je efektivní, tak pak jo. Však jsem taky psal, že to je "v podstatě" nemožné. Principielně je možné všechno, jde jenom o to, jestli efekt odpovídá námaze a jaké jsou vedlejší efekty.

[firewall]

To není pravda, je to naopak velmi jednoduché: iptables -A OUTPUT -m owner --uid-owner apache -j DROP

Ok, každý máme jiný způsob práce. Pokud myslíš, že má smysl mít firewall, kde budeš vyjmenovávat všechny uživatele, kteří nemají komunikovt ven, a že udržování takového firewallu je efektivní, tak pak jo. Však jsem taky psal, že to je "v podstatě" nemožné. Principielně je možné všechno, jde jenom o to, jestli efekt odpovídá námaze a jaké jsou vedlejší efekty.

Ano, oba máme jiný způsob práce. Já jsem totiž přesvědčený že investovat práci do zabezpečení serveru je nutnost která má přednost před administrátorovou pohodlností.

[Reklama]

[Mirek Prýmek]

Ano, oba máme jiný způsob práce. Já jsem totiž přesvědčený že investovat práci do zabezpečení serveru je nutnost která má přednost před administrátorovou pohodlností.

Nebudu to brát jako invektivu

Nejde o pohodlnost admina, ale - jak jsem psal - o udržovatelnost takového řešení. Ne admin vs. bezpečnost, ale bezpečnost vs. dostupnost. Ovšem pokud se ti nikdy nestalo a nestane, že sis takhle extenzivními fw pravidly zablokoval omylem legitimní provoz, tak ok, je to dobré řešení (teda za podmínky, že mi nevadí jeho limity - např. že takhle ochráněný apache pak nemůžu nastavit jako proxy pro jiný server obsahu).

Můj přístup je jiný - 1. apache do jailu a 2. smíření se s tím, že kompromitovaný stroj je kompromitovaný stroj 3. DR pro případ kompromitace. To tvoje řešení mi přijde trochu moc extenzivní a přeplácané. Ale to je věc názoru, jak jsem již byl řekl

[firewall]

Můj přístup je jiný - 1. apache do jailu a 2. smíření se s tím, že kompromitovaný stroj je kompromitovaný stroj 3. DR pro případ kompromitace. To tvoje řešení mi přijde trochu moc extenzivní a přeplácané. Ale to je věc názoru, jak jsem již byl řekl

Z druhého bodu musí mít extrémní radost správci všech serverů na které bude kompromitovaný stroj útočit, protože útočník má neomezenou možnost síťové komunikace. Pro mě je takový přístup nepřijatelný.

[Mirek Prýmek]

Z druhého bodu musí mít extrémní radost správci všech serverů na které bude kompromitovaný stroj útočit, protože útočník má neomezenou možnost síťové komunikace. Pro mě je takový přístup nepřijatelný.

Opět zdůrazňuju, že to je můj názor a můj přístup k věci.

Tohle považuju za pseudoproblém. Neomezenou možnost komunikace má libovolný uživatel libovolného stroje. Získat přístup k uživatelskému účtu je podstatně jednodušší než k systémovému účtu. Takže mi tahle myšlenka přijde trochu jako zamykání branky, u které není plot

[Tomáš Crhonek]

Takže mi tahle myšlenka přijde trochu jako zamykání branky, u které není plot

Souhlas. 

Jsou sítě, kde se omezuje provoz oboustraně, vyjmenovává se každá jednotlivá služba apod. Většinou to vypadá tak, jak jsem psal. Jsou povolené všechny služby, které na serveru běží a žádná jiná se na server stejně nedostane. Ale tak ok. Jsou i sítě, kdy komunikace (pouze http) dovnitř jde jen přes reverzní proxy a komunikace ven přes autentizaci na normální proxy. Pokud jsou na ostatních služby vnitřní servery, tak je do taky ještě docela ok, hlavně když to není tajná transparentní proxy. A pak když tam chcete pracovat, tak vám správce dá tajně přístup na "zadní vrátka" a dostanete se všude (i takový už jsem dostal). Výsledkem je extrémně drahé řešení, které, aby se tam dalo pracovat, tak tam někdo udělá díru. Jinak totiž pracovat nejde. Takže výsledkem je stav, na který je snad i nějaký audit a správce pro vlastní práci tam má někde soukromou VPN.

Teď pracujeme na projektu pro jeden z největších podniků v ČR. Všechno musí schvalovat bezpečnostní oddělení, všechno musí projít přes tamní správce sítě, vše je na příkaz a povolení od vedení a vše je pouze dočasné. Adresy DNS resolverů jsem dostal "už" po 14 dnech (forward před 16 lidí) a SMTP relay nastavovali bezmála měsíc. Jako dobře, možná že to je bezpečné, ale z tohoto způsobu práce je jasné, že tam nikdo nemá celkový přehled o celé síti (možná je to tak schválně). Povolují a zakazují se jen jednotlivé schválené služby a asi by šlo si nechat "nezávisle na sobě" povolit takové kombinace přístupů, že by z toho byla díra jak vrata do dvora. Výsledek je ale extrémně pomalé nasazení produktu, místo dvou dnů je to již na 3 měsíce. Na druhou stranu, je kompletně dokumentován každý krok a to je rozhodně plus. Ale nestěžuji si, na rozdíl od ostatních podniků, tady ti lidé dobře vědí co dělají a mají přehled o technologiích i mimo svůj obor. Jen by to chtělo větší systémovou flexibilitu.

[Tomáš Crhonek]

Z druhého bodu musí mít extrémní radost správci všech serverů na které bude kompromitovaný stroj útočit, protože útočník má neomezenou možnost síťové komunikace. Pro mě je takový přístup nepřijatelný.

Neomezenou možnost síťové komunikace má kdokoliv, nejen kompromitované stroje. To opravdu není moc dobrý argument.

[firewall]

Z druhého bodu musí mít extrémní radost správci všech serverů na které bude kompromitovaný stroj útočit, protože útočník má neomezenou možnost síťové komunikace. Pro mě je takový přístup nepřijatelný.

Neomezenou možnost síťové komunikace má kdokoliv, nejen kompromitované stroje. To opravdu není moc dobrý argument.

Ale u takového "kdokoliv" vím kdo to je - musím znát své uživatele. To je podstatný rozdíl proti útočníkovi který se mi dostal na server omylem, ale se kterým je nutno počítat - statisticky se to prostě jednou za čas stane, protože komplikovaný software bezpečnostní díry měl, má a bude mít.

[Mirek Prýmek]

Na druhou stranu, je kompletně dokumentován každý krok a to je rozhodně plus.

(pomalé) schvalování a (poměrně rychlý) change/config management jsou imho dvě na sobě docela nezávislé věci, i když v korporacích vždy úzce provázané.

Já třeba teď nasazuju change mgmt kombinovaný s HIDS na celkem jednoduchém principu na bázi gitu, takže plnou zdokumentovanost a přehled změn bych měl mít brzo k dispozici taky - i bez schvalování desítkou úředníků

Ale nestěžuji si, na rozdíl od ostatních podniků, tady ti lidé dobře vědí co dělají a mají přehled o technologiích i mimo svůj obor. Jen by to chtělo větší systémovou flexibilitu.

Na to si stěžují všichni zaměstnanci velkých korporací bez výjimky

[Mirek Prýmek]

Ale u takového "kdokoliv" vím kdo to je - musím znát své uživatele.

Nesmysl. Získat přístupové údaje řadového zaměstnance je triviální - social engineering ještě nikdy nezklamal A pak už nemáš "uživatele, kterého znám" ani náhodou - a NIC proti tomu neuděláš, protože BFU nezměníš. A že BFU vydal heslo dobrovolně, nikdy nedokážeš.

To je podstatný rozdíl proti útočníkovi který se mi dostal na server omylem, ale se kterým je nutno počítat - statisticky se to prostě jednou za čas stane, protože komplikovaný software bezpečnostní díry měl, má a bude mít.

Právě proto, že software díry měl a mít bude, je potřeba počítat s tím, že k průniku může dojít - sice se mu snažit _rozumně_ bránit, ale zároveň na obranu nespolíhat, brát úspěšný útok jako fakt a sichrovat se IDSkem a rozumně vymyšleným DR.

[firewall]

Ale u takového "kdokoliv" vím kdo to je - musím znát své uživatele.

Nesmysl. Získat přístupové údaje řadového zaměstnance je triviální - social engineering ještě nikdy nezklamal A pak už nemáš "uživatele, kterého znám" ani náhodou - a NIC proti tomu neuděláš, protože BFU nezměníš. A že BFU vydal heslo dobrovolně, nikdy nedokážeš.

Jaké NIC? Naopak něco - řadoví zaměstnanci nemají co mít přístup na server připojený do internetu. Klasifikovat servery do bezpečnostních zón a podle toho se k nim chovat je základ. Server přímo připojený do internetu je vždy v nejnižší bezpečnostní zóně.

[Mirek Prýmek]

Jaké NIC? Naopak něco - řadoví zaměstnanci nemají co mít přístup na server připojený do internetu. Klasifikovat servery do bezpečnostních zón a podle toho se k nim chovat je základ. Server přímo připojený do internetu je vždy v nejnižší bezpečnostní zóně.

No tak jestli se bavíme o prostředí, kde uživatelé nemůžou žádným způsobem na internet, tak to pak ano. To ale není prostředí 99,9% podniků, natož domácností.

Ale to už jsme dost offtopic, už se zdržím dalších komentářů.