Is this relevant? QUOTE---Protect to 2 for the best protection against SYN attacks. This value adds additional delays to connection indications, and TCP connection requests quickly timeout when a SYN attack is in progress. This parameter is the recommended setting.
NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows
-----IIRC? This is called the "Silly Window Syndrome", & this is a way, in theory, around it... & iirc, "Scalable Windows", via setsockopt API calls from an attacker are what the problem is here anyhow & this ought to 'stall it'... thoughts/feedback?
APKP.S.=> Also, "hardcoding" the TcpWindowSize & GlobalTcpWindowSize settings in the registry in TCP/IP Parameters (see registry path above) SHOULD also help here also, for servers that can accept MANY connections from MANY clients, worldwide, as your specific constraints specify...
Thus, effectively stalling the ability to use TcpWindowScaling is stopped by SynAttackProtect too, so an attacking system/app sending a setsockopt of 0 for this SHOULD also be nullified, on a server also...
(However/Again - Workstations are easily taken care of , vs. servers, just by what I wrote up above either by PORT FILTERING)
IP Security Policies, which can work on ranges of addresses to block, OR, single systems as well you either ALLOW or DENY to talk to your system, still can help also... vs. a DDOS though? SynAttackProtect is your best friend here... you'd use netstat -b -n tcp to see which are held in a 1/2 open SYN-RECEIVE state, & BLOCK THOSE FROM SENDING YOUR WAY (or just by doing it in a router or routing table)... takers anyone, on these thoughts (especially for Windows 2000)?
Thanks for your time... apk UNQUOTE-- Source: http://tech.slashdot.org/comments.pl?sid=1368439&cid=29424787 Susan Bradley wrote:
It's not that they aren't supported per se, just that Microsoft has deemed the impact of DOS to be low, the ability to patch that platform impossible/difficult and thus have make a risk calculation accordingly.Sometimes the architecture is what it is. Jeffrey Walton wrote:Hi Susan,Read the bulletin. There's no patch. It is deemed by Microsoft to be oflow impact and thus no patch has been built.I don't know how I missed that XP/SP2 and above were not being patched. It appears that my two references are worhtless... I used to use them in position papers! * http://support.microsoft.com/gp/lifepolicy * http://support.microsoft.com/gp/lifeselect JeffOn Tue, Sep 15, 2009 at 5:24 PM, Susan Bradley <sbradcpa@xxxxxxxxxxx> wrote:Read the bulletin. There's no patch. It is deemed by Microsoft to be oflow impact and thus no patch has been built. Jeffrey Walton wrote:Hi Aras,Given that M$ has officially shot-down all current Windows XP users by not issuing a patch for a DoS level issue,Can you cite a reference? Unless Microsoft has changed their end of life policy [1], XP should be patched for security vulnerabilities until about 2014. Both XP Home and XP Pro's mainstream support ended in 4/2009, but extended support ends in 4/2014 [2]. Given that we know the end of extended support, take a look at bullet 17 of [1]: 17. What is the Security Update policy? Security updates will be available through the end of the Extended Support phase (five years of Mainstream Support plus five years of the Extended Support) at no additional cost for most products. Security updates will be posted on the Microsoft Update Web site during both the Mainstream and the Extended Support phase.I realize some of you might be tempted to relay the M$ BS about "not being feasible because it's a lot of work" rhetoric...Not at all. Jeff [1] http://support.microsoft.com/gp/lifepolicy [2] http://support.microsoft.com/gp/lifeselect On Tue, Sep 15, 2009 at 2:46 PM, Aras "Russ" Memisyazici <nowhere@xxxxxxxxxxx> wrote:Hello All: Given that M$ has officially shot-down all current Windows XP users by not issuing a patch for a DoS level issue, I'm now curious to find out whetheror not any brave souls out there are already working or willing to workon an open-source patch to remediate the issue within XP. I realize some of you might be tempted to relay the M$ BS about "not being feasible because it's a lot of work" rhetoric... I would just like to hear the thoughts of the true experts subscribed to these lists :) No harm in that is there? Aras "Russ" Memisyazici Systems Administrator Virginia Tech