A french version is available here.

The D.D.O.S : a very special enemy!

Nowadays, most attacks can be easily blocked.

Let’s say your goal is to secure a Linux server: the installation of Grsec / Pax, some service hardening/disabling, a static kernel, a good password policy and your are already quite secure…

All daemons like Apache and MySQL, interpreters like PHP or Perl will be protected against their most critical enemies, the overflows. Privilege separations, filtered connections, PHP_IDS, Mod_sec, what else can we do? Separate the back-office with another vhost in order to add a htaccess, audit the website against the most classical vulnerabilities (XSS, SQL Injections…).

Well… Of course we could add one or two other protections but …

The D.D.O.S is still fatal.

No matter you are Wikileaks being attacked or the victims of the Payback operations or even political refugees, governments, private companies or E-merchants, we have no « side ». We only are here to help with defensive technics and try to help maintain the Internet in an operational state, with a little contribution.

Know your ennemy !

The D.D.O.S – Distributed Denial Of Services – is the biggest fear of every web merchant, of every system that earns money through the Internet and most of all of your IT facilities manager.

SYN or GET DDOS flood ?

There are two main different DDOS techniques. The packet one, trying to take down your network connection by sending a huge lot of packets (like SYN flooding) and the applicative one, trying to take down the resources of your servers by flooding them with requests, for example a basic « GET / ».

A distributed denial of service rely on many hosts to conduct a simultaneous flood and can lead to thousands or millions of requests / packet per second. When speaking only about web servers, most of the time, 2000 simultaneous GET are enough to knockout your server. If someone prefer the SYN flood attack like in the « Low Orbit Ion Cannon » (LOIC), he only have to overload the server bandwidth, usually less than 100 Mb/s, meaning thousands of computers will be enough.

Zombies or Voluntaries ?

Those numerous connections are coming, most of the time, from compromised computers, all over the world. These computers are hacked by worms like Conficker, Zeus (or sometime most confidential ones) that sleep into the computers for months, listening to the orders of their hacker-master. These are called « zombies » and they are part of what is called a bot net.

The « Voluntary » movement that aim to take down sites with Ion Cannon or similar tools are a new trend, gaining in strength quickly. It may soon overcome the biggest bot nets in raw network capacity. A script kiddie (and even sometime a real hacker) just has to pay some dollars to rent the power of a bot net. The next step aren’t more complicated…

The hacker just chooses the number of bots he wants and will increase that number until your site will be down.

The hacked computers receive the malicious orders and in just a few minutes, hundreds of thousands connections will start attacking the targeted web server.

How to handle a D.D.O.S attack?

D.D.O.S. are mainly based on private computers.

Of course, we can’t act on those computers directly. Disinfect them remotely is not possible and would not even be legal. This wouldn’t solve the problem of « volunteers« .

Then, blocking one by one those computers in the firewalls is as useless as impossible. We say it’s impossible, because it is extremely hard to differentiate real traffic from the junk one, especially if the attacked page is the front page of your website. It’s also useless because the hacker just has to add new computers to his bot net in order to circumvent your protection. Then, even if your firewall can handle the malicious traffic, it is probable that it won’t be the case of your Internet connection.

Damn, are we done?

No, well actually you have a serious problem but there are answers.
A better start would be to describe what can really be done.

It is not really possible for a Virus/worm to patch the kernel of the compromised Windows computers.

By behaving this way, a worm would be much less  efficient as many anti-virus are able to detect those threats. That’s why, D.D.O.S viruses are often located at the top of the different layers of the operating system: the software layer. This means that these worms must use the operating systems level to achieve their duties and this behavior can be their main flaw…

The tools like Low Orbit Ion Cannon or others are also operating in the user-land and won’t patch the IP stack or network card driver of their host.

If we can force the hacked computers to stop sending packets by using some subtleties of the TCP protocol, we will considerably lower the impact of the attack .

Tarpit : enjoy the power of tar and feathers !

This post is not made to explain how to configure the Linux kernel or help you compiling the necessary tools.
You will find the Linux kernel here and many tutorials on the Internet.

A long time ago, I wrote an article on the configuration of iptables. You can find it there. It is in French but it is quite readable and may be auto translated by Google if needed. The article is not perfect but is still a good starting point.

From that point (a working Linux server with iptables enabled on it and the iptables binaries having the tarpit capabilities built in), you should be able to succeed in applying the tips from that article.

First start by recompiling the iptables binaries like it is explained in this article here.

Why are iptables and tarpit your friends ?

The TARPIT rule gives you the ability to force a computers to wait from an acknowledgment coming from your attacked server before sending you the next packet.

Windows computers, as most of the modern operating systems will comply to this request based on ‘window resizing’.

When a server set the communication window size to 0, the remote computer will stay in a wait state until you change it back to a « normal size ». But… if you never change the window size to its initial size, the bots will passively wait until their operating systems clean all the idle connections. We have some kind of a solution there don’t we ?

It could last for a long time… even if the remote computer continue its attack, each time it sends us a packet, it will glue  its TCP stack a bit more. If everything works correctly, you will start seeing a big drop into the attack rate of your opponent.

The only way to stop this Window resizing trick is to instruct the NIC driver to behave differently, to patch Windows Kernel but in any case, this require a quite important modification that will trigger Windows UAC, require admin rights and make any decent anti-virus yell for a compromise attempt…

Beyond those consideration, we have to keep in mind that we will handle a lot of traffic, so the system need to be fast, reliable and have a low resource footprint. Well, this is definitely the definition of Netfilter, the kernel level firewall of Linux !

How and when use Tarpit ?

In order to differentiate the real traffic from the malicious one, we will have to be more intelligent than the bots. We could use Intrusion Detection Systems like Snort or log analyzers. Another strategy could be to monitor how often a same host try to connect to the same page (HTTP level monitoring).

When you think about the problem, it’s not that complicated to identify a bot only sending the same SYN or the same GET /foo.php page. Beyond that, you can also use the timing to see if there is a pattern and thus identify a bot/program. So we have the type of packet (SYN), the content of it (GET /foo.php) and the timings.

If we are using and IDS, he will control the firewall rule by himself, like snort and many other can. (you can see/translate our Snort howto here about this). If the IDS find a abnormal pattern (like GET /foo.php every 2 seconds), then we can dynamically insert rules in the firewall to Tarpit the attacker.

Limit by packet content

If a specific page is targeted, it is also possible to rewrite the URL or detect the payload of the packet with state-full inspection and reject them. If someone call for this page in a legitimate way, he will also be blocked but this is far better than locking down the whole site. Of course, if the targeted page is the homepage, this is not really something you can apply, but otherwise :

iptables -I INPUT -p tcp -s 0.0.0.0/0 –dport 80 -m string –string “foo” –j TARPIT 

Blackhole

IP Geolocalization can be a solution in a way.
For example, if you site is mainly made for the visitors coming from a precise country, you can consider black-holing the IP coming from other countries than the one targeted or even from a precise country. The tables linking IP to countries are publicly available so this is not a big deal.

It is possible to ask you ISP not to route the traffic incoming from a precise country to your server and send it in space, this is called the black hole method.

Limit by rate / timings

You can also filter (and apply the same « TAR » penalty) based on the incoming packet rhythm/rate/timings.
Iptables is a real laboratory and you’ll find a lot of funny things in the forge and a lot of clever way to use these exotic options :

-m limit –limit 2/second –dport 80 –syn -j ACCEPT

You can use limit and burst-limit to stop flowing or « crow control » the packet incoming rhythm.

Try playing with stacked conditions

-string to check the content PLUS
-limit and -burst for the rate/rhythm PLUS
-state to check the state of the connection

iptables -I INPUT -p tcp –dport 80 –m string –string “foo” –m limit –limit 1/6s –limit-burst 1 –m recent –name badguy –set
iptables –I INPUT FORWARD -p tcp –dport 80 -m recent –name badguy –set -j TARPIT
iptables –I INPUT -m state –state NEW –m limit –limit 1/6s –limit-burst 1-j TARPIT

Here, we have set strong limit to our tar and feather trap. Only new connection happening more often than every 6 seconds and asking for the foo string will be blocked.

More fun with iptables ?

iptables -I INPUT -m state –state NEW -m recent –update –seconds 20 –hitcount 4 -j DROP
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j RETURN

The Syn cookie parameter of the kernel allow you to be sure that a bad guy will be blocked if he only send SYNs. If he doesn’t follow this SYN by another demand within a limited time, the connection will be closed.

For the ICMP flooders :

iptables -A INPUT -p icmp -m limit --limit  1/s --limit-burst 1 -j ACCEPT 

you’ll perhaps have to deal with your /proc settings to tweak your IP stack parameter to release in a faster way the idle connection or clear the buckets.

More fun with Tarpit ? Well let me introduce knockd !

We can go far beyond in the fun :)

For example, someone scanning my servers will usually use a scanner that will « kock » to ports in a similar fashion (21,22,23,25 for example) or use some known sequence to fingerprint our IP stack. (Xmas scan, NUL, FIN, SYN etc…).

For TCP port sequence, a simple daemon called knockd can detect them and apply the TARPIT punishment to the funny guy…
The most funny part of it is that the more port he will scan, the more glued its IP stack will become !

If you need to detect Xmas Scans or others, your IDS can usually handle that and also add some Tarpit rules to your firewall dynamically.

Dig in the kernel options, in the /proc settings and in, iptables « patch-o-matic » all of this tools are sooooo useful when you have to deal with DDOS and other attacks ! And remember, analysis is the base, tarpit the fatal weapon.

Laisser un commentaire