[Tutorial sulla sicurezza] Attacchi SYN Flood, difesa dei cookie SYN e modifica dei parametri del kernel per Linux/FreeBSD

HackerÈ una carriera desiderabile e promettente. Apprezzo i bravi hacker e odio i cattivi hacker. Il cosiddetto hacker cattivo è il tipo di persona che fa fare straordinari a qualcuno dall'altra parte.

    Gli attacchi SYN Flood sono tipici attacchi di negazione del servizio. Il cosiddetto attacco di negazione del servizio serve a raggiungere indirettamente lo scopo dell'attacco rendendo l'host vittima o la rete incapace di fornire un buon servizio. Gli hacker amano giocare questo per dimostrare di essere alla linea, capaci e coraggiosi facendo lavorare l'altra parte straordinaria, ma in realtà non è nulla.

   1: Cos'è un attacco SYN Flood?

    Gli attacchi SYN Flood sfruttano il processo di handshake a tre vie del protocollo TCP in IPv4. Questo protocollo stabilisce che se un'estremità vuole avviare una connessione TCP all'altra estremità, deve prima inviare un pacchetto TCP SYN (sync) all'altra parte, e l'altra parte invia un pacchetto TCP SYN + ACK dopo averlo ricevuto, e poi l'iniziatore invia un pacchetto TCP ACK (ACKnowledge Character), così che le tre strette di mano siano terminate.

    Nel processo sopra, ci sono alcuni concetti importanti:

    La coda non è collegata: Nel protocollo a tre vie di handshake, il server mantiene una coda non connessa che apre una voce per ogni pacchetto SYN del client (syn=j) che indica che il server ha ricevuto il pacchetto SYN ed emette una conferma al cliente, in attesa del pacchetto di conferma del cliente. La connessione identificata da queste voci si trova in uno stato Syn_RECV sul server e, quando il server riceve un pacchetto di conferma dal cliente, la voce viene eliminata e il server entra nello stato ESTABLISHED. In altre parole, quando il server TCP riceve il pacchetto di richiesta TCP SYN, prima di inviare il pacchetto TCP SYN+ACK al client TCP, il server TCP deve prima allocare un'area dati per servire la connessione TCP formata da questa mano. Generalmente, lo stato di connessione è quando il pacchetto SYN viene ricevuto ma il pacchetto ACK non è ancora stato ricevutoConnessione semi-aperta(Connessione semiaperta)。

    Parametro di backlog: Indica il numero massimo di code non collegate.

    Numero di ritrasmissioni SYN-ACK: Dopo che il server invia il pacchetto SYN-ACK, se il pacchetto di conferma del cliente non viene ricevuto, il server esegue la prima ritrasmissione, aspetta un certo periodo di tempo e non riceve il pacchetto di conferma del cliente, ed esegue la seconda ritrasmissione; se il numero di ritrasmissioni supera il numero massimo di ritrasmissioni specificato dal sistema, il sistema elimina le informazioni di connessione dalla semi-coda di connessione. Nota che il tempo di attesa per ogni ripetizione non è necessariamente lo stesso.

    Tempo di sopravvivenza semi-connesso: Si riferisce al tempo massimo che una voce nella semi-coda di connessione sopravvive, cioè il tempo massimo dal momento in cui il servizio riceve il pacchetto SYN fino al momento in cui il pacchetto è confermato invalido, e il valore temporale è la somma del tempo massimo di attesa per tutti i pacchetti di richiesta di ritrasmissione (retransmission request). A volte chiamiamo anche tempo di sopravvivenza semi-connesso, SYN_RECV tempo di sopravvivenza.

    Nel più comune attacco a flood SYN, l'attaccante invia un gran numero di pacchetti TCP SYN alla vittima in un breve periodo di tempo, a quel punto l'attaccante è il client TCP e la vittima il server TCP. Secondo la descrizione sopra, la vittima assegnerebbe una zona dati specifica a ciascun pacchetto TCP SYN, purché i pacchetti SYN abbiano indirizzi sorgente diversi (cosa che sarebbe facile da falsificare per gli attaccanti). Questo metterà molta pressione sul sistema server TCP e alla fine farà sì che il sistema non funzioni correttamente.

    2. Il principio dei cookie SYN

    Uno dei modi per prevenire efficacemente gli attacchi SYN Flood sono i cookie SYN. Motivo D. Biscotto SYN. Inventato da J. Bernstain ed Eric Schenk.

    I cookie SYN sono una modifica del protocollo di handshake a tre vie lato server TCP per prevenire attacchi SYN Flood.Il suo principio è:Quando il server TCP riceve un pacchetto TCP SYN e restituisce un pacchetto TCP SYN+ACK, non alloca un'area dati dedicata, ma calcola un valore di cookie basato su questo pacchetto SYN. Quando viene ricevuto un pacchetto TCP ACK, il server TCP verifica la legittimità del pacchetto TCP ACK basandosi su quel valore del cookie. Se legale, viene assegnata un'area dati dedicata per gestire future connessioni TCP.

    Parliamo di come configurare i parametri del kernel per implementare i cookie SYN in Linux e FreeBSD

    Tre: impostazioni Linux

    Se la configurazione del tuo server non è buona, il numero di socket TCP TIME_WAIT raggiunge 20.000 o 30.000, e il server può facilmente essere trascinato fino all'esaurimento della situazione. Modificando i parametri del kernel Linux, il numero di socket TIME_WAIT sul server può essere ridotto.

    TIME_WAIT può essere visualizzato con il seguente comando:

Su Linux, come CentOS, puoi ottenere questo risultato modificando il file /etc/sysctl.conf.

    Aggiungi le seguenti righe:

Illustrare:

net.ipv4.tcp_syncookies = 1 significa che i cookie SYN sono abilitati, il che è un BOOLEAN. Quando SYN aspetta che la coda si sovrasvuoti, abilita i cookie per gestirla, il che può prevenire un piccolo numero di attacchi SYN, e il valore predefinito è 0, il che significa che è chiuso.
net.ipv4.tcp_tw_reuse = 1 significa che il riutilizzo è abilitato, il che è un BOOLEAN. Permette di riutilizzare socket TIME-WAIT per nuove connessioni TCP, impostando di default 0, indicando la chiusura;
net.ipv4.tcp_tw_recycle = 1 significa permettere il rapido riciclo dei socket TIME-WAIT nelle connessioni TCP, che è BOOLEAN, e il valore predefinito è 0, il che significa che è chiuso.
net.ipv4.tcp_fin_timeout = 30 significa che se il socket viene chiuso da una richiesta locale, questo parametro determina quanto tempo rimarrà nello stato FIN-WAIT-2. L'unità è a secondi.
net.ipv4.tcp_keepalive_time = 1200 indica con quale frequenza TCP invia messaggi keepalive quando viene utilizzato keepalive. Il valore predefinito è 2 ore, cambiato a 20 minuti. L'unità è a secondi.
net.ipv4.ip_local_port_range = 1024 65000 indica la gamma di porte utilizzate per le connessioni in uscita. Il caso predefinito è piccolo: da 32768 a 61000, cambiato da 1024 a 65000.
net.ipv4.tcp_max_syn_backlog = 8192 indica la lunghezza della coda SYN, che è 1024 di default, e la lunghezza della coda aumentata è 8192 per consentire più connessioni di rete in attesa di connessione.
net.ipv4.tcp_max_tw_buckets = 5000 indica il numero massimo di socket che il sistema mantiene contemporaneamente TIME_WAIT e, se questo numero viene superato, TIME_WAIT socket verranno immediatamente cancellati e verrà stampato un messaggio di avviso. Il valore predefinito è 180000, cambiato a 5000. Per server come Apache e Nginx, i parametri delle linee precedenti possono ridurre TIME_WAIT il numero di socket, ma per Squid l'effetto non è eccezionale. Questo parametro controlla il numero massimo di socket TIME_WAIT per evitare che il server Squid venga trascinato da un gran numero di socket TIME_WAIT.
net.ipv4.tcp_synack_retries e net.ipv4.tcp_syn_retries definiscono il numero di tentativi SYN.

Esegui il seguente comando per far entrare in vigore la configurazione:

Se non vuoi modificare /etc/sysctl.conf, puoi anche usare il comando per farlo:

Quarto, configurato sotto FreeBSD

    Il punto di vista personale di apprendimento di yayu: la difesa contro la syn in FreeBSD potrebbe non essere la stessa di Linux, i parametri configurati non sono esattamente gli stessi e la configurazione e la comprensione rilevanti potrebbero non essere corrette :)

    Ce n'è uno nel collegamento TCPMSL (vita massima del segmento)Il concetto diTempo massimo di generazioneIl valore MSL viene preso per 30 secondi nelle implementazioni generali, mentre alcune implementazioni richiedono 2 minuti. "Spegnimento passivo" nella macchina a stati TCP: Da CLOSE_WAIT a LAST_ACK, esiste una regola come segue: quando TCP effettua uno spegnimento attivo e restituisce l'ultimo ACK, la connessione deve rimanere nello stato TIME_WAIT per il doppio del tempo rispetto al MSL. Questo permette a TCP di inviare nuovamente l'ultimo ACK nel caso venga perso (l'altra estremità scade e riinvia l'ultimo FIN).

    L'esistenza di questa regola ha la conseguenza che il collegamento (indirizzo client, porta e indirizzo lato server, porta) su quell'indirizzo non può essere utilizzato durante questo tempo 2*MSL. Ad esempio, se chiudiamo un link dopo averlo creato e poi lo riavviiamo rapidamente, la porta non sarà disponibile.

    TIME_WAIT tempo è 2*MSL. Quindi puoi ridurre TIME_WAIT tempo regolando net.inet.tcp.msl. Per il server web, questo valore può essere regolato a 7500 o 2000 (accedi a un web, la pagina non può essere flashata per più di 4~15 secondi, puoi considerare di rinunciare -_-)

    Riferimento per impostazione dei parametri:

Su FreeBSD, yayu non vedeva un comando come "/sbin/sysctl -p" che potesse rendere efficace il contenuto di /etc/sysctl.conf, quindi usava semplicemente il comando: