« LINUX:DDOS » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
Ligne 7 : | Ligne 7 : | ||
Une première solution est d'établir des règles dans FireWall telles celles présentées dans l'article sur [[LINUX:XTABLES-ADDONS|IPTABLES: XTABLES-ADDONS]]. On complète cette approche par l'activation d'un HIDS tel [[LINUX:Wazuh: HIDS|Wazuh]]. | Une première solution est d'établir des règles dans le FireWall telles celles présentées dans l'article sur [[LINUX:XTABLES-ADDONS|IPTABLES: XTABLES-ADDONS]]. On complète cette approche par l'activation d'un HIDS tel [[LINUX:Wazuh: HIDS|Wazuh]]. | ||
Une seconde approche est la surveillance active des journaux du système et des messages d'alertes envoyés par un HIDS tel [[LINUX:Wazuh: HIDS|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 | Une seconde approche est la surveillance active des journaux du système et des messages d'alertes envoyés par un HIDS tel [[LINUX:Wazuh: HIDS|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 ralentissent l'accès au serveur et dans le cas d'une utilisation d'un HIDS, le FireWall s'encombre de règles qui peuvent être optimisée sous forme d'une seule règle. Par exemple, j'ai subi une attaque au travers d'un serveur VPN situé à Singapour par plusieurs centaines. Toutes provenaient du même sub-net. D'où l'ajout d'une règle de blocage sous forme de sub-net. L'alerte passée, on peut penser à ré-ouvrir la porte. | ||
Ligne 21 : | Ligne 21 : | ||
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). Nous travaillons en IPV4 mais le script peut gérer l'IPV6. | 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). Nous travaillons en IPV4 mais le script peut gérer l'IPV6. | ||
Dans notre cas, | Dans notre cas, nous serons confrontés aux logiciels principaux suivants: "iptables", "ss" et "tcpkill". | ||
=Installation= | =Installation= | ||
En premier, on télécharge le produit: | En premier, on télécharge le produit: | ||
wget <nowiki>https://github.com/jgmdev/ddos-deflate/archive/master.zip -O ddos.zip | wget <nowiki>https://github.com/jgmdev/ddos-deflate/archive/master.zip</nowiki> -O ddos.zip | ||
On le décompresse ensuite: | On le décompresse ensuite: | ||
unzip ddos.zip | unzip ddos.zip | ||
Ligne 51 : | Ligne 51 : | ||
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. | 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. | Voici quelques paramètres importants dans notre cas. Nous avons laissé les commentaires pour faciliter la compréhension de ces paramètres. | ||
---- | ---- | ||
# How many connections define a bad IP per user? Indicate that below. | # How many connections define a bad IP per user? Indicate that below. | ||
Ligne 80 : | Ligne 80 : | ||
192.168.1.0/24 | 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. | * Le fichier "ignore.host.list" reprend la liste blanche des machines sous forme de son nom DNS. Nous ne l'avons pas modifié. Aucune n'est active. | ||
Ligne 91 : | Ligne 91 : | ||
Pour le démon, on utilise le système "Systemd". | Pour le démon, on utilise le système "Systemd". Notons que d'autres méthodes sont utilisables. | ||
Pour relancer le service, on utilise la commande: | Pour relancer le service, on utilise la commande: | ||
Ligne 106 : | Ligne 106 : | ||
Par exemple, la commande: | |||
ddos -b | ddos -b | ||
liste les adresses IP bloquées. | 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 | 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 bloquée et en fin de ligne, 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 des messages 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: | 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: | ||
Ligne 154 : | Ligne 154 : | ||
On lance une commande qui peut ressembler à ceci: | 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 | slowhttptest -c 1000 -H -g -o slowhttp -i 10 -r 200 -t GET -u <nowiki>https://192.168.1.2/</nowiki> -x 24 -p 3 | ||
Si tout se passe bien, on recevra un mail et une entrée de blocage sera ajoutée. | Si tout se passe bien, on recevra un mail et une entrée de blocage sera ajoutée. |
Dernière version du 13 novembre 2024 à 21:17
→ 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 le 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 ralentissent l'accès au serveur et dans le cas d'une utilisation d'un HIDS, le FireWall s'encombre de règles qui peuvent être optimisée sous forme d'une seule règle. Par exemple, j'ai subi une attaque au travers d'un serveur VPN situé à Singapour par plusieurs centaines. Toutes provenaient du même sub-net. D'où l'ajout d'une règle de blocage sous forme de sub-net. L'alerte passée, on peut penser à ré-ouvrir la porte.
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). Nous travaillons en IPV4 mais le script peut gérer l'IPV6.
Dans notre cas, nous serons confrontés aux logiciels principaux suivants: "iptables", "ss" et "tcpkill".
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.
Le FireWall doit être actif. Nous utilisons le service "iptables.service". On peut le vérifier avec la commande:
systemctl status iptables
dans le cas d'IPV4.
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. Nous avons laissé les commentaires pour faciliter la compréhension de ces paramètres.
# 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 DNS. 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.
Pour le démon, on utilise le système "Systemd". Notons que d'autres méthodes sont utilisables.
Pour relancer le service, on utilise la commande:
sysytemctl restart ddos.service
Pour l'arrêter:
systemctl stop ddos.service
Un fichier d'aide existe:
man ddos
ou la commande:
ddos -h
donne une explication succincte.
Par exemple, 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 bloquée et en fin de ligne, 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 des messages 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