iptables config

[Therion]

Hallo,

ich würde gerne euer Feedback zu folgenden ipconfig Einstellungen haben.

Zunächst meine Anforderungen:

Ich habe eine Fritzbox 7141, zum einen gibt es das Lan mit mehreren Rechnern aus dem Ip Bereich 192.168.178.2-5 und dann noch das Wlan. Ich habe das Netz aufgetrennt, wie bei Wlan von Lan trennen beschrieben. Ich brauche keine Kummunikation zwischen den Rechnern.

Das Skript ist zum Teil aus http://www.freetz.org/wiki/packages/iptables zusammengesetzt, dann noch aus Wlan von Lan trennen inspiriert. Aber ich habe auch einiges geändert, wie man leicht sehen wird, also los geht es:

#Leere die Ketten
iptables-F

# Verwerfe erstmal alles
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# # # Regeln für FORWARD

iptables -A FORWARD -p tcp ! --syn -m state --state NEW -j DROP 				#Verhindern dass die Statustabelle überflutet wird von ACK
iptables -A FORWARD -p tcp  -o dsl -m multiport --dport 20,21,80,110,443,465,993,995,1863,5060 -j ACCEPT	# Erlaubter tcp Verkehr ins Inet
iptables -A FORWARD -p udp -o dsl -m multiport --dport 53,67,68,80,123,5060 -j ACCEPT		# Erlaubter udp Verkehr ins Inet
iptables -A FORWARD -p icmp -o dsl -j ACCEPT						# Ping ins Inet erlauben
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -j DROP								#Rest verwerfen (LAN+WLAN)

# # # Regeln für die Fritzbox

iptables -A INPUT -p tcp --dport 53 -j ACCEPT					#DNS-Server
iptables -A INPUT -p udp --dport 53 -j ACCEPT					#DNS-Server
iptables -A INPUT -p udp -s 0.0.0.0 -d 255.255.255.255 --sport 68 --dport 67 -j ACCEPT 		# DHCP Anfrage
iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT                 				# LOCALHOST
iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT                         				# LAN
iptables -A INPUT -s 169.254.0.0/16 -i lan -j ACCEPT                  				# EMERGENCY LAN
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 5060 -j ACCEPT                       				# VoIP
iptables -A INPUT -p udp --dport 5060 -j ACCEPT                       				# VoIP
iptables -A INPUT -j DROP                                             					# PARANOIA IN

iptables -A OUTPUT -d 192.168.0.0/24 -j ACCEPT                         		 		# Allow LAN
iptables -A OUTPUT -d 224.0.0.1/24 -j ACCEPT                          		 		# UPnP
iptables -A OUTPUT -d 239.255.255.250 -j ACCEPT			 		# UPnP
iptables -A OUTPUT -d 127.0.0.1 -j ACCEPT                            		 		# Local Host
iptables -A OUTPUT -p udp -m multiport --dport 53,123,5060 -j ACCEPT  	 		# DNS, TIME, VoIP
iptables -A OUTPUT -p tcp --dport 80 -d 63.208.196.0/24 -j ACCEPT     	 		# DynDNS
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT      		# stateful conntrack
iptables -A OUTPUT -d 212.42.244.73 -p tcp --dport 80 -j ACCEPT       	 		# Plugins Server AVM Benötigt für firmware update über inet
iptables -A OUTPUT -p tcp --dport 5060 -j ACCEPT                      				# VoIP
iptables -A OUTPUT -j DROP                                             				# PARANOIA OUT

#Regeln zum Verhindern eines NMAP-Scan

iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,URG,PSH \
             -j LOG --log-prefix "NMAP-XMAS SCAN:" --log-tcp-options --log-ip-options 
iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j LOG \
             --log-prefix "NMAP-NULL SCAN:" --log-tcp-options --log-ip-options 
iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST \
             -j LOG --log-prefix "SYN/RST SCAN:" --log-tcp-options --log-ip-options 
iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,FIN SYN,FIN \
             -j LOG --log-prefix "SYN/FIN SCAN:" --log-tcp-options --log-ip-options 

iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP 
iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j DROP 
iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j DROP 
iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

Ich wollte die Regeln bei FORWARD nicht ständig für jede IP im privaten Netz wiederholen, also hab ich einfach keine Einschränkungen gemacht an die Source gemacht und nur festgelegt, dass das Ausgabeinterface dsl sein muss? Ist aber schwer geraten, denn ifconfig -a im Rudishell hat mir garkein dsl Interface angezeigt. Ein Input Interface habe ich nicht angeben, da ich sonst die Regeln einmal für wlan und einmal für lan schreiben müsste. Es soll ja für beides gelten. Stellt sich nur die Frage nach den Nebenwirkungen, ist das wirklich sicher? Es sollen ja eigentlich nur ausgehende Verbindungen erlaubt sein, ein Server betreibe ich nicht.

Wäre das nicht besser:

iptables -A FORWARD -m state --state NEW -p tcp  -o dsl -m multiport --dport 20,21,80,110,443,465,993,995,1863,5060 -j ACCEPT

Also durch das -m state --state NEW drückt man doch explizit aus, dass es sich um ein Aufbau handelt. Der Rest müsste doch von conntrack erledigt werden.

Ich habe folgenden Typ von Regeln drin:

iptables -A FORWARD -j DROP

Ist das nicht eigentlich überflüssig? Ich setze ja default auf Drop. Kann das der Performanz schaden?

DAs verstehe ich nicht so recht:

iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT                         				# LAN
iptables -A INPUT -s 169.254.0.0/16 -i lan -j ACCEPT                  				# EMERGENCY LAN

bzw.

iptables -A OUTPUT -d 192.168.0.0/24 -j ACCEPT                         		 		# Allow LAN

Was muss ich da anpassen, hmm.

Ohje soviele Fragen, bin halt neu auf dem Gebiet, ich hoffe ihr verzeiht mir.

Vielen Dank schonmal,

Therion

 

[Therion]

Also die Mangle Tabelle scheint nicht da zu sein, bekomme Fehlermeldung

iptables v1.4.1.1: can't initialize iptables table `mangle': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

Habe insmod bzw. modprobe iptables_mangle probiert in modules bzw. rc.custom.

Aber vermutlich wurde das Packet von makeconfig beim erstellen der Firmware nicht eingebunden, hatte nur das default gewählte genommen. Hm, irgendwie blöd jetzt die ganze Firmware nochmal machen oder geht das auch anders?

Forward hab ich doch getrennt in eth0 und lan, das funktioniert auch, schon getestet.

Die Input und Output Ketten haben noch nen Fehler, weil danach komme ich ganricht mehr aufs Freetzbox Interface mehr. Zum Glück ist iptables nach Stecker ziehen wieder auf aus und man hat wieder Zugriff.

Wie stellt man es ein, dass iptables beim booten gestartet wird? und was passiert, wenn man sich selber mal per Regeln aussperrt, gibt es ein sicheren Weg, wie man an die Box immer dran kommt?

Die Sicherheitsregeln habe ich jetzt erstmal außen vor gelassen. Sowas ist toll:

# iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT 					# Schutz vor "Syn-Flood-Attacken"

Aber das Modul ipt_limit fehlt mit Sicherheit auch, so dass er das nicht verstehen wird.

Hm, wie bekomme ich die benötigten Module rein, arghs.

 

[Silent-Tears]

Die nötigen Module wirst du per Menuconfig und erneutem make und dem anschliessendem Flashen auf die Box bekommen. Alles andere wird für "Ottonormaluser" etwas viel des guten.

 

[Therion]

Ah okay, schonmal vielen Dank, hm vielleicht mache ich die Firmware dann doch nochmal neu.

Ich denke auch, dass die Probleme mit conntrack dadurch auftretten, das die Liste zu groß wird. Ich muss also sehen, dass ich die Liste klein halte, deswegen z.B. auch das:

-A FORWARD -p tcp ! --syn -m state --state NEW -j DROP

Ansonsten habe ich gelesen, dass man Timeout Werte anpassen kann, nachdem eine Verbindung wieder gelöscht wird aus der Verbindungstabelle. Werde mir das mal genauer ansehen, dann kann ich das gleich mit reinbauen.

Ich habe im Inet irgendwo gelesen, dass bei 16MB Ram default-mässig 1024 Verbindungen verwaltet werden können. Das ist nicht soviel denke ich mal, muss echt schaue, dass die Liste sauber bleibt.

 

[cuma]

Die Probleme mit conntrack treten auf, sobald das Modul geladen ist

 

[Therion]

Hm, wie kann man bei menuconfig conntrack abwählen? Selbst ohne cgi werden packete mit conntrack automatisch eingebunden.

Oder reicht es wenn man keine conntrack Regeln schreibt?

 

[cuma]

Manch' andere Module benötigen conntrack!

 

[Therion]

Also ich habe jetzt iptables leider wieder auf Eis gelegt, schade. Aber nachdem ich das alles hier im Forum gelesen habe, zweifel ich an der Stabilität danach. Einen 7270 habe ich leider nicht, da hast du ja geschrieben, dass contrack läuft.
Gilt das auch für den kleineren Bruder?

 

[cuma]

Anscheinend hast du nicht richtig gelesen und es gibt es auch nichts zu zweifeln. Was Probleme bei deiner Box verursacht steht oben. IPtables setzt außerdem kein conntrack voraus, sondern umgekehrt

 

[Therion]

Hallo, ja meinte es so wie du gesagt hast, bei allen außer dem Gerät 7270 funktioniert conntrack offensichtlich nicht stabil. Iptables ohne conntrack war mir zu mühselig, da muss man autoloade rabschalten und irgendwie die module einzeln laden ohne conntrack. Habe keine Anleitung gefunden und daher lasse ich es wohl einfach sein. Schade, weil Iptables eigentlich an sich ne schöne Sache sind.

Aber andererseits habe ich ja noch die avm Firewall die stateful arbeitet und eine Desktop Firewall dazu, das sollte als Schutz reichen, denke ich mal.

Vielen Dank Cuma für deine Anmerkungen.

 

[cuma]

Ein Modul lädt man (wie bei allen Linuxen) mit "insmod" oder "modprobe". Dann gäbe es noch "lsmod" und "rmmod"

 

[alpha1974]

Hallo, ja meinte es so wie du gesagt hast, bei allen außer dem Gerät 7270 funktioniert conntrack offensichtlich nicht stabil.

Das hängt von der individuellen Arbeitsumgebung / Konfiguration ab. Bei mir läuft iptables auf einer 7170 mit conntrack absolut problemlos (über Wochen ohne Reboots), solange das wlan nicht aktiviert ist. Anscheinend enthält das closed source tiap-Modul einen Fehler, der Reboots auslösen kann (die kfree calls müssten über dev_kfree_skb_any laufen, sonst kann ip_nat_cleanup_conntrack Probleme bekommen bei local_bh_enable-Aufrufen und irgendwann läuft der Speicher doch voll).

Ließe sich leicht beheben, aber das tiap-Modul ist closed source. Auf meine Fehlermeldung hin hat mir AVM zwar immerhin ein T-Shirt geschickt, aber den Fehler leider bislang nicht behoben....

 

[Therion]

Ja schade dass avm das nicht mal korregiert. Aber auf wlan kann ich auch nicht verzichten und spontane reboots wären naja nicht so toll.

 

[cando]

...

Ich habe folgenden Typ von Regeln drin:

iptables -A FORWARD -j DROP

Ist das nicht eigentlich überflüssig? Ich setze ja default auf Drop. Kann das der Performanz schaden?

Es ist überflüssig, wenn default auf DROP steht.

...
DAs verstehe ich nicht so recht:

iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT                         				# LAN
iptables -A INPUT -s 169.254.0.0/16 -i lan -j ACCEPT                  				# EMERGENCY LAN

bzw.

iptables -A OUTPUT -d 192.168.0.0/24 -j ACCEPT                         		 		# Allow LAN

Was muss ich da anpassen, hmm.

Die Input Regeln aus dem Privaten Netz erlauben Dir mit der Box zu kommunizieren. Wenn die nicht da wären und default auf DROP steht, erreichst Du die Box nicht mehr aus dem LAN. (Web-IF, Freetz, Telnet, DHCP, DNS, NTP, SSH, FTP...) Mit geeigneten Regeln kannst Du z.B. nur bestimmte PC für die Administration der Box zulassen und alle anderen im LAN aussperren. DHCP und DNS solltest Du auf jeden Fall im LAN zulassen, sonst geht nichts mehr.

Emergency LAN ist die alternative Box Adresse, um z.Z. ein kaputt konfiguriertes System per Software wiederbeleben zu können (z.B. wenn Du DHCP abgeschaltet und LAN Adressbereich vergessen hast...).

Die output Regel in das LAN-Segment bewirkt, dass die Box selbst Geräte im LAN kontaktieren kann (z.B. Netzlaufwerke mounten etc.) Ohne conntrack liefert die so formulierte Regel die Antwortpakete zur input Regel.

Viele Grüße

Cando

 

[Therion]

Danke für die Erläuterungen!