RE: DoS/DDoS Attack

From: Faisal Khan (faisal_at_netxs.com.pk)
Date: 01/14/05

  • Next message: FXCM - Brandon Palmer: "RE: DoS/DDoS Attack"
    Date: Sat, 15 Jan 2005 01:27:22 +0500
    To: pen-test@securityfocus.com
    
    

    Well I agree we are not helpless, we personally use the Top Layer box and
    its worked wonders.....have a half a dozen of them deployed (the IPS 100
    that is). We are now looking into a HA/LB setup of the IPS 5500.

    The only thing that gets to me is when large DDoS attacks come in - even
    with GigaE connectivity, sometimes the setup rates are so high - the boxes
    have a hard time keeping up with it. In this respect the Foundry's
    ServerIron 850 is amazing. It has something called the Transaction Rate
    Limiting, which we have configured for Port 80. If too many transactions
    from a specific IP happen in a defined period (all parameters are set by
    us), the device will instantly block the IP. For inquiring minds - the
    maximum we've experienced in a DDoS attack was about 240Mbps sustained
    coming in from what seemed to be a gazillion IPs. The attack lasted about
    2-3 days. Thank God for Foundry, which saved the day.

    What is truly frustrating is that the defences are at our perimeter -
    getting to the source I guess is just a Herculean task - I read
    somewhere that there are between 60 Million to 120 Million zombies out
    there - cannot recall the source, but that's what I read.

    There are still many features that all the DDoS mitigation OEM have not
    applied, that we have experienced and passed on as comments or as
    "wish-list" to the OEMs - I guess sooner or later someone will take care of
    them.

    My 2 cents added to yours! :)

    FK

    At 11:46 PM 1/14/2005, you wrote:
    >I would agree with most of what's been said so far. However, "helpless" is
    >such a strong word. I don't know exactly what you're referring to, but you
    >are definitely not "helpless" from a security standpoint. There are a host
    >of great DDoS/IPS appliances out there. I had a customer under a syn flood
    >attack a while back, and they plopped down six figures on the spot to buy
    >mitigation equipment. Since then, they have not experienced another attack,
    >though we can see the device blocking several such occurences (albeit
    >smaller ones).
    >
    >FYI, my favorite rate-based IPS box is Top Layer. It works great, and can
    >block gig speeds of bandwidth attacks. I've tested both the newest Top
    >Layer and Tipping Point boxes and I have to say Top Layer takes the cake.
    >The industry is constantly changing in this market, so you're bound to see
    >new leaders all the time.
    >
    >My $.02,
    >
    >Ed
    >
    >-----Original Message-----
    >From: nvfeito@advancedsl.com.ar [mailto:nvfeito@advancedsl.com.ar]
    >Sent: Friday, January 14, 2005 6:10 AM
    >To: pen-test@securityfocus.com
    >Subject: Re: DoS/DDoS Attack
    >
    >On Friday 14 January 2005 06:06 am, Faisal Khan wrote:
    > > Folks,
    > >
    > > Two quick questions.
    > >
    > > When IP (Source) addresses are spoofed, is there no way of determining
    > > (a) that the IP Source Addresses is spoofed and not the genuine one
    > > (b) to be able to determine the actual IP address that is sending DoS
    >packets?
    > >
    > > Somehow I get the feeling I'm SOL when trying to find out the
    > > "genuine/actual" source IP address.
    > >
    > > If this is the case, then pretty much we all are helpless with
    > > DoS/DDoS attacks - considering one can write a script/program to keep
    > > incrementing or randomly assigning spoofed source addresses in the DoS
    > > packets being sent out.
    > >
    > > Faisal
    >
    >I can't think of a way of reversing the process, the experiments I've done
    >with spoofed ip's have been done in C using raw sockets, some folks tried
    >with python, the language is indiferent, but what you do is alter the header
    >of the packet, and tell the kernel of the OS that there's no need to add a
    >header to the packet you're sending, then the kernel just place the packet
    >on the net with the data you filled in.
    >The main thing of a spoofed ip packet it's that you can fill the fields with
    >any info you want (of course it's important the checksum matches, this is
    >one way you could know if the packet is spoofed, and if it's not and the
    >checksum does not match, there's an error, so one way or another you should
    >get rid of the packet), check this with ethereal or another protocol
    >analyzer.
    >In theory it should be no way of knowing what's the real source address
    >(It's not like an smtp 'spoof' that you play with some rcpt to/mail from
    >commands and you have the email headers added by the MTA), if you think
    >about it a little bit, we're indeed helpless with DoS/DDoS attacks, if by
    >that you mean syn floods and that kind of stuff, and if you dig deeper,
    >you'll find out that if the operating system is in charge of stamping the ip
    >address to a packet and the OS itself it's sufficiently flexible to let you
    >do that from userspace, this is not considered a flaw, but a gift, the main
    >problem is that not all people is this gift the way they should.
    >
    >
    >--
    >
    >Saludos.
    >Nazareno Vicente Feito

    Faisal Khan, CEO
    Net Access Communication
    Systems (Private) Limited
    ________________________________

    Network Security - Secure Web Hosting
    Managed Internet Services - Secure Email
    Dedicated Servers - Reseller Hosting

    Visit www.netxs.com.pk for more information.


  • Next message: FXCM - Brandon Palmer: "RE: DoS/DDoS Attack"

    Relevant Pages

    • [NEWS] GnuPG and GnuPG Clients Unsigned Data Injection Vulnerability
      ... GnuPG and GnuPG Clients Unsigned Data Injection Vulnerability ... directly using GnuPG from the command line may be fooled by this attack. ... A packet is a chunk of data that has a tag specifying ... Symmetrical Encryption: ...
      (Securiteam)
    • IPS test criteria (was IDSIPS that can handle one Gig)
      ... Chris - what makes ICSA particularly relevant when it comes to defining IPS ... Speak to the vendors who were at their recent forum meeting ... a wide range of traffic loads and packet sizes. ... wide range of test criteria). ...
      (Focus-IDS)
    • Re: ARP - IP but why?
      ... The Network layer keeps track of logical addresses, and Ethernet handles delivery to a specific device. ... Since an IP address can be assigned to any ethernet device, it is utilized to associate an IP address to a real-world computer, printer, whatever. ... Once the network layer builds the TCP packet with a destination IP address, it hands it down to the link layer. ...
      (comp.os.linux.networking)
    • [Full-Disclosure] RE: Breaking the checksum (a new TCP/IP blind data injection technique)
      ... Capturing a packet isn't ... > downgraded the feasibility of the attack ... fragmentation to start ... checksum remains ...
      (Full-Disclosure)
    • Re: packet vs frame
      ... I.e., a data frame becomes ... a packet by tacking on some control bits fore and aft. ... OSI, and a frame is layer 2 of the OSI. ...
      (alt.internet.wireless)