Hallo LUG,
ich haette da ein kleines Problem ...
Folgendes Netzwerk-Setup:
Internet <-> Firewall <-> WebServer <-> Firewall <-> Internes Netz
(auf beiden Firewall-Rechnern natuerlich Linux ...)
D.h. der erste Firewall sichert den Webserver gegen schwere Angriffe aus dem Internet und der zweite sichert das Interne Netz gegen einen evtl. manipulierten WebServer ... (so als quasi als Trumpf)
Nun moechte ich aber schon bereits dem WebServer eine private IP Adresse geben, und den Firewall ins Internet ein Masquerading machen lassen (sowohl Verbindungen vom WebServer als auch ausgehende Verbindungen aus dem internen Netz, die ihrerseits schon ein Masquerading bei Firewall #2 hinter sich haben) ...
Die grosse Frage: Wie konfiguriere ich einen Kernel 2.2.x mit ipchains so, das er eingehende Anfragen aus dem Internet auf Port 80, zuerst maskiert, an den WebServer auf Port 8080 weiterschickt und die Antworten dann wieder demaskiert und an den originalen Absender im Internet schickt ... (so als waere er der Web-Server)
Es ist irgendwie eine Abart des Masquerading ... Aber saemtliche Doku die ich bis jetzt gefunden habe, bespricht immer nur den Fall Masquerading aus dem Internen Netz ins externe ... Ich brauch' das aber genau in der anderen Richtung ...
Oder geht das garnicht mit Masquerading und ich brauch' so 'ne Art Proxy auf dem ersten Firewall ?
Habt ihr Ideen oder URLs ?
Bye,
Jens
On Sat, Sep 16, 2000 at 11:43:44AM +0200, Jens Lorenz wrote:
Internet <-> Firewall <-> WebServer <-> Firewall <-> Internes Netz
Nun moechte ich aber schon bereits dem WebServer eine private IP Adresse geben, und den Firewall ins Internet ein Masquerading machen lassen (sowohl Verbindungen vom WebServer als auch ausgehende Verbindungen aus dem internen Netz, die ihrerseits schon ein Masquerading bei Firewall #2 hinter sich haben) ...
2 mal masquerading halte ich nicht fuer sehr sinnvoll. FW1 kommuniziert sowie nach innen nur mit FW2 und webserver. Faellt FW1 sind deren Adressen fuer den Angreifer sofort ersichtlich. Masquerading ist kein Sicherheitfeature sondern eine Notlösung wegen Adressmangel und sollte auch nur als soche Verwendung finden.
Die grosse Frage: Wie konfiguriere ich einen Kernel 2.2.x mit ipchains so, das er eingehende Anfragen aus dem Internet auf Port 80, zuerst maskiert, an den WebServer auf Port 8080 weiterschickt und die Antworten dann wieder demaskiert und an den originalen Absender im Internet schickt ... (so als waere er der Web-Server)
Ein einfaches Tool zum Portforwarding auf FW1 tut das z.B. rinetd Kann sein, dass das auch mit ipchains geht.
Es ist irgendwie eine Abart des Masquerading ... Aber saemtliche Doku die ich bis jetzt gefunden habe, bespricht immer nur den Fall Masquerading aus dem Internen Netz ins externe ... Ich
Von aussen klappt es auch nicht. Welche Ziel-IP sollte den der Nutzer des Webserveres angeben, wenn du auf FW1 NAT machst? Wenn du keine 2. IP-Adressse fuer den Webserver hast, laesst du www.domain.de auf FW1 auflösen und leitest - wie oben beschrieben - die Verbindung an den eigentlichen Webserver weiter.
Oder geht das garnicht mit Masquerading und ich brauch' so 'ne Art Proxy auf dem ersten Firewall ?
Das ist die andere Variante. Nur woher nimmt man so eine Teil -ich kenne kein geeigngnetes Tools dafuer. Ich wuerde fuer eingehende Webanfragen keinen Proxy nehmen.
Reinhard
Reinhard Foerster wrote:
Die grosse Frage: Wie konfiguriere ich einen Kernel 2.2.x mit ipchains so, das er eingehende Anfragen aus dem Internet auf Port 80, zuerst maskiert, an den WebServer auf Port 8080 weiterschickt und die Antworten dann wieder demaskiert und an den originalen Absender im Internet schickt ... (so als waere er der Web-Server)
Ein einfaches Tool zum Portforwarding auf FW1 tut das z.B. rinetd Kann sein, dass das auch mit ipchains geht.
Danke. rinetd war der Tip, den ich brauchte. Funktioniert wunderbar.
Bye.
Jens
On Sat, Sep 16, 2000 at 11:43:44AM +0200, Jens Lorenz wrote:
Nun moechte ich aber schon bereits dem WebServer eine private IP Adresse geben, und den Firewall ins Internet ein Masquerading machen lassen (sowohl Verbindungen vom WebServer als auch ausgehende Verbindungen aus dem internen Netz, die ihrerseits schon ein Masquerading bei Firewall #2 hinter sich haben) ...
Nun, ob das notwendig ist, weiss ich nicht. Was versprichst Du Dir davon? Einziger Grund, der mir einfiele, waere, dass Du von Deinem Provider nur eine Adresse bekommen hast ...
Dein Webserver muss ja erreichbar sein -- und dann kannst Du den wohl so hinbekommen, dass er nach aussen lediglich den Port 80 zur Verfuegung stellt -- dazu kann/soll Dich ja Dein aeusserer Firewall unterstuetzen.
Die grosse Frage: Wie konfiguriere ich einen Kernel 2.2.x mit ipchains so, das er eingehende Anfragen aus dem Internet auf Port 80, zuerst maskiert, an den WebServer auf Port 8080 weiterschickt und die Antworten dann wieder demaskiert und an den originalen Absender im Internet schickt ... (so als waere er der Web-Server)
rinetd ist ja irgendwo schon genannt worden. ipautofw waere vielleicht auch 'ne Variante.
Oder geht das garnicht mit Masquerading und ich brauch' so 'ne Art Proxy auf dem ersten Firewall ?
Squid kann sowas. Virtual Host Proxy oder so aehnlich -> @sysconfdir@/squid.conf
Best regards from currently Schwerin/Germany Viele Gruesse aus z.Z. Schwerin/MV Heiko Schlittermann
On Mon, Sep 18, 2000 at 09:57:55AM +0200, Heiko Schlittermann wrote:
Oder geht das garnicht mit Masquerading und ich brauch' so 'ne Art Proxy auf dem ersten Firewall ?
Squid kann sowas. Virtual Host Proxy oder so aehnlich -> @sysconfdir@/squid.conf
Noch ein potentiell unsicheres Riesenprogramm mehr auf der FW? Ich wuerde das nicht wollen.
Reinhard
Hallo!
Reinhard Foerster wrote:
Squid kann sowas. Virtual Host Proxy oder so aehnlich -> @sysconfdir@/squid.conf
Noch ein potentiell unsicheres Riesenprogramm mehr auf der FW? Ich wuerde das nicht wollen.
So unsicher ist Squid nicht. Es wechselt zur angegebenen UID (meist user=squid, group=squid) und arbeitet sehr zuverlässig. Man sollte nur das cachemgr.cgi sicher verwahren!
Gruss Reiner
On Mon, Sep 18, 2000 at 08:00:04PM +0200, Reiner Klaproth wrote:
Noch ein potentiell unsicheres Riesenprogramm mehr auf der FW? Ich wuerde das nicht wollen.
So unsicher ist Squid nicht. Es wechselt zur angegebenen UID (meist user=squid, group=squid) und arbeitet sehr zuverlässig. Man sollte
Na und? Falls jemand auf der FW squid/squid ist, ist er bereits drin. "arbeitet sehr zuverlässig" ist nicht ausreichend fuer Software auf einer FW. Programme mit tausenden Zeilen Code wie squid, bei denen dazu noch der Punkt Sicherheit nicht ganz oben auf der Liste steht, sind fuer eine ernstgemeinte FW absolut unbrauchbar. Abgesehen von der nichttrivialen Konfiguration und dem unueberschaubaren Umfang gab es beispielsweise mehrmals Bugs in Form falscher Interpretation der ACLs im Konfigfile. Squid wird eben gebaut, um eine möglichs schnelle Anbindung ans Web zu bekommen, alles andere ist Nebensache. Squid disqualifiziert sich somit völlig fuer den Einsatz auf der FW selbst. Falls es bei der FW lediglich um Kundenbefriedigung gehen sollte ist squid natuerlich super.
Reinhard
PS: Ich finde squid auch genial - nur sehe ich sein Einsatzgebiet etwas anders.
Hallo!
Reinhard Foerster wrote:
Squid kann sowas. Virtual Host Proxy oder so aehnlich -> @sysconfdir@/squid.conf
Noch ein potentiell unsicheres Riesenprogramm mehr auf der FW? Ich wuerde das nicht wollen.
So unsicher ist Squid nicht. Es wechselt zur angegebenen UID (meist user=squid, group=squid) und arbeitet sehr zuverlässig. Man sollte nur das cachemgr.cgi sicher verwahren!
Gruss Reiner
Heiko Schlittermann wrote:
Nun moechte ich aber schon bereits dem WebServer eine private IP Adresse geben, und den Firewall ins Internet ein Masquerading machen lassen (sowohl Verbindungen vom WebServer als auch ausgehende Verbindungen aus dem internen Netz, die ihrerseits schon ein Masquerading bei Firewall #2 hinter sich haben) ...
Nun, ob das notwendig ist, weiss ich nicht. Was versprichst Du Dir davon? Einziger Grund, der mir einfiele, waere, dass Du von Deinem Provider nur eine Adresse bekommen hast ...
Genau das ist der Fall. Jede weitere IP kostet bares Geld, und das habe ich nicht in rauhen Mengen ... Ausserdem reicht die eine IP auch voellig, da ja nur ein Web-Server (und andere Dienste wie DNS und Mail) zwischen den beiden Firewalls laufen sollen ...
Dein Webserver muss ja erreichbar sein -- und dann kannst Du den wohl so hinbekommen, dass er nach aussen lediglich den Port 80 zur Verfuegung stellt -- dazu kann/soll Dich ja Dein aeusserer Firewall unterstuetzen.
Genau. Ich wollte auf dem auesseren Firewall bei ipchains nur einkommende Verbindung fuer Port 80 zulassen ... Evtl. muss ich auch noch Port 53 UDP und TCP ausgehend aufmachen, weil ich ja hoechstwahrscheinlich einen internen DNS aufsetzen werde. Da ich nur eine IP habe, brauch' ich auch den DNS nicht nach draussen bekanntmachen. Und mit dem rinetd kann ich auch den Port 25 am Firewall zum Mail-Server durchstellen ...
Die grosse Frage: Wie konfiguriere ich einen Kernel 2.2.x mit ipchains so, das er eingehende Anfragen aus dem Internet auf Port 80, zuerst maskiert, an den WebServer auf Port 8080 weiterschickt und die Antworten dann wieder demaskiert und an den originalen Absender im Internet schickt ... (so als waere er der Web-Server)
rinetd ist ja irgendwo schon genannt worden. ipautofw waere vielleicht auch 'ne Variante.
Wie schon gesagt ... rinetd geht wunderbar ... Schade ist, dass ich mit dem kein Round-Robin machen kann, weil der IP-Adressen in seinem config file sehen will. (Falls soviel Traffic auf dem Web-Server anfaellt, das so eine Loesung Sinn macht)
Aber das kann man dem ja, wenn es denn soweit sein sollte, mit ein paar Zeilen C-Code beibringen kann ... (einfach mehrere IP's im config file und dann immer durchschalten)
Bye.
Jens
lug-dd@mailman.schlittermann.de
-
Heiko Schlittermann -
Jens Lorenz -
Jens Lorenz -
Reiner Klaproth -
Reinhard Foerster