Ein Anwender hat ohne bösen Willen an mehreren Tagen unsere Viruswall (Proxy-Server, der den gesamten HTTP-Datenverkehr nach Viren scannt) vorübergehend lahmgelegt und damit den HTTP-Internetzugang der Firma unbrauchbar gemacht.
Er hat einfach nur die Seite http://www.stadtplandienst.de/home.asp aufgerufen. Dies führt zunächst erwartungsgemäß zu einem HTTP-Zugriff (Port 80) auf den Server mit der IP 62.50.40.190.
Nun leitet dieser Server den Benutzer aber auf den Port 8080 um. Es kommt in der Folge also zu HTTP-Zugriffen auf 62.50.40.190, Port 8080. Dieser Port ist in unserer Firewall jedoch nicht geöffnet; die Zugriffe werden daher verworfen.
Offenbar ist nun die Stadtplandienstseite so programmiert, daß bei Ausbleiben der erwarteten Antwort immer neue Zugriffe auf 62.50.40.190, Port 8080 ausgelöst werden. Dies kann man sehr schön im Trace der Firewall verfolgen. Auf der Viruswall entstehen auf diese Weise immer mehr offene Verbindungen, bis sie irgendwann am Anschlag ankommt und keine Verbindungen mehr öffnen kann. Ist dieser Punkt erreicht, so lassen sich aus der gesamten Firma keine HTTP-Seiten mehr aufrufen. (Diese Erklärung für das Phänomen ist meine Theorie; wenn Sie eine andere Erklärung haben, die mit dem Symptomen konform geht, wäre das natürlich interessant.) Effektiv entspricht meine Theorie in der Auswirkung einem erfolgreichen DoS-Angriff auf unsere Viruswall, nur daß der Angriff unabsichtlich und von innen erfolgt (nämlich von dem Endanwender-PC, der immer wieder nach der HTTP-Seite auf Port 8080 verlangt).
Kurzfristig läßt sich Abhilfe schaffen, indem man sich auf der Viruswall einloggt und den HTTP-Dienst kurz aus- und wieder einschaltet. Die Frage ist natürlich, wie wir dies in Zukunft verhindern können. Für den Stadtplandienst könnten wir natürlich eine Regel definieren, die entweder Zugriffe auf diese IP ganz verbietet oder den Port 8080 für diese IP aufmacht. Aber das erscheint mir nur wie Kurieren am Symptom, denn es kann ja jederzeit eine andere Webseite geben, bei der dasselbe Phänomen auftritt.
An dieser Stelle stellt sich mir die Frage, ob es sicherheitstechnisch bedenklich wäre, der Viruswall generell Zugriffe auf Port 8080 zu erlauben. Wenn nein, wäre das ausreichend? Oder könnte das gleiche Problem jederzeit auch mit einem anderen Port auftreten? Wie geht man da am geschicktesten ran?
Hallo,
versteh ich nich so ganz, steht die Viruswall vor der Firewall??
Normalerweise müsste ja FW die 8080 einfach verwerfen und wenn die Viruswall hinter der FW steht dürfte es ja dann kein Problem machen. ODer alles auf einer Maschine?? aber auch dann...
Ist die FW sauber konfiguriert??
Wie sieht denn das Netzdesign aus??
tja , erstmal ein paar Fragen...
versteh ich nich so ganz, steht die Viruswall vor der Firewall??
Nein, dahinter. Genauer gesagt, in einer DMZ (einer richtigen DMZ, also nicht das, was viele DSL-Router fälschlich als DMZ bezeichnen).
Noch genauer erklärt läuft ein HTTP-Zugriff eines Endanwenders wie folgt ab:
Der Endanwender sitzt im internen Netz und stellt eine HTTP-Anfrage. Sein PC hat als Proxy für HTTP-Anfragen aller Art die Viruswall mit Port 80 eingetragen. Die Anfrage geht daher vom Endanwender-PC durch die Firewall in die DMZ und dort zur Viruswall. Die erzeugt eine eigene Anfrage gleichen Inhalts und schickt sie wieder durch die Firewall nach draußen ins Internet. Dabei setzt die Viruswall die Portnummer ggf. um: Während die Endanwender-PCs alle Anfragen auf Port 80 der Firewall schicken (weil das in den Proxy-Einstellungen des Netscape/IE/was auch immer so eingestellt ist), schickt die Viruswall die Anfrage auf dem eigentlich verlangten Port raus.
Die Antwort aus dem Internet geht dann durch die Firewall zur Viruswall, wird dort gescannt und bei Wohlgefallen zum Endanwender-PC weitergeleitet.
Normalerweise ist HTTP ja Port 80. Aber die o.g. Stadtplandienst-Seite leitet sofort auf eine andere Seite weiter, die zwar auch auf dem Stadtplandienst-Server liegt, aber dort auf Port 8080.
Ist die FW sauber konfiguriert??
Ich hoffe doch. Wobei "sauber" Ansichssache sein mag. Hier ist ja gerade die Frage, ob man der Viruswall erlauben sollte, auch andere Ports als 80 durch die Firewall hindurch anzufragen.
Eine "einfache" AdHoc-Lösung fällt mir da gerade nicht ein.
Im Prinzip ist das ja ein "erwünschtes" Verhalten der Firewall. Der eigentliche "Fehler" dürfte auf dem Webserver zu suchen sein (nicht dass der auf 8080 läuft sondern dass der permanent neue Sessions aufmacht). Ich vermute mal dass den Jemand administriert der keine Ahnung hat. Ist ja nicht nur so dass das HTTP-Relay in die Knie geht, auch der Webserver muss einiges an Ressourcen aufwänden um diese ganzen Sessions aufzubauen. Ggf. eine freundliche Mail an den Webmaster, ansonsten eventuell den Server einfach in der Firewall blocken, alternative Stadtplandienste gibt es etliche.
8080 ist im Webserverbereich ein recht gängiger Port. Wenn die Firewall nicht in der Lage ist, den Port-Redirect zu erkennen und den entsprechend zu behandeln könnte man den 8080 aufmachen zum HTTP-Relay.
Ansonsten könnte man auch noch etwas mit den Session-Timern und Session-Countern spielen (so das HTTP-Relay sowas hat).
GRÜBELMODUS ON: Wenn das HTTP-Relay in der DMZ steht muss der Traffic doch mindestens 1x durch die Firewall? Wenn die den Traffic aber blockt dürfte der doch garnicht erst bis zum HTTP-Relay kommen?!?!
sorry, ich kann dieses Problem nicht nachvollziehen -- bei mir kommt keine einzige Anfrage an Port 8080 zum Vorschein.
Könnte es sein, daß die Anfragen an Port 8080 clientseitig, z. B. durch ein JavaScript gesteuert werden?
Ich hoffe doch. Wobei "sauber" Ansichssache sein mag. Hier ist ja gerade die Frage, ob man der Viruswall erlauben sollte, auch andere Ports als 80 durch die Firewall hindurch anzufragen.
jau, das meinte ich damit. IMHO dürfte das portmapping auf 8080 gar nicht stattfinden und müsste an der FW hängen bleiben.
http ist eigentlich immer Port 80 und reicht fürs normale browsen auch völlig aus. Meine Firewalls bekommen immer nur ausgehend POrt 80 erlaubt und das langt!
Daher würd ich alle http Sachen blocken ausser ausgehend 80 und du dürftest das Problem nicht mehr haben.
Was für eine FW hast du denn im Einsatz? Mich wundert das die Viruswall überhaupt diesen POrt [8080]benutzen darf. Ich würd die Policy der FW nochmals durchdenken, hört sich nämlich ganz schön offen an.
Mich würd ja mal interessieren wie die Policy aussieht. Gibt es eine clean- up rule?? Vielleicht könntest du das ja mal posten!!??
GRÜBELMODUS ON: Wenn das HTTP-Relay in der DMZ steht muss der Traffic doch mindestens 1x durch die Firewall? Wenn die den Traffic aber blockt dürfte der doch garnicht erst bis zum HTTP-Relay kommen?!?!
Dieses Detail scheint hier von mehreren mißverstanden worden zu sein, daher nochmal Schritt für Schritt:
Browser will HTTP-Anfrage an Stadtplandienst, Port 8080, schicken
Auf dem Endanwender-Client ist jedoch ein HTTP-Proxy eingestellt, und zwar die Viruswall mit Port 80. Also schickt der Endanwender-Client die Anfrage dorthin.
Die Anfrage erreicht die Firewall. Es handelt sich um einen HTTP-Aufruf vom internen Netz an die Viruswall, Port 80. Das läßt die Firewall durch (normale Surfregel).
Die Viruswall erhält die Anfrage. Hier (und nicht in der Firewall) erfolgt das Port-Mapping, d.h. die Viruswall erkennt, daß die Anfrage eigentlich auf Stadtplandienst, Port 8080 gehen soll. Also schickt sie die Anfrage mit diesen Parametern an ihren Default-Gateway (nämlich die Firewall) in der Hoffnung, eine Antwort zu kriegen, die sie scannen und anschließend weiterleiten kann
Die Firewall erlaubt der Viruswall nur Anfragen nach außen auf Port 80. Daher verwirft sie das Paket. Die Viruswall erhält niemals die erwartete Antwort. Der Endanwender-PC natürlich auch nicht.
corc wrote:
sorry, ich kann dieses Problem nicht nachvollziehen -- bei mir kommt keine einzige Anfrage an Port 8080 zum Vorschein.
Könnte es sein, daß die Anfragen an Port 8080 clientseitig, z. B. durch ein JavaScript gesteuert werden?
Möglich, das habe ich nicht geprüft. Dieses Script wäre dann aber Bestandteil der o.g. Stadtplandienst-Seite. Damit würde sich an dem prinzipiellen Problem nichts ändern.
dongel wrote:
IMHO dürfte das portmapping auf 8080 gar nicht stattfinden und müsste an der FW hängen bleiben.
Genau das tut es auch. Darin liegt ja das Problem. Die erwartete Antwort bleibt aus, also gehen immer neue Anfragen raus.
dongel wrote:
Was für eine FW hast du denn im Einsatz?
CheckPoint Firewall NG FP3 HFA 325.
Operator wrote:
vielleicht gelingt es Dir hiermit die halboffenen Verbindungen rechtzeitig wieder zu schließen!
Sowohl die Viruswall als auch die Firewall laufen unter Linux. Damit scheiden Windows-Tipps aus.
Bin ich jetzt **** oder was, aber du sagst, dass die Viruswall, den Port 80 auf 8080 ummappt. Also im Prinzip machen alle Anfragen eine Schleiffe von FW/80 -> VW/8080 - > FW/8080
Ist das richtig?
P.S.: Wieso macht die VW (Viruswall) ein Portmapping? Läuft das Zeug auf dem selbben Rechner oder was?
Für Linux gibt es ebenfalls Einstellungen, was Timeouts von TCP-SYN angeht. Such mal nach SYN Flood Protection und Linux Security Denial of Service... Dabei sollte was zu finden sein.
Hab schon lange nix mehr in dieser Richtung an meinem Linux Router geändert, aber ich bin mir sicher, daß es nicht schwer ist das bei Linux einzustellen.
Aber damit bekommst Du die halboffenen Verbindungen bis zu einem gewissen Grad weg.
Eine Alternative wäre noch via iptables (oder jeder anderen Stateful Firewall) die Anzahl von TCP-SYNs pro IP pro Zeiteinheit zu begrenzen.
Damit könntest Du zum Beispiel sagen, daß pro Minute max. 100 neue Verbindungen geöffnet werden können. Ob dies jetzt ein sinniger Wert ist, kann ich Dir grad nicht sagen
Dazu würd ich die Leitung monitoren und mich an dir Durchschnittswerte + 20% richten.
XP - DOS-Angriff von innen verhindern
Genauer gesagt, in einer DMZ (einer richtigen DMZ, also nicht das, was viele DSL-Router fälschlich als DMZ bezeichnen).
