[Linux] Voyez comment mon Linux protège contre les attaques SYN

En arrivant à l’entreprise ce matin, je me suis senti assez lent en me connectant sur le site officiel de l’entreprise, en me connectant au serveur pour vérifier le statut d’accès du site officiel :

[root@web ~]# netstat -anp |awk '{print $6}'|sort|uniq -c |sort -rn

     FONDÉ EN 172

     59 CONNECTÉ

    589 SYN_RECV

     15 STREAM

Le SYN est en fait très élevé, continuez à suivre le SYN envoyé par ces IP :

[root@tweb ~]# netstat -an | grep SYN | awk '{print $5}' | awk -F : '{print $1}' | trier | uniq -c | Trier -nr | plus

570 x.x.x.x   

(L’IP n’est pas écrite, c’est une IP de Shandong Zaozhuang Unicom), mais cette IP a envoyé tellement de connexions de requêtes SYN, et la concurrence de notre serveur web n’est pas très élevée, de sorte que les requêtes normales des utilisateurs ne peuvent pas être correspondues, et la page ne peut pas être ouverte. Comme le pare-feu matériel est géré par le service informatique du groupe, je n’ai aucune autorité, donc je ne peux prendre que quelques mesures sur le serveur local pour atténuer partiellement l’attaque SYN.

Tout d’abord, parlons du principe d’attaque de SYN :

Dans le protocole TCP/IP, le protocole TCP fournit des services de connexion fiables en utilisant une poignée de main à trois voies pour établir une connexion.

Première poignée de main : lors de l’établissement d’une connexion, le client envoie un paquet syn (syn=j) au serveur et entre dans l’état SYN_SEND, en attendant la confirmation du serveur.

La seconde poignée de main : Lorsque le serveur reçoit le paquet SYN, il doit confirmer le SYN du client (ack=j+1), et également envoyer un paquet SYN (syn=k), c’est-à-dire le paquet SYN+ACK, moment où le serveur entre dans l’état SYN_RECV.

Troisième poignée de main : Le client reçoit le paquet SYN+ACK du serveur et envoie le paquet de confirmation ACK (ack=k+1) au serveur. Après trois poignées de main, le client et le serveur commencent à transmettre des données.

Si l’utilisateur initie une requête de connexion avec le serveur pour se serrer la main une seconde fois et ne répond pas au serveur, celui-ci continuera d’attendre la confirmation de l’utilisateur. Nous effectuons donc les modifications suivantes directement depuis la connexion SYN :

Vérifiez la configuration SYN par défaut sous Linux :

[root@web ~]# sysctl -a | GREP _syn

net.ipv4.tcp_max_syn_backlog = 1024

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_synack_retries = 5

net.ipv4.tcp_syn_retries = 5

tcp_max_syn_backlog est la longueur de la file d’attente SYN, et augmenter la longueur de la file SYN peut accueillir davantage de connexions réseau en attente d’être connectées. tcp_syncookies est un interrupteur pour activer la fonction cookie SYN, qui peut prévenir les attaques partielles SYN. tcp_synack_retries et tcp_syn_retries définissent le nombre de connexions de réessayage pour le SYN, et réduisent les paramètres par défaut pour contrôler autant que possible le nombre de connexions SYN.

Voici les paramètres que j’ai modifiés, qui peuvent être modifiés selon la situation réelle de mon serveur :

[root@web ~]# plus /etc/rc.d/rc.local

# !/bin/sh

# Ce scrip{filter}t sera exécuté *après* tous les autres scripts init {filter}ts.

# Tu peux mettre tes propres documents d’initialisation ici si tu ne le fais pas

# Je veux faire tout le style Sys V à l’intérieur.

toucher /var/lock/subsys/local

ulimit -HSn 65535

/usr/local/apache2/bin/apachectl start

#####

sysctl -w net.ipv4.tcp_max_syn_backlog=2048

sysctl -w net.ipv4.tcp_syncookies=1

sysctl -w net.ipv4.tcp_synack_retries=3

sysctl -w net.ipv4.tcp_syn_retries=3

Pour que la configuration prenne effet immédiatement sans redémarrer le serveur, cela peut être effectué

#sysctl -w net.ipv4.tcp_max_syn_backlog=2048

#sysctl -w net.ipv4.tcp_syncookies=1

#sysctl -w net.ipv4.tcp_synack_retries=3

#sysctl -w net.ipv4.tcp_syn_retries=3

Certaines personnes aiment utiliser les listes de contrôle d’accès pour prévenir les attaques SYN, ce qui ralentit dans une certaine mesure les attaques SYN :

Attaque de déluge syn

#iptables -A ENTRÉE -p tcp --syn -m limite ---limite 1/s -j ACCEPTER

--limite 1/s limite le nombre de concurrents syn à 1 fois par seconde

Balayage anti-port

# iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limite --limite 1/s -j ACCEPTER

Ping de la mort

# iptables -A FORWARD -p icmp --type icmp-request d’écho -m limite --limite 1/s -j ACCEPTER

#>iptables-save >/etc/sysconfig/iptables

Pour voir, #iptables -L

ACCEPTER tcp -- partout où où tcp drapeaux :FIN,SYN,RST,ACK/SYN limite : moyenne 1/sec rafale 5

ACCEPTER tcp -- partout où où tu drapeaux tcp : FIN, SYN, RST, ACK/RST limite : moyenne 1/sec rafale 5

ACCEPT icmp -- n’importe où où ICMP Echo-Request limite : moyenne 1/s rafale 5

Vérifie à nouveau la connexion syn :

[root@web ~]# netstat -an | grep SYN | awk '{print $5}' | awk -F : '{print $1}' | trier | uniq -c | Trier -nr | plus

     20 10.92.10.220

      1 125.43.36.199

Évidemment, le nombre de connexions SYN a diminué.