Auteur Sujet: Mitigation des DDOS (Lu 1223 fois)

vivien · « **le:** 13 mai 2022 à 18:37:07 »

Hors sujet extrait de Présentation de Dyjix, Hébergement de solutions informatiques

Citation de: Hexicans le 13 mai 2022 à 17:13:16

Le filtrage :

Afin de mener à bien notre filtrage, nous utilisons XDP. Attention, nous n’avons pas vocation à devenir un prestataire anti-ddos, simplement nous souhaitons nous protéger ainsi que nos clients en mettant tous les moyens possibles en œuvre à notre niveau.

XDP est très connu et très utilisé, notamment par PATH, ce n’est pas du bricolage :-).

Pour cela, nous utilisons un serveur Dell R630 avec une carte 2x100G Mellanox.

Merci pour ces photos et informations.

Pour les règles de filtrages pour XDP (eXpress Data Path) c'est réalisé comment ?

J'ai toujours du mal à comprendre le filtrage à réaliser quand le DDOS est en TCP avec le port 443.

Hexicans · « **Réponse #1 le:** 13 mai 2022 à 18:50:31 »

Vivien,

Landry (Hanarion) pourra te détailler tout ça, mais globalement on filtre par :
- TTL
- Taille de paquet
- IP Source
- Port source
- Port est (si très violent)
- checksum
- Frag / no frag
- Whitelist DNS..

Donc même avec un ddos sur un port 443, si tous les paquets entrants sont de taille 60, avec un TTL de 30... il suffit d'appliquer un filtre sur tous les paquets entrants de taille 60 avec un TTL de 30.

Pour faire bref, on fait une capture de paquet qui est ensuite analysée automatiquement (et les règles sont crées en conséquence) en quelques secondes.

Hanarion · « **Réponse #2 le:** 15 mai 2022 à 11:29:50 »

Citation de: vivien le 13 mai 2022 à 18:37:07

J'ai toujours du mal à comprendre le filtrage à réaliser quand le DDOS est en TCP avec le port 443.

Comme l'a expliqué Axel, il y as toujours un facteur commun en cas d'attaque L3/4 dans ce cas on utilise ce facteur commun pour filtrer l'attaque, et nous planchons sur un filtrage avancé protocolaire sur les ports d'application classiques, vérification du payload pour confirmer que le trafic correspond au protocole.

vivien · « **Réponse #3 le:** 15 mai 2022 à 12:50:41 »

Tous les serveurs supportant TLS 1.3, je me pose la question du retrait de TLS 1.2 lors des attaques applicatives (je ne parle pas des attaques volumétriques ou qui saturent les serveurs de connexions SYN)

Anonyme · « **Réponse #4 le:** 15 mai 2022 à 16:42:39 »

Belle Infrastructure, on vous souhaite de poursuivre votre croissance.

HS pour répondre à vivien, c'est un début ( tu pourras splitter ailleurs, il faut bien que tu fasses quelque chose :p ) :
Il y a un outil opensource ( dont j'ai oublié le nom ) permettant la mitigation des DDOS

https://javapipe.com/blog/iptables-ddos-protection/

Code: [Sélectionner]

### 1: Drop invalid packets ### 
/sbin/iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP  

### 2: Drop TCP packets that are new and are not SYN ### 
/sbin/iptables -t mangle -A PREROUTING -p tcp ! --syn -m conntrack --ctstate NEW -j DROP 
 
### 3: Drop SYN packets with suspicious MSS value ### 
/sbin/iptables -t mangle -A PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP  

### 4: Block packets with bogus TCP flags ### 
/sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
/sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
/sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
/sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,ACK FIN -j DROP
/sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,URG URG -j DROP
/sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,PSH PSH -j DROP
/sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j DROP

### 5: Block spoofed packets ### 
/sbin/iptables -t mangle -A PREROUTING -s 224.0.0.0/3 -j DROP 
/sbin/iptables -t mangle -A PREROUTING -s 169.254.0.0/16 -j DROP 
/sbin/iptables -t mangle -A PREROUTING -s 172.16.0.0/12 -j DROP 
/sbin/iptables -t mangle -A PREROUTING -s 192.0.2.0/24 -j DROP 
/sbin/iptables -t mangle -A PREROUTING -s 192.168.0.0/16 -j DROP 
/sbin/iptables -t mangle -A PREROUTING -s 10.0.0.0/8 -j DROP 
/sbin/iptables -t mangle -A PREROUTING -s 0.0.0.0/8 -j DROP 
/sbin/iptables -t mangle -A PREROUTING -s 240.0.0.0/5 -j DROP 
/sbin/iptables -t mangle -A PREROUTING -s 127.0.0.0/8 ! -i lo -j DROP  

### 6: Drop ICMP (you usually don't need this protocol) ### 
/sbin/iptables -t mangle -A PREROUTING -p icmp -j DROP  

### 7: Drop fragments in all chains ### 
/sbin/iptables -t mangle -A PREROUTING -f -j DROP  

### 8: Limit connections per source IP ### 
/sbin/iptables -A INPUT -p tcp -m connlimit --connlimit-above 111 -j REJECT --reject-with tcp-reset  

### 9: Limit RST packets ### 
/sbin/iptables -A INPUT -p tcp --tcp-flags RST RST -m limit --limit 2/s --limit-burst 2 -j ACCEPT 
/sbin/iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP  

### 10: Limit new TCP connections per second per source IP ### 
/sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m limit --limit 60/s --limit-burst 20 -j ACCEPT 
/sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -j DROP  

### 11: Use SYNPROXY on all ports (disables connection limiting rule) ### 
# Hidden - unlock content above in "Mitigating SYN Floods With SYNPROXY" section

thenico · « **Réponse #5 le:** 16 mai 2022 à 00:37:25 »

Mettre du conntrack quand tu te prends un ddos, c'est le meilleur moyen de faire tomber ton pare-feu...
Et bloquer ICMP, c'est fabuleux pour les problèmes de MTU...

Anonyme · « **Réponse #6 le:** 16 mai 2022 à 01:24:54 »

Citation de: thenico le 16 mai 2022 à 00:37:25

Et bloquer ICMP, c'est fabuleux pour les problèmes de MTU...

Oui, je suis d'accord, il y a quelques règles à modifier, ou ne pas inclure, dont celle-ci.
Mais pour du basic, c'est déjà pas mal , je ne vais pas aller pourrir le Business de ceux qui vendent ces solutions.

vivien · « **Réponse #7 le:** 16 mai 2022 à 09:26:19 »

Je confirme que connlimit m'a bien aidé :

Code: [Sélectionner]

/usr/sbin/iptables  -A INPUT -p tcp --syn -m connlimit --connlimit-above 200 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/usr/sbin/iptables  -A INPUT -p tcp --syn -m connlimit --connlimit-above 200 -j REJECT
/usr/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 200 --connlimit-mask 64 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/usr/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 200 --connlimit-mask 64 -j REJECT

C'est très efficaces contres les slow DOS et les bug de certains PC / réseaux.

Cela a vraiment amélioré les choses pour moi de façon spectaculaire sur plusieurs serveurs.

Je vais regarder les différentes règles proposées, mais si elles sembles intéressantes sur un firewall en entrée de réseau, sur un serveur il me semble que plusieurs règles ne vont pas changer grand chose : un paquet invalide qu'il soit supprimé par iptables ou par le noyau ne va pas changer grand chose, non ?

Idem pour "Drop TCP packets that are new and are not SYN" : il sera de toute façon ignoré.

Le blocage "Block spoofed packets" me semble par contre pertinent, car il permet d'éviter la réservations de ressources pour une nouvelle connexion.

SYNPROXY il ne s'active pas automatiquement en cas de forte activité ? Je vois souvent ça dans mes log.

Anonyme · « **Réponse #8 le:** 16 mai 2022 à 18:56:17 »

Dans l'absolu je dirais que entre l'espace noyau et userland, moins tu fais de syscall, moins tu empiles, moins tu dépiles.

Ce qui d'un point de vu performances, aurait tendance à améliorer les choses.
Ensuite cela dépends comment c'est écrit, quand tu as des mutex,ou empêche des interruptions système pour terminer ton process, cela un impact réel. Si c'est dans le noyau, j'ose espérer que la Team Linux surveille

Auteur Sujet: Mitigation des DDOS (Lu 1223 fois)

Anonyme

Anonyme

Anonyme