Partage de technologie

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Le principe de l’attaque conventionnelle par inondation

1. Lorsque la deuxième poignée de main TCP établit une semi-connexion, une attaque par inondation peut être lancée à ce moment-là.
2. Autrement dit, un grand nombre de requêtes initient des connexions TCP. Lors de la deuxième prise de contact, le serveur placera ces demandes dans la file d'attente de semi-connexion. Puisque ces clients attaquants malveillants ne confirmeront pas la troisième prise de contact, ces semi-connexions ne pourront pas être traitées. Relâchez, le serveur attendra l'expiration du délai. À ce moment-là, la file d'attente de semi-connexion sera remplie et les connexions de requêtes normales ne pourront pas recevoir de réponse. C'est la méthode d'attaque par inondation.

Comment résoudre les attaques d'inondations en général

1. Lorsque le mode syncookies est activé, le serveur calculera une valeur de hachage (SHA1) basée sur (l'adresse source, le port source, l'adresse de destination, le port de destination, etc.) et un nombre aléatoire lors de la première prise de contact, puis de la deuxième prise de contact. utilisera ceci. Les syncookies générés sont renvoyés au client. Lorsque le client confirme la troisième poignée de main, il enverra les syncookies au serveur. Le serveur vérifiera si le syncookie correspond au précédent. S'il correspond, une connexion TCP sera établie. établi.
2. L'avantage de cette approche : Lorsque le serveur ne reçoit pas ou que les syncookies reçus ne correspondent pas, la connexion TCP ne sera pas établie. Et lors de l'utilisation de syncookies, le serveur ne maintiendra pas la file d'attente de semi-connexion, c'est-à-dire qu'il n'y a pas d'état de semi-connexion. Parce que l'utilisation de syncookies à des fins de comparaison, la semi-connexion n'est pas nécessaire, ce qui évite la file d'attente de semi-connexion. étant rempli et empêchant la réception de nouvelles connexions.

Scénarios que les syncookies ne peuvent pas résoudre

1. Lorsqu'un grand nombre d'attaques DDOS sont lancées, la méthode syncookies sera également paralysée. La raison de la paralysie est que le CPU doit calculer un grand nombre de syncookies, ce qui entraîne sa mort. Étant donné que le calcul des syncookies consomme également des performances du processeur, celui-ci ne peut pas gérer l'énorme quantité de DDOS. Pour le moment, la seule option consiste à augmenter la bande passante et à configurer un plafond strict.

Autres solutions

1. Augmentez la file d'attente de semi-connexion et la file d'attente de connexion complète (cette méthode est fondamentalement inefficace pour les attaques massives)
2. Réduisez le nombre de retransmissions SYN+ACK (TCP s'appuie sur les retransmissions pour maintenir une connexion stable), c'est-à-dire que lorsqu'il reçoit une attaque par inondation provenant d'un grand nombre de requêtes de synchronisation, le serveur continuera de réessayer s'il ne peut pas recevoir de réponse jusqu'à ce que le nombre maximum de fois. Réduisez ce nombre maximum de fois. Cela vous soulagera.

Comment vérifier si vous avez été attaqué par une inondation

1. 先进行流量查看:
sar -n DEV 1 -h

然后只看eth0即可-->用rxkb/s 和 rxpck/s 这两列相除-->如果得出的包就50-60几字节，
那就说明是小包搞鬼，有可能遭受洪水攻击了，一般来说最大MTU = 1460

2. 如果发现是小包搞鬼，那就再进行网络抓包, 输入如下命令
tcpdump -i eth0 -n tcp port 80

3. 看有多少个[S], 这个表示发起TCP请求阶段，如果[S]过多，那就说明是洪水攻击，这是洪水攻击的特征


4. 进一步确认是洪水攻击，查询半连接的池子大小，以及当前半连接数量
半连接总大小: cat /proc/sys/net/ipv4/tcp_max_syn_backlog
当前半连接数: ss -s 或 netstat -n -p | grep SYN_RECV | wc -1



[S]: SYN，开始连接
[P]: PSH， 推送数据
[F]: FIN， 结束连接
[R]: RST, 重置连接
[.]: 没有Flag，可能是ACK 也可能是URG

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24