netfilter / iptables: perché non usare la tabella non elaborata?

Sotto Linux, di solito usiamo la tabella "filter" per fare un filtro comune:

iptables --table filter --append INPUT --source 1.2.3.4 --jump DROP
iptables --table filter --append INPUT --in-interface lo --jump ACCEPT

Secondo il seguente diagramma di flusso netfilter, i pacchetti viaggiano prima attraverso la tabella "grezza":

Quindi possiamo scrivere:

iptables --table raw --append PREROUTING --source 1.2.3.4 --jump DROP
iptables --table raw --append PREROUTING --in-interface lo --jump ACCEPT

i pacchetti vengono gestiti prima, senza la necessità di utilizzare conntrack + mangle + nat + routing. CPU / memoria quindi leggermente meno utilizzate (e, a sua volta, leggermente compensate dal fatto che il modulo iptable_raw deve essere caricato)
una sola regola nel caso in cui la scatola sia anche un router (ovviamente non andrà bene per tutte le regole) perché non è necessario aggiungere la stessa regola per filtro / inoltro

Ho fatto solo test rapidi e questo funziona perfettamente.
Le documentazioni che ho trovato descrivono sempre la tabella non elaborata da utilizzare in casi severi. Ma nessuno fornisce la minima giustificazione.

Domanda: c'è qualche motivo per non usare la tabella grezza, a parte quelle dogmatiche?

linux iptables

— Gregory MOUSSAT
fonte

Se si desidera semplicemente eliminare tutto il traffico proveniente da determinati indirizzi IP, la tabella non elaborata va bene. Tuttavia il firewalling è spesso un po 'più preciso di così, quindi finiresti con alcune regole in raw e alcune regole in filter. Questo rende la manutenzione un mal di testa, e semplificando questo vale un paio di cicli della CPU.

— wurtel,

Se è solo un problema di mal di testa, penso che dovremmo trovare alcuni esempi che parlano della tabella grezza. Poiché questo non è il caso, la teoria del mal di testa non è probabilmente il fattore principale.

— Gregory MOUSSAT,

L'autore di ipset consiglia di utilizzare la tabella non elaborata per le regole di iptables ipset ipset.netfilter.org/tips.html

— Stuart Cardall

Da man iptables :

raw: This table is used mainly for configuring exemptions from connection
     tracking in combination with the NOTRACK target. It registers at the
     netfilter hooks with higher priority and is thus called before
     ip_conntrack, or any other IP tables.
     It  provides the following built-in chains:

     - PREROUTING (for packets arriving via any network interface)
     - OUTPUT (for packets generated by local processes)

Analisi :

Quindi, la tabella RAW è prima di conntrack ed è stata progettata con l'obiettivo di essere utilizzata per impostare il segno NOTRACK sui pacchetti che non si desidera tracciare in netfilter.

Le destinazioni -j non si limitano solo a NOTRACK, quindi sì, è possibile filtrare i pacchetti nella tabella non elaborata con i vantaggi di un minore consumo di CPU / memoria.

Molto spesso, i server non devono tenere traccia di tutte le connessioni. È necessario tracciare solo se è necessario filtrare i pacchetti in iptables in base alle connessioni stabilite in precedenza. Sui server che hanno solo uno scopo semplice come con solo la porta 80 (e forse 21) aperta, non è necessario. In questi casi, è possibile disabilitare il tracciamento della connessione.

Tuttavia, se stai cercando di eseguire un router NAT, le cose si complicano leggermente. Per NAT qualcosa, è necessario tenere traccia di tali connessioni in modo da poter consegnare i pacchetti dalla rete esterna alla rete interna.

Se viene impostata un'intera connessione con NOTRACK, non sarà possibile tenere traccia delle connessioni correlate, conntrack e nat helpers non funzioneranno semplicemente per le connessioni non tracciate, né lo faranno gli errori ICMP correlati. Dovrai aprirli manualmente in altre parole. Quando si tratta di protocolli complessi come FTP e SCTP e altri, questo può essere molto difficile da gestire.

Casi d'uso :

Un esempio potrebbe essere se si dispone di un router pesantemente trafficato su cui si desidera bloccare il traffico in entrata e in uscita, ma non il traffico instradato. Quindi, è possibile impostare il segno NOTRACK per ignorare il traffico inoltrato per risparmiare energia di elaborazione.

Un altro esempio in cui NOTRACK può essere utilizzato è se si dispone di un server Web altamente trafficato, quindi è possibile impostare una regola che trasforma il rilevamento della porta 80 su tutti gli indirizzi IP di proprietà locale o quelli che servono effettivamente il traffico web. È quindi possibile usufruire del monitoraggio con stato su tutti gli altri servizi, ad eccezione del traffico Web che potrebbe risparmiare un po 'di potenza di elaborazione su un sistema già sovraccarico.

Esempio -> running-a-semi-stateless-linux-router-for-private-network

Conclusione : non esiste un motivo valido per non utilizzare la tabella non elaborata, ma è necessario fare attenzione quando si utilizza il target NOTRACK nella tabella non elaborata.

— Facundo Victor
fonte