Re: Preventing exploitation with rebasing

From: Deus, Attonbitus (Thorat_private)
Date: Wed Feb 05 2003 - 17:00:06 PST

  • Next message: Jason Coombs: "RE: Observation on randomization/rebiasing..."

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



    This archive was generated by hypermail 2b30 : Thu Feb 06 2003 - 10:40:28 PST