LINUX:DDOS

---

→ retour au menu pour contrer les attaques

---

But

Les attaques DOS et DDOS sont de plus en plus fréquentes. On ne peut pas nécessairement s'en prémunir complètement mais on peut en atténuer les effets.

Une première solution est d'établir des règles dans FireWall telles celles présentées dans l'article sur IPTABLES: XTABLES-ADDONS. On complète cette approche par l'activation d'un HIDS tel Wazuh.

Une seconde approche est la surveillance active des journaux du système et des messages d'alertes envoyés par un HIDS tel Wazuh. Si une recrudescence d'attaques provenant d'un sub-net ou d'un pays survient, on ajoute rapidement une règle dans notre FireWall. Ceci m'est arrivé trois fois, ces attaques ralentissant l'accès au serveur.

Je n'ai pas subit jusqu'à présent d'attaque massive. Mon site étant très anecdotique, non stratégique. Mais j'ai quand même ajouté un produit simple dans sa conception mais qui bloque quelques tentatives.

Au début j'ai utilisé un logiciel nommé No-More-DDos; je me suis tourné ensuite sur le logiciel DDoS-Deflate. Les deux ont une conception très proches et ont une base commune.

Principe

Le script travaille en boucle à intervalle régulier. Il analyse les connexions réseau avec la commande "ss" ou "netstat". Dès qu'une machine dépasse un certain nombre d'entrées et qu'elle n'est pas dans la liste blanche qui l'exclu de la recherche, un mail est envoyé à l'administrateur, une entrée de blocage est ajoutée au FireWall. Les connexions existantes pour cette machine seront éliminées ("tcpkill"). Après le temps de blocage écoulé, il enlève le blocage dans le FireWall. Plusieurs types de FireWall peuvent être utilisés. Nous n'avons pas utilisé le contrôle du taux de transfert ni la restriction à certains ports (80 et 443 par exemple pour le Web).

Dans notre cas, les logiciels "iptables", "ss" et "tcpkill" seront utilisés.

Installation

En premier, on télécharge le produit:

wget https://github.com/jgmdev/ddos-deflate/archive/master.zip -O ddos.zip

On le décompresse ensuite:

unzip ddos.zip

Son contenu se retrouve dans le sous-répertoire "ddos-deflate-master". On s'y rend:

cd ddos-deflate-master

Notons qu'il a besoin d'un certain nombre d'autres logiciels dont on peut découvrir la liste dans le fichier "README.md" et dans le fichier "config/dependencies.list". Normalement ils sont installés lors de la phase d'installation qui suit:

make install

Dans mon cas, la gestion des services est assurée par le système "Systemd". Le service "ddos.service" est ajouté et lancé automatiquement.

Ce logiciel est un simple script "sh" qui se trouve dans le répertoire "/usr/local/ddos". Ce script se nomme "ddos.sh".

Configuration

Les trois fichiers de configuration se trouvent dans le répertoire "/etc/ddos".

• Le fichier "ddos.conf" reprend tous les paramètres de configuration du logiciel. Nous avons modifié certains paramètres.

Nous avons choisi de ne vérifier que les connexions entrantes sans analyser l'importance du trafic. Au début nous surveillions le trafic dans les deux sens mais lors le le mise à jour de WordPress, nous avons été confrontés à un blocage. D'où notre changement. Nous avons aussi allongé le temps de blocage.

Voici quelques paramètres importants dans notre cas.

---

# How many connections define a bad IP per user? Indicate that below.
NO_OF_CONNECTIONS=150
# Only count incoming connections to listening services, which will
# prevent the server from banning multiple outgoing connections to
# a single ip address. (slower than default in/out method)
ONLY_INCOMING=true
# The firewall to use for blocking/unblocking, valid values are:
# auto, apf, csf, ipfw, and iptables
FIREWALL="auto"
# Number of seconds the banned ip should remain in blacklist.
BAN_PERIOD=18000
# An email is sent to the following address when an IP is banned.
# Blank would suppress sending of mails
EMAIL_TO="root"
# Connection states to block. See: man ss
# each state should be separated by a colon (:), for example:
# "established:syn-sent:syn-recv:fin-wait-1:fin-wait-2"
# by default it blocks all states except for listening and closed
CONN_STATES="connected"

---

• Le fichier "ignore.ip.list" reprend la liste blanche des machines sous forme d'adresses IP ou d'ensemble de machines sous forme de de sub-net IP.

On édite ce fichier pour l'adapter à notre contexte. On laisse l'adresse de localhost et on ajoute par exemple le sub-net de notre réseau local ou si on se veut plus restrictif, les adresses IP des machines de confiance. Par exemple:

---

127.0.0.0/8
192.168.1.0/24

---

• Le fichier "ignore.host.list" reprend la liste blanche des machines sous forme de son nom. Nous ne l'avons pas modifié. Aucune n'est active.

Après modification, le service doit être relancé:

systemctl restart ddos.service

Utilisation

Il a deux modes d'utilisation: en mode démon pour la contre-attaque automatique et en mode ligne de commandes pour la consultation de son état.

Un fichier d'aide existe:

man ddos

ou la commande:

ddos -h

donne une explication succincte.

La commande:

ddos -b

liste les adresses IP bloquées.

Les fichiers de gestion se trouvent dans le répertoire "/var/lib/ddos". Dans mon cas, c'est le fichier "bans.list" qui est concerné. Quand une machine distante est bloquée, un entrée est ajoutée. Chaque ligne comporte une date exprimée en secondes qui définit l'échéance du blocage. Elle est suivie de l'adresse IP de la machine distante et en fin, le nombre de connexions concomitantes effectuées lors de sa détection. Dès que la date limite est atteinte, le blocage est éliminé ainsi que son entrée dans ce fichier. On retrouvera un message dans le fichier journal "/var/log/ddos.log".

Dans le cas d'une machine bloquée, par exemple "95.214.27.19", l'entrée suivante a été ajoutées au FireWall, via IPTABLES dans notre cas:

iptables -A INPUT -s 95.214.27.19 -DROP

Elle sera éliminée par une commande analogue:

iptables -D INPUT -s 95.214.27.19 -DROP

le temps de blocage écoulé.

Correction

Suite à l'utilisation du paramètre "ONLY_INCOMING=true", le blocage dans la détection ne s'effectuait pas.

En analysant le code du script "/usr/local/ddos/ddos.sh", j'ai dû effectuer deux corrections dans la procédure "get_connections" aux lignes 359 et 362.

Voici les lignes d'origine:

---

           ss -ntu"$1" state listening state unconnected | \
...
               sed -E "s/(tcp|udp)/\\1 /g; s/ *:([0-9]+) / [::]:\\1 /g"

---

Voici les lignes modifiées:

---

           ss -ntu state listening state unconnected | \
...
               sed -E "s/(tcp|udp)/\\1 /g; s/ \*:([0-9]+) / [::]:\\1 /g"

---

Pour la première ligne, on a éliminé l'utilisation du paramètre "$1" qui est blanc mais qui empêche l'exécution de la commande "ss".

La seconde nécessite un back-slach devant l'étoile pour qu'elle soit utilisée telle quelle.

Test

Maintenant que tout est en place, il est utile de tester ce logiciel.

On va utiliser le logiciel "slowhttptest".

On va l'installer sur une autre machine Linux qui sera chargée de l’attaque:

dnf install slowhttptest

Evidemment la machine qui attaque ne doit pas être dans le fichier de la liste blanche.

Supposons que la machine protégée a l'adresse IP "192.168.1.2" et possède un service Web "httpd.service".

On lance une commande qui peut ressembler à ceci:

slowhttptest -c 1000 -H -g -o slowhttp -i 10 -r 200 -t GET -u https://192.168.1.2/ -x 24 -p 3

Si tout se passe bien, on recevra un mail et une entrée de blocage sera ajoutée.

---

→ retour au menu pour contrer les attaques

---