219
« kdy: 29. 06. 2022, 10:49:17 »
drop je krajní řešení a co vidím u sebe, používá se až, když probíhá nějaký útok a potřebuji ochránit služby, zpravidla se děje na hraniční firewallu nebo agregátorů a hlavně z důvodu vytížení linky, k ničemu jinému drop není užitečný.
Běžný webhosting začíná s rate limitováním, tak aby neomezoval služby a zároveň je ochránil. Když někdo dává příliš požadavků, prostě ho zpomalím na firewallu.
Obrana proti různým typům útoků na aplikace a používáním známých zranitelností se řeší různě, opět je tady lepší to prostě na straně infrastruktury neblokovat a přidávat ad-hoc dočasná pravidla až podle toho, jestli se nějaká věc masivně zneužívá (např. nedávno log4shell zranitelnost jsme takhle fixlovali než byl update). Ono to je totiž dvousečné, ty nevíš co je legitimní provoz a co je zranitelnost aplikace, můžeš mít speciální filtry pro nějaké krabice jako wordpress, ale dá dost práce je připravit a udržovat a zároveň něco nerozbít.
Samozřejmě je velice vhodné provoz logovat a analyzovat, v případě kdy rozpoznáš nebezpečné chování, informuješ uživatele, pokud jeho aplikace masivně nebezpečně dotazuje jiné aplikace či oťukává infrastrukturu, můžeš přistoupit k blokování, ale opět tady platí, že dělat to automaticky je nebezpečné a mělo by se to používat jako krajní řešení. Tvoje infrastruktura musí být záplatovaná a bezpečná, nemělo by jít skenování či oťukávání ohrozit, pokud již je penetrovaná, přichází na řadu blokování a izolace, je ale těžké to dělat automatizovaně a neomezovat služby platícím zákazníkům. Je to něco jiného než, když jako firma provozuješ infrastrukturu pouze pro sebe, tam si můžeš blokovat poměrně snadno a dělá se to tak.
K různýmu podezřelýmu chování ještě nezapomeň i variantu, že to může být legitimní provoz, různé bezpečnostní či skenovací nástroje mohou zkoušet jak je aplikace zabezpečená, může si takovou službu i platit sám zákazník. Je těžké mezitím rozlišovat a automaticky něco blokovat na vyšší vrstvě.