Compartilhamento de tecnologia

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

O princípio do ataque de inundação convencional

1. Quando o segundo handshake TCP estabelece uma semiconexão, um ataque de inundação pode ser lançado neste momento
2. Ou seja, um grande número de solicitações inicia conexões TCP. Durante o segundo handshake, o servidor colocará essas solicitações na fila de semiconexões. Como esses clientes atacantes maliciosos não confirmarão o terceiro handshake, essas semiconexões não poderão ser processadas. Liberado, o servidor aguardará até o tempo limite. Nesse momento, a fila de semi-conexão será preenchida e as conexões de solicitação normais não poderão ser atendidas.

Como resolver ataques de inundação em geral

1. Quando o modo sincronizadores estiver ativado, o servidor calculará um valor de hash (SHA1) com base em (endereço de origem, porta de origem, endereço de destino, porta de destino, etc.) e um número aleatório durante o primeiro handshake e, em seguida, o segundo handshake usará isto Os sincookies gerados serão retornados ao cliente. Quando o cliente confirmar o terceiro handshake, ele enviará os sincookies ao servidor. O servidor verificará se o sincookie corresponde ao anterior. estabelecido.
2. A vantagem desta abordagem: quando o servidor não recebe ou os sincookies recebidos não correspondem, a conexão TCP não será estabelecida. E ao usar sincookies, o servidor não manterá a fila de semi-conexão, ou seja, não há estado de semi-conexão, pois ao usar sincookies para comparação, não há necessidade de semi-conexão, evitando assim a fila de semi-conexão. sendo preenchido e incapaz de receber novas conexões.

Cenários que os sincronizadores não conseguem resolver

1. Quando um grande número de ataques DDOS são lançados, o método de sincookies também fica paralisado. O motivo da paralisia é que a CPU precisa calcular um grande número de sincookies, fazendo com que a CPU seja morta. Como o cálculo de sincookies também consome o desempenho da CPU, a CPU não consegue lidar com a enorme quantidade de DDOS. Neste momento, a única opção é aumentar a largura de banda e configurar um hard cap.

Outras soluções

1. Aumente a fila de semi-conexão e a fila de conexão completa (este método é basicamente ineficaz para ataques massivos)
2. Reduza o número de retransmissões SYN+ACK (o TCP depende de retransmissões para manter uma conexão estável), ou seja, quando recebe um ataque de inundação de um grande número de solicitações syn, o servidor continuará tentando novamente se não puder receber uma resposta até o número máximo de vezes. Reduza esse número máximo de vezes.

Como verificar para determinar se você foi atacado por uma inundação

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