20
Windows Server vor SYN-Flood schützen
Moin-Moin!
Seit letzter Woche Donnerstag hat offenbar jemand im Internet entdeckt, dass man anderer Leute Server aus dem Internet schmeißen kann, indem man mit deren gespoofeter IP-Adresse SYN-Pakete an offene Ports (z.B. Port 80/TCP) an alle Server im Internet richtet und so gewaltige Paketraten erzeugt - denn auf ein SYN-Paket erfolgt ein SYN-ACK, und der wird 3-5 Mal wiederholt wenn dieser nicht bestätigt wird. Soviel als Präambel.
Das ist für die so als Reflektor/Verstärker missbrauchten Server auch normalerweise kein Problem.
Nun habe ich aber hier einen Kunden, der einen Windows-Server hier im Rechenzentrum stehen hat, welcher unter Windows 2012 R2 läuft und auf dem ca. 35 IPv4-Adressen konfiguriert sind.
Jede dieser IP-Adressen bekommt so ca. 30-40 SYN-Pakete in der Minute ab, was dem Server nicht weh tun würde. Aufgrund der vielen IP-Adressen bekommt der Server aber natürlich die 35-Fache Menge an Paketen und kämpft auf diese Weise mit ca. 1.400 SYN-Paketen pro Minute. Auch das ist aus meiner Sicht eigentlich etwas, was ein Server aushalten können muss.
Tut er aber nicht, stattdessen beginnt er irgendwann damit, die CPU voll auszulasten (100% CPU-Zeit entfallen auf PID 4, "System") bis das System nicht mehr reagiert und mit Gewalt neugestartet werden muss.
Sind nur 2-3 IP-Adressen konfiguriert tritt das Problem nicht auf. Dafür sind dann aber auch Dienste nicht erreichbar
Momentan filtere ich auf unserem Router teilweise den Traffic mit statischen Paketfilter-Regeln, damit der Server zumindest am Tag mehr Up- als Downtime hat. Aber das ist natürlich kein Zustand.
Schon alleine deshalb, weil die Source-IPs mit einer hohen Wahrscheinlichkeit auch wechseln werden
Da ich in der Windows-Welt überhaupt nicht mit solchen Szenarien vertraut bin:
Gibt es irgendwas, entweder direkte Windows-Funktionen oder als zusätzliche Software, was man konfigurieren kann damit Windows nicht ständig deswegen die Latschen aufstellt?
Ich bin mir nicht sicher, ob das wirklich ein Problem des TCP-Stacks ist oder ob der IIS da nicht vielleicht die Ursache setzt. Aber rein vom OSI-Modell her dürfte das eigentlich nicht passieren, denn da keine voll aufgebaute TCP-Verbindung zustande kommt, dürfte der IIS überhaupt nicht mitbekommen, dass da was auf Port 80 anklopft.
"Attackiert" wird Port 80/TCP, wo ein IIS Webseiten ausliefert. Attackiert wird er im engeren Sinne eigentlich nicht, es geht ja nur darum die SYN-ACK-Pakete vom Server in Richtung DDoS-Opfer zu bekommen
Virenscanner wurde schon testweise ausgeschaltet, als Firewall wird die Windows-Firewall verwendet. Die lässt aber Port 80/TCP natürlich eingehend zu, das ist schließlich Sinn und Zweck dieses Servers. Eine Hardware-Firewall ist nicht vorgschaltet.
Vielen Dank!
Seit letzter Woche Donnerstag hat offenbar jemand im Internet entdeckt, dass man anderer Leute Server aus dem Internet schmeißen kann, indem man mit deren gespoofeter IP-Adresse SYN-Pakete an offene Ports (z.B. Port 80/TCP) an alle Server im Internet richtet und so gewaltige Paketraten erzeugt - denn auf ein SYN-Paket erfolgt ein SYN-ACK, und der wird 3-5 Mal wiederholt wenn dieser nicht bestätigt wird. Soviel als Präambel.
Das ist für die so als Reflektor/Verstärker missbrauchten Server auch normalerweise kein Problem.
Nun habe ich aber hier einen Kunden, der einen Windows-Server hier im Rechenzentrum stehen hat, welcher unter Windows 2012 R2 läuft und auf dem ca. 35 IPv4-Adressen konfiguriert sind.
Jede dieser IP-Adressen bekommt so ca. 30-40 SYN-Pakete in der Minute ab, was dem Server nicht weh tun würde. Aufgrund der vielen IP-Adressen bekommt der Server aber natürlich die 35-Fache Menge an Paketen und kämpft auf diese Weise mit ca. 1.400 SYN-Paketen pro Minute. Auch das ist aus meiner Sicht eigentlich etwas, was ein Server aushalten können muss.
Tut er aber nicht, stattdessen beginnt er irgendwann damit, die CPU voll auszulasten (100% CPU-Zeit entfallen auf PID 4, "System") bis das System nicht mehr reagiert und mit Gewalt neugestartet werden muss.
Sind nur 2-3 IP-Adressen konfiguriert tritt das Problem nicht auf. Dafür sind dann aber auch Dienste nicht erreichbar
Momentan filtere ich auf unserem Router teilweise den Traffic mit statischen Paketfilter-Regeln, damit der Server zumindest am Tag mehr Up- als Downtime hat. Aber das ist natürlich kein Zustand.
Schon alleine deshalb, weil die Source-IPs mit einer hohen Wahrscheinlichkeit auch wechseln werden
Da ich in der Windows-Welt überhaupt nicht mit solchen Szenarien vertraut bin:
Gibt es irgendwas, entweder direkte Windows-Funktionen oder als zusätzliche Software, was man konfigurieren kann damit Windows nicht ständig deswegen die Latschen aufstellt?
Ich bin mir nicht sicher, ob das wirklich ein Problem des TCP-Stacks ist oder ob der IIS da nicht vielleicht die Ursache setzt. Aber rein vom OSI-Modell her dürfte das eigentlich nicht passieren, denn da keine voll aufgebaute TCP-Verbindung zustande kommt, dürfte der IIS überhaupt nicht mitbekommen, dass da was auf Port 80 anklopft.
"Attackiert" wird Port 80/TCP, wo ein IIS Webseiten ausliefert. Attackiert wird er im engeren Sinne eigentlich nicht, es geht ja nur darum die SYN-ACK-Pakete vom Server in Richtung DDoS-Opfer zu bekommen
Virenscanner wurde schon testweise ausgeschaltet, als Firewall wird die Windows-Firewall verwendet. Die lässt aber Port 80/TCP natürlich eingehend zu, das ist schließlich Sinn und Zweck dieses Servers. Eine Hardware-Firewall ist nicht vorgschaltet.
Vielen Dank!
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 388542
Url: https://administrator.de/forum/windows-server-vor-syn-flood-schuetzen-388542.html
Ausgedruckt am: 16.03.2025 um 09:03 Uhr
20 Kommentare
Neuester Kommentar
Hallo,
warum hat der Kunde denn so viele IPs auf einem Server? ZU welchem Zweck?
Firewall davor und gut und dann das Design neu zu machen.
warum hat der Kunde denn so viele IPs auf einem Server? ZU welchem Zweck?
Firewall davor und gut und dann das Design neu zu machen.
Zitat von @LordGurke:
Gibt es irgendwas, entweder direkte Windows-Funktionen oder als zusätzliche Software, was man konfigurieren kann damit Windows nicht ständig deswegen die Latschen aufstellt?
Gibt es irgendwas, entweder direkte Windows-Funktionen oder als zusätzliche Software, was man konfigurieren kann damit Windows nicht ständig deswegen die Latschen aufstellt?
Üblicherweise hängt man genau aus diesem Grund immer eine Firewall vor einen Server, insbesondere bei Windows-Servern.
lks
Die Anzahl der IP-Adressen hängt wohl mit HTTPS-Anwendungen zusammen, die nicht zwingend alle SNI können und deshalb über die IP separiert werden. Das ist zumindest die Begründung, die ich bekommen habe.
Das mit der Hardware-Firewall ist eine Sache - aber ich frage mich, wie die hier helfen würde.
Port 80/TCP soll ja aus dem Internet erreichbar sein, kann also nicht einfach weggefiltert werden. Die Source-IP-Adressen sind ja auch variierend und können nicht einfach per Blacklist gedropped werden.
Das Teil müsste diese Art SYN-Flood selbst erkennen und wegfiltern können, da frage ich mich dann aber, in welche Richtung Hardware ich resp. der Kunde da suchen müsste. Die muss ja dann genug Power haben um nicht selbst wie das Windows-Kästchen vollzulaufen.
Da habe ich mich seit Jahren nicht mehr mit beschäftigt, weil ich das inzwischen weitesgehend von unseren BigIrons erledigen lasse und derartige SYN-Floods die von mir administrierten Linux-Systeme nichtmal ansatzweise stören...
Und obendrein kann ich mir einfach nicht richtig vorstellen, dass jetzt alle per Software-Firewall geschützten Windows-Server bei Massenhostern aus dem Internet fallen, nur weil jemand viele SYN-Pakete schickt. Deswegen frage ich mich halt, ob da nicht irgendein Dienst oder eine Windows-Funktion eventuell dieses Problem bekanntermaßen verursachen könnte.
Das mit der Hardware-Firewall ist eine Sache - aber ich frage mich, wie die hier helfen würde.
Port 80/TCP soll ja aus dem Internet erreichbar sein, kann also nicht einfach weggefiltert werden. Die Source-IP-Adressen sind ja auch variierend und können nicht einfach per Blacklist gedropped werden.
Das Teil müsste diese Art SYN-Flood selbst erkennen und wegfiltern können, da frage ich mich dann aber, in welche Richtung Hardware ich resp. der Kunde da suchen müsste. Die muss ja dann genug Power haben um nicht selbst wie das Windows-Kästchen vollzulaufen.
Da habe ich mich seit Jahren nicht mehr mit beschäftigt, weil ich das inzwischen weitesgehend von unseren BigIrons erledigen lasse und derartige SYN-Floods die von mir administrierten Linux-Systeme nichtmal ansatzweise stören...
Und obendrein kann ich mir einfach nicht richtig vorstellen, dass jetzt alle per Software-Firewall geschützten Windows-Server bei Massenhostern aus dem Internet fallen, nur weil jemand viele SYN-Pakete schickt. Deswegen frage ich mich halt, ob da nicht irgendein Dienst oder eine Windows-Funktion eventuell dieses Problem bekanntermaßen verursachen könnte.
Servus,
entweder eine Firewall die das erkennt und die entsprechenden Sourcen zumindest temporär aussperrt. Wenn mehr als 1-2 Syn.Reqs kommen.
Ist aber in dem Fall nicht praktikabel. Für jede eingehende Verbindung belegt der Server ein Stück RAM, und die Summe macht es dann. Darum ist das eine DOS-Atacke gegen die man kaum etwas machen kann.
TCP Connection Timeout deutlich runter drehen. Eine andere Chance wirst Du sonst nicht haben.
Evtl auch einen sehr potenten Reverse-Proxy davor.
Ansonsten kannst Du nicht wirklich was machen, wenn die Dienste weiterhin auf einem Windowsserver erreichbar sein sollen.
Wenn die Atacken aus gewissen Regionen (bei gespooften Adressen schwer) kommen, würde ich auf alle Fälle mit dem Provider reden. So haben wir damals die Antenne Bayern am leben gehalten.
Grüße, Henere
entweder eine Firewall die das erkennt und die entsprechenden Sourcen zumindest temporär aussperrt. Wenn mehr als 1-2 Syn.Reqs kommen.
Ist aber in dem Fall nicht praktikabel. Für jede eingehende Verbindung belegt der Server ein Stück RAM, und die Summe macht es dann. Darum ist das eine DOS-Atacke gegen die man kaum etwas machen kann.
TCP Connection Timeout deutlich runter drehen. Eine andere Chance wirst Du sonst nicht haben.
Evtl auch einen sehr potenten Reverse-Proxy davor.
Ansonsten kannst Du nicht wirklich was machen, wenn die Dienste weiterhin auf einem Windowsserver erreichbar sein sollen.
Wenn die Atacken aus gewissen Regionen (bei gespooften Adressen schwer) kommen, würde ich auf alle Fälle mit dem Provider reden. So haben wir damals die Antenne Bayern am leben gehalten.
Grüße, Henere
Moin...
also als erstes würde ich mal prüfen ob der Server alle MS Updates hat, und natürlich von welcher Hardware reden wir eigentlich?
hast du das schon glesen?
Sync attack protection
How to protect Windows server from SYN flood
Tsunami SYN Flood attack
Syn attack protection on Windows Vista, Windows 2008, Windows 7, Windows 2008 R2, Windows 8/8.1, Windows 2012 and Windows 2012 R2
Frank
also als erstes würde ich mal prüfen ob der Server alle MS Updates hat, und natürlich von welcher Hardware reden wir eigentlich?
hast du das schon glesen?
Sync attack protection
How to protect Windows server from SYN flood
Tsunami SYN Flood attack
Syn attack protection on Windows Vista, Windows 2008, Windows 7, Windows 2008 R2, Windows 8/8.1, Windows 2012 and Windows 2012 R2
Frank
Moin,
Windows hat einen eingebauten Schutz - limitiert durch CPU-Power / RAM (https://blogs.technet.microsoft.com/nettracer/2010/06/01/syn-attack-prot ..)
Die einzige mir bekannte Methode, solche Angriffe wirklich in den Griff zu bekommen, ist massive Power. Diese bieten Anbieter wie Cloudflare https://www.cloudflare.com/learning/ddos/syn-flood-ddos-attack/
Gruß
Windows hat einen eingebauten Schutz - limitiert durch CPU-Power / RAM (https://blogs.technet.microsoft.com/nettracer/2010/06/01/syn-attack-prot ..)
Die einzige mir bekannte Methode, solche Angriffe wirklich in den Griff zu bekommen, ist massive Power. Diese bieten Anbieter wie Cloudflare https://www.cloudflare.com/learning/ddos/syn-flood-ddos-attack/
Gruß
und diese WebApps können nicht aufgesplittet werden?
Firewall (dazu gehört dann ein Reverse Proxy), wie beispielsweise eine Sophos und gut ist. da hast dann auch eine weitaus breitere Möglichkeit per IPS/IDS zu agieren - oder den Angreifer einfach auszusperren.
Bei konkreten Fragen, PN.
VG
Firewall (dazu gehört dann ein Reverse Proxy), wie beispielsweise eine Sophos und gut ist. da hast dann auch eine weitaus breitere Möglichkeit per IPS/IDS zu agieren - oder den Angreifer einfach auszusperren.
Bei konkreten Fragen, PN.
VG
Hallo,
auf einer Sophos UTM Firewall z.B. kann man u.a. TCP SYN Flood Protection aktivieren. Ab einer bestimmten Anzahl Pakete/s (einstellbar) wird dann gedrosselt, damit der Server dahinter nicht alles abbekommt.
Eine Sophos läßt sich auch virtuell als VM betreiben. Du kannst das ja mal mit einer 30-Tage-Testlizenz ausprobieren.
Just my 2c,
ipzipzap
auf einer Sophos UTM Firewall z.B. kann man u.a. TCP SYN Flood Protection aktivieren. Ab einer bestimmten Anzahl Pakete/s (einstellbar) wird dann gedrosselt, damit der Server dahinter nicht alles abbekommt.
Eine Sophos läßt sich auch virtuell als VM betreiben. Du kannst das ja mal mit einer 30-Tage-Testlizenz ausprobieren.
Just my 2c,
ipzipzap
Das kann nicht nur die sondern jede x-beliebige Firewall und auch Loadbalancer.
Der Knackpunkt sind sicher die 35 IP Adressen. Wenn die in einer L2 Broadcast Domain arbeiten wird das die Wurzel allen Übels sein wie der Kollege @certifiedit.net schon richtig gesagt hat.
Die Frage ist ob man dann mit hohem technischen Aufwand an den Symptomen rumdoktert oder gleich die Ursache bekämpft.
Der Knackpunkt sind sicher die 35 IP Adressen. Wenn die in einer L2 Broadcast Domain arbeiten wird das die Wurzel allen Übels sein wie der Kollege @certifiedit.net schon richtig gesagt hat.
Die Frage ist ob man dann mit hohem technischen Aufwand an den Symptomen rumdoktert oder gleich die Ursache bekämpft.
Moin,
danke erstmal für die Tipps.
Zu der Anzahl der Adressen: Diese haben wohl zum einen den Grund um mit Nicht-SNI-Kompatiblen Embedded-Systemen arbeiten zu können, aber wohl auch um im Falle eines L3/L4-DDoS den angegriffenen Dienst oder Kunden erkennen zu können.
Viel mehr Details habe ich allerdings momentan nicht, da ich das System nicht administriere sondern nur der Techniker aus dem hostenden Rechenzentrum bin
Das Konzept mit mehreren IPs pro Server aufgrund DDoS-Analyse ist allerdings auch bei von mir administrierten Webspace-Servern tatsächlich gängige Praxis (wenn auch da eher im Bereich von 6-8 IP-Adressen pro VM), da man so das eigentliche Ziel einer DDoS-Attacke leichter eingrenzen kann. Oder - wenn man schlechtestenfalls blackholen muss - nur ein möglichst kleiner Teil der Kunden betroffen ist.
35 IP-Adressen in einer Broadcast-Domain sind aus meiner Sicht kein grundsätzlich problematisches Layout. Der Server befindet sich in einem eigenen VLAN in dem nur dieses eine /26-Präfix geroutet wird - das ist so IMHO kein sonderlich großes Problem.
Problematisch ist wohl eher, dass diese 35 IP-Adressen auf einem einzigen Betriebssystem gebunden sind, was dafür offenbar einfach nicht ausgelegt ist.
Wir haben bereits versucht, Gegenmaßnahmen mit unseren Routern umzusetzen. Das Problem ist, dass die Paketrate pro einzelner IP so gering ist, dass die Schutzfunktionen fast nie anspringen und anfangen zu filtern. Stellt man die Empfindlichkeit höher, sperrt man dafür sehr häufig legitime Nutzer aus. Selbst als wir einen namhaften Anti-DDoS-Dienstleister davorgeschaltet haben, ist von denen nichts erkannt oder gefiltert worden. Vermutlich aus dem gleichen Grund.
Hat jemand Erfahrungen, ob beispielsweise Sophos den Traffic auf einem kompletten Subnetz als Referenz für die Pakektrate nehmen kann? Das ist etwas, was unseren Routern (oder deren Lizenz) leider komplett abgeht
Das Problem bei der ganzen Sache ist ja auch: Der Server ist eigentlich nicht Ziel einer DoS-Attacke. Er ist höchstens Kollateralschaden bei dem Versuch, jemand vollkommen anderen mittels SYN-ACK-Flooding zu attackieren.
Wenn ihr selber Server auf Port 80 betreibt könnt ihr ja mal Traffic von bspw. 149.56.180.252 beobachten - da werdet ihr auch zeitweise viele SYN-Pakete sehen
Dementsprechend ist die Paketrate halt sehr gering und die Diversität der Source-IPs auch, was die klassischen Anti-DDoS-Maßnahmen erstaunlich gut unterwandert.
Windows-Updates sind - soweit ich das beurteilen kann - alle installiert. Die letzten Updates wurden wohl diese Woche Dienstag installiert.
Ich empfehle dem Kunden jetzt mal, dass er sich testweise mal Sophos ansieht und irgendwo innerhalb seines VLANs installiert.
Oder wenigstens als erste Maßnahme die Anzahl der IP-Adressen pro Maschine reduziert.
danke erstmal für die Tipps.
Zu der Anzahl der Adressen: Diese haben wohl zum einen den Grund um mit Nicht-SNI-Kompatiblen Embedded-Systemen arbeiten zu können, aber wohl auch um im Falle eines L3/L4-DDoS den angegriffenen Dienst oder Kunden erkennen zu können.
Viel mehr Details habe ich allerdings momentan nicht, da ich das System nicht administriere sondern nur der Techniker aus dem hostenden Rechenzentrum bin
Das Konzept mit mehreren IPs pro Server aufgrund DDoS-Analyse ist allerdings auch bei von mir administrierten Webspace-Servern tatsächlich gängige Praxis (wenn auch da eher im Bereich von 6-8 IP-Adressen pro VM), da man so das eigentliche Ziel einer DDoS-Attacke leichter eingrenzen kann. Oder - wenn man schlechtestenfalls blackholen muss - nur ein möglichst kleiner Teil der Kunden betroffen ist.
35 IP-Adressen in einer Broadcast-Domain sind aus meiner Sicht kein grundsätzlich problematisches Layout. Der Server befindet sich in einem eigenen VLAN in dem nur dieses eine /26-Präfix geroutet wird - das ist so IMHO kein sonderlich großes Problem.
Problematisch ist wohl eher, dass diese 35 IP-Adressen auf einem einzigen Betriebssystem gebunden sind, was dafür offenbar einfach nicht ausgelegt ist.
Wir haben bereits versucht, Gegenmaßnahmen mit unseren Routern umzusetzen. Das Problem ist, dass die Paketrate pro einzelner IP so gering ist, dass die Schutzfunktionen fast nie anspringen und anfangen zu filtern. Stellt man die Empfindlichkeit höher, sperrt man dafür sehr häufig legitime Nutzer aus. Selbst als wir einen namhaften Anti-DDoS-Dienstleister davorgeschaltet haben, ist von denen nichts erkannt oder gefiltert worden. Vermutlich aus dem gleichen Grund.
Hat jemand Erfahrungen, ob beispielsweise Sophos den Traffic auf einem kompletten Subnetz als Referenz für die Pakektrate nehmen kann? Das ist etwas, was unseren Routern (oder deren Lizenz) leider komplett abgeht
Das Problem bei der ganzen Sache ist ja auch: Der Server ist eigentlich nicht Ziel einer DoS-Attacke. Er ist höchstens Kollateralschaden bei dem Versuch, jemand vollkommen anderen mittels SYN-ACK-Flooding zu attackieren.
Wenn ihr selber Server auf Port 80 betreibt könnt ihr ja mal Traffic von bspw. 149.56.180.252 beobachten - da werdet ihr auch zeitweise viele SYN-Pakete sehen
Dementsprechend ist die Paketrate halt sehr gering und die Diversität der Source-IPs auch, was die klassischen Anti-DDoS-Maßnahmen erstaunlich gut unterwandert.
Windows-Updates sind - soweit ich das beurteilen kann - alle installiert. Die letzten Updates wurden wohl diese Woche Dienstag installiert.
Ich empfehle dem Kunden jetzt mal, dass er sich testweise mal Sophos ansieht und irgendwo innerhalb seines VLANs installiert.
Oder wenigstens als erste Maßnahme die Anzahl der IP-Adressen pro Maschine reduziert.
Eine Sophos dafür virtuell zu betreiben ist ziemlicher Blödsinn, ok eigentlich in jedem Fall.
Zitat von @LordGurke:
Hat jemand Erfahrungen, ob beispielsweise Sophos den Traffic auf einem kompletten Subnetz als Referenz für die Pakektrate nehmen kann?
Hat jemand Erfahrungen, ob beispielsweise Sophos den Traffic auf einem kompletten Subnetz als Referenz für die Pakektrate nehmen kann?
Nein, das geht leider nicht. Du kannst zwar eine Paketrate einstellen, aber nur "über alles" und nicht nur für ein bestimmtes Subnetz.
Was Du machen könntest, ist, die Paketrate sehr niedrig zu stellen, und über Ausnahmen alle anderen Bereiche als den gewünschten rauszunehmen. Dann würde es zwar nur noch für das Subnetz gelten, allerdings hat dann der Rest keinen Schutz mehr. Als zeitlich begrenzte Testumgebung aber vorstellbar.
Zitat von @certifiedit.net:
Eine Sophos dafür virtuell zu betreiben ist ziemlicher Blödsinn, ok eigentlich in jedem Fall.
Eine Sophos dafür virtuell zu betreiben ist ziemlicher Blödsinn, ok eigentlich in jedem Fall.
Kann es sein, das Du immer alles nur schwarz und weiß siehst? Ja, eine Firewall gehört im Normalfall auf ein eigenes Blech, da stimme ich jedem sofort zu, aber eine virtualisierte Firewall direkt als Blödsinn zu bezeichnen?
Es kommt immer darauf an, was man damit bezwecken möchte. Wir betreiben z.B. für einen Kunden seit vielen Jahren ohne Probleme eine virtualisierte Sophos; allerdings nur in einem sehr eng gesteckten Szenario.
Aber sowas direkt zu verteufeln?
Schönen Sonntag noch,
ipzipzap
Zitat von @ipzipzap:
Nein, das geht leider nicht. Du kannst zwar eine Paketrate einstellen, aber nur "über alles" und nicht nur für ein bestimmtes Subnetz.
Nein, das geht leider nicht. Du kannst zwar eine Paketrate einstellen, aber nur "über alles" und nicht nur für ein bestimmtes Subnetz.
Das wäre schon perfekt!
Da der Kunde nur ein einziges Präfix von uns hat, hätte eine Filterung über alles ja den gleichen Effekt
Zitat von @certifiedit.net:
Eine Sophos dafür virtuell zu betreiben ist ziemlicher Blödsinn, ok eigentlich in jedem Fall.
Eine Sophos dafür virtuell zu betreiben ist ziemlicher Blödsinn, ok eigentlich in jedem Fall.
Kann es sein, das Du immer alles nur schwarz und weiß siehst? Ja, eine Firewall gehört im Normalfall auf ein eigenes Blech, da stimme ich jedem sofort zu, aber eine virtualisierte Firewall direkt als Blödsinn zu bezeichnen?
Von Virtualisierung habe ich ja vor allen Dingen überhaupt nicht gesprochen, insbesondere nicht, dass das auf der selben Hardware passieren soll
Eine Sophos läßt sich auch virtuell als VM betreiben. Du kannst das ja mal mit einer 30-Tage-Testlizenz ausprobieren.
kam vom Typen über dir
und bezugnehmend auf zu wenig Leistung bringt es auch nichts, wenn man die Sophos auf gleichem Blech betreibt. irgendwie, irgendwo, irgendwann kann das sicher Sinn machen, hier aber definitiv nicht.
Ich schrieb "läßt sich AUCH virtuell betreiben". Es war nur als ein Hinweis gedacht, wie man es mal testen könnte. Wenn er ein Blech dafür hat, umso besser.
So wie Audi auch nur getestet hat, nicht? Bringt Ihm in dem Fall aber überhaupt nichts, denn 3 Hände voll IP Adressen stellt man nicht mal kurz zum Spaß auf eine virtuelle Appliance um...- bringen tut's auch nix, denn offensichtlich ist dabei ein Lastproblem zu bewerkstelligen.
Kurzes Update dazu:
Der Kunde hat am Wochenende bereits ein paar Maßnahmen ergriffen und dabei die Anzahl der gebundenen IP-Adressen auf 5 Stück reduziert.
Dennoch ist das System heute Mittag wieder mehrfach vor die Wand gefahren, als da mal (in Summe über alle 5 IPs) ~15 SYN-Pakete pro Sekunde kamen. Dabei wieder 100% CPU-Last auf allen Kernen durch den Prozess "System", bis nichts mehr ging. Selbst der Cursor auf dem Bildschirm bewegte sich nicht mehr.
Eine H/W-Firewall ist noch nicht davorgeschaltet, das wird gerade erprobt.
Ich will ja Windows nicht grundsätzlich schlecht reden - aber das kann doch unmöglich normal sein, dass ein Betriebssystem, welches das Wort "Server" im Namen führt, damit nicht umgehen kann.
Zumindest habe ich schon virtuelle Linux-Systeme gehabt, die mit 1,4 Millionen SYNs pro Sekunde attackiert wurden und das ohne Filterung am Router klaglos überstanden haben...
Wir hatten die OnBoard-Netzwerkkarte im Verdacht und haben deshalb eine Intel Pro 1000 eingebaut - allerdings bringt auch das keine Verbesserung.
Ich frage mich jetzt: Kann es sein, dass a) der IIS, dessen Port 80 ja die Pakete abbekommt, eventuell unter der PID "System" arbeitet und b) dass dieser bereits bei nicht vollständig aufgebauten TCP-Verbindungen, also quasi beim ersten SYN, bereits aktiv wird?
Dass der IIS quasi das System komplett auslastet?
Halte ich für eher unwahrscheinlich, da ein Prozess normalerweise keine Verbindung signalisiert bekommt, wenn sie noch nicht vom TCP-Stack als aufgebaute Verbindung verfügbar ist - aber dem IIS traue ich ehrlich gesagt sowas zu
Der Kunde hat am Wochenende bereits ein paar Maßnahmen ergriffen und dabei die Anzahl der gebundenen IP-Adressen auf 5 Stück reduziert.
Dennoch ist das System heute Mittag wieder mehrfach vor die Wand gefahren, als da mal (in Summe über alle 5 IPs) ~15 SYN-Pakete pro Sekunde kamen. Dabei wieder 100% CPU-Last auf allen Kernen durch den Prozess "System", bis nichts mehr ging. Selbst der Cursor auf dem Bildschirm bewegte sich nicht mehr.
Eine H/W-Firewall ist noch nicht davorgeschaltet, das wird gerade erprobt.
Ich will ja Windows nicht grundsätzlich schlecht reden - aber das kann doch unmöglich normal sein, dass ein Betriebssystem, welches das Wort "Server" im Namen führt, damit nicht umgehen kann.
Zumindest habe ich schon virtuelle Linux-Systeme gehabt, die mit 1,4 Millionen SYNs pro Sekunde attackiert wurden und das ohne Filterung am Router klaglos überstanden haben...
Wir hatten die OnBoard-Netzwerkkarte im Verdacht und haben deshalb eine Intel Pro 1000 eingebaut - allerdings bringt auch das keine Verbesserung.
Ich frage mich jetzt: Kann es sein, dass a) der IIS, dessen Port 80 ja die Pakete abbekommt, eventuell unter der PID "System" arbeitet und b) dass dieser bereits bei nicht vollständig aufgebauten TCP-Verbindungen, also quasi beim ersten SYN, bereits aktiv wird?
Dass der IIS quasi das System komplett auslastet?
Halte ich für eher unwahrscheinlich, da ein Prozess normalerweise keine Verbindung signalisiert bekommt, wenn sie noch nicht vom TCP-Stack als aufgebaute Verbindung verfügbar ist - aber dem IIS traue ich ehrlich gesagt sowas zu
Zitat von @certifiedit.net:
So wie Audi auch nur getestet hat, nicht? Bringt Ihm in dem Fall aber überhaupt nichts, denn 3 Hände voll IP Adressen stellt man nicht mal kurz zum Spaß auf eine virtuelle Appliance um...- bringen tut's auch nix, denn offensichtlich ist dabei ein Lastproblem zu bewerkstelligen.
So wie Audi auch nur getestet hat, nicht? Bringt Ihm in dem Fall aber überhaupt nichts, denn 3 Hände voll IP Adressen stellt man nicht mal kurz zum Spaß auf eine virtuelle Appliance um...- bringen tut's auch nix, denn offensichtlich ist dabei ein Lastproblem zu bewerkstelligen.
Was hat Audi damit zu tun? Und wieso sollte das nichts bringen? Klar, auf Blech ist immer besser, aber auch virtuell kann man damit Lastprobleme lösen. Und man kann auch "3 Hände voll IP-Adressen" mal eben schnell umstellen. Ich weiß nicht, was Du damit immer für Probleme hast.
Aber ist gut jetzt. Du hast wie immer Deine festgefahrene Meinung und dabei lassen wir es. Das geht sonst am Thema vorbei, und das bring LordGurke auch nicht weiter.
Zitat von @LordGurke:
Dennoch ist das System heute Mittag wieder mehrfach vor die Wand gefahren, als da mal (in Summe über alle 5 IPs) ~15 SYN-Pakete pro Sekunde kamen. Dabei wieder 100% CPU-Last auf allen Kernen durch den Prozess "System", bis nichts mehr ging. Selbst der Cursor auf dem Bildschirm bewegte sich nicht mehr.
Dennoch ist das System heute Mittag wieder mehrfach vor die Wand gefahren, als da mal (in Summe über alle 5 IPs) ~15 SYN-Pakete pro Sekunde kamen. Dabei wieder 100% CPU-Last auf allen Kernen durch den Prozess "System", bis nichts mehr ging. Selbst der Cursor auf dem Bildschirm bewegte sich nicht mehr.
Also 15 Pakete/s halte ich jetzt für sehr ungewöhnlich. Das steht in der Sophos z.B. auf 100 Source Pakete/s oder 200 Destination/s. Hier würde die also nichtmal anspringen. Klar kann man das auf z.B. 10 Pakete/s ändern, aber das ist dann doch schon sehr niedrig.
Ich würde hier vielleicht mal auf der Maschine mit ProcMon aus den Sysinternals schauen, ob man nicht im "System" Prozess einen Thread identifizieren kann, der sich da hochschaukelt.
1
Nachtrag dazu:
Nachdem es einige Zeit ruhig war, haben die Probleme vor ein paar Wochen wieder angefangen.
Wohl auch hauptsächlich deshalb, weil das Volumen solcher SYN-ACK-Floods zugenommen hat.
Jedenfalls hat sich nun nach intensiver Suche herausgestellt, dass die Software "RDPGuard" wohl Verbindungen auf Port 80 getracked hat und von diesen ganzen SYN-Paketen schlicht überfordert war.
Seitdem der Dienst deaktiviert ist, hält der Server diese Pakete problemlos aus.
Nachdem es einige Zeit ruhig war, haben die Probleme vor ein paar Wochen wieder angefangen.
Wohl auch hauptsächlich deshalb, weil das Volumen solcher SYN-ACK-Floods zugenommen hat.
Jedenfalls hat sich nun nach intensiver Suche herausgestellt, dass die Software "RDPGuard" wohl Verbindungen auf Port 80 getracked hat und von diesen ganzen SYN-Paketen schlicht überfordert war.
Seitdem der Dienst deaktiviert ist, hält der Server diese Pakete problemlos aus.
