Uvědomuji si, že existují různé názory, ale jedním z hlavních postojů lidí, kteří opravdu vědí o sítích a zabezpečení, je, že většina těchto pravidel iptables/sysctl je nadbytečná, ne-li škodlivá pro vás a síť. Někteří vás budou agresivně kritizovat za to, že bezdůvodně porušujete standardní chování. Několik příkladů:
-
Standardním chováním TCP/IP je ODMÍTNUTÍ, aby partner získal nějakou nápovědu o tom, co se děje. Možná někdo právě zadal špatně URL nebo váš administrátor počítá hostitele nebo se někdo chce připojit k vašemu hernímu serveru, ale zadal špatný port. S DROP dostávají pouze nejasné a nepříjemné časové limity.
-
Není potřeba zahazovat neplatné nebo poškozené pakety, všechny tyto útoky jsou staré deset let. Vývojáři linuxového jádra jsou mnohem aktuálnější než vy, pokud jde o to, které druhy paketů jsou platné a které ne. "A co budoucí nedostatky", někteří by mohli namítnout. Jak víte, že budoucí chyba bude v obslužné rutině TCP a ne v analyzátoru TCP iptables?
-
Většina nastavení sysctl je výchozí. Pokud nejsou, obvykle to má svůj důvod. Proč např. zakázat odesílání přesměrování? Považuji za velmi užitečné být informován od partnera, že moje směrování je špatné, i když bych nikdy nereagoval ("accept_redirects", default=0) automaticky.
-
S vašimi log_martians a dalšími pravidly protokolování doufám, že máte také kvótu na /var/log, nebo bude velká zábava vzdáleně zaplňovat váš disk, což obvykle zabíjí vaše služby/aplikace. Kromě toho byste měli použít limit rychlosti pro protokolování, jinak by někdo mohl naplnit kvótu, aby vám zabránil vidět pokusy bruteforce SSH hesla v auth.log nebo jiných věcech. Opravdu čtete tyto protokoly na ploše? Doporučuji logcheck.
-
Zdá se, že blokujete ICMP. Kromě zmíněného problému s DHCP to také zabraňuje zjišťování PMTU. Bez PMTUD získáte podivné chování, když budete systém používat v místech s DSL připojením nebo jiným síťovým nastavením. Některé pakety budou prostě zahozeny a nikdo vám neřekne proč.
-
Filtrování odchozích paketů je poněkud nejasné. nevěříš si? Obecně byste neměli spouštět žádné programy, kterým nemůžete důvěřovat. Komoditní operační systémy většinou nejsou schopny izolovat tyto programy před odposloucháváním nebo dokonce manipulací s daty jiných programů (např. útoky na časování mezipaměti)
-
Chcete-li mít SYN, potřebujete NOVÉ pakety. To se přeruší, pokud TCP spojení pokračuje po uplynutí časového limitu příslušného stavu v iptables. Nejste si jisti, jaké jsou výchozí časové limity, ale nějaký chlápek ze síťového filtru na to varoval.
Kdy by tedy měl mít počítač firewall?
-
Pokud se ve zprávách vyskytuje konkrétní útok, na který jsou zranitelné váš aktuální operační systém nebo servery, a jednou z doporučených rychlých oprav je pravidlo brány firewall.
-
Musíte spouštět určité služby, které neumožňují zabezpečenou konfiguraci. Většina ano a zbytek je nejlépe nahradit bezpečnými alternativami.
-
Máte složitější sítě s několika virtuálními počítači a/nebo rozhraními na ploše.
Prvním a nejdůležitějším nástrojem pro zabezpečení vaší sítě je aktualizace systému. Za druhé jsou zde netstat a nmap, které byste měli použít k nalezení a potvrzení toho, jaké služby používáte. Pak stačí zakázat ty, které nepotřebujete, nebo je omezit na 127.0.0.1.
Bonus, pokud jste dočetli až sem:Pakety jsou buď ZALOŽENÉ, SOUVISEJÍCÍ nebo NOVÉ, vše ostatní zahodíte. Pokud není nastaveno pouze SYN, zahodíte také NEW. Protože se zdá, že ESTABLISHED,RELATED kontroluje příznaky, jsou všechna pravidla --tcp-flags a také pravidlo -f nadbytečná. Totéž pro OUTPUT, ale protože pro OUTPUT stejně nejsou přijímány žádné pakety, na tom pravděpodobně nezáleží.
Byl bych opatrný při vytváření těchto součástí stejné sady pravidel pro zařízení v důvěryhodné síti a zařízení v DMZ. Použitím pravidel, která jste tam definovali, nebudete odpovídat na dotaz serveru DHCP (ICMP echo), zda je vaše IP adresa používána. To by mohlo vést k situaci duplicitní adresy.
Vytvořil bych dvě různé sady pravidel, které se použijí na každý scénář, něco jako to, co je uvedeno výše, je dobrý základ pro počítač s DMZ, ale vytváří určité problémy v typické síti LAN.
Také bych rozhodně doporučil přidat logování do marťanů, odchozí dropy, příchozí přerušení připojení atd. To může být zásadní pro řešení problémů a může to být užitečnější data pro vaše SIEM k jídlu.
Pro klientský počítač připojený přímo k internetu přes ppp je dobrým začátkem následující sada pravidel:
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp -j REJECT
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
ip6tables -A INPUT -j REJECT
- Umožňuje vše na interním místním rozhraní.
- Povoluje jakýkoli paket, který je odpovědí na paket, který odešlete. To zahrnuje pakety v rámci TCP spojení, odpovědi na UDP pakety, jako jsou malé DNS dotazy. U starého nešifrovaného protokolu FTP to zahrnuje datové připojení za předpokladu, že je načten soubor ip_conntrack_ftp
- Odmítnout všechny pokusy o otevření tcp připojení zvenčí
- Odmítnout všechny počáteční pakety udp (bez odpovědi).
Alternativně můžete v posledních dvou pravidlech použít -j DROP. Diskusi na toto téma naleznete v tématu Odmítnout pakety IP s chybou ICMP, nebo je prostě zahodit?