Jak funguje na webhostinzích firewall a ochrany

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Dejme tomu, že mám veřejnou IP a na ní hostuju různé druhy serverů, www hosting, smtp atd... Každý se asi setká s tím, že mu tam chodí různé automaty, boti(search engine), pak tam zkouší různé URL typu GET /rom0?cmd=%2Eshell/rm%20-rf  atd... Nebo na IMAP se zkouší některé adresy přihlašovat 100krát denně atd atd
kdo to loguje, tak má přehled, případně používá přehled přímo v daných Dashboardech, vidí tam frekventované adresy....

Já bych je dal do iptables -j DROP ( v lepším případě  s --comment, --match-set, -j LOG+DROP , případně -m recent, --connlimit ,--limit)

Takhle ten seznam pak ale bobtná, pak je taky problém, že ne každá malicous IP(případně rovnou rozsahy), která se dostane na seznam třeba podle zablokování  nevalidní SMTP komunikace, není "hacker", ale třeba napadený počítač uživatele, kterému by nemělo být bráněno dostat se na
 www (http 80 a 443). Tím spíš, ,dyž za jednou natovanou adresou může být víc uživatelů

A ještě pozorování, z deseti adres třeba 7 jich otravuje jen 2 dny a pak dá pokoj, 3 třeba zkouší nonstop 10 požadavků za zen a nebo pak je skupina, kde někdo zkouší 100 rq/s (ale   třeba po hodině by to ustalo). Další aspekt je, že někde je to vyloženě jedna IP a jinde jsou v shluku v nějaké rozsahu (většinou /24, ale mám 2 případy nějakého nizozemského providera /16)


To je popis jak to dělat po domácku.. Má otázka jak tohle řešit lépenež sadou iptables

A druhá otázka je ,jak tohle řeší webhostingové služby (multihosting s virtualhosty tedy s víc doménama a taky víc IP než jednou ať už víc IP na jednom stroji nebo  více stroji, prostě M:N a nebo rovnou s load balancerem)... V téhle oblasti je i druhá strana mince dostupnost, protože  se může stát, že vložením adresy do REJECTu  která lezla po SMTP se zablokuje WWW pro ni(nebo rozsah) pro nevinné uživatele, kteří mají tu smůlu že jsou v rozsahu útočníka/ za NATem,kde je útočník a nebo jen mají napadený počítač...

Nezdá se mi, že by ručně admin sledoval countery iptables nebo dashboard serveru a během šichty operoval s iptables -D INPUT / -I INPUT

Jak reálně na web  hostinízích funguje ochrana proti malicious aktérům, IP adresám  z blocklistů ?

Nezajímá mě tolik konkrétní produkt, ale spíš přístup a koncept a přístup.

Třetí aspekt je časové ohraničení blokování. Protože se na problematický traffic přijde, provider upozorní zákazníka(zafiltruje porty), uživatel "udělá reinstall widlí když má pomalý internet" a prostě nedá se dát -DROP na furt

[Reklama]

[_Tomáš_]

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