Jump to content

DOS-Angriff von innen verhindern


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Wir haben folgendes Problem:

 

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?

Link zu diesem Kommentar

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...

 

mit internettem Gruß

 

dongel

Link zu diesem Kommentar
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.

Link zu diesem Kommentar

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?!?!

 

Verwirrt bin.

 

Gruss

Markus

Link zu diesem Kommentar

hallo,

 

Zitat:

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.

 

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!!??

 

mit internettem Gruß

 

dongel

Link zu diesem Kommentar

Vielen Dank erstmal für eure engagierte Hilfe!

 

Blacky_24 wrote:

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.

Link zu diesem Kommentar

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.

 

 

Gruß

Andre

Link zu diesem Kommentar

Velius:

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?

 

Ja, aber nicht ganz vollständig. Die vollständige Kette sieht wie folgt aus:

 

Endanwender-Browser will haben: 8080 -> Proxy-Settings in Browser leiten die Anfrage auf Viruswall, Port 80 um -> FW/80 -> VW/8080 - > FW/8080 ->|| Stadtplandienst/8080

 

Wenn Du mal in die Proxy-Einstellungen Deines Browsers (egal ob Netscape oder IE) reinschaust, dann siehst Du, daß Du dort nicht nur eine IP, sondern auch einen Port für den Proxy eingeben kannst. Dahin werden alle Anfragen umgeleitet. Erst der Proxy (hier: VW) selber stellt die Anfrage dann wieder auf dem eigentlich gewünschten Port an den Zielserver.

 

Operator:

Aber damit bekommst Du die halboffenen Verbindungen bis zu einem gewissen Grad weg.

 

Ok, das wäre ein Workaround. Meine ursprüngliche Frage war allerdings, ob sicherheitstechnisch etwas dagegen spricht, der Viruswall alle Ports nach außen zu erlauben. Das wäre nach meinem gegenwärtigen Eindruck nur dann gefährlich, wenn die Viruswall selbst erfolgreich angegriffen werden würde. Die ist jedoch hinter NAT versteckt und von außen nur über SMTP erreichbar, wobei dabei die Firewall noch die Korrektheit des SMTP-Protokolls überprüft, bevor sie die Anfragen an die Viruswall weiterleitet.

Link zu diesem Kommentar

Mir ist schon klar, dass du im IE auch auf Ports umleiten kannst, nur finde ich die Vorgehensweise etwas merkwürdig....

 

In deinem Fall ist die VW also im eigentlichen Sinne Proxy Server mit Virus Scan Funktion. Meine Frage wäre gewesen: Wieso nicht Port 80 auf der FW für die VW nach aussen öffnen? Aber scheinbar bist du jetzt selber darauf gekommen....

 

Gruss

Link zu diesem Kommentar

Hi,

 

also bevor ich alle Ports öffnen würde, würde ich mir das Logfile schnappen und schauen welche Ports denn alle betroffen sind.

 

Wenn es nur 3 wenige sind, gibst Du halt die frei und auch nur zu bestimmten Zielen. Das wäre das sicherste.

 

Zu Testzwecken kann man kurzfristig alle Ports outbound freigeben, aber eine Dauerlösung sollte das nicht sein.

 

Meine Meinung :)

 

Andre

Link zu diesem Kommentar

holla, da hast du ja ne lecker Firewall stehen!! Checkpoint is ja echt Klasse. Wenn wir hier um checkpoint und Viruswall reden, handelt es sich bei der Viruswall um eSafe??

 

wenn es nur das eine Ziel ist was solche Probleme bereitet, dann würde ich auch nur für diese Ziel die Checkpoint öffnen. Komplett aufmachen, halte ich für einen fatalen Fehler, damit knockst du die Firewall ja komplett aus!!! und zumindest ein Server in der DMZ ist komplett offen------- geht nicht!!! Das Widerspricht doch jedem Sicherheitskonzept. :suspect:

Und die andere Frage, ist diese Ziel denn so wichtig???

Ich meine, man sollte das genau abwägen, bloß wegen einer Webseite die Firewall aufzumachen!!! und stattdessen eine alternative Seite ansurfen, oder, dem Webmaster der entsprechenden Seite mal eine Mail schicken, ob die das nicht umstricken können und das ganz normal auf Port 80 laufen zu lassen. Immerhin bist du ja nicht der einzige der ne Firewall und einen Virusfilter verwendet. Ist für den Website Betreiber sicherlich nur ne Kleinigkeit dies abzuändern. Versuch isses wert!!! zudem auch ganz interessant was zurückkommt :) Zumal ja alle Firewalls ausgehend http(eben Port 80) aufhaben und Rest eben dicht. Wer soll denn dann diese Seite dann brauchbar nutzen können?? Da müsste ich ja schon Probleme ohne einen Viruswall haben!!! :cool:

Um welche Seite handelt es sich denn genau?? Kannst du mal die URL posten???

 

mit internettem Gruß

 

dongel

Link zu diesem Kommentar

Velius:

In deinem Fall ist die VW also im eigentlichen Sinne Proxy Server mit Virus Scan Funktion.

 

Das gilt für alle mir bekannten Anti-Virus-Gateways. Wie willst Du es anders technisch realisieren, den gesamten Traffic (HTTP und SMTP), der in Dein Netz hineinfließt, nach Viren zu scannen? Bezüglich Email könnte man vielleicht noch was direkt auf dem Mail-Server machen. Aber wenn Du HTTP transparent scannen möchtest, ist doch ein Proxy-Server die naheliegendste Lösung. Insofern ist das, was ich hier geschildert habe (mit Viruswall in DMZ der Firewall), die branchenübliche Konfiguration.

 

Velius:

Meine Frage wäre gewesen: Wieso nicht Port 80 auf der FW für die VW nach aussen öffnen?

 

Der war schon immer offen. :) Du meinst sicherlich 8080.

 

Velius:

Aber scheinbar bist du jetzt selber darauf gekommen....

 

"Jetzt"? Hmm... Lies doch mal bitte den ersten Satz des letzten Absatzes des Anfangstextes, mit dem ich diesen Thread eröffnet habe...

 

Nix für ungut, Velius, ich weiß Deine Bemühungen wirklich zu schätzen, aber bitte erst mal genau lesen, worum es bei der Frage eigentlich geht.

 

Operator:

also bevor ich alle Ports öffnen würde, würde ich mir das Logfile schnappen und schauen welche Ports denn alle betroffen sind.

 

Wenn es nur 3 wenige sind, gibst Du halt die frei und auch nur zu bestimmten Zielen. Das wäre das sicherste.

 

Na ja, das Problem ist, daß ich damit nur an den Symptomen doktere. Jeden Tag könnte ein Server mit einem anderen Port auftauchen, und ich merke das dann daran, daß der Internetzugang der ganzen Firma plötzlich nicht mehr funktioniert. Ich würde das Problem aus naheliegenden Gründen gerne stoppen, bevor es soweit kommt...

 

Wobei ich anhand der Firewall-Logs den Eindruck habe, daß es nicht der Endanwender-Client, sondern die Viruswall ist, die bei Ausbleiben der Antwort immer wieder neue Anfragen ins Netz schickt - und damit sich selber und/oder die Firewall mit den offenen Verbindungen ausbremst. Möglicherweise müßte man damit mal an den Hersteller herantreten...

 

dongel:

Wenn wir hier um checkpoint und Viruswall reden, handelt es sich bei der Viruswall um eSafe??

 

Nein, um eine TrendMicro InterScan VirusWall.

 

dongel:

Komplett aufmachen, halte ich für einen fatalen Fehler, damit knockst du die Firewall ja komplett aus!!! und zumindest ein Server in der DMZ ist komplett offen------- geht nicht!!!

 

Komplett offen würde ich nicht sagen. Nur offen für ausgehende Verbindungen. Solange niemand die Viruswall übernimmt, sollte das egal sein. Und zum Übernehmen bräuchte man eine eingehende Verbindung.

 

dongel:

Und die andere Frage, ist diese Ziel denn so wichtig???

Ich meine, man sollte das genau abwägen, bloß wegen einer Webseite die Firewall aufzumachen!!!

 

Wie gesagt, wenn ich sicher wüßte, daß es für alle Zeit nur diese eine Seite sein wird, würde ich mir was einfallen lassen. Aber jeden Tag kann eine andere Seite mit einem anderen Port auftauchen, die von irgendeinem ahnungslosen Anwender angesurft wird, und wenn dann jedesmal der gesamte Internetzugang der Firma zusammenbricht, dann ist das sch****.

 

dongel:

Ist für den Website Betreiber sicherlich nur ne Kleinigkeit dies abzuändern.

 

Noch nicht mal da bin ich mir so sicher. 8080 für Web-Server nimmt man meistens dann, wenn man mehrere Webserver auf einer Maschine zu laufen hat. Den Port 80 gibt's halt nur einmal. Möglicherweise würde das für ihn bedeuten, daß er sich einen weiteren Server hinstellen muß, und das ist nicht ganz ohne Aufwand für ihn. Und für mich würde das wie gesagt das Problem nur für diese eine Seite lösen, aber nicht prinzipiell.

 

dongel:

Um welche Seite handelt es sich denn genau?? Kannst du mal die URL posten???

 

Die steht detailliert im Anfangstext dieses Threads. ;)

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...