Arch Linux

iptables, verkehr auf zweiter netzwerkkarte beschränken

tofuwurst

hallo,

seit kurzem hängt mein rechner über zwei netzwerkkarten in zwei verschiedenen netzwerken. zum einen mein eigenes lokales (an eth0) und zum anderen ein seperates nur für die kinder (an eth1).

auf dem server laufen einige dienste (smb, privoxy, tvheadend, lighttpd, dovecot+roundcube...), allerdings möchte ich nicht das die kinder auf alle zugriff haben. deshalb möchte ich den netzwerkverkehr von eth1 mit iptables einschränken, so dass nur noch lighttpd (port 80) und privoxy (port 8118) zu erreichen sind.

folgendermassen sieht mein script aus:

#!/bin/sh

# FLUSH EVERYTHING
iptables -F

# SET POLICYS
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# LOOPBACK INTERFACE
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# SET FILTER FOR ETH0
iptables -A INPUT -i eth0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j ACCEPT

# SET FILTER FOR ETH1
iptables -A INPUT -i eth1 -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -o eth1 -p tcp --dport 80 -j ACCEPT

allerdings funktioniert es nicht wie erwartet. ich kann aus meinem lokalem netz weiterhin auf alle dienste zugreifen, aus dem netz der kinder bleibt mir aber jeglicher zugriff verwehrt.

wo liegt der fehler?

midan23

Hallo,

in den Regeln für ETH1 kann ein Browser eine Anfrage an den Webserver schicken, dieser möchte die Antwort allerdings nicht an Port 80 des Client-Rechners schicken, sondern an einen anderen, was durch die zweite Regel blockiert wird.

Versuch es mal so:

iptables -A INPUT -i eth1 -p tcp --sport 1024:65535 --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth1 -p tcp --sport 80 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT

mpausch

probier mal das

#!/bin/sh

# FLUSH EVERYTHING
iptables -F

# SET POLICYS
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Pakete erlauben, die zu bestehenden Verbindungen gehoeren
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# LOOPBACK INTERFACE
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# SET FILTER FOR ETH0
iptables -A INPUT -i eth0 -m state --state NEW -j ACCEPT

# SET FILTER FOR ETH1
iptables -A INPUT -i eth1 -p tcp --dport 80 -m state --state NEW-j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 8118 -m state --state NEW-j ACCEPT

tofuwurst

ok, der regelsatz von midan23 funktioniert so. danke :-)

der andere blockiert immernoch...

# Pakete erlauben, die zu bestehenden Verbindungen gehoeren
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

müsste hier nicht auch eine output regel angelegt werden?

mpausch

~~Normalerweise braucht's dafür eben keine separate OUTPUT-Regel.~~
Edit: ja, die braucht's (siehe späteres Posting)

Ich habe gesehen, dass ich bei

iptables -A INPUT -i eth1 -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 8118 -m state --state NEW -j ACCEPT

das Leerzeichen zwischen NEW und -j vergessen habe... Wurden evtl nur die letzten beiden Regeln nicht angenommen?
Das würde erklären, warum es nicht funktioniert.

Ansonsten muss ich das mal nachstellen, wenn ich wieder zu Hause bin

tofuwurst

das mit den leerzeichen hab ich korrigiert gehabt, es kommen trotzdem keine pakete durch.

mittlerweile sieht das script folgendermassen aus. funktioniert aber immernoch nicht richtig....

#!/bin/sh

# FLUSH EVERYTHING

iptables -F

# SET POLICYS

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# STATEFUL INSPECTION
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# LOOPBACK INTERFACE
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# SET FILTER FOR ETH0
iptables -A INPUT -i eth0 -m state --state NEW -j ACCEPT

# SET FILTER FOR ETH1
iptables -A INPUT -i eth1 -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 8118 -m state --state NEW -j ACCEPT
#iptables -A INPUT -i eth1 -p tcp --dport 9981 -m state --state NEW -j ACCEPT

midan23

Schauen wir mal kurz drüber ...

#!/bin/sh

# FLUSH EVERYTHING

iptables -F

# SET POLICYS

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

Bis hier ist alles in Ordnung

# STATEFUL INSPECTION
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Ich weiss nicht, was die beiden Zeilen mit "stateful inspection" zu tun haben, da ja alles so läuft.
Aber bei den beiden Zeilen darunter gefällt mir so einiges nicht:

Es fehlt die Angabe der Protokoll-Familie TCP
Es handelt sich um pauschale Regeln, die ich normalerweise vermeide wo ich nur kann

# LOOPBACK INTERFACE
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

Die beiden einzigen pauschalen Regeln, die ich systematisch verwende ;-)

# SET FILTER FOR ETH0
iptables -A INPUT -i eth0 -m state --state NEW -j ACCEPT

Eine pauschale Regel ohne nähere Angaben ... böse

# SET FILTER FOR ETH1
iptables -A INPUT -i eth1 -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 8118 -m state --state NEW -j ACCEPT
#iptables -A INPUT -i eth1 -p tcp --dport 9981 -m state --state NEW -j ACCEPT

Auf den ersten Blick sieht es so aus, als ob nur neue Verbindungen erlaubt sind ... und keine Antwortmöglichkeit besteht, weil die dazu gehörigen Regeln fehlen ...
Erst wenn man die beiden pauschalen Regeln weiter oben mit dazu nimmt, machen diese Regeln Sinn ...

Mein Vorschlag:

#!/bin/sh

# FLUSH EVERYTHING

iptables -F

# SET POLICYS

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# LOOPBACK INTERFACE
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# SET FILTER FOR ETH0
iptables -A INPUT -i eth0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j ACCEPT

# SET FILTER FOR ETH1
iptables -A INPUT -i eth1 -p tcp --sport 1024:65535 --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth1 -p tcp --sport 80 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --sport 1024:65535 --dport 8118 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth1 -p tcp --sport 8118 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
#iptables -A INPUT -i eth1 -p tcp --sport 1024:65535 --dport 9981 -m state --state NEW,ESTABLISHED -j ACCEPT
#iptables -A OUTPUT -o eth1 -p tcp --sport 9981 --dport 1024:65535 -m state --state NEW,ESTABLISHED -j ACCEPT

Ja, ich weiss: 2 pauschale Regeln für ETH0 ...

Mir würden zwei zusätzliche Verbesserungen einfallen:

Die Regelpaare kann man in eine Funktion packen; würde eventuelle Tippfehler vermeiden
Sicherstellen das die Namen der Netzwerk-Schnittstellen immer gleich bleiben:
Welche der beiden Netzwerk-Karten ETH0 heisst, wird ja bei jedem Neustart zufällig entschieden. Man kann aber über eine UDEV-Regel festlegen, welche Karte ETH0 sein soll. (Anhand der MAC-Adresse sind die Karten eindeutig voneinander zu unterscheiden)

tofuwurst

ja, so ähnlich hab ich das jetzt auch hinbekommen.... pauschale regeln für eth0 sind schon ok. ist ja schliesslich nur mein lokales netz...

  # FLUSH EVERYTHING

   iptables -F

   # SET POLICYS
   iptables -P INPUT DROP
   iptables -P OUTPUT DROP
   iptables -P FORWARD DROP

   # SET FILTER FOR LO
   iptables -A INPUT -i lo -j ACCEPT
   iptables -A OUTPUT -o lo -j ACCEPT

   # SET FILTER FOR ETH0
   iptables -A INPUT -i eth0 -j ACCEPT
   iptables -A OUTPUT -o eth0 -j ACCEPT

   # SET FILTER FOR ETH1
   iptables -A INPUT -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
   iptables -A OUTPUT -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT

   eth1  () {
       	iptables -A INPUT -i eth1 -p $1 --dport $2 -m state --state NEW -j ACCEPT
   }

   eth1 tcp 80
   eth1 tcp 8118
   eth1 tcp 9981

danke nochmal :-)

mpausch

tofuwurst schrieb
# Pakete erlauben, die zu bestehenden Verbindungen gehoeren
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
müsste hier nicht auch eine output regel angelegt werden?

korrigiere meine erste Aussage dazu, die ich anscheinend während einer Phase der geistigen Umnachtung gemacht habe.
hier braucht es in der Tat auch eine entsprechende OUTPUT-Regel:

iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

dann werden auch die "Antwort-Pakete" zu Verbindungen erlaubt, die über die Regel

iptables -A INPUT -i eth1 -p tcp --dport XZY -m state --state NEW -j ACCEPT

erlaubt sind.

Das erspart dann diese Schweinereien:

iptables -A OUTPUT -o eth1 -p tcp --sport XYZ --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT

midan23 schrieb
# STATEFUL INSPECTION
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Ich weiss nicht, was die beiden Zeilen mit "stateful inspection" zu tun haben, da ja alles so läuft.
Aber bei den beiden Zeilen darunter gefällt mir so einiges nicht:

Es fehlt die Angabe der Protokoll-Familie TCP

Es handelt sich um pauschale Regeln, die ich normalerweise vermeide wo ich nur kann

Da die beiden Regeln nur bei bereits bestehenden Verbindungen matchen können (RELATED,ESTABLISHED), kommt
es darauf an wie die Regel aussieht die die Verbindung erlaubt (-m state --state NEW).
Die NEW-Regel fasse ich auch immer so eng wie möglich (mit Protokoll-Familie, mit Source-Adresse, mit Ziel-Adresse, mit Ziel-Port, ggf mit Incoming Interface, etc....)

Die RELATED,ESTABLISHED-Regel enthält diese Einschränkungen bewusst nicht, weil damit auch z.B. auch ICMP-Pakete die eine bestehende Verbindung betrteffen erlaubt sind (z.B. Source Quench, TTL Exceeded, Port Not Reachable, etc...)
Die RELATED,ESTABLISHED-Regel steht vorteilhafterweise am Anfang einer Chain (INPUT, OUTPUT, FORWARD,...). Dann muss nicht bei jedem Paket die ganze Chain ausgewertet werden um festzustellen, ob ein Paket erlaubt ist oder nicht.

midan23 schrieb
# SET FILTER FOR ETH1
iptables -A INPUT -i eth1 -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 8118 -m state --state NEW -j ACCEPT
#iptables -A INPUT -i eth1 -p tcp --dport 9981 -m state --state NEW -j ACCEPT
Auf den ersten Blick sieht es so aus, als ob nur neue Verbindungen erlaubt sind ... und keine Antwortmöglichkeit besteht, weil die dazu gehörigen Regeln fehlen ...
Erst wenn man die beiden pauschalen Regeln weiter oben mit dazu nimmt, machen diese Regeln Sinn ...

die Kombination aus NEW-Regeln und den RELATED,ESTABLISHED-Regeln trägt ausserdem gut dazu bei die Anzahl der
Regeln möglichst klein zu halten.
Man denke wieder an viele tausend Regeln. Wenn man für jede Verbindung eine Regel braucht, die die Antwortpakete
zulässt, dann verdoppelt sich auf einen Schlag die Anzahl der Regeln und die "Fehlersuche" wird womöglich unnötig erschwert...

midan23

mpausch schrieb die Kombination aus NEW-Regeln und den RELATED,ESTABLISHED-Regeln trägt ausserdem gut dazu bei die Anzahl der
Regeln möglichst klein zu halten.
Man denke wieder an viele tausend Regeln. Wenn man für jede Verbindung eine Regel braucht, die die Antwortpakete
zulässt, dann verdoppelt sich auf einen Schlag die Anzahl der Regeln und die "Fehlersuche" wird womöglich unnötig erschwert...

Reine Ansichtssache ... wenn beide zusammen stehen und entsprechend formatiert sind, sieht man auf einen Blick was durch darf.

In einem anderen Punkt muss ich dich leider enttäuschen: Das state-Modul, welches mit "-m state" geladen wird, funktioniert meines Wissens nach nur mit der TCP-Protokollfamilie. UDP und ICMP sind ja verbindungslos, kennen also keinen Zustand, der mit dem state-Modul abgefragt werden könnte.

mpausch

midan23 schrieb In einem anderen Punkt muss ich dich leider enttäuschen: Das state-Modul, welches mit "-m state" geladen wird, funktioniert meines Wissens nach nur mit der TCP-Protokollfamilie. UDP und ICMP sind ja verbindungslos, kennen also keinen Zustand, der mit dem state-Modul abgefragt werden könnte.

das state-Modul schlägt auch bei verbindungslosen Protokollen an:

RedHatEnterpriseSecurityGuide schrieb You can use the stateful functionality of iptables connection tracking with any network protocol, even if the protocol itself is stateless (such as UDP).

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-Firewalls-IPTables_and_Connection_Tracking.html

Kurz gegenchecken:
in der Connection Tracking Tabelle tauchen die UDP-"Verbindungen" auch auf.

/proc/net # grep -i udp nf_conntrack | grep port=53
ipv4     2 udp      17 13 src=x.y..z.z dst=a.b.c.d sport=45039 dport=53 packets=1 bytes=63 src=a.b.c.d dst=x.y.z.z sport=53 dport=45039 packets=1 bytes=479 mark=0 secmark=0 use=2
.....

Technisch gesehen zwar verbindungslos, das stimmt. Logisch gesehen sind aber z.B. DNS-Anfrage und -Antwort eine "Verbindung".
Und dank RELATED,ESTABLISHED braucht man dafür dann nur eine Regel die man reinklopfen und pflegen muss.

Und mit welcher Regel willst Du Sachen wie z.B. "ICMP Port unreachable" erschlagen, wenn eine TCP-Verbindungsanfrage auf einen
nicht geöffneten Port gemacht wird?

Bei 10 "produktiven" Regeln mag's egal sein, ob noch 10 "Wasserkopf-Regeln" dazukommen.
Zwar nicht wirklich schön, aber was solls.
Aber ich bin froh, dass ich bei >2500 Regeln nicht noch weitere 2500 (IMHO sinnlose) Regeln pflegen muss.