-----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-----

[ reply ]