[Tutoriel de sécurité] Attaques SYN Flood, défense des cookies SYN et modification des paramètres du noyau pour Linux/FreeBSD

HackerC’est une carrière désirable et prometteuse. J’apprécie les bons hackers et je déteste les mauvais hackers. Le soi-disant mauvais hacker est le genre de personne qui fait faire des heures supplémentaires à quelqu’un de l’autre camp.

    Les attaques SYN par inondation sont typiques d’attaques par déni de service. La soi-disant attaque par déni de service vise indirectement à atteindre le but de l’attaque en rendant l’hôte ou le réseau victime incapable de fournir un bon service. Les hackers aiment jouer cela pour montrer qu’ils sont équilibrés, capables et courageux en faisant travailler l’autre partie en heures supplémentaires, mais en réalité, ce n’est rien.

   1 : Qu’est-ce qu’une attaque SYN Flood ?

    Les attaques SYN Flood exploitent le processus de handshake à trois voies du protocole TCP en IPv4. Ce protocole stipule que si une extrémité souhaite initier une connexion TCP à l’autre extrémité, elle doit d’abord envoyer un paquet TCP SYN (sync) à l’autre partie, puis l’autre partie renvoie un paquet TCP SYN + ACK après l’avoir reçu, puis l’initiateur renvoie un paquet TCP ACK (ACKnowledge Character), de sorte que les trois poignées de main sont terminées.

    Dans le processus ci-dessus, il y a quelques concepts importants :

    La file d’attente n’est pas connectée: Dans le protocole de poignée de main à trois voies, le serveur maintient une file d’attente non connectée qui ouvre une entrée pour chaque paquet SYN du client (syn=j) indiquant que le serveur a reçu le paquet SYN et émettant une confirmation au client, en attendant le paquet de confirmation du client. La connexion identifiée par ces entrées est dans un état Syn_RECV sur le serveur, et lorsque le serveur reçoit un paquet de confirmation du client, l’entrée est supprimée et le serveur entre dans l’état ÉTABLI. En d’autres termes, lorsque le serveur TCP reçoit le paquet de requête TCP SYN, avant d’envoyer le paquet TCP SYN+ACK au client TCP, le serveur TCP doit d’abord allouer une zone de données pour servir la connexion TCP formée par cette main. En général, l’état de connexion est lorsque le paquet SYN est reçu mais que le paquet ACK n’a pas encore été reçuConnexion semi-ouverte(Connexion à moitié ouverte)。

    Paramètre de retard: Indique le nombre maximal de files d’attente non connectées.

    Nombre de retransmissions SYN-ACK: Après que le serveur a envoyé le paquet SYN-ACK, si le paquet de confirmation client n’est pas reçu, le serveur effectue la première retransmission, attend un certain temps et ne reçoit pas le paquet de confirmation client, puis effectue la seconde retransmission ; si le nombre de retransmissions dépasse le nombre maximal de retransmissions spécifiées par le système, le système supprime les informations de connexion de la file semi-connexion. Notez que le temps d’attente pour chaque repasse n’est pas nécessairement le même.

    Temps de survie semi-connexe: Fait référence au temps maximal qu’une entrée dans la file de semi-connexion survit, c’est-à-dire le temps maximal entre le moment où le service reçoit le paquet SYN jusqu’au moment où le paquet est confirmé comme invalide, et la valeur de temps est la somme du temps d’attente maximal pour tous les paquets de demande de retransmission. Parfois, on appelle aussi le temps de survie semi-connecté, SYN_RECV temps de survie.

    Dans l’attaque SYN en inondation la plus courante, l’attaquant envoie un grand nombre de paquets TCP SYN à la victime en peu de temps, moment où l’attaquant devient le client TCP et la victime le serveur TCP. Selon la description ci-dessus, la victime assignait une zone de données spécifique à chaque paquet TCP SYN, tant que les paquets SYN avaient des adresses sources différentes (ce qui serait facile à forger pour les attaquants). Cela mettra beaucoup de pression sur le serveur TCP et finira par faire que le système ne fonctionnera pas correctement.

    2. Le principe des cookies SYN

    L’une des façons de prévenir efficacement les attaques SYN Flood est l’utilisation de cookies SYN. Raison D. Cookie SYN. Inventé par J. Bernstain et Eric Schenk.

    Les cookies SYN sont une modification du protocole TCP côté serveur à trois voies de négociation pour prévenir les attaques SYN Flood.Son principe est :Lorsque le serveur TCP reçoit un paquet TCP SYN et retourne un paquet TCP SYN+ACK, il n’alloue pas de zone de données dédiée, mais calcule une valeur de cookie basée sur ce paquet SYN. Lorsqu’un paquet TCP ACK est reçu, le serveur TCP vérifie la légitimité du paquet TCP ACK en fonction de la valeur de ce cookie. Si cela est légal, une zone de données dédiée est allouée pour gérer les futures connexions TCP.

    Parlons de la façon de configurer les paramètres du noyau pour implémenter les cookies SYN sous Linux et FreeBSD

    Trois : réglages Linux

    Si la configuration de votre serveur n’est pas bonne, le nombre de sockets TCP TIME_WAIT atteint 20 000 ou 30 000, et le serveur peut facilement être épuisé. En modifiant les paramètres du noyau Linux, le nombre de sockets TIME_WAIT sur le serveur peut être réduit.

    TIME_WAIT peut être consulté avec la commande suivante :

Sous Linux, comme CentOS, vous pouvez y parvenir en modifiant le fichier /etc/sysctl.conf.

    Ajoutez les lignes suivantes :

Illustrer:

net.ipv4.tcp_syncookies = 1 signifie que les cookies SYN sont activés, ce qui est un BOOLEAN. Lorsque SYN attend que la file d’attente déborde, activez les cookies pour gérer cela, ce qui peut empêcher un petit nombre d’attaques SYN, et le défaut est 0, ce qui signifie qu’il est fermé.
net.ipv4.tcp_tw_reuse = 1 signifie que la réutilisation est activée, ce qui est un objectif BOOLÉEN. Permet de réutiliser les sockets TIME-WAIT pour les nouvelles connexions TCP, en passant par défaut à 0, indiquant la fermeture ;
net.ipv4.tcp_tw_recycle = 1 signifie permettre un recyclage rapide des sockets TIME-WAIT dans les connexions TCP, ce qui est un BOOLEAN, et le défaut est 0, ce qui signifie qu’il est fermé.
net.ipv4.tcp_fin_timeout = 30 signifie que si le socket est fermé par une requête locale, ce paramètre détermine combien de temps il restera dans l’état FIN-WAIT-2. L’unité est en secondes.
net.ipv4.tcp_keepalive_time = 1200 indique à quelle fréquence TCP envoie des messages keepalive lorsque keepalive est utilisé. Par défaut, c’est 2 heures, puis changé à 20 minutes. L’unité est en secondes.
net.ipv4.ip_local_port_range = 1024 65000 indique la portée des ports utilisés pour les connexions extérieures. Le cas par défaut est petit : 32768 à 61000, changé de 1024 à 65000.
net.ipv4.tcp_max_syn_backlog = 8192 indique la longueur de la file d’attente SYN, qui est de 1024 par défaut, et la longueur de la file d’attente augmentée est de 8192 pour accueillir davantage de connexions réseau en attente de connexion.
net.ipv4.tcp_max_tw_buckets = 5000 indique le nombre maximal de sockets que le système maintient en TIME_WAIT simultanément, et si ce nombre est dépassé, TIME_WAIT sockets seront immédiatement effacés et un message d’avertissement sera imprimé. Le chiffre par défaut est 180 000, changé à 5 000. Pour des serveurs comme Apache et Nginx, les paramètres des lignes précédentes peuvent TIME_WAIT réduire le nombre de sockets, mais pour Squid, l’effet n’est pas très bon. Ce paramètre contrôle le nombre maximal de sockets TIME_WAIT afin d’empêcher le serveur Squid d’être traîné vers l’extérieur par un grand nombre de sockets TIME_WAIT.
net.ipv4.tcp_synack_retries et net.ipv4.tcp_syn_retries définissent le nombre de tentatives SYN.

Exécutez la commande suivante pour que la configuration prenne effet :

Si vous ne souhaitez pas modifier /etc/sysctl.conf, vous pouvez aussi utiliser la commande pour le faire :

Quatrièmement, configuré sous FreeBSD

    Point de vue personnel de yayu : la défense contre la synologie dans FreeBSD peut ne pas être la même que sous Linux, les paramètres configurés ne sont pas exactement les mêmes, et la configuration et la compréhension pertinentes peuvent ne pas être correctes :)

    Il y en a un dans le lien TCPMSL (durée de vie maximale du segment)Le concept deTemps de production maximalLa valeur MSL est prise pendant 30 secondes dans les implémentations générales, et certaines mettent en œuvre 2 minutes. « Arrêt passif » dans la machine à états TCP : De CLOSE_WAIT à LAST_ACK, il existe une règle suivante : lorsque TCP effectue un arrêt actif et renvoie le dernier ACK, la connexion doit rester dans l’état TIME_WAIT deux fois plus longtemps que le MSL. Cela permet à TCP d’envoyer à nouveau le dernier ACK en cas de perte (l’autre extrémité expire et renvoie le dernier FIN).

    L’existence de cette règle a pour conséquence que le lien (adresse client, port et adresse côté serveur, port) sur cette adresse ne peut pas être utilisé pendant ce temps 2*MSL. Par exemple, si nous fermons un lien après l’avoir créé puis que nous redémarrons rapidement le lien, alors le port sera indisponible.

    TIME_WAIT temps est de 2*MSL. Vous pouvez donc réduire TIME_WAIT temps en ajustant net.inet.tcp.msl. Pour le serveur web, cette valeur peut être ajustée à 7500 ou 2000 (accédez à un web, la page ne peut pas être flashée plus de 4~15 secondes, vous pouvez envisager d’abandonner -_-)

    Référence de paramètre :

Sur FreeBSD, yayu n’a pas vu de commande comme « /sbin/sysctl -p » qui pourrait rendre le contenu de /etc/sysctl.conf efficace, alors il a simplement utilisé la commande :