Archive for the DDoS Category

New version of ddosim – DDOS simulator

Posted in DDoS, Tools (StormSecurity) on November 4, 2010 by stormsecurity

I am pleased to announce a new version of ddosim (v0.2) – the application layer DDOS simulator. It can be downloaded from http://sourceforge.net/projects/ddosim/.

For documentation and use cases please see this post.

If you have any questions, don’t hesitate to ask!

Application Layer DDoS Simulator

Posted in DDoS, Tools (StormSecurity) with tags , , , on March 3, 2009 by stormsecurity

Update(november 2010):  ddosim v0.2 has been released. You can find it at: https://sourceforge.net/projects/ddosim/.

ddosim is a tool that can be used in a laboratory environment to simulate a distributed denial of service (DDOS) attack against a target server. The test will show the capacity of the server to handle application specific DDOS attacks. ddosim simulates several zombie hosts (having random IP addresses) which create full TCP connections to the target server. After completing the connection, ddosim starts the conversation with the listening application (e.g. HTTP server).

ddosim is written in C++ and runs on Linux. Its current functionalities include:

  • HTTP DDoS with valid requests
  • HTTP DDoS with invalid requests (similar to a DC++ attack)
  • SMTP DDoS
  • TCP connection flood on random port

In order to simulate such an attack in a lab environment we need to setup a network like this:

Network configuration for DDOS simulation

Network configuration for DDOS simulation

On the victim machine ddosim creates full TCP connections – which are only simulated connections on the attacker side.

There are a lot of options that make the tool  quite flexible:

Usage: ./ddosim
-d IP                   Target IP address
-p PORT            Target port
[-k NET]             Source IP from class C network (ex. 10.4.4.0)
[-i IFNAME]      Output interface name
[-c COUNT]       Number of connections to establish
[-w DELAY]       Delay (in milliseconds) between SYN packets
[-r TYPE]             Request to send after TCP 3-way handshake. TYPE can be HTTP_VALID or HTTP_INVALID or SMTP_EHLO
[-t NRTHREADS]   Number of threads to use when sending packets (default 1)
[-n]                       Do not spoof source address (use local address)
[-v]                       Verbose mode (slower)
[-h]                       Print this help message

Examples:

1. Establish 10 TCP connections from random IP addresses to www server and send invalid HTTP requests (similar to a DC++ based attack):

./ddosim   -d 192.168.1.2   -p 80   -c 10   -r HTTP_INVALID  -i eth0

2. Establish infinite connections from source network 10.4.4.0 to SMTP server and send EHLO requests:

./ddosim   -d 192.168.1.2   -p 25   -k 10.4.4.0   -c 0   -r SMTP_EHLO  -i eth0

3. Establish infinite connections at higher speed to www server and make HTTP valid requests:

./ddosim   -d 192.168.1.2   -p 80   -c 0   -w 0   -t 10   -r HTTP_VALID  -i eth0

4. Establish infinite TCP connections (without sending a Layer 7 request)  from local address to a POP3 server:

./ddosim   -d 192.168.1.2   -p 110   -c 0  -i eth0

 

More background info:

Some of the hardest to mitigate distributed denial of service attacks are the ones targeting the application layer (in TCP/IP stack). They are difficult to stop because they look legitimate to classic firewalls which let them pass freely (for an example look here). The only way to stop this kind of attacks is deep packet inspection (layer 7 inspection) which means a lot of money/resources.

In general, a DDoS attack is performed by an armie of bots (zombies) that simultaneously send attack packets to a victim server. If we talk about UDP packets (ex. targeting a DNS server), the attack is easier to implement because a zombie needs to send a single UDP packet (multiple times) to contribute to the attack. But in case of a TCP based attack, the zombie needs first to establish the full TCP 3-way handshake and then send the data packets (e.g. HTTP GET request). ddosim successfully simulates this attack scenario.

If you have any questions regarding ddosim, please let me know.

DC++ and DDoS attacks – the full story

Posted in DDoS with tags , , , , , , , , , on August 11, 2008 by stormsecurity

Hello, (security) world!

This is my first post on StormSecurity blog and I am going to talk about a paper I wrote called DC++ and DDoS attacks. This is a rather old subject (2007) but this kind of attack can hit a server anytime even in nowadays and there are not so many companies out there prepared to handle it. This paper describes in detail the anatomy of such an attack and also talks about a tool I wrote – HubMonitor– that is able to detect the attacker hubs. You can download it from here.

The paper is intended to be a full reference on this topic but I am going to highlight here the most interesting ideas of it.

What is it about?

I believe many of you used or still use the DC++ network to download or upload files. It’s not a secret although most of the time is not a legal activity. The DC++ network is pretty much spread around the world and there are many people using it. But what they don’t know is that they could participate anytime in a devastating DDoS attack against a victim server. The DC++ clients won’t know this and they would not care either but the victim server could be easily shutdown because of them.

Last year, there were many reports of DDoS attacks against web servers: Prolexic, SecurityFocus, etc. People started to patch DC++ hubs but…

Why is this still actual?

Do you know who are the persons that own the DC++ hubs you connect to? Most probably no. So you can’t trust them. You can’t know if they will use your DC++ client in a DDoS attack or not. And they COULD do that anytime. You won’t know it but others will suffer.

There still are many unpatched hub servers out there (Verlihub-0.9.8c, Verlihub-0.9.8d-rc1, Ynhub < 1.0306, Ptokax < 0.3.5.2) and others have custom backdoored hub software that can be used anytime to generate a DDoS attack.

Connections hitting the victim:

connections/sec = hub_no * hub_clients * $CTMs/sec
where:
hub_no = number of hubs participating in the attack
hub_clients = average number of clients on each hub
$CTMs/sec = number of $ConnectToMe commands received by each client per second

For a moderately big attack, the variables are:
hub_no ~= 5
hub_clients ~= 5000
$CTMs/sec ~= 1
=> 25.000 connections/sec

How to stop it?

Lots of money is needed to effectively stop such an attack. Because it is an application layer attack, the good solution is a deep packet inspection capable device but this is very expensive. There are other ways described in the paper to try to defend against it.

But when you want to find the attacker hubs, there’s a real problem. The packets reaching the victim contain no information about him. Here is where HubMonitorcomes into scene. This application connects simmultanously to many suspected DC++ hubs and listens for attack packets. When it receives specific packets related to the victim server, it declares the hub as attacker and legal measures can be taken.

Conclusion

Although the number of DDoS attacks generated using DC++ network has decreased, hacker teams could set up anytime such an attack against a victim server and the intensity of the attack could easily overwhelm it. HubMonitor is a tool that can be used to find the attacker hubs. You can find more details about it and about this kind of attacks in my paper.