Jednog prekrasnog proljetnog večera, kada se nije htjelo ići kući, a nepokolebljiva želja za životom i saznanjem svrbila je i gorjela kao užarena željeza, pojavila se ideja da pregledam zavodljivu opciju na firewallu pod nazivom "IP DOS politika«.
Nakon uvodnih priprema i upoznavanja s priručnikom, postavio sam u načinu Pass-and-Log, da bih uopće vidio ishod i sumnjivu korisnost ovog podešavanja.
Nakon nekoliko dana (da se statistika nakupi, naravno, a ne zato što sam zaboravio) pogledao sam u logove i, plešući na mjestu, zapljeskao dlanovima — skupilo se zapisa do iznad glave. Činilo bi se, što je lakše — uključi politiku u način blokiranja svih koji spamiraju, skeniraju, postavljaju half-open sesije s banom na sat i spavaj mirno s spoznajom da je granica zaključana. Ali 34. godina života prešla je mladenački maksimalizam i negdje na stražnjem dijelu mozga začuo se tihi glasić: "Hajde da otvorimo oči i pogledamo čije adrese naš omiljeni firewall prepoznaje kao zle spamera? Tako, u skladu s ludostima."
Počinjemo analizirati prikupljene podatke s liste anomalija. Prolazim adrese kroz jednostavni skript Powershell i oči mi zapnu za poznate znakove google.
Trljam oči, trepćući pet minuta, kako bih se uvjerio da mi se ne priviđa — doista na listi onih koje je firewall smatrao zlim spamerom, tip napada — udp flood, adrese pripadaju korporaciji dobra.
Češkam se po zatiljku, istovremeno postavljajući na vanjskom sučelju hvatanje paketa za kasniju analizu. U glavi mi prolaze duge misli: "Kako to, nešto zaraženo u opsegu Googlea? I to sam otkrio ja? Pa to su, to su — nagrade, počasti i crveni tepih, i svoje kasyno s blackjackom i, znate već…"
Analiziram dobivenu datoteku Wireshark-om.
Da, doista s adrese iz opsega Google šalju UDP pakete s 443 porta na nasumični port na mom uređaju.
Ali, stani malo… Evo protokol se mijenja s UDP na GQUIC.
Semen Semenovič…
Odmah se sjetim izlaganja s HighLoad Aleksandra Tobolja «UDP protiv TCP ili budućnost mrežnog stoga" ().
S jedne strane, dolazi do blagog razočaranja — ni ti, gospodaru, lovorika, ni počasti. S druge strane, problem je jasan, ostaje razumjeti kamo i koliko kopati.
Nekoliko minuta razgovora s Korporacijom Dobrote – i sve dolazi na svoje mesto. U pokušaju poboljšanja brzine isporuke sadržaja, kompanija Google još 2012. godine najavila je protokol QUIC, koji omogućava uklanjanje velikog broja nedostataka TCP-a (da, da, da, u ovim člancima – i govori se o potpuno revolucionarnom pristupu, ali, budimo iskreni, svi želimo da se slike mačaka učitavaju brže, a ne sve te vaše revolucije svesti i napretka). Kako je pokazalo daljnje istraživanje, mnoge organizacije trenutno prelaze na ovakav način isporuke sadržaja.
Problem u mom slučaju, a verujem i u mnogim drugim, je u tome što na kraju dolazi previše paketa, a vatrozid ih percipira kao spam.
Rešenja su se pokazala kao malo:
1. Dodati u izuzetak za DoS politiku na vatrozidu opseg adresa Google. Pri samoj pomisli na opseg mogućih adresa, oko je počelo nervozno da trepće – ideja je odložena kao besmislena.
2. Povećati prag aktivacije za udp flood politiku – takođe nije rešenje, a šta ako nekome stvarno padne na pamet da napadne.
3. Zabrana poziva iz unutrašnje mreže prema UDP na 443 spoljnom portu.
Nakon dodatnog proučavanja implementacije i integracije QUIC u Google Chrome prihvaćen je kao akcija poslednja opcija. Stvar je u tome što, svima omiljeni bezobzirno (ne razumem zašto, veću bi težinu imala siva mačka Firefox-ova njuška koja bi dobijala za potrošene gigabajte RAM-a), Google Chrome prvo pokušava uspostaviti vezu koristeći svoj iscrpljeni QUIC, ali ako čudo ne uspe, vraća se proverenim metodama kao što su TLS, iako se srami toga.
Kreiramo na vatrozidu zapis za uslugu QUIC:
Podesimo novo pravilo i stavimo ga negde više u lancu.
Nakon aktiviranja pravila, na spisku anomalija mir i tišina, osim za stvarno zle prestupnike.
Hvala svima na pažnji.
Korišćeni resursi:
1.
2.
3.
4.
Izvor: habr.com
