sysctl net.inet.icmp.icmplim

[Dan Lukes]

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.


> 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 ;-)

>> Musel byses bliz podivat na to co ty ICMP/RST vyvolava abysis moh'
>> udelat nejakej nazor na aktualni pricinu.
>
> Nad tim prave premyslim, jak ten provoz zanalyzovat.

No zachytis nejaky ten ICMP/RST paket a podivas se do nej. V nem je 
napsano na co to je odpoved ...

Teda, krome pripadu 'ping', kde musis zachytavat uz prichozi paket.

> 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.

> 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 ...

Neco ale projde nezmenene ...

> 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.

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.

>>> Takhle to ale na mě dělá dojem, že to limituje i packety, které skrz
>>> router prochází z vnitřní sítě.
>>
>> Nenaznacil's co tvuj dojem vyvolava, takze tezko ti to rozmlouvat ;-)
>
> Muj dojem vyvolala frekvence tech RST / unreach packetu

Nejdriv musis zjistit na co jsou ty pakety odpovedi. Ztaci si do souboru 
ulozit par minut veskery komunikace a pak se na to podivat off-line. 
Myslim, ze ke kazdemu RST na ktery se podivas najdes o kousek vys paket, 
ktery prisel z venku a odpoved vyvolal.

> 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 ...

To se muzes rovnou od site uplne odpojit. Podobny vysledek, min prace. ;-)


Dan