4
Offene Fragen zu iptables
Hallo, ich bin gerade dabei in einem kleinen Firmennetzwerk ein abgetrenntes LAN einzurichten. Bei der Programmierung der iptables habe ich jedoch noch die eine oder andere Frage und würde um Eure Hilfe bitten 
Der Aufbau ist normal, eth0 kommt aus dem bestehenden LAN, eth1 geht ins abgetrennte LAN. Was ich noch nicht so richtig verstehe: wenn ich mit
bestehende Verbindungen erlaube, genügt es dann wenn ich nachfolgend ausschließlich input von LAN2 auf die Firewall bzw einen Dienst definiere? Etwa
oder muss ich zusäzlich noch den passenden output aufnehmen? Hier wäre es nicht so schlimm, aber generell geht es mir um das Verständnis, wie es funktioniert, dass die Firewall Richtung LAN1 alle Verbindungen aufbauen darf, LAN1 aber erst dann, wenn entweder mit input chain erlaubt oder von der Firewall initiiert und anschließend aufgebaut.
Was mir auch nicht so klar ist, eigentlich analog zur ersten Frage, wenn ich eine forward Chain aufstelle, etwa
reicht diese bei einer bestehenden
oder muss ich auch hier das Gegenstück in die andere Richtung aufnehmen:
Hier sollte das Ziel sein, dass sämtliche forward Anfragen aus LAN1 erst mal geblockt werden, erst wenn eine Anfrage aus LAN2 kommt und eine Verbindung aufgebaut wurde, soll input bzw. forward von eth0 auf eth1 möglich sein, daher ist mittels
erst mal alles verboten und ich muss jetzt eben die ganzen Ausnahmen hinzufügen.
Der Aufbau ist normal, eth0 kommt aus dem bestehenden LAN, eth1 geht ins abgetrennte LAN. Was ich noch nicht so richtig verstehe: wenn ich mit
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPTbestehende Verbindungen erlaube, genügt es dann wenn ich nachfolgend ausschließlich input von LAN2 auf die Firewall bzw einen Dienst definiere? Etwa
$IPTABLES -A INPUT -i eth1 -m state --state NEW -p tcp --dport 22 -j ACCEPToder muss ich zusäzlich noch den passenden output aufnehmen? Hier wäre es nicht so schlimm, aber generell geht es mir um das Verständnis, wie es funktioniert, dass die Firewall Richtung LAN1 alle Verbindungen aufbauen darf, LAN1 aber erst dann, wenn entweder mit input chain erlaubt oder von der Firewall initiiert und anschließend aufgebaut.
Was mir auch nicht so klar ist, eigentlich analog zur ersten Frage, wenn ich eine forward Chain aufstelle, etwa
$IPTABLES -A FORWARD -i eth1 -o eth0 -p tcp --dport 80 -j ACCEPTreicht diese bei einer bestehenden
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPToder muss ich auch hier das Gegenstück in die andere Richtung aufnehmen:
$IPTABLES -A FORWARD -i eth0 -o eth1 -p tcp --dport 80 -j ACCEPTHier sollte das Ziel sein, dass sämtliche forward Anfragen aus LAN1 erst mal geblockt werden, erst wenn eine Anfrage aus LAN2 kommt und eine Verbindung aufgebaut wurde, soll input bzw. forward von eth0 auf eth1 möglich sein, daher ist mittels
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROPerst mal alles verboten und ich muss jetzt eben die ganzen Ausnahmen hinzufügen.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 329361
Url: https://administrator.de/forum/offene-fragen-zu-iptables-329361.html
Ausgedruckt am: 05.04.2025 um 15:04 Uhr
4 Kommentare
Neuester Kommentar
Zitat von @Lars15:
Der Aufbau ist normal, eth0 kommt aus dem bestehenden LAN, eth1 geht ins abgetrennte LAN. Was ich noch nicht so richtig verstehe: wenn ich mit
bestehende Verbindungen erlaube, genügt es dann wenn ich nachfolgend ausschließlich input von LAN2 auf die Firewall bzw einen Dienst definiere? Etwa
Ja, das reicht. Stichwort Statefull (SPI) Firewall. IPtables hält im Hintergrund eine Session-Tabelle mit den aktuellen Verbindungen vor und lässt bei den obigen statefull rules dazugehörige Verbindungen passieren. Sie weiß also das der Client eine Verbindung initiiert hat und ordnet die Pakete die von der Gegenseite kommen passend dieser Verbindung zu und lässt sie dementsprechend automatisch passieren.Der Aufbau ist normal, eth0 kommt aus dem bestehenden LAN, eth1 geht ins abgetrennte LAN. Was ich noch nicht so richtig verstehe: wenn ich mit
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPTbestehende Verbindungen erlaube, genügt es dann wenn ich nachfolgend ausschließlich input von LAN2 auf die Firewall bzw einen Dienst definiere? Etwa
$IPTABLES -A INPUT -i eth1 -m state --state NEW -p tcp --dport 22 -j ACCEPToder muss ich zusäzlich noch den passenden output aufnehmen?
Nein. Das wäre nur der Fall wenn die Firewall selber die Verbindung initiieren würde und die Default-Rules im OUTPUT auf DROP stehen.Was mir auch nicht so klar ist, eigentlich analog zur ersten Frage, wenn ich eine forward Chain aufstelle, etwa
reicht diese bei einer bestehenden
Ja das reicht, es gilt das oben gesagte zu den states.$IPTABLES -A FORWARD -i eth1 -o eth0 -p tcp --dport 80 -j ACCEPTreicht diese bei einer bestehenden
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPToder muss ich auch hier das Gegenstück in die andere Richtung aufnehmen:
Nein.$IPTABLES -A FORWARD -i eth0 -o eth1 -p tcp --dport 80 -j ACCEPTHier sollte das Ziel sein, dass sämtliche forward Anfragen aus LAN1 erst mal geblockt werden, erst wenn eine Anfrage aus LAN2 kommt und eine Verbindung aufgebaut wurde, soll input bzw. forward von eth0 auf eth1 möglich sein, daher ist mittels
erst mal alles verboten und ich muss jetzt eben die ganzen Ausnahmen hinzufügen.
Wenn du alles dropst, korrekt musst du alles was aus dem LAN an eth1 kommt definieren. Denke dran das die Clients DNS benötigen wenn sie ins Internet kommen sollen (Auflösen von Hostnamen) (Port 53 UDP/TCP INPUT) wenn die Firewall auch selbst DNS-Proxy ist.$IPTABLES -P INPUT DROP
> $IPTABLES -P FORWARD DROP
> $IPTABLES -P OUTPUT DROP
> erst mal alles verboten und ich muss jetzt eben die ganzen Ausnahmen hinzufügen.
Die INPUT-Chain handelt alles was direkt in die Firewall selbst fließt und die FORWARD-Chain alles was die Firewall nur passiert und weiterleitet.
Wenn die Firewall weiterleiten können soll ist es natürlich ebenso nötig das das IP-Forwarding auf der Kiste aktiviert wurde.
Gruß
iptables schön und gut macht sicher Sinn, aber warum tust du dir das mit dem CLI an. Mit einer kleinen Open Source Firewall löst man das viel eleganter:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Nur mal so am Rande bemerkt...
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Nur mal so am Rande bemerkt...
@132272
Danke für die Erklärung, das hilft mir sehr. Dann wäre es auch Sicherheitsgründen angebracht, forward nur von eth1 zu eth0 zu erlauben, damit der andere Weg nur möglich ist, wenn zuvor LAN 2 eine Verbindung anfordert und aufbaut.
Dass ich wie DNS, Ping oder IMAP manuell freigeben muss, weiss ich, aber mir ist es lieber, per default alles auf Drop und dann die 10 Ports freizugeben, als nachher irgendwas zu vergessen. Wenn etwas später nicht funktioniert, kann man immer noch reagieren.
@aqui
Berechtigte Frage Deinerseits, die Antwort ist recht einfach: ich habe früher schon mit ufw oder ipcop/ipfire Regeln erstellt, aber das Problem an einem Frontend ist halt, dass Du später das Produkt hast, aber nicht verstehst wie es entwickelt wurde. Ich will bewusst alles händisch machen, um die Systematik zu verstehen. Konsolenbasiertes Arbeiten finde ich zudem angenehm, ist doch irgendwie alles eine Sache der Gewohnheit.
Danke für die Erklärung, das hilft mir sehr. Dann wäre es auch Sicherheitsgründen angebracht, forward nur von eth1 zu eth0 zu erlauben, damit der andere Weg nur möglich ist, wenn zuvor LAN 2 eine Verbindung anfordert und aufbaut.
Dass ich wie DNS, Ping oder IMAP manuell freigeben muss, weiss ich, aber mir ist es lieber, per default alles auf Drop und dann die 10 Ports freizugeben, als nachher irgendwas zu vergessen. Wenn etwas später nicht funktioniert, kann man immer noch reagieren.
@aqui
Berechtigte Frage Deinerseits, die Antwort ist recht einfach: ich habe früher schon mit ufw oder ipcop/ipfire Regeln erstellt, aber das Problem an einem Frontend ist halt, dass Du später das Produkt hast, aber nicht verstehst wie es entwickelt wurde. Ich will bewusst alles händisch machen, um die Systematik zu verstehen. Konsolenbasiertes Arbeiten finde ich zudem angenehm, ist doch irgendwie alles eine Sache der Gewohnheit.
Zitat von @Lars15:
Danke für die Erklärung, das hilft mir sehr. Dann wäre es auch Sicherheitsgründen angebracht, forward nur von eth1 zu eth0 zu erlauben, damit der andere Weg nur möglich ist, wenn zuvor LAN 2 eine Verbindung anfordert und aufbaut.
Das ist ja schon nicht erlaubt wenn du alles per default dropst Danke für die Erklärung, das hilft mir sehr. Dann wäre es auch Sicherheitsgründen angebracht, forward nur von eth1 zu eth0 zu erlauben, damit der andere Weg nur möglich ist, wenn zuvor LAN 2 eine Verbindung anfordert und aufbaut.
.
