Condivisione della tecnologia

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

Il principio dell'attacco convenzionale alle piene

1. Quando il secondo handshake TCP stabilisce una semi-connessione, in questo momento può essere lanciato un attacco Flood
2. Cioè, un gran numero di richieste avvia connessioni TCP. Durante il secondo handshake, il server inserirà queste richieste nella coda di semi-connessione. Poiché questi client dannosi non confermeranno il terzo handshake, queste semi-connessioni non possono essere elaborate. Rilasciato, il server attenderà fino al timeout. In questo momento, la coda di semi-connessione verrà riempita e non sarà possibile rispondere alle normali connessioni di richiesta.

Come risolvere gli attacchi di alluvioni in generale

1. Quando la modalità syncookies è attivata, il server calcolerà un valore hash (SHA1) basato su (indirizzo di origine, porta di origine, indirizzo di destinazione, porta di destinazione, ecc.) e un numero casuale durante il primo handshake, quindi il secondo handshake utilizzerà questo I syncookie generati vengono restituiti al client. Quando il client conferma il terzo handshake, invierà i syncookie al server Il server verificherà se il syncookie corrisponde a quello precedente. Se corrisponde, verrà stabilita una connessione TCP stabilito.
2. Il vantaggio di questo approccio: quando il server non riceve o i syncookie ricevuti non corrispondono, la connessione TCP non verrà stabilita. E quando si utilizzano i syncookie, il server non manterrà la coda di semi-connessione, ovvero non esiste uno stato di semi-connessione. Poiché utilizzando i syncookie per il confronto, non è necessaria la semi-connessione, quindi evita la coda di semi-connessione essere riempiti e impedire la ricezione di nuove connessioni.

Scenari che i syncookies non possono risolvere

1. Quando vengono lanciati un gran numero di attacchi DDOS, anche il metodo syncookies viene paralizzato. Il motivo della paralisi è che la CPU deve calcolare un gran numero di syncookies, causandone l'uccisione. Poiché il calcolo dei syncookie consuma anche le prestazioni della CPU, la CPU non è in grado di gestire l'enorme quantità di DDOS. Al momento, l'unica opzione è aumentare la larghezza di banda e configurare un limite rigido.

Altre soluzioni

1. Aumentare la coda di semi-connessione e la coda di connessione completa (questo metodo è sostanzialmente inefficace per attacchi massicci)
2. Ridurre il numero di ritrasmissioni SYN+ACK (TCP si basa sulle ritrasmissioni per mantenere una connessione stabile), ovvero quando riceve un attacco Flood da un gran numero di richieste syn, il server continuerà a riprovare se non può ricevere una risposta fino a quando il numero massimo di volte. Riduci questo numero massimo di volte. Ti darà un po' di sollievo

Come verificare se sei stato attaccato da un'alluvione

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