sysctl net.inet.icmp.icmplim

Dan Lukes dan at obluda.cz
Sun Apr 19 17:32:34 CEST 2015


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





More information about the Users-l mailing list