nf_conntrack: tabella piena, eliminazione del pacchetto

16

Vedo molti di questi messaggi in / var / log / messages del mio server Linux

kernel: nf_conntrack: table full, dropping packet.
kernel: __ratelimit: 15812 callbacks suppresse

mentre il mio server è sotto attacco DoS ma la memoria non è ancora saturata. Mi chiedo quale sia il significato del messaggio e come contrastare possibili implicazioni sulla sicurezza.

    
posta hnn 02.10.2013 - 07:44
fonte

3 risposte

19

Il messaggio indica che la tabella di tracciamento della connessione è piena. Non ci sono implicazioni sulla sicurezza oltre al DoS. È possibile attenuarlo parzialmente aumentando il numero massimo di connessioni tracciate, riducendo i timeout di tracciamento o disattivando del tutto il tracciamento della connessione, che è possibile sul server, ma non su un router NAT, perché quest'ultimo cesserà di funzionare.

sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=54000
sysctl -w net.netfilter.nf_conntrack_generic_timeout=120
sysctl -w net.ipv4.netfilter.ip_conntrack_max=<more than currently set>
    
risposta data 02.10.2013 - 10:13
fonte
5

Ecco un grande articolo che tratta dell'argomento. In sostanza significa semplicemente che la tabella utilizzata dalle tabelle IP (tramite APF o qualsiasi altra soluzione) per memorizzare le connessioni persistenti è piena. A scapito della memoria puoi aumentarlo.

link

    
risposta data 03.10.2013 - 01:19
fonte
3

Suggerirei anche di impostare le regole del firewall in modo che rifiutino anziché rilasciare

Una soluzione temporanea, risolta se è necessario mantenere le regole NAT di iptables:

 linux:~# sysctl -w net.netfilter.nf_conntrack_max=131072

Dico temporaneamente, perché alzare il nf_conntrack_max non garantisce, le cose andranno bene d'ora in poi. Tuttavia su molti server con traffico non molto carico basta aumentare il valore di net.netfilter.nf_conntrack_max=131072 ad un valore sufficientemente alto per risolvere il problema.

- Aumentare la dimensione della tabella hash nf_conntrack

Il valore hash della tabella hash, che memorizza gli elenchi delle voci conntrack, dovrebbe essere aumentato in modo proporzionale, ogni volta che net.netfilter.nf_conntrack_max viene generato.

linux:~# echo 32768 > /sys/module/nf_conntrack/parameters/hashsize

La regola per calcolare il valore corretto da impostare è:

hashsize = nf_conntrack_max / 4

- Per memorizzare in modo permanente le modifiche apportate; a) inserisci in /etc/sysctl.conf:

linux:~# echo 'net.netfilter.nf_conntrack_count = 131072' >> /etc/sysctl.conf
linux:~# /sbin/sysct -p

b) inserisci /etc/rc.local (prima della riga 0 di uscita):

echo 32768 > /sys/module/nf_conntrack/parameters/hashsize

Nota: fare attenzione a questa variabile, in base alla mia esperienza, portandola a un valore troppo alto (specialmente sui kernel con patch XEN) potrebbe bloccare il sistema. Anche l'aumento del valore su un numero troppo elevato può bloccare un normale server Linux in esecuzione su hardware vecchio.

- Per la diagnosi di% ro_de% roba ci sono;

nf_conntrack directory memorizzata nella memoria del kernel. Qui puoi trovare alcuni valori memorizzati dinamicamente che forniscono informazioni riguardanti /proc/sys/net/netfilter operazioni in "tempo reale":

linux:~# cd /proc/sys/net/netfilter linux:/proc/sys/net/netfilter# ls
-al nf_log/ total 0 dr-xr-xr-x 0 root root 0 Mar 23 23:02 ./ dr-xr-xr-x 0 root root 0 Mar 23 23:02 ../
-rw-r--r-- 1 root root 0 Mar 23 23:02 0
-rw-r--r-- 1 root root 0 Mar 23 23:02 1
-rw-r--r-- 1 root root 0 Mar 23 23:02 10
-rw-r--r-- 1 root root 0 Mar 23 23:02 11
-rw-r--r-- 1 root root 0 Mar 23 23:02 12
-rw-r--r-- 1 root root 0 Mar 23 23:02 2
-rw-r--r-- 1 root root 0 Mar 23 23:02 3
-rw-r--r-- 1 root root 0 Mar 23 23:02 4
-rw-r--r-- 1 root root 0 Mar 23 23:02 5
-rw-r--r-- 1 root root 0 Mar 23 23:02 6
-rw-r--r-- 1 root root 0 Mar 23 23:02 7
-rw-r--r-- 1 root root 0 Mar 23 23:02 8
-rw-r--r-- 1 root root 0 Mar 23 23:02 9

IV. Riduzione di altri valori di timeout NAT nf_conntrack per impedire il server contro gli attacchi DoS

Generalmente, il valore predefinito per nf_conntrack timeout è (inutilmente) grande.

Pertanto, per grandi flussi di traffico anche se aumenti nf_conntrack_* , ancora shorty puoi ottenere una tabella di overflow nf_conntrack_max con conseguente caduta di connessioni al server. Per evitare che ciò accada, controlla e diminuisci gli altri valori di monitoraggio della connessione di timeout nf_conntrack :

linux:~# sysctl -a | grep conntrack | grep timeout 
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120 
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_events_retry_timeout = 15
net.ipv4.netfilter.ip_conntrack_generic_timeout = 600
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent2 = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10
net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300
net.ipv4.netfilter.ip_conntrack_udp_timeout = 30
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180
net.ipv4.netfilter.ip_conntrack_icmp_timeout = 30

Tutti i timeout sono in secondi. nf_conntrack come vedi è piuttosto alto - 600 secondi = (10 minuti). Questo tipo di valore indica che qualsiasi connessione NAT-ted che non risponde può rimanere sospesa per 10 minuti!

Anche il valore net.netfilter.nf_conntrack_generic_timeout è abbastanza alto (5 giorni!) Se questi valori non vengono abbassati, il server sarà un facile bersaglio per chiunque desideri riempirlo di connessioni eccessive, una volta che questo accadrà il server raggiungerà rapidamente anche il valore rialzato per net.netfilter.nf_conntrack_tcp_timeout_established = 432000 e la connessione iniziale verrà rimossa -Comincia di nuovo ...

Con tutto ciò detto, per impedire al server di utenti malintenzionati, situato dietro il NAT che ti affligge con attacchi Denial of Service:

Riduci net.nf_conntrack_max a 60 - 120 secondi e net.ipv4.netfilter.ip_conntrack_generic_timeout a qualcosa come 54000

linux:~# sysctl -w net.ipv4.netfilter.ip_conntrack_generic_timeout = 120
linux:~# sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 54000

Questo timeout dovrebbe funzionare correttamente sul router senza creare interruzioni per gli utenti NAT regolari. Dopo aver modificato i valori e il monitoraggio per almeno alcuni giorni, rendere permanenti le modifiche aggiungendole a net.ipv4.netfilter.ip_conntrack_tcp_timeout_established

linux:~# echo 'net.ipv4.netfilter.ip_conntrack_generic_timeout = 120' >> /etc/sysctl.conf 
linux:~# echo 'net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 54000' >> /etc/sysctl.conf

secondo il fantastico articolo di link

    
risposta data 04.04.2016 - 11:56
fonte

Leggi altre domande sui tag