RE: Limited vs full blown testing

From: Wayne Wooley (wayne.wooley_at_ps.net)
Date: 06/25/04

  • Next message: jatkinson: "IE caching issue"
    To: "'R. DuFresne'" <dufresne@sysinfo.com>, Peter Wood <peterw@firstbase.co.uk>
    Date: Thu, 24 Jun 2004 17:06:21 -0500
    
    

    I believe it depends on how far you want to go with your testing. There has
    been some exploits that require a two fold attack. In other words, the DOS
    attack in some systems opens up the possibility to gain root by timing it
    with a different attack.

    But the thing is, a lot of these types of attacks that are currently out are
    not published to the public. So its a good chance you will never see them
    used against your systems. And this all so brings up the point that, no one
    can ever have a completely secure system. As there will always be exploits
    available to select individuals that do not publish their work.

    In my experience most attacks are from individuals with very little
    knowledge as to what they are doing (kiddie scripts).

    -----Original Message-----
    From: R. DuFresne [mailto:dufresne@sysinfo.com]
    Sent: Thursday, June 24, 2004 3:13 PM
    To: Peter Wood
    Cc: pen-test@securityfocus.com
    Subject: Re: Limited vs full blown testing

            [SNIP]

    >
    > We accept a brief excluding DoS attacks, as most clients just won't
    support
    > DoS testing. However we include appripriate caveats in our report and
    > continue to suggest they do these tests.
    >

    I'm trying to understand the significance of DDOS testing and importance.
    Thing is, if you can spew packets fast enough, or make enough connections
    to consume the resources involved, you can take a site/serice down for at
    least the duration of the attack, even pipes as large as those of
    akami<sp?> were proven to be susceptable in recent days. It's a given
    vector of attack that we live with, a risk level we hope to avoid. But,
    not something that gives away the insides of the network to thugs and
    theives. No root shell and all that, which constitute a real threat, at
    least in my mind. Perhaps I'm missing something that has come up in
    recent years that redefines DDOS as something that is preventable and a
    potential for something other then a blip, however long lasting the
    attack, in service?

    Thanks,

    Ron DuFresne

    -- 
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            admin & senior security consultant:  sysinfo.com
                            http://sysinfo.com
    "Cutting the space budget really restores my faith in humanity.  It
    eliminates dreams, goals, and ideals and lets us get straight to the
    business of hate, debauchery, and self-annihilation."
                    -- Johnny Hart
    testing, only testing, and damn good at it too!
    

  • Next message: jatkinson: "IE caching issue"

    Relevant Pages

    • Re: whats the best virus protection
      ... >> haven't they now been given the go ahead to lauch DOS attacks against ... > give the content industry the legal power to attack infringers (DoS'ing ... [quote from "Steal This File Sharing Book - What They Wont Tell You About ... Martin Spencer-Ford ...
      (alt.comp.anti-virus)
    • RE: DOS ATTACK
      ... Subject: DOS ATTACK ... server which I guess is your problem. ... block traffic based on referrer. ...
      (Incidents)
    • PHP and remote execution
      ... not been fix that allows execution of code on the hosting server. ... he installed a DoS client and initiated 2 DoS ... so this clued us in that it was a rather local attack. ... was not launched via an interactive web script. ...
      (Security-Basics)
    • RE: PHP and remote execution
      ... not been fix that allows execution of code on the hosting server. ... he installed a DoS client and initiated 2 DoS ... so this clued us in that it was a rather local attack. ... prospectus based upon the core principle concepts of security. ...
      (Security-Basics)
    • Re: Open source two-factor authentication system released
      ... > with passwords? ... Are you suggesting that the attack is easier because ... There are surely much more effective DoS ... DoS is not the point - how do you prevent easy brute forcing the PIN? ...
      (comp.security.misc)