-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 03:38 AM 2/4/2003, Charlie Root wrote: >With all the respect... I think your ideea is a BAD one ! Why ? Well... It >might be verry efective if one to... mhm... 100 persons would aply this >technique. That's because hackers/worms wouldn't mind loosing a few >servers if they got the rest of the world. But if this technique would >became a standard then the worm-industry (if there is such a thing) would >also evolve... making it brute-force the addreses. I admit that >brute-forcing would slow down the worm/hacker/whatever... but this is no >way of looking at the security. This is like protecting a house/store by >putting 15 doors that all could be easily broken... Of course there is a >chance that a thief trying to break in would get bored breaking door after >door... but if he's really determined... Well... I guess I made my point. A couple of things- one, David did not say "Stopping Worm Propagation with Rebasing," he said "Preventing exploitation..." If only 100 people do it where one has the capability to reloc, then right on. Let the other 74,900 people lick their wounds while I sip on a White Russian and giggle. He never said it was a silver bullet, never said it would be a panacea, never said it would apply to all applications. He offered the information as an additional strategy one could use, where applicable, to mitigate exploitation of your typical worm. I completely disagree with the statement that worm writers would evolve to brute-forcing addresses. Not only from a stability standpoint (if they were lucky enough NOT to trash the service) but from a practical standpoint... A worm's primary goal is to propagate to infect-able systems before the jig is up. They will not go through the trouble of trying to BF a jmp address when they might draw attention and prematurely alert the target population to the attempt. They will go for the low hanging fruit every time. Hell, that is why they jacked David's vector code in the first place; they did not want to go through the trouble of doing it themselves. Could Halvar do it? Sure- in a nanosecond. But I'm not building security in depth measures against people like Halvar and David (there's really no point in that.) I'm building up security in depth against the architecture and vector of your typical worm. >Why was slammer so successfull... Well... Here's my oppinion: Sysadmins >experienced in windows usually have little firewalling skills. That's >probably because there is no powerfull firewalling tool like ipfw or >ipchains on windows. If all the SQL ports would have been firewalled the >worm would probably wouldn't have caused any harm. I believe this point needs to be corrected- Shipped since Win2k, the IPSec policy manager can be used as a powerful firewall tool if you so desire. It is highly configurable, can be set up via command line like ipchains or gui like the firewall config on Linux, can be set remotely via the MMC plug in, or deployed in the Enterprise via group policy and organizational units. And that is just part of the power of the tools aside from their primary purpose of maintaining IPSec tunnelling policies. It also supports a more expanded protocol list than ipchains (just tcp, udp, and icmp) with additional protocols like RDP, HMP, RAW, etc. I don't know your criteria for suggesting Windows folks "usually" have little firewalling skills, but if that is indeed true, it is not because of Windows. All my peeps use IPSec extensively. Besides, SQL Server is not an application where one would normally implement host-based port firewalling; not without breaking other things, anyway. Localized host-based hardening is fine for net-facing web servers and DNS boxes, but SQL Server should not be directly on the net in the first place. It was more of an infrastructure issue where these boxes could be reached on UDP 1434; host-based firewalling was not the answer: strong border -> DMZ firewalling policy was the answer (in addition to patch management.) T -----BEGIN PGP SIGNATURE----- Version: PGP 7.1 iQA/AwUBPkGzlohsmyD15h5gEQLtGACfbIK5quvBDn/A0X5hz3/o3a4//hoAoNz8 Bd/++Ep/uRekp9WkHI6BYyWx =J8fv -----END PGP SIGNATURE-----
