lars15
Goto Top

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 face-smile

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 ACCEPT

bestehende 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 ACCEPT

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

$IPTABLES -A FORWARD -i eth1 -o eth0 -p tcp --dport 80 -j ACCEPT

reicht diese bei einer bestehenden

$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

oder muss ich auch hier das Gegenstück in die andere Richtung aufnehmen:

$IPTABLES -A FORWARD -i eth0 -o eth1 -p tcp --dport 80 -j ACCEPT

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

$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.

Content-Key: 329361

Url: https://administrator.de/contentid/329361

Printed on: April 20, 2024 at 03:04 o'clock

Mitglied: 132272
Solution 132272 Feb 14, 2017 updated at 15:17:08 (UTC)
Goto Top
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

$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

bestehende 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 ACCEPT

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.

oder 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

$IPTABLES -A FORWARD -i eth1 -o eth0 -p tcp --dport 80 -j ACCEPT

reicht diese bei einer bestehenden

$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Ja das reicht, es gilt das oben gesagte zu den states.
oder muss ich auch hier das Gegenstück in die andere Richtung aufnehmen:
$IPTABLES -A FORWARD -i eth0 -o eth1 -p tcp --dport 80 -j ACCEPT
Nein.
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

$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.
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.
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ß
Member: aqui
Solution aqui Feb 14, 2017 updated at 16:54:07 (UTC)
Goto Top
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...
Member: Lars15
Lars15 Feb 15, 2017 at 13:00:41 (UTC)
Goto Top
@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.
Mitglied: 132272
132272 Feb 15, 2017 updated at 13:05:58 (UTC)
Goto Top
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 face-smile.