In fight against DDoS through the years, i’ve compiled a list of useful iptables commands which may come handy in time of trouble.
Here is how to stop DDoS attack with iptables
To block small SYN floods: iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j RETURN
To block small UDP floods: iptables -N udp-flood iptables -A OUTPUT -p udp -j udp-flood iptables -A udp-flood -p udp -m limit --limit 50/s -j RETURN iptables -A udp-flood -j LOG --log-level 4 --log-prefix 'UDP-flood attempt: ' iptables -A udp-flood -j DROP
To limit rate of connections on a port: iptables -A INPUT -p tcp --dport (port-here) -m state --state NEW -m recent --set --name DDOS --rsource iptables -A INPUT -p tcp --dport (port-here) -m state --state NEW -m recent --update --seconds 5 --hitcount 5 --name DDOS --rsource -j DROP
Limit connections per ip on a port iptables -A INPUT -p tcp --syn --dport (port-here) -m connlimit --connlimit-above (limit-here) --connlimit-mask 32 -j REJECT --reject-with tcp-reset
To block an ip using iptables iptables -A INPUT -s (ip-here) -j DROP
If you use haproxy as load balancer use this to limit concurrent connections: stick-table type ip size 200k expire 30s store conn_cur tcp-request connection reject if { src_conn_cur ge 6 } tcp-request connection track-sc1 src
Une attaque par déni de services SYN flood est une technique visant à saturer un serveur en envoyant une multitude de paquets TCP, avec le flag SYN. Les connexions sont alors établies vers la machine, mais restent à moitié ouvertes, car le client malveillant (hacker) ne renvoie pas de confirmation (ACK).
Le serveur attend pendant un certain délai la réponse et la connexion semi-ouverte consomme alors un certain nombre de ressources. En multipliant ce type de connexions, le hacker peut arriver à créer un déni de service qui rendra la machine inopérante.
1. Détection d’une l’attaque DDoS SYN flood
Pour détecter la présence de l’attaque, il faut utiliser la commande netstat et repérer la présence des connexions de type SYN_RECV. Si il y a beaucoup de réponses, c’est qu’une attaque est sans doute en cours :
We’ve seen recently more and more DOS and DDoS attacks. Some of them were very big, requiring thousands of computers… But in most cases, this kind of attacks are made by a few computers aiming to make a service or website unavailable, either by sending it too many requests or by taking all its available resources, preventing regular users to use the service. Some attacks targets known vulnerabilities of widely used applications.
In the present article, we’ll explain how to take advantage of an application delivery controller to protect your website and application against DoS, DDoS and vulnerability scans.
Why using a LB for such protection since a firewall and a Web Application Firewall (aka WAF) could already do the job? Well, the Firewall is not aware of the application layer but would be useful to pretect against SYN flood attacks. That’s why we saw recently application layer firewalls: Web Application Firewalls, also known as WAF. Well, since the load balancer is in front of the platform, it can be a good partner for the WAF, filtering out 99% of the attacks, which are managed by script kiddies. The WAF can then happily clean up the remaining attacks. Well, maybe you don’t need a WAF and you want to take advantage of your Aloha and save some money ;).
Note that you need an application layer load-balancer, like Aloha or OpenSource HAProxy to be efficient.
TCP syn flood attacks
The syn flood attacks consist in sending as many TCP syn packets as possible to a single server trying to saturate it or at least, saturating its uplink bandwith.
If you’re using the Aloha load-balancer, you’re already protected against this kind of attacks: the Aloha includes mechanism to protect you. The TCP syn flood attack mitigation capacity may vary depending on your Aloha box.
It you’re running your own LB based on HAProxy or HAPEE, you should have a look at the sysctl below (edit /etc/sysctl.conf or play with sysctl command):
Note: If the attack is very big and saturates your internet bandwith, the only solution is to ask your internet access provider to null route the attackers IPs on its core network.
Une zone démilitarisée est un sous-réseau (DMZ) isolé par deux pare-feux (firewall). Ce sous-réseau contient des machines se situant entre un réseau interne (LAN – postes clients) et un réseau externe (typiquement, Internet).
La DMZ permet à ces machines d’accéder à Internet et/ou de publier des services sur Internet sous le contrôle du pare-feu externe. En cas de compromission d’une machine de la DMZ, l’accès vers le réseau local est encore controlé par le pare-feu interne.
La figure ci-contre représente un cas particulier de DMZ; pour des raisons d’économie, les deux pare-feu sont fusionnés. C’est la ‘colapsed dmz‘, moins sure, car dès que le pare-feu est compromis, plus rien n’est contrôlé.
Schéma DMZ avec 1 seul pare-feu
Schéma DMZ avec 2 pare-feux
une installation complète contient :
Un réseau privé, dont on considère (souvent à tort) qu’il ne sera pas utilisé pour attaquer notre système informatique. Dans cette zone, il n’y a que des clients du réseau et des serveurs qui sont inaccessibles depuis l’Internet. Normalement, aucune connexion, au sens TCP du terme, aucun échange, au sens UDP du terme, ne peuvent être initiés depuis le Net vers cette zone.
Une « DMZ » (Zone DéMilitarisée), qui contient des serveurs accessibles depuis le Net et depuis le réseau privé. Comme ils sont accessibles depuis le Net, ils risquent des attaques. Ceci induit deux conséquences :
Il faut étroitement contrôler ce que l’on peut faire dessus depuis le Net, pour éviter qu’ils se fassent « casser » trop facilement,
Il faut s’assurer qu’ils ne peuvent pas accéder aux serveurs de la zone privée, de manière à ce que si un pirate arrivait à en prendre possession, il ne puisse directement accéder au reste du réseau.
Le dispositif qui va permettre d’établir ces règles de passages s’appelle un pare-feu. Techniquement, ce pourra être un logiciel de contrôle installé sur un routeur.
1.1 Les trois passages.
1.1.1 Entre le réseau privé et le Net.
Toujours typiquement, ce sont les clients du réseau (les utilisateurs) à qui l’on va donner des possibilités d’accéder au Net comme par exemple le surf ou la messagerie. Toutes les requêtes partent du réseau privé vers le Net. Seules les réponses à ces requêtes doivent entrer dans cette zone. Les accès peuvent être complètement bridés (les clients du réseau privé n’ont aucun droit d’accès vers le Net, ça nuit à leur productivité.
Seul le patron y a droit). Ou alors, les utilisateurs ne pourront consulter qu’un nombre de sites limités, dans le cadre de leurs activités professionnelles exclusivement. Très généralement, cette zone est construite sur une classe d’adresses privées et nécessite donc une translation d’adresse pour accéder au Net. C’est le routeur qui se chargera de cette translation.
1.1.2 Entre la DMZ et le Net.
Ici, nous avons des serveurs qui doivent être accessibles depuis le Net. Un serveur Web, un serveur de messagerie, un FTP… Il faudra donc permettre de laisser passer des connexions initiées depuis l’extérieur. Bien entendu, ça présente des dangers, il faudra surveiller étroitement et ne laisser passer que le strict nécessaire.
Si l’on dispose d’adresses IP publiques, le routeur fera un simple routage. Si l’on n’en dispose pas, il devra faire du « port forwarding » pour permettre, avec la seule IP publique dont on dispose, d’accéder aux autres serveurs de la DMZ. Cette technique fonctionne bien sur un petit nombre de serveurs, mais devient très vite un casse-tête si, par exemple, plusieurs serveurs HTTP sont présents dans la DMZ.
1.1.3 Entre le réseau privé et la DMZ.
Les accès devraient être à peu près du même type qu’entre la zone privée et le Net, avec un peu plus de souplesse. En effet, il faudra
Mettre à jour les serveurs web,
Envoyer et recevoir les messages, puisque le SMTP est dedans
Mettre à jour le contenu du FTP (droits en écriture).
En revanche, depuis la DMZ, il ne devrait y avoir aucune raison pour qu’une connexion soit initiée vers la zone privée. Lire la suite…
Ce chapitre vous propose d’apprendre à maîtriser le trafic réseau qui passe par votre ordinateur. En effet, lorsque vous êtes connectés à l’internet, vous avez régulièrement des applications qui vont se connecter puis télécharger et envoyer des informations. Comment surveiller ce qui se passe ? Quelle application est en train de communiquer et sur quel port ?
Savoir paramétrer un pare-feu est essentiel, que ce soit sur votre PC à la maison ou, à plus forte raison, sur un serveur. Cela vous protège de manière efficace contre les programmes qui voudraient échanger des informations sur le réseau sans votre accord. C’est une mesure de sécurité essentielle qu’il faut connaître et dont aucun administrateur système sérieux ne peut se passer.
Je vous propose de découvrir d’abord quelques outils de base qui vont vous permettre de bien comprendre comment une IP est associée à un nom d’hôte. Puis nous analyserons le trafic en cours avec un outil comme netstat. Enfin — et ce ne sera pas le plus facile, je vous préviens — nous apprivoiserons le célèbre pare-feu utilisé sous Linux : iptables. Il est assez complexe à paramétrer, mais heureusement des programmes supplémentaires peuvent nous simplifier le travail.
host & whois : qui êtes-vous ?
Comme vous le savez sûrement, chaque ordinateur relié à l’internet est identifié par une adresse IP (figure suivante).
Une adresse IP est une suite de quatre nombres séparés par des points. Par exemple :86.172.120.28.
