Compartir tecnología

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

El principio del ataque convencional contra inundaciones.

1. Cuando el segundo protocolo de enlace de TCP establece una semiconexión, se puede lanzar un ataque de inundación en este momento.
2. Es decir, una gran cantidad de solicitudes inician conexiones TCP durante el segundo protocolo de enlace, el servidor colocará estas solicitudes en la cola de semiconexiones. Dado que estos clientes atacantes maliciosos no confirmarán el tercer protocolo de enlace, estas semiconexiones no se pueden procesar. Liberado, el servidor esperará hasta que se agote el tiempo de espera. En este momento, la cola de semiconexión se llenará y las conexiones de solicitud normales no podrán responder. Esta es la forma de ataque de inundación.

Cómo solucionar los ataques de inundaciones en general

1. Cuando el modo syncookies está activado, el servidor calculará un valor hash (SHA1) basado en (dirección de origen, puerto de origen, dirección de destino, puerto de destino, etc.) y un número aleatorio durante el primer protocolo de enlace y luego el segundo. usará esto Las syncookies generadas se devuelven al cliente. Cuando el cliente confirma el tercer protocolo de enlace, enviará las syncookies al servidor. El servidor verificará si la syncookie coincide con la anterior. Si coincide, se establecerá una conexión TCP. establecido.
2. La ventaja de este enfoque: cuando el servidor no recibe o las cookies sincronizadas recibidas no coinciden, no se establecerá la conexión TCP. Y cuando se usan syncookies, el servidor no mantendrá la cola de semiconexión, es decir, no hay un estado de semiconexión. Debido al uso de syncookies para comparar, no hay necesidad de semiconexión, por lo que se evita la cola de semiconexión. llenándose e impidiendo que se reciban nuevas conexiones.

Escenarios que las syncookies no pueden resolver

1. Cuando se lanza una gran cantidad de ataques DDOS, el método syncookies también se paralizará. El motivo de la parálisis es que la CPU tiene que calcular una gran cantidad de syncookies, lo que provoca que la CPU muera. Debido a que el cálculo de syncookies también consume rendimiento de la CPU, la CPU no puede manejar la gran cantidad de DDOS. En este momento, la única opción es aumentar el ancho de banda y configurar un límite máximo.

Otras soluciones

1. Aumente la cola de semiconexión y la cola de conexión completa (este método es básicamente ineficaz para ataques masivos)
2. Reduzca la cantidad de retransmisiones SYN + ACK (TCP depende de las retransmisiones para mantener una conexión estable), es decir, cuando recibe un ataque de inundación de una gran cantidad de solicitudes de sincronización, el servidor continuará reintentando si no puede recibir una respuesta hasta el número máximo de veces. Reduzca este número máximo de veces. Le dará algo de alivio.

Cómo comprobar si ha sido atacado por una inundación

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