On 04/19/15 15:16, Zbyněk Burget:
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.
O tom se neda az tak moc obecne rict. Proste si porid zaznam nekolika
minut provozu a podivej se na to, jake komunikace se tykaji.
Existujucu TCP spojeni lze regulerne uzavrit (FIN) nebo abortovat (RST).
Je na implementaci konkretniho serveru jak v te-ktere situaci uzavira
spojeni. Mozna tam mas neco/od tebe komunikuji nekam, co/kde se pouziva
RST celkem normalne.
Pokud na tvym pripojeni dochazi relativne casto k prichodu paketu v
"prevracenem poradi" nebo k jejich duplikaci, muze taky dochazet k
vzniku RST (kdyz opozdeny nebo duplikovany paket dorazi po regulernim
uzavreni spojeni).
A pak samozrejme existuji mene legitimni duvody. To se ale neda
rozhodnout "od stolu", budes do toho blata muset jit strcit ruce ;-)
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.
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.
Blbe nastaveny firewall (blokovani vsech ICMP neni nijak statisticky
nevyznamna chyba v nastaveni firewallu), zamer (ICMP paketem s padelanou
zdrojovou adresou lze nekomu jinemu rusit legitimni spojeni, pokud ty
ICMP zamerne nezablokuje), v pripade UDP pak i blbe napsana aplikace, ...
... urcite se najde jeste par dalsich moznosti.
Pokud bych dokazal zjistit IP adresy takovych utocicich stroju, asi
bych je rovnou zarizl na firewallu.
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.
Metod jak tohle resit je spousta a tahle je v tomhle konkretnim pripade
zrejme dobra. Ale musis si rozmyslet, jestli "ignorovat to" prinasi
takovy potize, aby to omlouvalo cas potrebny na "neignorovat to".
Tohle hodnoceni zalezi na spouste okolnosti, z nichz rada je
subjektivnich, cizm chci rict, ze si to musis posoudit sam.
Furt si rikam, jak jednoduchy zivot maji treba zemedelci nebo popelari - makaj
na cerstvym vzduchu, nenici si oci u monitoru, nekrivi si zada sezenim... ;-)
A ty zas evidentne naprosto netusis o cem mluvis ... ;-)
Po nekolika hodinach v traktoru me ty zada docela bolej, zatimco z
lezeni u pocitace se mi to vetsinou nestava.
Dan
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
