wie is de beheerder van die server?
als je alleen een room huurt, huur je uptime. claim die bij de verhuurder.

als je een hele server huurt, is 25,- per maand peanuts, dus niet klagen als je monkey service krijgt.

als je in staat bent een firewall in te stellen, laat dit dan eens doen door iemand die ervaring met synfloods heeft...
de verhuurder wellicht?

probeer eens een packetfilter en filter de syn floods van de aanvaller uit. Als je server in een rack in een datacenter staat dan heeft de verhuurder er mogelijk ook last van of kun je terugzoeken waar de pakketten vandaan komen en die uit laten filteren op de eerste router waar die binnen komt. Niks geen dure oplossing maar simpelweg samenwerken want iedereen in het datacenter heeft hier baat bij.

windows...

"windows..."

Tja, en indien het OS linux was geweest, dan waren SYN floods nog evengoed mogelijk geweest. Bedankt voor je nutteloze bijdrage.

NAT bied bescherming tegen SYN floods door heel korte time-outs voor half open sessies in te stellen.

Zyxel firewall gebruiken :D

er is geen oplossing voor SYN flood, het hoeft niet perse spoofed te zijn.. 16kb per pakket, als je verbinding wilt maken stuurt hij als eerst een SYN flag, daarna verbreek je de verbinding, en maak opnieuw een verbinding aan.. als dit om een hoog aantal gaat.. vergeet het :), je kunt hooguit de IP's bannen (mits ze niet spoofed zijn)

Op Linux zijn SYN floods inderdaad ook evengoed mogelijk, alleen heb je dan out of the box wel veel meer mogelijkheden om er iets tegen te doen.

http://www.gotroot.com/tiki-index.php?page=Linux%20Firewall%20rules
http://tomicki.net/syn.flooding.php

Een simpele regel als eerste van de chain is dan vaak al voldoende namelijk.


Het is zaak de syn flood te detecteren en te droppen voordat deze in je buffer zitten te wachten op een ack.
Hoe dit bij een windows server gerealiseerd kan worden heb ik geen idee van, maar dat er iets voor gekocht moet worden dat vrij veel geld kost, sta ik niet van te kijken.

Toch denk ik dat wanneer je een firewall zou installeren en een dergelijke regel zou toepassen met een limit waardoor je service wel gewoon blijft werken, maar de packet floods je buffer niet kunnen vullen, je probleem minder groot zal zijn.

De grote vraag blijft altijd bij dit soort zaken, wie is er kwaad op je, waarom neemt iemand de moeite jou een probleem te bezorgen?

Een gewone synflood (alleen valse syn's, geen excessieve load in #packets/sec) is met syncookies prima tegen te gaan.
Het geeft wat beperkingen, dus je wilt het alleen gebruiken als je echt last hebt van een synflood.
De syncookie feature zit (oa) in de Linux kernel, sinds 1996 .

Een aanvaller kan meer soorten DoS'en doen dan synfloods, maar een synflood voor een behoorlijk OS gewoon een opgelost probleem.

Dus anoniem @12:41 had inderdaad gelijk, een gewone synflood is met Linux inderdaad prima op te vangen.

Zolang het totale verkeersvolume van de flood overigens beperkt blijft is de enige die er last van kan hebben de slachtoffer host. Een hoster (zeker een low budget hoster) gaat echt niet heel hard hollen voor een "mijn server is onbereikbaar vanwege 25 kbit pakketjes" probleem van een 25-euro klant.
Als die 25 eurp/m serverhuur is, kan de OP misschien het beste een linux server erbij huren, en die als firewall (of reverse proxy) voor z'n server inzetten, en op de linux bak behoorlijk firewallen en synfloods afhandelen.

@4 Ik ben het met je eens dat "windows" een redelijk nutteloze post is. Echter onder Linux is een syn attack redelijk eenvoudig tegen te gaan. Het commando "echo -n 1 > /proc/sys/net/ipv4/tcp_syncookies" en de aanval is geneutraliseerd. Die mogelijkheid zit er al in sinds 1997. Jouw post is dus niet zo zeer nutteloos als wel incorrect.

Ze schieten niet alleen op ons.
Ze pakken heel de toplist aan.
Dus persoonlijk is het zeker niet.
Vervelend des te meer.

Heb je hier nu ondertussen al iets aan gehad? Al iets gevonden om deze oplossingen naar windows te vertalen?

Of het nou windows is of linux, wat je er tegen kan doen is dus rate limiting.
Zodra de server moet reageren met syncookies of met w/e verstookt de server CPU cycles en dat wil je niet.
Het beste is een hardware matige firewall, maar op de L3 switch ervoor kun je ook makkelijk rate limiting instellen. Wellicht kun je dat eens vragen aan je hoster.

Geleuter, je begrijpt het verschil tussen rate limiting en syncookies niet. Noch een synflood, als je denk dat rate limiting helpt om je server bereikbaar te houden.
Syncookies zijn bijzonder licht op de CPU, en konden al in 1996 op wirespeed (100Mbit) werken.

Rate limiting zonder herkenning van valse syns is al helemaal zinloos, je rate-limit de echte syns even hard als de valse, en de valse zijn in de overgrote meerderheid. Nog steeds geen service dus voor je valide bezoekers want die hebben weinig kans om door de rate limiter te komen.

"hardware matige firewall" is meestal marketing speak voor een gewone CPU met OS, management frontend in een kastje, en functie van firewall. Zelfs als er echt wat asics bij zitten is dat meestal alleen voor packetfiltering en worden meer intelligente taken door de CPU gedaan.

Firewall of IPS systemen filteren dit met gemak voor je, maar goed, ook voor Windows zijn er wel settings te vinden om je TCP/IP stack te hardenen.

http://www.microsoft.com/downloads/details.aspx?FamilyID=12ac9780-17b5-480c-aef7-5c0bde9060b0&displaylang=en

"Op Linux zijn SYN floods inderdaad ook evengoed mogelijk, alleen heb je dan out of the box wel veel meer mogelijkheden om er iets tegen te doen."

Daar heb je verder natuurlijk volstrekt gelijk in. Ik wordt alleen allergisch van de mensen hier die pretenderen dat alle beveiligingsproblemen de wereld uit zijn zolang je maar linux gebruikt, zonder in te gaan op de verdere configuratie. Immers is security geen produkt wat je krijgt meegeleverd, maar een proces wat afhankelijk is van de maatregelen die je neemt, ongeacht het gebruikte OS.