Enigma
14.04.04, 16:57
Hallo,
bin neu hier und habe das Forum über Google entdeckt. Da bisher zu fast jedem Thema gute Antworten kamen, hoffe ich, dass Ihr auch mir weiterhelfen könnt.
Ich bin Azubi bei einem großen deutschen Telekommunikationsunternehmen und bastle gerade an einer Firewall unter Linux für das Firmennetzwerk. Ich verwende dabei die SuSE Linux 9.0, iptables und den Firewall Builder. Ein neuer Mail- und Webserver soll in einer DMZ stehen, dass heißt ich mache zwei Firewalls. Das LAN hat den Adressbereich 192.168.1.0/24 und die DMZ 172.16.240.96/28. Auf der internen Firewall(Choke) läuft ein Squid Proxy und ein BIND DNS. Hier ist IP-Weiterleitung unter SuSE deaktiviert, da der Squid alle Anfrage aus dem LAN(192.168.1.0/24) entgegen nimmt und über die eth1(172.16.240.108/28) in die DMZ schickt.
Ich habe zwar meine Regeln, die ich bisher mit dem Firewall Builder erstellt habe, noch nicht testen können, bin jedoch gut mit dem FW Builder klar gekommen und denke, dass die Regel soweit in Ordnung sind.
Womit ich allerdings ein Problem in Zusammenhang mit dem FWBuilder habe, ist Masquerading, da es in der grafischen Oberfläche irgendwie nicht so deutlich wird und ich im fertigen Skript auch keine Regel diesbezüglich entdecken kann. Auf der internen Firewall ist dies ja nicht nötig, da dort der Squid Proxy alle Anfragen aus dem LAN entgegen nimmt und routet. Auf der externen Firewall (Bastion) müssen die Pakete aber an die externen Schnittstelle (ppp0, wir haben DSL) übergeben werden.
Die Regelung für Masquerading stelle ich ja, neben dem Haken in den Firewall Optionen, im Firewall Builder unter der "NAT" Regelung ein, oder?
Reicht es da wenn ich sage, dass alle ankommenden Pakete aus der DMZ (Source), die nicht in die DMZ gehen (Destination) über Port 80, 443 etc. als neue Quelladresse die ppp0 Schnittstelle bekommen? Leitet dann die Firewall die Pakete selbstständig an die ppp0 Schnittstelle weiter und schickt sie ins Internet oder muss ich erst ankommende Pakete an die Netzwerkkarte(DMZ), von der Netzwerkkarte an ppp0 schicken und von dort aus weiter - was ja mehrere Regeln wären und so kompliziert kann es ja nicht sein...
Außerdem gibt es noch ein weiteres Problem: Will ich ohne geladene iptables über den Squid auf einen Webserver in der DMZ zugreifen, funktioniert alles einwandfrei. Schalte ich die iptables hinzu, schickt die ChokeFirewall auf einmal die Pakete an die Adresse 192.168.2.1(in die DMZ, anscheinend als Gateway)??? Diese Adresse taucht jedoch nicht in meinen iptables(-skripten) und ich frage mich wirklich wie dies zustande kommt. Die Routen habe ich alle schon überprüft und es funktioniert ja auch ohne die iptables. Aber sobald diese geladen sind, kommt bei den ausgehenden Verbindungen auf der internen Firewall nur noch Mist raus. :( Ich denke ja mittlerweile, dass SuSE da ein bißchen rumspinnt, aber vielleicht hätte jemand von Euch einen Tip, woran das liegen könnte...
Ich würde mich freuen, wenn mir jemand weiterhelfen könnte!
Mfg
Dominik
bin neu hier und habe das Forum über Google entdeckt. Da bisher zu fast jedem Thema gute Antworten kamen, hoffe ich, dass Ihr auch mir weiterhelfen könnt.
Ich bin Azubi bei einem großen deutschen Telekommunikationsunternehmen und bastle gerade an einer Firewall unter Linux für das Firmennetzwerk. Ich verwende dabei die SuSE Linux 9.0, iptables und den Firewall Builder. Ein neuer Mail- und Webserver soll in einer DMZ stehen, dass heißt ich mache zwei Firewalls. Das LAN hat den Adressbereich 192.168.1.0/24 und die DMZ 172.16.240.96/28. Auf der internen Firewall(Choke) läuft ein Squid Proxy und ein BIND DNS. Hier ist IP-Weiterleitung unter SuSE deaktiviert, da der Squid alle Anfrage aus dem LAN(192.168.1.0/24) entgegen nimmt und über die eth1(172.16.240.108/28) in die DMZ schickt.
Ich habe zwar meine Regeln, die ich bisher mit dem Firewall Builder erstellt habe, noch nicht testen können, bin jedoch gut mit dem FW Builder klar gekommen und denke, dass die Regel soweit in Ordnung sind.
Womit ich allerdings ein Problem in Zusammenhang mit dem FWBuilder habe, ist Masquerading, da es in der grafischen Oberfläche irgendwie nicht so deutlich wird und ich im fertigen Skript auch keine Regel diesbezüglich entdecken kann. Auf der internen Firewall ist dies ja nicht nötig, da dort der Squid Proxy alle Anfragen aus dem LAN entgegen nimmt und routet. Auf der externen Firewall (Bastion) müssen die Pakete aber an die externen Schnittstelle (ppp0, wir haben DSL) übergeben werden.
Die Regelung für Masquerading stelle ich ja, neben dem Haken in den Firewall Optionen, im Firewall Builder unter der "NAT" Regelung ein, oder?
Reicht es da wenn ich sage, dass alle ankommenden Pakete aus der DMZ (Source), die nicht in die DMZ gehen (Destination) über Port 80, 443 etc. als neue Quelladresse die ppp0 Schnittstelle bekommen? Leitet dann die Firewall die Pakete selbstständig an die ppp0 Schnittstelle weiter und schickt sie ins Internet oder muss ich erst ankommende Pakete an die Netzwerkkarte(DMZ), von der Netzwerkkarte an ppp0 schicken und von dort aus weiter - was ja mehrere Regeln wären und so kompliziert kann es ja nicht sein...
Außerdem gibt es noch ein weiteres Problem: Will ich ohne geladene iptables über den Squid auf einen Webserver in der DMZ zugreifen, funktioniert alles einwandfrei. Schalte ich die iptables hinzu, schickt die ChokeFirewall auf einmal die Pakete an die Adresse 192.168.2.1(in die DMZ, anscheinend als Gateway)??? Diese Adresse taucht jedoch nicht in meinen iptables(-skripten) und ich frage mich wirklich wie dies zustande kommt. Die Routen habe ich alle schon überprüft und es funktioniert ja auch ohne die iptables. Aber sobald diese geladen sind, kommt bei den ausgehenden Verbindungen auf der internen Firewall nur noch Mist raus. :( Ich denke ja mittlerweile, dass SuSE da ein bißchen rumspinnt, aber vielleicht hätte jemand von Euch einen Tip, woran das liegen könnte...
Ich würde mich freuen, wenn mir jemand weiterhelfen könnte!
Mfg
Dominik