Feeds

back to article Microsoft, Cisco issue patches for newfangled DoS exploit

Microsoft and Cisco have issued updates that protect against a new class of attack that requires very little bandwidth and can leave servers and routers paralyzed even after a flood of malicious data has stopped. The bug in the TCP, or transmission control protocol, was disclosed in October by security researchers Jack Louis and …

COMMENTS

This topic is closed for new posts.

This post has been deleted by a moderator

Flame

Well there one for flamebait...

...MS fix their product, Redhat provide no fix, only a workaround....

What a turnaround.

0
0
Gold badge

Re: flamebait.

I'm not so sure. I hate to speculate ahead of the "how it works" revelations, but it sounds like the vulnerability is inherent in the TCP standard.

If that proves to be the case, then Red Hat may well be doing the right thing by continuing to abide by the letter of the standard in the product and informing their customers how to configure bending the rules to eliminate the vulnerability if they so wish.

I'm going to cling to this theory for comfort as it leaves everything in the world in its usual places, Red Hat doing their best given the conflicting drivers and M$ just going with b0rking the standard as per usual.

0
0
Linux

Re: flaimbait

This is the third TCP vulnerability that's crossed my desk in as many weeks. I haven't looked closely at the details or the vulnerability but I strongly suspect that this is just another of the ones for which a properly configured firewall can stop the attacker in their tracks and, importantly, you get to identify the attacker so you can send the boys round.

I think Red Hat are doing the right thing here.

0
0
Gates Horns

No fix for Win2K

Microsoft's KB article on this vulnerability says that they're not fixing this issue for Win2K..... yeah, I know it's an old OS, but some of us still use it and it is still supported by Microsoft.

"The architecture to properly support TCP/IP protection does not exist on Microsoft Windows 2000 systems, making it infeasible to build the fix for Microsoft Windows 2000 Service Pack 4 to eliminate the vulnerability. To do so would require rearchitecting a very significant amount of the Microsoft Windows 2000 Service Pack 4 operating system, not just the affected component. The product of such a rearchitecture effort would be sufficiently incompatible with Microsoft Windows 2000 Service Pack 4 that there would be no assurance that applications designed to run on Microsoft Windows 2000 Service Pack 4 would continue to operate on the updated system."

0
0

This post has been deleted by a moderator

Flame

Falmebait, but for a different reason

The full writeup on the vulnerability has just been posted on BUGTRAQ and off the top of my head most Unixes will not be vulnerable to it because they do not disable TCP timers in a TCP zero-window state after the app has closed the socket.

The control portion of Juniper software stack is FreeBSD derived from the days of version 3.x so it should not be vulnerable. If I correctly remember the source (cannot be bothered to look at it right now) it still has the timer running in that case so it will kill the connection.

Neither should be Linux because the fixes for the various old FIN resource exhaustion vulnerabilities should deal with this. On top of that Linux actually has a few recent "special" fixes to deal with zero-window and broken window scaling attacks which should catch that as well.

0
0
Pint

@Anton

Juniper have various different o/s, not all of which are derived from FreeBSD, eg ScreenOS, JunOS etc.

0
0
Thumb Down

@AC from wed 10:11

"I strongly suspect that this is just another of the ones for which a properly configured firewall can stop the attacker in their tracks"

You're wrong. Checkpoint and CIsco (among others) make firewalls, and have released or are to release patches for this vuln, which affects them. Don't just guess at whether you're vulnerable or not, find out.

0
0
APK

PORT FILTERING stops this for Windows 2000 users

See subject-line, & this quote from the pages @ MS on how to "mitigate" this type of attack (easily done really):

http://www.microsoft.com/technet/security/Bulletin/MS09-048.mspx

"To help protect from network-based attempts to exploit this vulnerability, enable advanced TCP/IP filtering on systems that support this feature"

I cover how to do that (& really, EVERYONE should on Windows 2000/XP/Server 2003, because it acts as another "layer" of defense, for "layered security" above & beyond std. firewalling, because it uses ipfltdrv.sys, which acts PERFECTLY FINE alongside all other defenses)

I cover a LOT of this here, & IP FILTERING'S VERY EASY TO SETUP (you may want to refer to the IANA ports list though, for YOUR particular needs, it does help):

-----

HOW TO SECURE Windows 2000/XP/Server 2003 & even VISTA, plus, make it "Fun-to-Do", via CIS Tool Guidance (& beyond):

http://www.tcmagazine.com/forums/index.php?s=33555fc937017deab726a927c1c4a7fd&showtopic=2662

(You MAY want to look @ points #3 - #5 there, they cover IP Filtering, IPSec, & more... specifically in regards to this, & protecting yourself vs. it, on Windows 2000... it SHOULD work, according to MS, & it is JUST GOOD "LAYERED SECURITY" anyhow!)

-----

Now, the IP FILTERING (ipfltdrv.sys) works PERFECTLY FINE alongside ipnat.sys (firewall driver), & ipsec.sys (IP Security Policies) too... all of them, alongside TCP FILTERING, work fine "all @ once"/"concurrently"... + of course, alongside tcpip.sys, the base IP driver)

The 3 other drivers work @ DIFFERENT LAYERS of the IP stack around tcpip.sys, making them function PRETTY MUCH like a "Zone Defense"/"Greek Phalanx", so if you take 1 down? The others are STILL IN THE WAY... it's neat - too bad MS did away with that w/ VISTA onwards now using the single layer (& thus, single "lock" only) WFP + NDIS6, which even the folks @ ROOTKIT.COM are stating is "much easier to unhook & bypass" vs. the older model whose architecture I just laid out...))

APK

P.S.=> Enjoy, that OUGHT to help you Windows 2000 folks out there, vs. this "bug"... do I think MS could fix it? Sure, but it'd "hurt business"... & I truly DO think that is why MS is not fixing it - to drive away those that use Windows 2000 from it, so they have to buy a newer OS (even though MS said they'd support & patch Windows 2000 for security bugs until, iirc 2011++ or so).

Well, in this post up there? That is your "rescue parachute" fix, for those of you that utilize Windows 2000 (one of those folks here myself,)

I use Windows 2000, & Windows Server 2003... with good reasons, especially on the latter model (the foundation code of VISTA, the GOOD parts). Win2k3's MS' BEST OS to date!

(No DRM, no WGA, no OpenGL ICD hassles, & a 3 part/driver based security system (vs. NDIS6 + WFP on VIsta onwards) + a HOSTS file that can STILL use the smaller, & faster + more efficient 0, vs. 0.0.0.0 or worse yet, 127.0.0.1 (Which Windows 2000, XP, & Server 2003 can STILL do, & do right unlike VISTA onwards))

Still, Win2k users need not fear: Courtesy of "yours truly", above & MS too on this one, as it is an easy, working fix.

NOW - IF Microsoft would only replace RDR20.DLL (Windows 2000's LSP) with MSWSOCK.DLL (for LSP/Layered Service Providers for the rest of MS' Windows NT-based Operating System family), I think it really could be fixed imo, & w/out using PORT FILTERING (Still a good layered security measure though)... but, "that's business" for you! apk

0
0
Thumb Down

@APK

You've completely misunderstood this vulnerability. If you have a 2k server which listens for connections on port 445 or 139 for shares, or it hosts a webserver on port 80 or 443, or it's a mailserver on port 25, you can't filter those ports, because they need to be open. So you're vulnerable to this issue.

0
0
APK

@AC - For Servers, you have a point, but otherwise no + IANA ports list usage... apk

WELL - per your reply & my subject-line above? It depends on how you use your system & THAT is why I noted the use of the IANA ports list in my last post (see the part where I note IANA & "your particular needs" above).

Yes - That COULD/MIGHT be a caveat for those running servers (webservers, ftp servers, mail servers, etc. et al - because in those cases, you'd be correct - they have to solicit connections on said ports & on THEIR server systems (or workstations acting as servers)) just as you noted...

Same again also, for those who use fileshares (for internal home networks, OR, those in corporate environs) which are driven on the ports you noted, via LanMan/NetBIOS networking (via Client for Microsoft Networks + Windows File & Printer sharing & Server service etc.)

HOWEVER- Otherwise, if you are a "stand-alone" single machine user (connected to the internet especially)?

This can, & does, actually work.

APK

P.S.=> What "upsets me" (well, not really, but... you know what I mean) the most about it though, is that MS should and most likely, COULD fix it!

Again - I suspect the problem is in (@ least in part) the RDR20.DLL lib/dll used in Windows 2000 (for LSP/Layered Service Provider for TCP/IP), vs. MSWSOCK.DLL lib/dll used in Windows XP/Server 2003 etc. et al (post Windows 2000 versions of Windows NT-based OS by MS)

(I say that much above now, because offhand, it is the ONLY part of the IP stack I could see that was "radically different" in that it uses a diff. named library/DLL than the others)

Plus - MS "backports" features from VISTA & Windows Server 2003 to XP for instance, like TcpChimney, quite a lot... why not THIS time? Some "Food 4 Thought", on that account... apk

0
0
APK

Incidentally? DO notice that Microsoft ALSO says, TCP/IP Filtering WORKS to stop this

See my subject-line Anton, & the first post I did above's URL & pertinent quote (from "the horses' mouth" in MS, no less)

APK

0
0
APK

@AC - Microsoft apparently has "misunderstood" also, see the url above in my 1st post

"You've completely misunderstood this vulnerability" - By Anonymous Coward Posted Friday 11th September 2009 10:00 GMT

----

Apparently Microsoft has also "misunderstood" it also, "oddly enough": See this URL from my 1st post above, and what it states verbatim in this quote from it:

http://www.microsoft.com/technet/security/Bulletin/MS09-048.mspx

"To help protect from network-based attempts to exploit this vulnerability, enable advanced TCP/IP filtering on systems that support this feature"

-----

Additionally/again - realize that I noted that folks SHOULD use the IANA ports list for their own "particular needs" in my FIRST post here.

(I say that, because you do have a point in your post, albeit I covered it in that statement (perhaps I assumed too much in being so general, so I responded as I did in my 2nd post above)).

Thanks for your time.

APK

0
0
Joke

@APK

You're not Steve Gibson in disguise, are you?

0
0
APK

@untruenorth: No, I am not - why do you ask that?

See my subject-line above, & answer my question please... thanks for your time.

APK

P.S.=> Additionally?? If you have objections to ANY of the points I raised above (such as HOSTS 0, vs. 0.0.0.0 or 127.0.0.1, or the WFP/NDIS6 vs. the older Windows' editions use of a 3 part system for that (vs. the now apparently SINGLE part WFP only), OR even this last issue on PORT FILTERING being useful, how & when??? Do voice you objection & we can discuss it rationally, hopefully - we ALL can gain by such discussions (because I can provide examples that allow you to test for some of them, such as my points on HOSTS files above))... apk

0
0
Thumb Down

@APK, what's with all the "punctuation"?

See subject-line above and answer please

Why do you KEEP CAPITALISING things "which" don't require it or "put things" within quotation marks when quoting "doesn't help" convey any extra meaning?

Basically you're saying don't allow any TCP connections to the box, and you're laughing. That's fine as far as it goes, but unrealistic. Almost all networked servers require you to make TCP connections to them, so those network servers are vulnerable to this, and your mitigation advice is useless.

Incidentally, microsoft didn't misunderstand the vulnerability, they suggested that as a mitigation because they basically don't have one, and when that happens they suggest stupid things so that people who don't pay attention think there's a workaround. There isn't.

0
0
APK

@AC: Because Microsoft said the same thing I have, see above quote from they

"Why do you KEEP CAPITALISING things "which" don't require it or "put things" within quotation marks when quoting "doesn't help" convey any extra meaning?" - By Anonymous Coward Posted Monday 14th September 2009 16:40 GMT

Well, you apparently can read what I wrote, just fine, regardless of the use of caps on my part (that is just for emphasis only, since I cannot use bold here afaik). - & how YOU perceive it, or interpret it? May not be how everyone else does... so, get over it, & thanks.

(I'd suggest getting your PHD in English, prior to telling others how to write, because your missing I noted the IANA ports list for folks "particular needs" in my 1st post completely nullfies this b.s. you are wasting mine & others' time on here in your further replies).

----

"Basically you're saying don't allow any TCP connections to the box, and you're laughing. That's fine as far as it goes, but unrealistic. Almost all networked servers require you to make TCP connections to them, so those network servers are vulnerable to this, and your mitigation advice is useless." - By Anonymous Coward Posted Monday 14th September 2009 16:40 GMT

No, you are perceiving & interpreting things wrong again - did I not:

1.) Note that one should refer to the IANA ports list, for how one might need to for THEIR PARTICULAR NEEDS? YES, I did.

2.) Did I not elucidate & specify further that those that run servers (webservers, fileservers, ftp servers, etc. et al) above ought to pay attention to this & understand it MAY affect those shares & servers adversely?? YES, I did...

3.) Does or does not Microsoft recommend PORT FILTERING as a mitigator of this issue?? YES, they do....

(I suggest you stop INTENTIONALLY MISINTERPRETING that which I wrote, because anyone is free to verify my 3 statements just now in my list just above this sentence as to their veracity, right in this very exchange no less).

APK

P.S.=> And, before you comment on others' writing? Learn to READ on your part, first, & to interpret things correctly, by not 'skimming' over things!

(As you had obviously, when you omitted that I noted the IANA ports list (which tells folks which ports are needed for what, & for their PARTICULAR NEEDS - which may be servers of various kinds))... apk

0
0
APK

@AC - Take a read, & if you do not like how I write? DON'T READ IT: Simple... apk

First of all, see my subject-line above.

Secondly: I would also like to know where you said I was "laughing" about this & where I said to block ALL PORTS... can you show us this much? Because if you cannot?? That's accusing me of something I did not state, period.

"so those network servers are vulnerable to this, and your mitigation advice is useless." - By Anonymous Coward Posted Monday 14th September 2009 16:40 GMT

That's for servers, not workstations - & face it: MOST folks use workstations, not servers. It's Microsoft's advice, I have merely suggested it as "layered security" for others, per the SECURITY GUIDE I put up above, which is GEARED TO STAND-ALONE SYSTEMS ONLINE (for lack of a better expression? The home user with a single machine in other words).

Now - I stated that much above, as far as servers (per my suggestion folks refer to the IANA ports list, because it can tell them which ports are needed & for what type of server, in my very first post) - care to deny this??

See - I interpret your attempts @ nitpicking as poor here, & I do suspect trolling on your part, so in my next post(s) I was more SPECIFIC later, per your points, like next below:

E.G.-> Yes - The use of PORT FILTERING MIGHT be a caveat for those running servers!

(Webservers port 80/8080/443, ftp servers ports 21-22 typically (can be others), mail servers on ports 25/110, etc. et al )

I say that, because as you said- in those cases, you'd be harming them possibly & that is, as you say, because they have to solicit connections on said ports & on THEIR server systems (or workstations acting as servers) as I said above. I figured MOST of you would infer that, via my mentioning the IANA ports list... I guess not though, eh?

Same again also, for those who use fileshares (for internal home networks, OR, those in corporate environs) which are driven on the LanMan/NetBIOS networking in Windows (via Client for Microsoft Networks + Windows File & Printer sharing & Server service etc., which use ports 139 & 445 iirc)

QUESTION - Do you know what the IANA ports list is for???

HOWEVER- Otherwise, if you are a "stand-alone" single machine user (connected to the internet especially)? This can, & does, actually work.

APK

P.S.=> That's again, pretty much what I said above, with yet even MORE specifics. As to this statement from you:

"Incidentally, microsoft didn't misunderstand the vulnerability, they suggested that as a mitigation because they basically don't have one, and when that happens they suggest stupid things so that people who don't pay attention think there's a workaround. There isn't." - By Anonymous Coward Posted Monday 14th September 2009 16:40 GMT

YOU DON'T PAY ATTENTION, & YOU SKIM - again, do you know what the IANA PORTS LIST IS FOR????

For servers? Possibly not, depending on what the server is up to, it may not work..., unless you look to IPSecurity Policies!

(That's where you can specifically LIMIT what comes in & out of your system, with finer 'granularity' than you can using PORT FILTERING offers, but it is harder to work with, but my guide above in my 1st post covers that too)...

I.E..-> You can limit what systems (IP Addresses) can "talk" to your machine if you wish, via IP Security Policies...

(AND, if this "malware" does any "talk back" to the "mothership" (a command & control server)? You can stall that via IPSecurity Policies too)

OR

Even add those "command & control servers" a malware may use, to a HOSTS file to block them (using 0, 0.0.0.0, or 127.0.0.1 in front of their hostnames, assuming they use those, & they usually do - because using a hardcoded IP is foolish for a botmaster really, because they get 'taken down" fast usually by the ISP or hosting provider for them... they instead tend to rely on domain names/hostnames because they can be quickly re-registered @ another ISP or hosting provider & use the SAME hostname/domainname) OR, even to your routing tables to block them out.. apk

0
0
FAIL

Wow

Ok, walk us through how to use "IPSecurity Policies" to protect a mail server from this vulnerability. Bear in mind it needs to accept SMTP email from anywhere on the internet. No? Ok, thanks for playing.

The point you consistently miss is that if you allow any TCP connection to the box AT ALL the vulnerability can be exploited.

The IANA Port list is irrelevant because the port number you allow is utterly irrelevant. If you don't get that then you've missed how the exploit works.

There are very few situations where configuring a server not to accept any TCP connections is a useful server configuration.

So basically you're suggesting a complicated way to "mitigate" attacks on a standalone workstation which does no sharing on a home network. Which would be more easily achieved by putting it behind a nat device, such as a router. Like everyone uses to get to the internet.

Also, this is a DoS attack. It's not "malware" "talking back" to a "mothership" (a ... mothership?)

Try to pay attention.

0
0
APK

@AC - Short version = SynAttackProtect

"Also, this is a DoS attack" - By Anonymous Coward Posted Tuesday 15th September 2009 09:23 GMT

Fine, that's taken care of by the SynAttackProtect setting here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

What does it do??

http://msdn.microsoft.com/en-us/library/aa302363.aspx

Description: When SynAttackProtect is enabled, this value specifies the threshold of TCP connections in the SYN_RCVD state. When SynAttackProtect is exceeded, SYN flood protection is triggered.

This registry value causes Transmission Control Protocol (TCP) to adjust retransmission of SYN-ACKS. When you configure this value, the connection responses time out more quickly in the event of a SYN attack (a type of denial of service attack).

2: Set SynAttackProtect 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

-----

Oh, & by the way?

AGAIN - Where are those quotes of my laughing about this, and my saying I said to BLOCK ALL PORTS, as you stated?

You put words in my mouth I never stated, so, where did I ever say them??

APK

P.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 app sending a setsockopt of 0 for this SHOULD also be nullified, on a server...

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

0
0
FAIL

@ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

The above registry key does not mitigate the attack described in the article.

It mitigates TCP connections in a SYN-RECV state. That is not how this DoS attack works.

Please please stop, read about the attack, and understand how it works before commenting further.

0
0
APK

@AC: Read these articles on "Silly Window Syndrome", TcpWindowSize, & SynAttackProtect, ok?

"It mitigates TCP connections in a SYN-RECV state" - By Anonymous Coward Posted Tuesday 15th September 2009 12:31 GMT

So what? You do a netstat -n -b TCP and see what's "hanging" in a RCVD/RECV state, & block it out via IP Security Policies then & that can be done in ranges as well... which netstat with those parameters (netstat -b -n WILL show you).

I still would think this much, though, ontop of that, so read on:

"Please please stop, read about the attack, and understand how it works before commenting further." - By Anonymous Coward Posted Tuesday 15th September 2009 12:31 GMT

Why don't you do the same, & read this much:

http://msdn.microsoft.com/en-us/library/aa302363.aspx

Description: When SynAttackProtect is enabled, this value specifies the threshold of TCP connections in the SYN_RCVD state. When SynAttackProtect is exceeded, SYN flood protection is triggered.

KEYWORD = SYN_RCVD

AND

"The above registry key does not mitigate the attack described in the article" - By Anonymous Coward Posted Tuesday 15th September 2009 12:31 GMT

TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems:

KEYWORD = SLIDING WINDOW SYSTEM (for TCP/IP)

http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm [tcpipguide.com]

PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."

Which, per the setsockopt 0 call & parameter? Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!

----

Again - please, read the above, and take YOUR OWN ADVICE:

Reading the above article(s) especially & its KEY POINT/CONCEPTS, quoted from both above... & about how setsockopt 0 is used in attacks of this nature, on this vulnerability in Windows 2000.

APK

P.S.=> I.E.-> By setting a non-scaling TcpWindowSize, that should be enough to stall out the setsockopt 0 calls an attacking DDOS/DOS program would use, to set a SMALL Window size, & that is even for server-class systems!

That, alongsize using SynAttackProtect, which STOPS TCP WINDOW SCALING (vs. this "silly window syndrome" style attack - because it sounds like it IS using that much, via setsockopt 0) should help also, especially vs. DOS/DDOS attacks... apk

0
0
Troll

Ah, I get it now

Finally I twig. Troll.

It was the way you went from a registry key which helps protect against SYN-Floods to an entirely unrelated discussion of modern TCP stacks protecting against silly window syndrome, as if they were in some way related concepts, and as if they were somehow relevant to the Dos attack described in the article.

I'll cheerfully stop now. Enjoy the view from the bridge.

0
0
APK

@AC above me, the "True Troll"? Take a read

1.) This DOS/DDOS attack utilizes an API call with a 0 window size parameter -> setsockopt 0

----

2.) TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems - which is what this attack sounds as if it is exploiting:

KEYWORD = SLIDING WINDOW SYSTEM (for TCP/IP) -> Tcp Scaling

http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm

PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."

Which, per the setsockopt 0 call & parameter?

Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!

----

3.) SynAttackProtect, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters STOPS TCP WINDOWS SCALING, per this MS article on it:

http://msdn.microsoft.com/en-us/library/aa302363.aspx

PERTINENT QUOTE -> "NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows"

-----

4.) Tcp1323Opts - This also turns off the RFC 1323 "Hi-Performance TCP/IP" options like "Scalable Windows" (sliding Windows noted in "silly window syndrome") also, because, you would be safer on a Windows 2000 machine because of it no longer allowing the TcpWindowSize to be reset by this attack (that uses that to its advantage via setsockopt 0) - the ONLY QUESTION I HAVE HERE is, does this guarantee that "SET WINDOWS SIZE" (a buffer of requests Windows fills first, & then satisfies, in other words?).

http://www.speedguide.net/read_articles.php?id=157

Tcp1323Opts is a necessary setting in order to enable Large TCP Window support as described in RFC 1323. Without this parameter, the TCP Window is limited to 64K.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Tcp1323Opts="1" (DWORD, recommended setting is 1. The possible settings are 0 - Disable RFC 1323 options, 1 - Window scaling but no Timestamp options, 3 - Window scaling and Time stamp options.)

Like SynAttackProtect = 2?

Tcp1323Opts = 0 "turns off" the ability to use "scalable windows" that RFC1323 allows, & which it appears that this setsockopt 0 command exploits, via the "Silly Window Syndrome"...

----

Thus, if you have a 'hardcoded' TcpWindowSize in the registry, & one set to a PRE-DEFINED value/size, & "sliding window sizes" for TCP are 'turned off' by SynAttackProtect = 2 and Tcp1323Opts = 0?

The ability to use setsockopt 0 should, in theory, be utterly nullified.

APK

P.S.=> BOTTOM-LINE, is this: I am looking to others to comment on my thoughts here & find any errors in the suppositions I am making (just by deductive reasoning in what these TCP parameters can do):

Right now?

Well - I can't think of anything better than this, FOR WINDOWS 2000 SERVERS, but the evidence above tends to show that IF you use SynAttackProtect = 2 (which works vs. types of DOS/DDOS attacks, as is) and Tcp1323Opts = 0 which STALLS "SLIDING WINDOW SIZES" (Tcp Scaling in other words), then, this attack which seems to use the "Silly Window Syndrome" per the above cannot work...

(As it cannot reset TcpWindowSize & the system will NOT use TcpScaling/Sliding Windows anymore to "renegotiate" a new TcpWindow Size... & thus, setsockopt 0 shouldn't work to send your system into a 'tailspin" DOS/DDOS... even if it is a server!)

If this doesn't work, then, nothing really can (for servers, but MS says PORT FILTERING works for it, on workstations, Yes, I can agree on that much, but not on servers that solicit & accept connections)...apk

0
0
This topic is closed for new posts.