Sicherheit von ESTABLISHED,RELATED

[feldmaus]

Guten Abend,

ich bin gerade dabei meine Firewall-Regeln auf Mldonkey abzustimmen. Dabei habe ich bemerkt das meine Firewall auf einen Mldonkey-Server abgestimmt ist, der auch auf meinem Server/Router läuft, allerdings nicht wenn dieser auf einen Client in meinem Netzwerk läuft. Den Fehler habe ich denke ich schon ausgelotet.

In meinen Regeln nutzte ich die Erweiterung state um Packete die als NEW oder INVALID gekennzeichnet sind, und in meiner INPUT- oder FORWARD-Chain landen, zu verwerfen.

Hier ein kurzer Ausschnitt meiner selbstdefinierten state-Chain mit iptables -L -n -v :
34477

Es werden ja größtenteils neue Verbindungen von anderen Clients zu meinem Client und Server aufgebaut. Ich würde ja gerne die Zustände ESTABLISHED und RELATED verwenden, nur weiß ich nicht wie sicher das ganze ist???

Hier noch ein Ausschnitt meiner Log-Datei wo man sehen kann das Packete verworfen werden:

Code: Alles auswählen

Apr  2 01:18:03 feld-server kernel: [23172.652749] Unerwuenschte Verbindung: IN=ppp0 OUT= MAC= SRC=91.194.40.23 DST=92.76.232.84 LEN=44 TOS=0x00 PREC=0x00 TTL=53 ID=17861 DF PROTO=TCP SPT=52478 DPT=4662 WINDOW=5840 RES=0x00 SYN URGP=0

Das andere Problem ist, dass ich mir nicht sicher bin ob mein Rechner weiß ob er das Paket nun an meinen Server oder an meinen Client weiterreichen soll? Ich denke aber das dies mit der Nutzung der Zustände ESTABLISHED und RELATED funktionieren sollte. Was meint Ihr?

Weiterhin weiß ich nicht wo in meiner state-CHAIN Regeln mit ESTABLISHED und RELATED einbauen sollte? Zur Zeit sehen die Regeln für meine state-CHAIN wie folgt aus:

Code: Alles auswählen

	iptables -A states -p icmp --icmp-type 8 -j RETURN # Sollen weiter verarbeitet werden, daher RETURN
	iptables -A states -m state --state NEW,INVALID -j LOG --log-prefix "Unerwuenschte Verbindung: "
	iptables -A states -m state --state NEW,INVALID -j DROP
	iptables -A states -j RETURN	# Ruecksprung, falls noch nicht verworfen

Grüße Markus

[Danielx]

Vielleicht hilft dir das "Iptables Tutorial" weiter, z.B. das Kapitel "The state machine":
http://www.frozentux.net/iptables-tutor ... ATEMACHINE

Gruß,
Daniel

[suno]

Es werden ja größtenteils neue Verbindungen von anderen Clients zu meinem Client und Server aufgebaut. Ich würde ja gerne die Zustände ESTABLISHED und RELATED verwenden, nur weiß ich nicht wie sicher das ganze ist???

Die gesamte "Sicherheit" deines Systems wird dadurch nicht ueberwiegend bestimmt werden da "Sicherheit" eine Vielzahl von Dingen/Aktionen/Prozessen beinhaltet.

Um exakt auf die Frage antworten zu koennen muesstest du eine exakte Frage in Bezug auf ESTABLISHED und RELATED stellen. Sieh einmal hier nach damit du die Theorie hinter connection tracking des Linux Kernels verstehst.

http://sunoano.name/ws/public_xhtml/fir ... n_tracking
http://sunoano.name/ws/public_xhtml/fir ... tate_match

Das andere Problem ist, dass ich mir nicht sicher bin ob mein Rechner weiß ob er das Paket nun an meinen Server oder an meinen Client weiterreichen soll? Ich denke aber das dies mit der Nutzung der Zustände ESTABLISHED und RELATED funktionieren sollte. Was meint Ihr?

Hm ...?

mldonkey laeuft auf derselben Maschine auf welcher du das Netfilter Framework (Iptables sind die Userspace utils) verwenden willst nein?

Weiterhin weiß ich nicht wo in meiner state-CHAIN Regeln mit ESTABLISHED und RELATED einbauen sollte?

Hm, ohne Details zu kennen klingt das fuer mich seltsam denn soetwas wie eine "state" chain sollte es eigenlich nicht geben. Du hast die chains die Netfilter bereitstellt und welche verschiedene Aufgaben und Faehigkeiten haben. Dementsprechend baust du "den Weg der Pakete durch deine Firewall auf".

http://sunoano.name/ws/public_xhtml/fir ... ains_rules

Meine Seite hat Examples. Du kannst dich auch an einem Skript orientieren welches ich selbst verwende (auch auf einer Maschine wo mldonkey laeuft) http://github.com/sunoano/bash/blob/mas ... ket_filter Das Skript verwenden wir auch im Hosting Bereich in einer modifizierten und komplexeren Variante fuer ueber 286k managed Webhosts.