Dne 19. 4. 2015 v 13:48 Dan Lukes napsal(a):
On 04/19/15 13:22, Zbyněk Burget:
+Limiting icmp unreach response from 252 to 200 packets/sec
+Limiting icmp ping response from 211 to 200 packets/sec
+Limiting closed port RST response from 301 to 200 packets/sec
Nedokazu odhadnout, jak dalce neco takoveho zatezuje sit.
Prave jsi to udelal. Evidentne ji to zatezuje natolik zanedbatelne, ze
te to nikdy nevyburcovalo ke zkoumani veci alespon natolik
povsechnemu, ze bys dopad dokazal odhadnout lip.
No jo, ale to, ze jsem se tim zatim nezabyval neznamena, ze to nejaky
dopad treba i na vykon routeru mit nebude. Zatim jsem to prechazel s
tim, ze to tak proste je, jen se mi to nelibi. Dnes jsem si rekl, ze se
na to zkusim podivat, jen poradne nevim, jak realne zjistit, jestli to
nejaky dopad muze mit. Proto jsem se nejdriv ptal, jestli to nekdo nejak
resi (proto, ez to realne vliv na vykon/propustnost ma/muze mit/ma
obcas/utocnik pozna, ze timhle smerem neco pokazi) a nebo to nikdo
neresi, protoze je to zanedbatelna cast provozu, resp. snaha o likvidaci
takoveho provozu by byla nakladnejsi, nez reseni mozne vznikle skody.
Jsem rad, ze se dozvim, ze se deje neco neobvykleho. Jenze to, co se
deje, se bojim, ze neobvykle neni :-( Takze by asi bylo nejjednodussi
proste tu hlasku vypnout (zajistuje jine sysctl). Na druhou stranu bych
se rad dozvedel, kdyby se nekdo snazil o nejaky DoS utok, kdyby mi
konkurence skenovala porty (bohuzel dva lidi v mem okoli jsou toho
schopni) apod.
Ty dve vety si proste protireci. Az se pro jednu rozhodnes, zarid se
podle toho ;-)
No prave - a ted, jestli to dilema resit a nebo prijmout stavajici stav,
jako fakt a neresit...
kdyz se divam na vnejsi iface, vidim, ze (prakticky) vse jde z
venkovni verejne
Coz neni az takovy prekvapeni, tak to, s vyjimkou situace, kdy je
ovnitr site jeden nebo vice zavirovanych stroju, obvykle byva.
Jj, jasne - ja to myslel tak, ze diky NATu nepoznam, jestli jde o provoz
z vnitrni site nebo ode mne samotneho.
Pri kontrole vnitrniho provozu ale vidim, ze RST / ICMP unreach packetu
putuje obousmerne pomerne vysoke mnozstvi. Tedy odpovidaji takto klienti
na vnitrni siti na pozadavky zvenci = pozadavek prosel NATem a rovnez
prichazeji takto odpovedi zvenci na pozadavky mych klientu.
Moje otazka se tedy ted otaci smerem, jak dalece regulerni je tento
provoz. Tedy vim, ze regulerni je, ale jak bezny by mel byt. TCP RST je
prece "nasilne" ukonceni spojeni, ktere by se asi bezne dit nemelo. TCP
spojeni by melo spravneji koncit FIN packetem, ne? Dival jsem se, ze
tyhle RST packety jsou nejcastejsi z/na nejaky facebookovy server (ten
facebook je opravdu mor). Tech RST packetu je ale nejak moc. Takze bud
jsem presne nepochopil jejich uplny vyznam nebo nechapu, co se u celkem
dost vysokeho poctu klientu deje.
Kdyz se divam na vnitrni iface, tak tam zase samozrejme nevidim utoky
zvenci. Bohuzel asi jednoduse nejde nastavit tcpdump tak, abych videl
pouze provoz, ktery je urcen pro muj router a nejedna se o provoz, ktery
projde NAtem :-(
NATem projde vsechno, co do nej 'divert' pravidlo firewallu zazene. CO
se tyce prichoziho provozu, tak obvykle uplne vsechno ...
Ja do natu nestrkam jen provoz pro verejne adresy. Jinak tam jde opravdu
vsechno.
Takze muj predpoklad byl spravny a tenhle provoz o nejake vyssi
frekvenci bude prakticky jiste neco, co by v siti byt nemelo - tedy pro
pripad, ze je to provoz generovany routerem
Nejsem si jisty, jestli si rozumime - ty pakety jsou generovane
routerem, ale jsou odpovedi na prichozi paket, ktery routerem
generovany neni.
Podstata, jak to funguje, je mi známa :-) Jen nektere podrobnosti mi
obcas unikaji, resp. mi trva dyl, nez si je uvedomim. V sitarine jsem
samouk, i kdyz nejakych 15 let celkem a 11 let vlastni site uz nejake ty
vedomosti prineslo :-)
A s ohledem na NAT to v nekterych pripadech muze byt odpoved na paket,
ktery prisel v souvislosti s drivejsi komunikaci smerovane na nejaky
vnitrni stroj - kterazto session uz ale davno zanikla. NAT uz o ni
nevi, nevi tedy kam "dovnitr" paket poslat, necha ho tedy nezmemeny,
takze paket dostane ke zpracovani jadro routeru - a to ho zamitne jako
paket neexistujici session.
Jo - a tohle je presne to, co mi v prvnim okamziku nedocvaklo. Vypada
to, ze drtiva vetsina tech ICMP unreach je odpoved na nejaky UDP provoz,
ktery uz neni v NATu a proto na nej odpovi kernel (a nebo se opravdu
jedna o nejaky utok) a nebo v NATu je, ale uz na nej neodpovida klient
uvnitr site a pak ty ICMP posila az klient. Bohuzel jsem se v nekolik
apripadech, kdy jsem to prohlizel, setkal s tim, ze prichazely packety,
odchazely ICMP unreach a zdroj packetu to evidentne nezajimalo a provoz
posilal stale dal. V pripade vyse zmineneho facebookoveho serveru to
bylo dokonce tak, ze od facebooku prisel TCP (https) packet, za 3sec.
(neni to moc pozde?) klient odeslal ICMP unreach odpoved a facebook za
dalsich cca 10 sec. poslal dalsi podobny (nebo stejny, obsah jsem
nezkoumal) TCP (https) packet a opet dostal unreach odpoved. A tohle
trvalo nekolik minut. Kdyz tech lidi u mne na siti na facebooku sedi
soucasne 200, tak verim tomu, ze uz to dokaze vygenerovat provoz, ktery
jsem povazoval za neobvykly.
Pokud bych dokazal zjistit IP adresy takovych utocicich stroju, asi
bych je rovnou
zarizl na firewallu.
Seznam se pomerne casto meni, v pripade UDP mohou byt zdrojove adresy
bez problemu padelane, takze si brzo zablokujes i uzitecny stroje,
fireall ti nakonec nabobtna tak, ze ti bude zpomalovat beznou
komunikaci ...
Delal jsem to tak, ze se utocici stroje davaly do IPFW tabulky, ktera je
na firewallu zariznuta a z tabulky se po cca mesici mazou. Takovy seznam
mel drive kolem 250 polozek, nedavno jich tam bylo kolem 2000 a dnes se
opet smrskl na 500. Kdyz jich bylo 2000, tak jsem pravidlo z firewallu
odstranil, aby to pripadne nezpomalovalo, ted nedavno jsem ho tam vratil
zpet. Zda se, ze to na provoz zadny zasadni vliv nema. Ale tohle jeste
musim dukladne proverit.
To se muzes rovnou od site uplne odpojit. Podobny vysledek, min prace.
;-)
Mas recht! Porad rikam, ze se na to vykaslu - cesky lidi jsou vecne
nespokojeny uz z principu, porad se neco kazi, porad to chce investice,
porad se ucit neco noveho... Furt si rikam, jak jednoduchy zivot maji
treba zemedelci nebo popelari - makaj na cerstvym vzduchu, nenici si oci
u monitoru, nekrivi si zada sezenim... ;-)
Zbyněk Burget
Mlýnská 397
798 26 Nezamyslice
tel: 588 580 000, 739 930 931
http://www.burgnet.cz
IČ: 606 88 220; DIČ: CZ7210184674
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
