Attaques DoS et Anti-DoS OVH

Un article sur les attaques DoS et les protections fournies par OVH.
Je n’ai pas énormément d’expériences sur le sujet mais le site ayant subit quelques attaques, j’ai tout de même quelques notions.
Le site est hébergé chez l’hébergeur OVH, ce dernier propose maintenant une solution Anti-DoS – voici une présentation de cette protection.

Table des matières

1 Quelques présentations d’attaques DoS
2 Anti-DOS OVH
3 HTTP Flood
4 EDIT – Décembre 13
5 EDIT – 9 Février 2015

Quelques présentations d’attaques DoS

Il existe plusieurs types d’attaques, les plus répondus sont des attaques de type :

TCP Syn flood : ce dernier consiste à envoyer des requêtes SYN avec des IPs falsifiées (spoofing), le serveur peux alors répondre à ces requêtes (si le fait qu’elle soit falsifiées n’est pas détectée) est coulée sous la demande – le but est de saturer la couche réseau du serveur visé voire le système en son entier.
UDP flood : le mécanisme est assez similaire au TCP Syn – On peux aussi de tenter de saturer la bande passante du serveur.
HTTP Flood: à destination des serveurs WEB – le but est d’envoyer une multitude de requêtes sur le serveur WEB pour le saturer.

Plus d’informations, se reporter au dossier sur les attaques DDoS : les attaques DoS
Exemple en vidéo d’une attaque SlowLoris et SYN :

Les deux premières sont plutôt à destination de tout type de serveur (serveur de jeux, Teamspeak etc) – Notez que vous pouvez simuler une attaque de ce type avec le programme hping3 (par exemple, pour un Syn Flood : hping3 -S –faster dest).
Le dernier est à destination des serveurs WEB, c’est ce type d’attaque, que j’ai en général eu, puisqu’avec peu de ressources, on peux mettre à genoux un serveur WEB si aucune protection n’est présente.

Je ne parlerai pas donc des deux premières attaques. La protection Anti-DoS d’OVH est justement à destination de ce type d’attaque.

Une petite note pour vous signaler que votre serveur peux servir dans les attaques DoS par amplification/réflexion.
Le principe est d’envoyer les paquets sur un service en écoute qui va appliquer un facteur d’amplification.
Le facteur d’amplification peut-être sur les datas ou sur le nombre de paquets.
A partir de x machines qui devrait générer x paquets ou data, on peux donc parvenir à obtenir x*y paquets ou datas et donc au final une attaque plus conséquente.

Les services DNS et NTP ont été utilisés dernièrement pour ces attaques par amplifications, pour le NTP, la page suivante donne une bonne explication : http://www.bortzmeyer.org/dns-attaque-ns-point.html

Ci-dessous, un exemple d’amplification de paquets sur mon kimsufi.
On voit en première ligne un SYN de 10 data avec une IP spoofée (Google) envoyé depuis une connexion ADSL.
Le kimsufi se met à envoyer une multitude de paquets ACK à Google.

en abaissant la valeur /proc/sys/net/ipv4/tcp_synack_retries à 1, on constate que le nombre de paquets ack envoyé est moindre et donc l’amplification aussi.
Par défaut, sur Debian, le nombre est 5, vous pouvez par exemple le réduire à 3 : sysctl -w net.ipv4.tcp_synack_retries=3

Pour ceux qui sont chez OVH, après quelques essais, il semblerait qu’on ne peux pas s’appuyer sur une machine OVH pour en attaquer une autre (le spoof semble être rejeté).
Par contre, il est possible d’utiliser une machine OVH pour spoofer vers une machine or OVH (comme dans l’exemple ci-dessus en tappant sur Google).

Anti-DOS OVH

La protection Anti-DoS d’OVH consiste, lorsqu’une attaque est détectée, de rediriger le trafic vers le serveur à travers un VAC (solutions Arbor + Firewall Network).
Le VAC permet une mitigation, le trafic néfaste est stoppé et le trafic légitime passe. Cela permet d’atténuer voire de bloquer l’intégralité de l’attaque.
Un Firewall Network est aussi disponible sur lequel, il est possible de configurer soit même ses règles.

Voici un schéma qui résume cette solution :

La protection protège donc du traffic venant d’internet mais pas du traffic intra-OVH
Notez que lorsqu’un serveur participe à DDoS en interne, OVH peut le détecter (j’imagine que ça dépend la vitesse de l’attaque), vous pouvez alors obtenir un mail « Anti-Hack » de ce type :

Ca peut vite monter avec un seul serveur :

Pour les utilisateurs Pro, il est possible de mettre son serveur en permanence derrière le VAC et le Firewall Network ou seulement le Firewall Network (donc sans le VAC).
Notez que cette solution protège contre les attaques venant de l’internet mais pas des attaques intra-OVH (un serveur OVH qui en attaque un autre).

Voici quelques traceroutes selon les différentes solutions :

Aucune protection activée :

Avec seulement le Firewall Network (saut de 11 à 14) :

Mitigation + Firewall network (saut de 11 à 14):

La gestion de la mitigation, activer la mitigation en permanence ou Firewall Network (Options Pros obligatoires) ou ajouter des règles peux se faire à partir du manager OVH en version 6.
Ci dessous, la mitigation et le firewall sont activés :

Les règles du Firewall Network :

L’ajout de règles sur le Firewall Network :

Une offre OVH pour des firewalls matériels est aussi disponible :

Lorsqu’une attaque est détectée par OVH et que la mitigation se met en route pour protéger le serveur, un mail vous ait envoyé.
De même, lorsque l’attaque est terminée, un mail vous le notifie.

Enfin notez que le programme floodmon peut aussi aider.
Vous pouvez aussi configurer le sytème pour limiter les SYNs, je vous laisse googler 🙂

La solution OVH permet donc de bloquer les attaques sur la couche 4.
Les attaques HTTP étant sur la couche 7, la solution Arbor n’est pas adaptée.

HTTP Flood

Ci-dessous quelques captures d’écran d’attaques HTTP :

Cela peux faire vite pas mal de paquets :

Comme vous pouvez le constater sur les captures ci-dessus des logs Apache, il existe une pattern afin de pouvoir isoler les requêtes issues de l’attaque.
Par exemple, dans la première captures, on a un referrer avec des lettres aléatoires de 10 caractères . 2 caractères.
Dans le second cas, on a des GET sans referrer.
Via un script, on peux donc récupérer les reqûetes répétées à partir des pattern.
Cela demande donc quelques connaissances systèmes.

Ce qui peux arriver, c’est que la table de routage soit pleine, on obtient en général ce message : nf_conntrack: table full, dropping packet

Vous pouvez alors augmenter le nombre de paquets avec cette commande : sysctl -w net.ipv4.netfilter.ip_conntrack_max=<more than currently set>

Noter que vous pouvez aussi jouer sur le timeout:

sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=54000
sysctl -w net.netfilter.nf_conntrack_generic_timeout=120

mod-evasive

Afin de limiter le nombre de requêtes sur une page, vous pouvez installer le module evasive pour Apache :

aptitude install libapache2-mod-evasive
a2enmod mod-evasive
/etc/apache2/mods-available/mod-evasive.conf

et ajouter :

<IfModule mod_evasive20.c>
           # taille de la table de surveillance, a augmenter pour les DDoS
           DOSHashTableSize 2048
           # Nb maximum de refresh d'une uri par periode
           DOSPageCount 5
           # Duree de la periode pour la uri
           DOSPageInterval 1
           # Nb maximum de requete sur le site par periode
           DOSSiteCount 150
           # Duree de la periode pour le site
           DOSSiteInterval 1
           # Duree du blacklistage de l'IP reconduite si retentative
           DOSBlockingPeriod 10
           # envoie de mail quant une IP est bloquee
           DOSEmailNotify "admin@localhost"
           # repertoire des logs
           DOSLogDir "/var/log/apache2/"
           # Whitelist non surveillee
           DOSWhiteList 127.0.0.1
           DOSWhitelist 192.168.0.*
</IfModule>

modsecurity peux aussi aider, puisqu’il incorpore des fonctions Anti-Dos : https://www.malekal.com/2013/08/12/presentation-modsecurity-pour-apache/

Renvoyer un 403

Ce qui peux être tenté aussi, c’est de faire renvoyer un 403 forbidden sur les requêtes issues de l’attaque.
Le 403 répondra plus vite et cela demandera surtout moins de ressources (surtout s’il y a des requêtes derrière, si par exemple, la page visée est une page de recherche).
Cela peux donc être fait avec du rewrite par exemple :

RewriteEngine On
RewriteCond %{HTTP_REFERER} [a-zA-Z0-9]{8}.[a-z]{2}$
RewriteRule ^.* - [F]

Par exemple si on veux interdir les POSTs sur la page index.php :


RewriteCond %{REQUEST_METHOD} POST
RewriteRule ^/index.php$ - [F] Si modsecurity est installée, on peux aussi ajouter une règle.

Syn flood : Limiter le nombre de connexions TCP par IP

Une option sympa d’iptables qui, d’après les tests fonctionne pas mal, c’est l’option connlimit.
Celle-ci permet de limiter le nombre de sessions TCP par IP.

Par exemple pour limiter à 10 sessions TCP par IP pour le port 80, cela donne :

/sbin/iptables -I INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 10 -j DROP

Dernièrement iptables et le kernel ont ajouté de nouvelles méthodes pour dropper les paquets SYN relativement efficace le SYNPROXY :
Limiter le nombre de connexion par IP à 20 :

/sbin/iptables/iptables -A INPUT -p tcp --port 80 -m connlimit --connlimit-above 10 -j REJECT --reject-with tcp-reset
/sbin/iptables/iptables -I INPUT -p tcp --dport 80-m connlimit --connlimit-above 20 --connlimit-mask 40 -j DROP
/sbin/iptables -I INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 10 -j DROP

Firewall logiciel (ipset)

Si la requête contient des éléments non aléatoire, vous pouvez utiliser l’option string d’iptables – exemple, la règle ci-dessous bloque les GET /w00tw00t :

iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t' -j DROP

ici on limite la vérification à une longueur de 70 caractères, veuillez à limiter au maximum la vérification, pour libérer des ressources.
En règle générale, si le nombre d’IPs est conséquente, l’ajout des IPs peut s’avérer long et bouffer des ressources (du fait qu’iptables joue les règles de manière linéaire).
IPset permet d’ajouter beaucoup d’IPs de manière rapides sans toucher aux règles iptables.
IPset nécessite de charger des modules dans le kernel.

modprobe ip_set_hash_net
modprobe ip_set_list_set

Pour créer un set :

ipset create attaquant hash:ip

auquel on applique une règle iptable – par exemple :

iptables -A INPUT -m set --match-set attaquant src -p tcp --dport 80 -j DROP

pour ajouter une IP dans le set attaquant :

ipset -! add attaquant IP

Pour ce type d’attaque, le gros problème est le nombre d’IPs, s’il y a vraiment beaucoup d’IPs, le temps de les récupérer sur Apache et les blacklister, de nouvelles IPs peuvent arriver pour saturer Apache.
De plus selon les ressources du serveur, si ces dernières était déjà limites en temps normal, bloquer une attaque sera plus difficile qu’avec un serveur sur-dimensionné.

Pour rappel, il existe aussi un topic pour sécuriser un serveur LAMP : https://forum.malekal.com/securiser-serveur-apache-php-mysql-lamp-t12276.html

EDIT – Décembre 13

Aujourd’hui, le site a subi une attaque.
La machine a été automatiquement basculée derrière la mitigation, ce qui est une bonne chose.
Le bémol, c’est qu’on est pas prévenu.

Par contre, ce qui est sympa, c’est que des statistiques ont été ajoutée sur le manager, on peux donc visualiser si l’attaque est toujours en cours avec le débit.