"Possibile inondazione di SYN" nel registro nonostante il numero basso di connessioni SYN_RECV

Recentemente abbiamo avuto un server apache che rispondeva molto lentamente a causa delle inondazioni di SYN. La soluzione per questo è stata quella di abilitare tcp_syncookies ( net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf ).

Ho inviato una domanda su questo qui se vuoi più background.

  • Il server Windows chiude la connessione TCP immediatamente dopo l'invio di SYN + ACK
  • Cosa significa Upstream e Downstream?
  • richiedere la password sudo per comandi specifici
  • Come utilizzare iptables o tc per limitare i pacchetti per client.
  • Linux per controllare i record TXT di un dominio
  • Inserisce automaticamente l'indirizzo IP se accede a un determinato URL
  • Dopo aver abilitato le sincookie abbiamo iniziato a vedere il seguente messaggio in / var / log / messages circa each 60 secondi:

    [84440.731929] possible SYN flooding on port 80. Sending cookies.

    Vinko Vrsalovic mi ha informato che questo significa che il numero di ordini di sin è in pieno, quindi ho sollevato tcp_max_syn_backlog a 4096. A un certo punto ho anche abbassato tcp_synack_retries a 3 (giù dal default di 5) emettendo sysctl -w net.ipv4.tcp_synack_retries=3 . Dopo averlo fatto, la frequenza sembrava scendere, con l'intervallo dei messaggi che variano tra circa 60 e 180 secondi.

    Avanti ho emesso sysctl -w net.ipv4.tcp_max_syn_backlog=65536 , ma sto ancora ricevendo il messaggio nel registro.

    Nel complesso ho osservato il numero di connessioni in SYN_RECV state (eseguendo l' watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l' ) e non supera mai più di 240, molto molto inferiore alle size del backlog. Eppure ho un server Red Hat che si aggira intorno al 512 (il limite su questo server è il default di 1024).

    Ci sono altre impostazioni di tcp che limiterebbero la dimensione del backlog o sto abbaiando l'tree sbagliato? Se il numero di connessioni SYN_RECV in netstat -tuna corrisponda alle size del backlog?


    Aggiornare

    Come meglio posso dire che ho a che fare con collegamenti legittimi qui, netstat -tuna|wc -l aggira intorno ai 5000. Ho scoperto questo oggi e ho trovato questo post da un dipendente last.fm, che è stato piuttosto utile.

    Ho anche scoperto che il tcp_max_syn_backlog non ha alcun effetto quando le sincookie sono abilitate (come per questo collegamento )

    Così come un passo successivo ho impostato quanto segue in sysctl.conf:

     net.ipv4.tcp_syn_retries = 3 # default=5 net.ipv4.tcp_synack_retries = 3 # default=5 net.ipv4.tcp_max_syn_backlog = 65536 # default=1024 net.core.wmem_max = 8388608 # default=124928 net.core.rmem_max = 8388608 # default=131071 net.core.somaxconn = 512 # default = 128 net.core.optmem_max = 81920 # default = 20480 

    Ho quindi impostato il mio tempo di risposta, ho eseguito sysctl -p e le sincookie distriggerste da sysctl -w net.ipv4.tcp_syncookies=0 .

    Dopo aver fatto questo il numero di connessioni nello stato SYN_RECV rimane ancora intorno a 220-250, ma le connessioni hanno iniziato a ritardare di nuovo. Una volta notato questi ritardi, riattivo le sincookie ei ritardi si fermarono.

    Credo che quello che vedevo era ancora un miglioramento dallo stato iniziale, tuttavia alcune richieste erano ancora ritardate, che è molto peggio di avere abilitato le sincookie. Quindi sembra che sono bloccato con loro abilitato fino a quando non possiamo get altri server in linea per far fronte al carico. Anche allora, non sono sicuro che vedo una ragione valida per distriggersrli nuovamente mentre vengono inviati (apparentemente) quando i buffer del server vengono pieni.

    Ma il backlog di syn non sembra essere pieno con solo ~ 250 connessioni nello stato SYN_RECV! È ansible che il messaggio di inondazione di SYN sia un aringa rossa ed è diverso da quello di syn_backlog che si riempie?

    Se qualcuno ha altre opzioni di tuning non ho ancora provato, sarei più che felice di provarli, ma sto cominciando a chiedermi se l'impostazione syn_backlog non viene applicata correttamente per qualche motivo.

  • La tariffa di ampiezza di banda Amazon EC2 in caso di traffico in ingresso non desiderato (ddos / flood)?
  • Come proteggere Lighttpd da attacchi DOS e da inondazioni?
  • each minuto - eventuale inondazione SYN sulla port 80
  • Trovare traffico insolito google
  • 3 Solutions collect form web for “"Possibile inondazione di SYN" nel registro nonostante il numero basso di connessioni SYN_RECV”

    Quindi, questa è una domanda ordinata.

    Inizialmente ero sorpreso di aver visto collegamenti in stato SYN_RECV con i cookie SYN abilitati. La bellezza dei cookie SYN è che puoi partecipare senza precedenza alla stretta di mano TCP a tre mani come server che usa la crittografia, quindi mi aspetto che il server non rappresenti affatto le connessioni semestrali, perché sarebbe lo stesso stato che è non essere tenuto.

    Infatti, una rapida occhiata all'origine (tcp_ipv4.c) mostra interessanti informazioni su come il kernel implementa i cookie SYN. In sostanza, nonostante lo si accenda, il kernel si comport normalmente finché la sua coda di collegamenti in sospeso non è piena. Questo spiega l'elenco esistente di connessioni in stato SYN_RECV.

    Solo quando la coda delle connessioni in sospeso è piena e viene ricevuto un altro pacchetto SYN (tentativo di connessione) E è passato più di un minuto dall'ultimo messaggio di avviso, il kernel invia il messaggio di avviso visualizzato ("invio di cookie" ). I cookie SYN vengono inviati anche quando il messaggio di avviso non è; il messaggio di avvertimento è solo per farti capire che il problema non è andato via.

    Mettere un altro modo, se spegni i cookie SYN, il messaggio andrà via. Questo è solo che functionrà per te se non sei più SYN inondato.

    Per affrontare alcune delle altre cose che hai fatto:

    • net.ipv4.tcp_synack_retries :
      • Aumento di questo non avrà alcun effetto positivo per le connessioni in entrata che sono spoofed, né per coloro che ricevono un cookie SYN anziché lo stato lato server (nessuna tentazione per loro).
      • Per le connessioni spoofed in arrivo, aumentando questo aumenta il numero di pacchetti inviati a un indirizzo falso e forse la quantità di tempo che l'indirizzo spoofed rimane nella tabella di connessione (questo potrebbe essere un effetto negativo significativo).
      • In un carico normale / numero di connessioni in entrata, più alto è questo, più è probabile che tu sia in grado di completare rapidamente / con successo le connessioni sui collegamenti che eliminano i pacchetti. Ci sono diminuzioni di rendimento per aumentare questo.
    • net.ipv4.tcp_syn_retries : cambiare questo non può avere alcun effetto sulle connessioni in entrata (riguarda solo le connessioni in output)

    Le altre variables che hai citato non sono ancora state studiate, ma sospetto che le risposte alla tua domanda siano praticamente qui.

    Se non si è inondati SYN e la macchina è sensibile alle connessioni non HTTP (ad es. SSH), credo che probabilmente è un problema di networking e si dovrebbe avere un tecnico di networking che ti aiuti a guardarlo. Se la macchina non risponde generalmente anche quando non si è inondati SYN, sembra un problema di carico grave se influisce sulla creazione di connessioni TCP (abbastanza basso livello e risorse non intensive)

    Ho affrontato esattamente lo stesso problema su una nuova installazione di Ubuntu Oneiric 11.10 in esecuzione di un server web (apache2) con un sito pesante caricato. Per impostazione predefinita, sono state triggerste le sincookie di Ubuntu Oneiric 11.10.

    Ho avuto gli stessi messaggi del kernel che indicano un ansible attacco SYN di inondazione sulla port del server web:

    kernel: [739408.882650] TCP: Possibile inondazione SYN sulla port 80. Invio di cookie.

    Allo stesso tempo, ero abbastanza sicuro, che non c'era attacco che accadesse. Ho riportto questo messaggio a 5 minuti. Ciò sembrava proprio come un carico di peek, perché un attaccante continuerebbe a mantenere il carico sempre più lungo mentre cercava di arrestare il server a rispondere alle richieste.

    La sintonia del parametro net.ipv4.tcp_max_syn_backlog non ha portto ad alcun miglioramento – i messaggi continuavano allo stesso ritmo. il fatto che il numero di connessioni SYN_RECV fosse sempre molto basso (nel mio caso inferiore a 250) era un indicatore, che deve esserci un altro parametro, responsabile di questo messaggio.

    Ho trovato questo messaggio di errore https://bugzilla.redhat.com/show_bug.cgi?id=734991 sul sito del cappello rosso affermando che il messaggio del kernel potrebbe essere dovuto a un bug (o una configuration errata) sul lato dell'applicazione . Naturalmente il messaggio di log è molto fuorviante! Poiché questo non è il parametro del kernel che è responsabile in quel caso, ma il parametro della tua applicazione, passando al kernel.

    Quindi dobbiamo anche dare un'occhiata ai parametri di configuration della nostra applicazione webserver. Apri i documenti doc e vai a http://httpd.apache.org/docs/2.0/mod/mpm_common.html#listenbacklog

    Il valore predefinito del parametro ListenBacklog è 511. (Questo corrisponde al numero di connessioni che hai osservato sul server del cappello rosso. Il tuo altro server potrebbe avere un numero inferiore configurato.)

    Apache dispone di un proprio parametro di configuration per la coda di backlog per le connessioni in arrivo. se hai un sacco di connessioni in arrivo e in qualsiasi momento (come una cosa random) arrivano tutti insieme quasi nello stesso momento, in modo tale che il webserver non sia in grado di servirli abbastanza velocemente in modo appropriato, il tuo backlog essere pieno con 511 connessioni e il kernel lancerà il messaggio di cui sopra, indicando un eventuale attacco di alluvioni SYN.

    Per risolvere questo problema, aggiungo la seguente row a /etc/apache2/ports.conf o uno degli altri file concon, che verrà caricato da apache ( /etc/apache2/apache2.conf dovrebbe essere anche ok):

    ListenBackLog 5000

    è inoltre necessario impostare il net.ipv4.tcp_max_syn_backlog su un valore ragionevole. nella mia comprensione, il massimo del kernel limiterà il valore, che sarà ansible configurare nella configuration apache. così correre:

     sudo sysctl -w net.ipv4.tcp_max_syn_backlog=5000 

    Dopo aver sintonizzato la configuration, non dimenticare di riavviare il tuo apache:

     sudo service apache2 restart ( or sudo /etc/init.d/apache2 restart ) 

    Nel mio caso, questa configuration cambierà immediatamente gli avvertimenti del kernel. Sono in grado di riprodurre i messaggi impostando un basso valore ListenBackLog nella configuration apache.

    Dopo alcuni test con il kernel 3.4.9, dipende il numero di connessioni SYN_RECV in netstat

    • /proc/sys/net/core/somaxconn arrotondato al potere successivo di 2 (ad es. 128 -> 256)
    • 75% di /proc/sys/net/ipv4/tcp_max_syn_backlog se /proc/sys/net/ipv4/tcp_syncookies è impostato su 0 o 100% se /proc/sys/net/ipv4/tcp_syncookies è impostato su 1
    • ListenBackLog nella configuration apache arrotondata alla potenza successiva di 2 (ad es. 128 -> 256)

    viene utilizzato il minimo di ciascuno di questi parametri. Dopo aver cambiato somaxconn o ListenBackLog apache deve essere riavviato.

    E dopo aver aumentato tcp_max_syn_backlog apache deve anche essere riavviato.

    Senza tcp_syncookies apache sta bloccando, perché in questo caso solo il 75% di tcp_max_syn_backlog è il limite è strano. e aumentando questa parametro aumenta le connessioni SYN_RECV al 100% del valore precedente senza riavviare apache.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.