FWBuilder(iptables) und Masquerading(DMZ ins Internet)

#1 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. Auf der inneren Firewall (Choke) läuft noch der BIND DNS Dienst und ein Squid Proxy. Das LAN hat den Adressbereich 192.168.1.0/24 und die DMZ 172.16.240.96/28 - nur so nebenbei erwähnt :-)

Ich habe zwar meine Regeln, die ich bisher mit dem Firewall Builder erstellt habe, noch nicht testen können - da bis heute der Proxy rumgesponnen hat - 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.

Erstmal von welchem Objekttyp ist der DSL Anschluss(ppp0)? Ist das eine Schnittstelle mit dynamischer IP Zuweisung oder, wie es im FWBuilder angeboten wird, ein "nicht nummeriertes Interface".
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...

Ich würde mich freuen, wenn mir jemand weiterhelfen könnte!

Mfg

Dominik

#2 hi

wenn du routing aktiviert hast (cat /proc/sys/net/ipv4/ip_forward gibt "1"), brauchst du keine extra rule, die dir die pakete weiterleitet

die forward chain müssen die pakete, die maskiert werden sollen, logischerweise passieren dürfen

pppx ist ein dial up interface, kann aber auch eine statische IP besitzen
somit lässt sich deine frage diesbezüglich nicht eindeutig beantworten

Zitat

Die Regelung für Masquerading stelle ich ja, neben dem Haken in den Firewall Optionen, im Firewall Builder unter der "NAT" Regelung ein, oder?

kenne den builder nicht

Zitat

Reicht es da wenn ich sage, dass alle ankommenden Pakete aus der DMZ (Source), die nicht in die DMZ gehen (Destination)

dann erreichen sie die FW nicht, da sie nicht geroutet werden (außer du hast proxy_arp aktiv, was ich nicht glaube)

damit deine rechner in der DMZ erreichbar sind, musst du zusätzlich auch noch mit DNAT arbeiten

dann musst du der firewall noch beibringen, dass sie alle pakete, die von port 80/443 aus der DMZ kommen und ins WAN (ppp) sollen, maskiert werden sollen

greez

#3 @Emba

Ganz kleine korekktur:

Zitat

wenn du routing aktiviert hast (cat /proc/sys/net/ipv4/ip_forward gibt "1"), brauchst du keine extra rule, die dir die pakete weiterleitet

ip_forward muss immer auf 1 stehen damit der kernel überhaupt forwarded - wenn nun die Policy der forward change auf ACCEPT steht DANN brauchst du keine extra rule.

@Enigma

Zitat

Erstmal von welchem Objekttyp ist der DSL Anschluss(ppp0)? Ist das eine Schnittstelle mit dynamischer IP Zuweisung oder, wie es im FWBuilder angeboten wird, ein "nicht nummeriertes Interface".

der device name immer ppp* bei einer ppp (point-to-point) verbindung, die nummer fängt bei 0 an und erhöht sich wenn du mehr als eine verbindung hast.
Ob sich ppp nur auf dynamischen IP's beschränkt weiß ich nicht - in erster linie ist es ein protokoll.

Zitat

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.

Squid ist ja nur ein webproxy der sich um http und ftp hauptsächlich kümmert. Benutzt du einen Proxy oder SOCKS brauchst du kein NAT.

Zitat

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.

MASQ brauchst du wirklich nur wenn du eine dynamische public ip von deinem ISP zugeweisen bekommst so wie ich das verstanden habe ist es hier der Fall aber wenn nicht solltest du SNAT verwenden.

Zitat

Die Regelung für Masquerading stelle ich ja, neben dem Haken in den Firewall Optionen, im Firewall Builder unter der "NAT" Regelung ein, oder?

Du brauchst solche Dinge nicht wenn du die manpage von iptables verstehen kannst.
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#4 @xeper

Zitat

Ganz kleine korekktur:

"die forward chain müssen die pakete, die maskiert werden sollen, logischerweise passieren dürfen" - das gefiel dir wohl nicht?

Zitat

Ob sich ppp nur auf dynamischen IP's beschränkt weiß ich nicht - in erster linie ist es ein protokoll.

beschränkt sich nicht nur auf dynamische IPs (siehe manual )

greez

#5 @Emba

Zitat

"die forward chain müssen die pakete, die maskiert werden sollen, logischerweise passieren dürfen" - das gefiel dir wohl nicht?

Ne ist okay so - ich denke ich habe das überlesen.
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#6 Danke erstmal für Eure Antworten. Also bezüglich des Typs von ppp0 habe ich mich inzwischen selbst schlau gemacht, beim Firewall Builder gilt diese als "dynamische Schnittstelle". Das "nicht nummerierte Interface" nimmt man nur bei VPN etc.

Nochmal kurz etwas zur Netzstruktur, denn wie mir scheint sind da ein paar Unstimmigkeiten aufgetreten. 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. Da brauche ich natürlich kein NAT usw.

Etwas anders ist es da bei der externen Firewall(Bastion). Auf diesem Rechner läuft nichts außer die Firewall, sprich die iptables, und dieser soll die Pakete auch nur weiterleiten und filtern. Da ich von der DMZ(172.16.240.108/28, eth1 der Choke) komme und ins Internet will, muss ich hier ja die Adresse übersetzen und meine Frage ist was muss ich ändern.
Die Pakete kommen ja vom Proxy(172.16.240.108/28) an der eth0 Schnittstelle(172.16.240.97/28) der Bastion Firewall an und von dort aus müssen sie irgendwie ins Internet(ppp0) geschickt werden. Der Firewall Builder habe ich unter der Tabelle NAT die Möglichkeit die Adressen, sei es jetzt SNAT oder DNAT zu ändern. Den Antworten entnehme ich, dass es ausreicht Paketen die aus der DMZ kommen und nicht in die DMZ gehen(Destination) über Port 80, 443 etc. gehen, als Absender(Source) die ppp0 Schnittstelle zu geben. Der Rest geht dann von selbst, oder?

Heute hat sich aber noch ein anderes Problem ergeben. 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??? Diese taucht 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...

Sorry, dass es nun soviel Text geworden ist.

Gruß
Dominik

#7

Zitat

als Absender(Source) die ppp0 Schnittstelle zu geben. Der Rest geht dann von selbst, oder?

ja, steht doch alles schon oben:

- routing aktiv
- forward chain blockt keine pakete
- masquerading

SNAT wird dir nicht viel nützen bei dynIP

zu deiner 2.1 IP
poste doch bitte mal den output von

iptables -t nat -L -nv

der choke FW

greez

#8 Hallo Emba,

erstmal danke wieder für die Antwort!
Das Internet habe ich nun zum Laufen gebracht und auch durch den Squid komme ich an den Webserver in die DMZ. Will ich aber durch einen Client im LAN ins Internet kommt die Fehlermeldung (Im Browser) "No DNS record" und gebe ich die IP von Google ein kommt "Network is unreachable" also die gleiche Fehlermeldung wie auch bei der Choke für den Standardgateway kommt. Die NAT Chain der Choke habe ich gerade nicht da, kann ich aber bei Bedarf noch nachreichen.

Ich denke allerdings nicht, dass es an einer Regel liegt, da die Meldung "Network unreachable" bereits beim Hochfahren der Choke Firewall kommt, wo die iptables Regel noch gar nicht geladen sind. Komischerweise können sich sie anpingen und sind anscheinend verbunden. Ich verstehe nicht, was da falsch sein könnte. Die IP Adressen der Interface stimmen und die 3 Route, die ich eingetragen sind auch okay. 172.16.240.96/28(DMZ) bekommt er über seine eth1(172.16.240.108) und das LAN mit 192.168.1.0/24 über seine eth0(192.168.1.2). Dazu habe ich noch in Yast den Standardgateway(172.16.240.97) angegeben - mehr nicht Wie gesagt ich denke nicht, dass es an einer Regel liegt, da der Fehler auch auftaucht, wenn die iptables nicht geladen sind. Wie kann ein "Network unreachable" zustande kommen, wenn ein Ping an diese (Gateway-)Adresse funktioniert???

Man soll zwar nicht von einer Baustelle zur nächsten rennen, aber da ist noch ein Problem, dass ich habe. Im Moment geht ja auf der Bastion Firewall der Internetzugriff von innen nach außen.
Wie ist das aber wenn jemand von außen(Internet) auf unsere Firmenhomepage, sprich dem Webserver in der DMZ, möchte.

Ich habe im Firewall Builder schon die folgende Regel für die Bastion erstellt:

Source(Original)-Dest.(Org.)-Port(Org.) > Source(NAT)-Dest.(NAT)-Port(NAT)

Any - ppp0 - 80 m state NEW > eth0 - DMZ_Server - OriginalPort(80)
Any - ppp0 - 443 m state NEW > eht0 - DMZ_Server - OrignalPort(80)

aber irgendwie hat nun der DMZ Server alle HTTP Pakete zugeschickt bekommen Ich muss doch auf jeden Fall den Verbindungszustand auf NEW definieren, da die eingehenden HHTP Pakete zu einer bestehenden Verbindung ja in der Regel nicht an den DMZ Server sondern an den Squid zurück sollen. Es muss doch eine Regel erstellt werden, die nur neue eingehende HTTP Verbindungen an den DMZ Server weiterleitet. Wie muss hier NAT aussehen?

Ich hoffe man kann verstehen, was ich meine

Viele Grüße

Dominik

#9 du brauchst da gar nix mit NEW oder so machen, denn du hast wahrscheinlich was in der DNAT rule falsch gemacht

korrekt muss es lauten: alle pakete vom internetinterface an die (externe) firewall mit dstport 80 sollen zieladresse WWW bekommen

was du hast, klingt eher nach srcport 80

greez

#10 Okay, da habe ich nicht deutlich genug geschrieben. Der Firewall Builder arbeitet ja mit Objekten und mit 80 oben meine ich einfach das HTTP Objekt. Dies ist im FWB mit SourcePort 0 bis 0 (also alles) und Destinationport 80 bis 80 definiert - stimmt also, oder?

Die ausgehende NAT Regel sind so aus

Source(Original)-Dest.(Org.)-Port(Org.) > Source(NAT)-Dest.(NAT)-Port(NAT)
DMZ_Netz - !DMZ_Netz - HTTP > ppp0 - Original - Original

Und so geht es auch, wie ich getestet habe
Für mich ist nun nicht klar ob ich die NAT Regelung im vorherigen Beitrag für eingehende HTTP Verbindungen auf unseren Webserver so verwenden kann. Denn wie mir scheint kommen dadurch alle HTTP Pakete beim DMZ_Server an, wo sie nicht hinsollen.
Ist das "ip_conntrack" Modul so "mächtig", dass es sieht dass ankommende Pakete auf HTTP zu einer vorherigen Anfrage von innen gehören und schickt diese dann an den Squid Proxy weiter und leitet wirklich nur neue Verbindungen von außen an den Webserver weiter?

Wobei man bei dem allen sagen muss, dass mein Hauptproblem die Verbindung der beiden Firewalls untereinander ist. Da ja eine Antwort in Form von "No DNS record" bzw. "Network unreachable" zurückkommt und Linux da schon vor der Nutzung der iptables meckert, liegt wohl ein anderen Problem vor. Die Frage ist nur wo danach suchen...

Edit:
Hallo Emba,

ich bin heute morgen selbst auf die Lösung gekommen
Gehe ich von der DMZ/Squid aus ins Internet ist der Zielport ja 80 und Pakete auf diese Anfragen kommen von 80 auf einen unpriviligierten Port zurück.
Also kann ich ja eine NAT Regelung für eingehende Pakete machen, da neue Verbindungen ja eingehende Verbindungen auf Port 80 ankommen...Manchmal kann es so einfach sein, man muss nur logisch denken

#11 das ist exakt das, was ich oben geschrieben habe

Zitat

alle pakete vom internetinterface an die (externe) firewall mit dstport 80 sollen zieladresse WWW bekommen

WWW ist hier dein rechner, den du von außen aus mit DNAT zur verfügung stellen möchtest

greez

#12 Hallo Emba,

erstmal wieder Danke für die Antwort - in einem anderen Linux Forum hat nämlich anscheinend keiner Lust was zu schreiben

Also die Bastion funktioniert soweit, nur die Choke bzw. wahrscheinlich der Rechner selbst machen Probleme. Gebe ich mich mit meinem Notebook nämlich als Squid Rechner aus und benutze die DNS Adressen von T-Online funktioniert die Bastion und eine Verbindung ins I-Net kommt zustande. Gehe ich über den Squid - auch ohne iptables - geht nichts. Es kommen zwar Anfragen aus dem LAN am Proxy an, aber er schickt nichts auf eth1 raus (habe mit tcpdump mitgeloggt) und meldet ständig nur "Network is unreachable" Dies Meldung erscheint auch beim Booten bzw. Netzwerkneustart. Kurioserweise können sich die Rechner in der DMZ einwandfrei per Ping erreichen, sind also erreichbar!

Mein Ausbilder und ich sind nun zum Entschluss gekommen, dass eindeutig das Routing des Rechners fehlerhaft ist. Mag vielleicht auch damit zusammenhängen, dass der Kernel neu kompiliert wurde. Im Firewall Builder gab es nämlich eine Funktion zum Loggen aller verworfenden Pakete, was ja besonders in der Testphase der Firewall von Vorteil ist. Nun braucht man aber zur Nutzung dieses Feature das "Patch-o-matic" Update von der Netfilter.org Seite. Um dieses Update nutzen zu können muss aber der Kernel frisch kompiliert werden. Da mein Ausbilder und ich das zum ersten Mal gemacht haben, wird wohl hier der Hund begraben liegen, wobei es mit dem alten Kernel auch nicht geht. Aber wahrscheinlich haben wir das Linux einfach zerschossen. Wir haben uns nun darauf geeignet, dass ich die Choke Firewall nochmal neu installiere.

Bis dahin hätte ich aber an Dich (oder an die anderen, die auch dieses Thema verfolgen) eine riesengroße Bitte. Die Firewall ist nämlich für meine Abschlussprüfung und da sollte ich in den nächsten 7-10 Tagen mit fertig sein, so dass ich leider ziemlich unter Zeitdruck bin. Ich habe die Skripte und einen Netzplan zum besseren Verständnis auf meinen Webspace geuppt und würde Dich bzw. Euch bitte falls Du/Ihr Zeit und Lust habt, die Skripte mal durchzuschauen ob die Regeln soweit in Ordnung sind.

Folgendes sollen die Firewall filtern

- LAN darf auf den Proxy bzw. die Choke Firewall auf Port 8080 zugreifen
- Dieser erledigt dann die FTP und HTTP Anfragen ins Internet bzw. den DMZ-Webserver
- Die Bastion Firewall leitet Pakete von DMZ auf das externe Interface(ppp0) um
- Eingehende HTTP und FTP Verbindungen werden an den DMZ-Server weitergeleitet
- Diverse Sicherheitseinstellungen (SYN Cookies, Ignore Broadcast Ping, Log Martian Source) sind aktiviert

Choke:
eth0 - LAN
eth1 - DMZ

Bastion:
eth0 - DMZ
eth1(ppp0) - Internet

Ich denke mal, dass die Bastion Konfig okay ist und das vielleicht eher noch Fehler bei der Choke sind, da ich diese eben aufgrund der Routing Probleme bisher nicht groß testen konnte.
Also ich würde mich wahnsinnig freuen wenn sich jemand die Mühe macht und mein Skript kurz durchschaut und mir eventuelle Fehler meldet. DANKE für jegliche Hilfe im Voraus!

[url=http://www.dominik-keppner.de/Netzplan.jpg]Netzplan[/url]
[url=http://www.dominik-keppner.de/ChokeFirewall.fw]ChokeFirewall Skript[/url]
[url=http://www.dominik-keppner.de/BastionFirewall.fw]Bastion Firewall Skript[/url]

Viele Grüße und ein schönes Wochenende

Dominik

#13 oh man,

die rules sind so komplex, da wird sich sicher kaum jmd. die mühe machen und durchlesen und prüfen - so böse wie das klingen mag

ich habe gerade angefangen aber in der hälfte des choke-scripts einfach aufgegeben (bis dahin okay), weil es einfach zu viel ist (für mich grad am sonntag *gg)

warum prüfst du nicht selbst die rules?
nmap kann das doch alles...

such dir die regeln raus, die droppen (sollen), bastel entsprechend den rules pakete (mit nmap) und scanne auf allen interfaces von verschiedenen maschinen

desweiteren: lasse dir alle rules ausgeben, die -j ACCEPT (klappt mit grep klasse) enthalten und überprüfe, ob diese rules in deinem sinne sind

greez

#14 Okay, trotzdem Danke für Deine Hilfe. Hab mir schon gedacht, dass es zuviel ist, aber vielleicht hätte ja einer gerade Bock darauf gehabt Wie mir scheint gibt's außer Dir nicht viele hier im Forum die sich damit auskennen Aber wenn das Choke Skript bis zur Hälfte okay war, kann nur noch eine Hälfte falsch sein

Und das probiere ich halt dann morgen noch aus. Die Kundendoku habe ich mit dem momentanen Regelwerk mal so geschrieben. Ich habe eigentlich bei meinen Regel ein gutes Gefühl und denke nicht dass ich noch arg viel ändern muss.

Gruß und nochmal Danke für die Hilfe in den letzten Tagen

Dominik