Hledání jehly v kupce firewallového sena

Každý den se nyní na firewallech routerů Turris zachytí přibližně 6 milionů paketů, které nejsou propuštěny do routerů ani do vnitřních sítí, které tyto routery obsluhují. Zachycování nežádoucího provozu zvenčí firewallem je přitom běžnou vlastností (správně nakonfigurovaných) routerů, specialitou routerů Turris potom je to, že jsou záznamy o těchto zablokovaných přístupech odesílány na naše servery a podrobeny další analýze. V tomto provozu je totiž možné najít mnoho zajímavých informací, díky kterým můžeme například odhalovat šířící se malware nebo chránit uživatele routerů před průniky útočníků zvenčí. Protože ale škodlivý provoz představuje jen malý zlomek ze všech těchto záznamů, museli jsme najít způsob, jak oddělit zrno od plev, tedy jak vytěžit tyto cenné informace z množství dat, která se zachytávají na firewallu při běžném provozu.

Co nám tedy znesnadňuje práci při analýze dat z firewallů? Pokud se podíváme níže na graf nejčastěji blokovaných portů, můžeme rozdělit původce těchto „zbytečných“ dat na dvě skupiny. V první jsou služby, které jsou charakteristické pro lokální sítě, tedy například protokol pro hledání sousedů routerů MikroTik na portu 5678/UDP, synchronizační protokol služby Dropbox na portu 17500/UDP nebo port 137/UDP patřící službě NetBIOS. Téměř všechny pakety na těchto portech se šíří v rámci sítí, do kterých je sice router připojen zdířkou WAN, ale nikoliv celým Internetem. Konkrétně se pak jedná o routery u poskytovatelů, kteří umožňují přímou komunikaci mezi jednotlivými klienty, případně o sítě na vysokoškolských kolejích a podobně.

Do druhé skupiny spadají pakety zablokované z toho důvodu, že už se – velmi vágně řečeno – „nevešly do routeru“. K tomu dochází nejčastěji u paketů zasílaných v rámci P2P sítě BitTorrent, pro kterou jsou nejběžnější porty 51413 a 6881 (na protokolech TCP i UDP). Zde může docházet k problémům v tom případě, kdy se vytvoří takové množství spojení, které překročí nastavenou hodnotu sledovaných spojení – tedy parametru kernelu net.netfilter.nf_conntrack_max. Tipem pro uživatele routeru Turris, kteří ve svých statistikách pozorují velké množství paketů ze služby BitTorrent, může být navýšení hodnoty tohoto parametru v souboru /etc/sysctl.conf. Příčinou může být i špatná konfigurace firewallu na routeru, kdy jednoduše dochází k tomu, že data, která se nám snaží protější strana poslat, nejsou propuštěna.

Pakety zablokované na firewallech routerů Turris za poslední rok.

Pakety zablokované na firewallech routerů Turris za poslední rok.

Podobně zaplňují tabulky záznamů z firewallu i přerušená TCP spojení, nejčastěji pak HTTP a HTTPS spojení, tedy komunikace na portu 80, respektive 443. K tomuto jevu dochází například tehdy, když přichází odpověď ze vzdáleného serveru skrz router v dobu, kdy již klient ve vnitřní síti routeru není k dispozici, k čemuž může dojít třeba při krátkém výpadku připojení klienta připojeného prostřednictvím Wi-Fi. Stejně tak se ve firewallových záznamech toto spojení objeví v případě, že dojde k zahlcení routeru, jak bylo vysvětleno výše, nebo pokud TCP spojení není korektně ukončeno z jiného důvodu.

Rozhodli jsme se tedy v první řadě použít jednu z nejjednodušších metod, jakými je možné tato data připravit pro další zpracování. Nejprve vyřadíme z analýzy nezajímavé pakety tím, že stanovíme minimální počet klientů, na které zdrojová IP adresa přistupovala – už zvýšením na dva až tři routery odstraníme většinu provozu, který se vyskytuje pouze v rámci jedné sítě, a nepřišel tedy na router z Internetu. Dále jsme na základě známých vzorců chování sestavili tabulku pravidel, podle kterých se jednotlivé adresy klasifikují. Pro neškodné chování, jakým je právě zablokovaná BitTorrent nebo HTTP komunikace, jsou v tabulce pravidla se záporným skóre, pro potenciálně škodlivé chování, jako pokusy o přístup na SSH, hledání veřejných DNS resolverů nebo třeba pokus o přístup na služby pro sdílení souborů, aplikujeme pravidla s různými kladnými hodnotami skóre. U každé adresy poté podle četnosti jednotlivých jevů pozorovaných ve firewallových záznamech aplikujeme vážená skóre (na celkové skóre má tedy vliv i to, jaké procento ze zablokovaných paketů mělo „škodlivý“ charakter) a adresu označíme „štítky“ (nebo také „tagy“), jaká pravidla byla aplikována.

Když máme všechny adresy tímto klasifikátorem ohodnoceny, pokračujeme tím, že vytvoříme seznam adres, které překročily určitou hodnotu skóre, tzv. „greylist“. Pravidelně pak ještě dochází k ruční kontrole „zahozených“ adres a průběžné aktualizaci tabulky pravidel – postupně tak jsou přidávány nové porty, které se pokouší útočníci zneužívat.

Mimo pravidla, která komunikaci klasifikují na základě informací o portu a protokolu, používáme ještě seznamy adres, u kterých bylo neslušné chování pozorováno někde jinde. Aktuálně to pak jsou adresy, které se snažily získat přístup k systému v některém z honeypotů spravovaných Laboratořemi CZ.NIC, kam momentálně experimentálně přesměrováváme i provoz z několika routerů Turris dobrovolníků z vývojového týmu, případně nahrávaly na tyto nastrčené servery soubory se škodlivým kódem. Těmto adresám pak přidáváme kladné skóre a opět je označíme příslušným „tagem“.

V rámci projektu Turris poté „greylist“ aplikujeme prostřednictvím firewallových pravidel na všechny routery v systému Turris a sledujeme statistiky provozu, který si routery s adresami na seznamu vyměnily. Cenné informace nám v tomto případě poskytuje plugin Flows nástroje ucollect, který sleduje i množství dat, která byla s protější stranou vyměněna. Takto se nám například podařilo odhalit proniknutí do sítě jednoho z uživatelů routeru Turris, který si s adresou v Albánii vyměnil několik desítek megabajtů dat prostřednictvím protokolu pro sdílení souborů – tato albánská adresa se přitom snažila připojit na několik stovek dalších routerů.

Výstupy z analýzy záznamů z firewallu nyní publikujeme pravidelně na adrese https://www.turris.cz/greylist – data jsou generována jednou týdně ve formátu CSV a kromě samotných adres jsou na seznamu uváděna i metadata o adrese – z jaké země je a do jakého AS (autonomního systému) v registru IANA patří – a seznam „tagů“, kterými byla adresa při klasifikaci označena. Tento seznam rozhodně není vhodné chápat jako seznam adres k blokování, ale může sloužit k dalšímu zpracování nebo sledování podezřelé aktivity ve Vaší síti.

Autor:

Komentáře (1)

  1. NONES říká:

    To je slušný počin. Tímto se získaná data z routerů stávají opravdu užitečnými.

Napsat komentář: NONES Zrušit odpověď na komentář

Všechny údaje jsou povinné. E-mail nebude zobrazen.

Tato stránka používá Akismet k omezení spamu. Podívejte se, jak vaše data z komentářů zpracováváme..