Hi, 20.09.2007 13:48,, Eric Scheen wrote::
Arno Lehmann schrieb:
Hi,
20.09.2007 08:57,, Eric Scheen wrote::
[...] Die Groupware ist auf einem Rechner installiert der im 192.168.1.0er Netz ist - ein zweites Interface der Maschine ist über DSL am I-Net (dynamische IP). Die Maschine arbeitet auch als Router für die anderen Rechner im LAN (Win XP), als DHCP Server und Samba läuft - DNS für das LAN ist nicht konfiguriert.
vor lauter Schreck vergessen: OpenSuse 10.1 Kernel 2.6.16.27
Die Groupware kann per Webinterface von den Rechnern aus dem LAN erreicht werden (so auch gewollt) von extern sollte dies nicht möglich sein - in der Firewall ist kein Port freigegeben und ein Portscan bestätigt mir das auch.
Schonmal sehr gut.
Nachdem ich mal spaßeshalber die aktuell zugewiesene IP Adresse der I-Net Schnittstelle eingegeben habe meldete sich zu meinem erstaunen das Webinterface der Groupware! Nach einem ersten Schreck und einem Blick in das Zugangsprotokoll musste ich feststellen das der Zugang von einer internen IP und nicht von extern erfolgte.
Frage ist nun: Wer oder was biegt mir meine Verbindung (durchaus passend) um?
Die Routingfunktionen.
Die Anfrage geht ja an <extIP> und wird als erstes an den Router geschickt, der nun zufällig auch der den Dienst bedienende Host ist.
Sie kommt am internen Interface an. Es wird festgestellt, das geroutet werden muss. Als nächstes wird festgestellt das das Ziel-Interface lokal vorhanden ist, also werden die Daten intern an den IP-Stack weitergegeben der für die <extIP> zuständig ist. Und da kommen sie quasi innerhalb der Firewall an.
Also die Maschine weiß mein Interface dsl0 hat die IP 87.189.210.120 und routet wenn von intern eine Anfrage dahin geht auf dsl0 um - wenn ich das jetzt richtig verstehe.
So ähnlich, nur dass tatsächlich nicht geroutet wird. Daten mit der <ExtIP> kommen auf einer Netzwerkkarte rein, der IP-Stack sieht dass das eine eigene Adresse ist, und schiebt die Daten quasi eine Ebene im Protokollstapel nach oben.
....aber...
Auf den Hinweis von Fred Ockert habe ich mir mal die Ausgabe von route -n angesehen
Destination Gateway Genmask Flags Metric Ref Use Iface 217.0.117.16 0.0.0.0 255.255.255.255 UH 0 0 0 dsl0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 217.0.117.16 0.0.0.0 UG 0 0 0 dsl0
nur taucht da zumindest nicht meine externe IP auf - müsste dsl0 nicht diese haben?
Hat dsl0 ja wahrscheinlich, nur kommt das hier nicht zum Tragen. Was der Routingeintrag bewirkt ist ja nur, dass Daten an <ExtIP> an das Interface dsl0 weitergereicht werden.
und noch ein traceroute 87.189.210.120 hinterher
traceroute to 87.189.210.120 (87.189.210.120), 30 hops max, 40 byte packets 1 p57B3FA66.dip.t-dialin.net (87.189.210.120) 0.000 ms 0.000 ms 0.000 ms
d.h. das ganze bleibt im Haus, oder?
Sieht so aus - ein Hop wäre ja in jedem Fall ein Interface das bei Dir zu finden ist.
Das ganze wird sogar verständlicher wenn man das ISO-Schichtenmodell kennt und sich überlegt, zwischen welchen Schichten die Firewall arbeiten kann. Aber das hier auszuführen würde wohl eine etwas längere Mail bedeuten, und ich hab' gar keine Zeit...
...ist mir als Telefoner prinzipiell bekannt - darum würde ein Schubs in die richtige Richtung vermutlich reichen ;-)
Na gut :-) Auf Layer 2 kommt das Datenpaket an. L2 kennt keine IP-Adressen, sondern stellt nur fest dass die PDU an die eigene MAC-Adresse geschickt ist. Also geht's einen Layer aufwärts. Auf L3 wird IP gesprochen. Hier merkt der IP-Stack dass die PDU an eine eigene Adresse gerichtet ist, also wird sie weiter nach oben gereicht. Auf L4 wartet nun der Apache mit einem Socket, das an *kein bestimmtes Interface gebunden* ist. Voilà, Ziel erreicht. Mehrere Abhilfen (wenn man dieses Verhalten nicht will) sind möglich: Apache nur auf dem internen Interface lauschen lassen. Das hätte den Effekt dass, sinngemäß, die Protokollstacks auf L4 nicht gemeinsam bearbeitet werden, sondern pro Interface unabhängige Sockets genutzt würden. Ergo würde ein Paket da nicht beim Apachen ankommen. Was die Firewalls betrifft gibt es ja mehrere Möglichkeiten. Auf jedem Layer kann eine Firewall bestimmte Filter einsetzen, z.B. im L2 auf MAC-Adressen filtern, in L3 auf IP-Ebene. Ein Interface ist definiert durch die L2-Adresse, denn an die Hardware kommt die Firewall weder ran noch könnte sie ggf. das Kabel kappen :-) Die gängigen Strategien sehen ja so aus, dass man für ein externes Interfaces bestimmte Sachen wegfiltert. Das heisst also, dass in deinem Beispiel eine Firewall im L4 arbeiten würde wenn du Traffic auf TCP-Port 80 blockst. Nur nur kommt der Traffic bei dir ja auf dem internen Interface rein... Also müsstest du auch auf dem internen Interface die Firewall den jeweiligen Traffic blocken. Natürlich nicht alles was an Port 80 geht - dann hättest du einen sehr sicheren Router :-) - sondern nur, was an die externe IP-Adresse und Port 80 gerichtet ist. Also sehr viel mehr und komplexere Regeln, ohne dass die einen Zugewinn an Sicherheit bringen. Um solcherlei Probleme zu vermeiden, und trotzdem überschaubare Regelsätze zu bekommen, nutzt man ja komplexere Firewall-Setups mit externer Firewall, DMZ, und interner Firewall. Hilft der Schubs? Arno -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org