Surviving Denial of Service
Results 1 to 4 of 4

Thread: Surviving Denial of Service

  1. #1
    AntiOnline Senior Medicine Man
    Join Date
    Nov 2001
    Posts
    724

    Post Surviving Denial of Service

    There Many ways and different avenues to go into when trying to keep your network up when it is under DDOS attack. Yes, distributed denial of service attacks and the like bring buisiness for many to a hault every day. For a while, there wasn't a whole lot that could be done to stop a determined attacker. Those days have obviously been turned into nothing but memories. Herein I will discuss DDOS Attack Mititgation, and other forms of Valid Traffic Verification.

    The Distributed Denial of Service Attack is still a very effective, and easy way of crippling a network/website. While dealing with a large network of dedicated webservers, I see 20 different types of attacks a day, and I have learned that the most comman of those, is the [SYN] flood. These attacks vary depending on the target.

    The Victim in this case will be 66.77.88.99. And A very large distributed SYN flood is coming into the network, taking out the switch 66.77.88.99 is sitting on. First thing we do, of course is get some packet captures. (Ethreal is the most comman and recommended.) Upon our capture, we see that the attack is a Distributed [SYN] flood to 66.77.88.99 on port 6667. At this point there are a few different ways to go about this.

    1) You could block the Victim as destination at the backbone, for the good of the other users on the switch.
    2) Could attempt blocking all sources as source at backbone( i have found this to be very tedious and impossible to clean up 100% sometimes.)
    3) Rate Limit the SYN Traffic to 66.77.88.99

    Options 1 and 2 can be easily done with any firewall. However rate limiting may take a more advanced administrator to apply. But in my Professional Opinion, Rate Limiting, combind with Valid Traffic Verification, could be the difference between a "Sale", and "Page Cannot Be Displayed".

    Below we can see the Sample capture seemingly Random Sources hitting 66.77.88.99 with SYN packets to TCP port 6667. The first thing I am going to do is check to see if this guy is running an irc server, or something else on TCP 6667. For the main reason, that if this customer did NOT use port 6667 then a filter when then be applied that discards, and blackholes all TCP packets to 66.77.88.99 TCP 6667. But in this case we will continue on because this guy NEEDS his IRC server, and is bitching insessantly about the "Terrorist Attack" on his server. (They can be irate) So we go back to the cap examing it further...to bad most [SYN] packets are the same size other wise maybe we could filter on packet length, but these [SYN] packets are legit length. So putting that thought aside I'm going look at the "Source Ports". I can see that 'MOST' of the attack is coming from 2 source ports, 43830 and 50211. So we apply a filter limiting all [SYN] 66.77.88.99>TCP6667 from Source Ports 43830 or 50211 to 32k. Thus only allowing 32k worth of those packets matching the attack signature. This wont harm much at all.

    217.89.198.24 -> 66.77.88.99 TCP 43830 > 6667[SYN] Seq=0 Ack=0 Win=5840
    207.46.196.23 -> 66.77.88.99 TCP 43830 > 6667 [SYN] Seq=0 Ack=0 Win=5840
    207.44.184.128 -> 66.77.88.99 TCP 50211 > 6667 [SYN] Seq=0 Ack=14480 Win=63712
    27.48.198.23 -> 66.77.88.99 TCP 43830 > 6667 [SYN] Seq=0 Ack=0 Win=5840
    27.4.198.23 -> 66.77.88.99 TCP 43830 > 6667[SYN] Seq=0 Ack=0 Win=5840
    207.44.198.23 -> 66.77.88.99 TCP 43830 > 6667 [SYN] Seq=0 Ack=0 Win=5840
    23.44.184.128 -> 66.77.88.99 TCP 50211 > 6667 [SYN] Seq=0 Ack=14480 Win=63712
    7.44.198.23 -> 66.77.88.99 TCP 2526 > 6667 [SYN] Seq=0 Ack=0 Win=5840
    7.44.198.24 -> 66.77.88.99 TCP 2548 > 6667 [SYN] Seq=0 Ack=0 Win=5840


    Now we are only left with the seemingly spoofed sources with random source ports, listed below. This is where things get advanced. What you need, is a router, or machine that is capable of responding to every [SYN] thrown at it. There are some really big Cisco or Juniper routers that could do the job. This is where traffic verification begins. In order to determine if a [SYN] packet is legit, one must simply respond with a [ACK], if the target ip is expecting the [ACK] packet a connection will be made and that traffic is routed through to 66.77.88.99. However, if a [ACK] get sent to a spoofed source, the responce will differ from that of a computer expecting a responce and will thus be null routed.


    7.44.198.23 -> 66.77.88.99 TCP 5261 > 6667 [SYN] Seq=0 Ack=0 Win=5840
    7.44.198.24 -> 66.77.88.99 TCP 21548 > 6667 [SYN] Seq=0 Ack=0 Win=5840
    7.44.198.25 -> 66.77.88.99 TCP 25829 > 6667 [SYN] Seq=0 Ack=0 Win=5840
    7.44.198.26 -> 66.77.88.99 TCP 7280 > 6667 [SYN] Seq=0 Ack=0 Win=5840

    In the end, while dealing with DDOS attacks you must understand that the nature of the attack will change almost as soon as you apply a signature or some sort of filter. The determined attack has a seemingly unlimited amount of protocals and methods to attack with. Be on your toes, and keep a close eye on your traffic usage, your best bet is try and stay one step ahead of the attacker, and try and keep connectivity up.


    EDIT: I just had to write another tut on this topic, as I looked at the one from 2 years ago...yikes....
    It is better to be HATED for who you are, than LOVED for who you are NOT.

    THC/IP Version 4.2

  2. #2
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    Call me a little stupid, but if you're suffering a DDoS synflood attack, why not just enable syncookies? Surely this enables the target OS to not use up any more resources for spoofed SYNs.

    The problem I've seen is not with syn flooding, but with DDoS bandwidth flooding which is much worse. The attackers usually spoof all the packets and choose random source port numbers, and a legit destination port. Thus you can't filter them upstream *at all*, it is just impossible to avoid.

    Of course, bandwidth flooding is much harder to achieve (i.e. you need more boxes). But a site that I co-admin runs some web sites which are frequently the target of attacks.

    Unfortunately our box was flooded (possibly some other targets on the same network too), and the bandwidth was mostly used up, resulting in very poor performance for legit users. The packets (of which I captured a few) were just plain vanilla TCP packets which had no identifying features.

    What we believe happened is, some kid gave several hundred of his internet contacts a copy of a DDoS tool, and they all ran it at the same time from their own broadband connections. Ouch.

    Slarty

  3. #3
    AntiOnline Senior Medicine Man
    Join Date
    Nov 2001
    Posts
    724
    Originally posted here by slarty
    Call me a little stupid, but if you're suffering a DDoS synflood attack, why not just enable syncookies?
    Syn cookies can be an effective way to fight a SYN flood. However, that needs to be set up on the server. Meaning, that I would have to set up SYNcookies on the customers machine. Most customers would not be happy us setting up local process'. But yes, SYN Cookies do kick ass
    It is better to be HATED for who you are, than LOVED for who you are NOT.

    THC/IP Version 4.2

  4. #4
    Elite Hacker
    Join Date
    Mar 2003
    Posts
    1,407
    Originally posted here by slarty
    Call me a little stupid
    You're a little stupid. j/k
    nice posts, both of you. Thanks for the info.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •