Administrace komentářů

napríklad privátne adresy nemajú čo hľadať na rozhraní, ktoré ide do netu

To neplatí obecně. IPSec je jedna z důležitých výjimek.

(Ať tak nebo tak, IPv4 se svými „privátními“ adresami je něco jako mor, protože kvůli němu přestal fungovat Internet „tak, jak měl“ a zvítězily pak pochybné technologie typu Skype, které celý uměle vytvořený problém „řeší“.)

Základní technika obrany proti svinstvu z netu (na které všechno ostatní stojí) je aktuální kernel. Pokud jde o ip{,6}tables, filtrovat se dá téměř všechno, ale v každém případě by mělo být povolené ICMP{v4,v6}. Dají se nastavit omezení na frekvenci a typ zpráv, ale bez ICMP může docházet ke spoustě ošklivých jevů jak pro klienty serveru ve vnějším Internetu, tak pro stroje ve vnitřní síti, pro které server třeba slouží jako router. Jde zejména o MTU. Když je někde po cestě menší MTU než lokální, uživatelům se pak třeba nestahují z některých serverů stránky, případně se jejich stahování pokaždé na pár minut zasekne.

Pravidla s typy TCP paketů by pravděpodobně měla být vhodně seřazená a na vhodném místě v řetězci oddělená něčím jako

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

To oddělí kombinace flagů, které jsou podezřelé vždy, od těch, které se v navázaném spojení můžou vyskytovat. To všechno by pak mělo být před přijímacími pravidly pro různé konkrétní protokoly nad TCP. Otázkou zůstává, jestli má smysl „závadné“ kombinace flagů takto fitrovat. Nesmyslné kombinace musí zahodit přímo TCP stack v kernelu. (Kdyby na něj nebylo spolehnutí, Internet by byl velmi nebezpečným místem.) Jediné vysvětlení by mohlo být, že správce u nějaké konkrétní služby neočekává jisté typy chování (protistrany), takže si může dovolit některé zvláštnosti odfiltrovat. Nicméně nepřipadá mi, že by se něco takového obecně hodilo jako globální nastavení pro všechny protokoly nad TCP.

Ochrana proti SYN floodingu je v kernelu zabudovaná pro IPv6 i IPv4 a ve většině případů není nutné vymýšlet na to nějaká explicitní pravidla. Přímé filtrování na základě frekvence se sice na první pohled může jevit jako dobrý nápad, ale nějaký globální limit nadělá nakonec víc škody než užitku, protože jeden útočník útočící na jednom portu může klidně omezit použitelnost všech ostatních služeb, když se mu zlíbí. Přinejmenším by mělo existovat jiné nastavení pro SSH (velmi nízká frekvence i burst) a jiné třeba pro HTTP, DNS (ano, i tam dojde na TCP, třeba u DNSSEC) či obecně pro protokoly, kde se větší bursty dají očekávat. Rozhodně tady nebude fungovat one size fits all konfigurace; server pak může navenek vypadat jako nespolehlivý a každou chvíli offline.