it-swarm-eu.dev

nf_conntrack: tabella piena, pacchetto di rilascio

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 satura. Mi chiedo qual è il significato del messaggio e come contrastare le possibili implicazioni sulla sicurezza.

21
hnn

Il messaggio indica che la tabella di tracciamento della connessione è piena. Non ci sono implicazioni di sicurezza diverse da DoS. È possibile mitigarlo parzialmente aumentando il numero massimo di connessioni da tracciare, riducendo i timeout di tracciamento o disabilitando del tutto il tracciamento delle connessioni, il che è fattibile sul server, ma non su un router NAT, poiché quest'ultima 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>
21
Matrix

Ecco un ottimo articolo che tratta l'argomento. In sostanza significa solo che la tabella utilizzata dalle tabelle IP (tramite APF o qualsiasi altra soluzione) per archiviare connessioni persistenti è piena. A scapito della memoria è possibile aumentarlo.

http://pc-freak.net/blog/resolving-nf_conntrack-table-full-dropping-packet-flood-message-in-dmesg-linux-kernel-log/

5

Suggerirei inoltre di impostare le regole del firewall in modo da rifiutare anziché eliminare

Un temporaneo, risolve se è necessario mantenere iptables NAT sono:

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

Dico temporaneo, perché aumentare il nf_conntrack_max Non garantisce, le cose andranno bene da ora in poi. Tuttavia, su molti server non così pesantemente caricati sul traffico, è sufficiente aumentare net.netfilter.nf_conntrack_max=131072 A un valore abbastanza alto per risolvere il problema.

- Aumentare la dimensione della tabella hash di nf_conntrack

Il valore hashsize della tabella Hash, che memorizza gli elenchi delle voci conntrack dovrebbe essere aumentato in modo corretto, ogni volta che viene sollevato net.netfilter.nf_conntrack_max.

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

La regola per calcolare il giusto valore da impostare è:

hashsize = nf_conntrack_max / 4

- Per memorizzare permanentemente le modifiche apportate; a) mettere 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 dell'uscita 0):

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

Nota: fai attenzione a questa variabile, secondo la mia esperienza aumentandola a un valore troppo alto (specialmente sui kernel con patch XEN) potrebbe congelare il sistema. Anche aumentare il valore a un numero troppo alto può bloccare un normale server Linux in esecuzione su hardware vecchio.

- Per la diagnosi di nf_conntrack C'è;

/proc/sys/net/netfilter Directory memorizzata nella memoria del kernel. Qui puoi trovare alcuni valori memorizzati dinamicamente che forniscono informazioni riguardanti le operazioni nf_conntrack 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 nf_conntrack NAT valori di timeout per impedire il server contro gli attacchi DoS

In genere, i valori predefiniti per i timeout nf_conntrack_* Sono (non necessari) di grandi dimensioni.

Pertanto, per grandi flussi di traffico anche se si aumenta nf_conntrack_max, Tuttavia è possibile ottenere una tabella di overflow nf_conntrack Con conseguente caduta delle connessioni al server. Per evitare che ciò accada, controllare e ridurre gli altri valori di tracciamento 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. net.netfilter.nf_conntrack_generic_timeout Come vedi è abbastanza alto - 600 secondi = (10 minuti). Questo tipo di valore significa che qualsiasi connessione NAT non risponde può rimanere in sospeso per 10 minuti!

Anche il valore net.netfilter.nf_conntrack_tcp_timeout_established = 432000 È piuttosto alto (5 giorni!) Se questi valori, non vengono abbassati, il server sarà un obiettivo facile per chiunque desideri inondarlo con connessioni eccessive, una volta che ciò accade il server sarà veloce raggiungere anche il valore sollevato per net.nf_conntrack_max e la caduta iniziale della connessione si ripeterà di nuovo ...

Detto questo, per impedire al server di utenti malintenzionati, situato dietro il NAT ti affligge con attacchi Denial of Service:

Abbassa net.ipv4.netfilter.ip_conntrack_generic_timeout A 60 - 120 secondi e net.ipv4.netfilter.ip_conntrack_tcp_timeout_established 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 regolari NAT. Dopo aver modificato i valori e monitorato per almeno alcuni giorni, rendere permanenti le modifiche aggiungendole a /etc/sysctl.conf

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 su http://pc-freak.net/blog/resolving-nf_conntrack-table-full-dropping-packet-flood-message-in-dmesg-linux-kernel-log/ =

4
Sandri_Nenes