È sicuro disabilitare il tracciamento della connessione in iptables?

Question

È sicuro disabilitare il tracciamento della connessione in iptables?

#1 da (13 voti)

12

Durante la lettura del NOTRACK target della tabella raw in iptables, ho riscontrato un articolo che suggeriva che per un determinato traffico potevi (o dovresti) disabilitare il tracciamento della connessione. I due esempi erano: (1) tutti i tipi di pacchetti indirizzati e (2) se si dispone di un server Web o di altri servizi che consumano risorse, è necessario disabilitare anche il tracciamento della connessione per tale servizio. Non ho un server web, ma ho alcuni client p2p. Le seguenti sono le regole standard per il tracciamento della connessione:

iptables -t filter -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -t filter -A INPUT -p udp -m conntrack --ctstate NEW -j udp
iptables -t filter -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j tcp

e nelle catene udp e tcp apro la porta per un client torrent usando:

iptables -t filter -A udp -p udp --dport 33333 -m conntrack --ctstate NEW -j ACCEPT
iptables -t filter -A tcp -p tcp --dport 33333 -m conntrack --ctstate NEW -j ACCEPT

Quando controllo le voci del conntrack:

# cat /proc/net/nf_conntrack | wc -l
3569

Ora l'opzione sarebbe di impostare NOTRACK in raw tabella per questo tipo di traffico, ad esempio:

iptables -t raw -A notrack_in -p udp --dport 33333 -j NOTRACK
iptables -t raw -A notrack_in -p udp --dport 33333 -j ACCEPT
iptables -t raw -A notrack_in -p tcp --dport 33333 -j NOTRACK
iptables -t raw -A notrack_in -p tcp --dport 33333 -j ACCEPT

e ha bisogno anche di due regole nella tabella dei filtri:

iptables -t filter -A INPUT -p udp --dport 33333 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 33333 -j ACCEPT

Dopo questa operazione, il numero di voci in /proc/net/nf_conntrack è sceso a 150-200 e non c'è nessuna riga con la porta 33333.

La mia domanda è questa: è sicuro disabilitare il tracciamento della connessione? Fare ciò richiede l'aggiunta di regole per iptables? Quali sono i pro e i contro di questa soluzione?

linux firewalls iptables

posta Mikhail Morfikov 13.07.2014 - 10:41

fonte

1 risposta

Leggi altre domande sui tag linux firewalls iptables

Rilevamento sandbox malware Il filtro Smart-Screen continua a lamentarsi, nonostante abbia firmato l'eseguibile, perché?

score 13 · Answer 1

La risposta breve

Di solito è necessario solo il tracciamento della connessione per le connessioni in uscita. Se qualsiasi dispositivo locale effettua una connessione a Internet, il firewall registra che questo specifico IP e porta hanno tentato di stabilire una connessione con l'altro IP e la porta.

Così, quando arriva la risposta da Internet, il firewall sa di lasciarlo passare, perché ha già visto un pacchetto in uscita. Se non è stato eseguito il tracciamento della connessione, è necessario inserire regole esplicite in base a dove o da dove può viaggiare un pacchetto (ad esempio, consentire tutti i pacchetti dalla porta 80 di google.com). È facile vedere che questo renderebbe le regole del firewall piuttosto complicate.

La risposta lunga

Esistono solo sottili differenze tra le due soluzioni se utilizzate per le connessioni in entrata. Una differenza è su quale sistema si verifica il carico della CPU dei pacchetti di controllo. Se hai un computer / router / firewall dedicato (chiamato firewall da qui in poi), facendo questo, con il tracciamento della connessione abilitato, questo dispositivo controllerà almeno la plausibilità di un pacchetto. Ciò libererà il server delle applicazioni (il server che riceve i pacchetti) dal farlo.

La plausibilità si riferisce al fatto che il pacchetto proviene dall'host atteso e dalla porta prevista nel caso di UDP, e inoltre dal numero di sequenza nel caso di TCP.

Solitamente la validazione può avvenire solo all'interno del livello dell'applicazione, poiché la validità può essere garantita solo in base al protocollo nell'applicazione stessa.

Ci sono tre conseguenze da questi presupposti:

Il carico della CPU e della rete viene spostato verso il "bordo" della rete nel caso di rilevamento dello stato. Ciò significa che il primo dispositivo (di solito) sulla rete eseguirà alcuni controlli di base del pacchetto, prima di inoltrarlo nella rete locale, mantenendo così la rete interna pulita e il carico sul firewall.
Il server delle applicazioni dovrà solo preoccuparsi se il pacchetto è valido, cioè se i dati all'interno del pacchetto sono conformi al protocollo previsto.
Ciò potrebbe aprire la possibilità di superare una connessione UDP, a seconda del protocollo. Se l'applicazione non ha (o non è affidabile) il modo di autenticare il mittente di un pacchetto, accetterà il carico utile corretto da qualsiasi indirizzo IP. Ad esempio in una trasmissione di dati sarebbe possibile inviare rifiuti al destinatario, se il pacchetto UDP supera la convalida.

Ciononostante la pratica comune (a meno che non sia in ambienti ad alta sicurezza) consiste nell'utilizzare il tracciamento della connessione (generale) solo per le connessioni in uscita, in modo da non dover consentire esplicitamente ad ogni server Internet di rispondere ad una richiesta dalla rete locale. Nel caso di connessioni in ingresso, in genere si consente solo di accedere alla porta (definita) (-A INPUT -p tcp -dip 80 -j ACCEPT). Ciò si applicherebbe alle nuove connessioni, ma si applicherebbe anche alle connessioni esistenti, evitando il sovraccarico, per tenere traccia della connessione. Analogamente, si inoltrano i pacchetti solo a una porta di destinazione specifica a un server delle applicazioni all'interno della rete locale.

tracciamento della connessione specifico per l'applicazione

C'è un caso che non ho menzionato ancora e questo è il tracciamento della connessione specifico per l'applicazione. Per alcuni protocolli (ftp, irc, tftp, amanda, sip e possibilmente altri, vedi link per esempio) potrebbero esserci speciali moduli iptables per consentire il tracciamento avanzato della connessione. Ad esempio in FTP, si aprirà una connessione dal client al server sulla porta 21, chiamata connessione di controllo, che dovrebbe essere aperta nel firewall con mezzi normali. All'interno di questo canale, il client e il server definiscono quindi una seconda connessione in cui verranno inviati i dati del file non elaborato. Di solito questa connessione viene stabilita dal server al client (in modalità ATTIVA). Questa porta locale e remota sono apparentemente casuali, quindi non possono essere definiti in un file di configurazione del firewall statico. Se ci fosse un firewall con iptables sulla rete del client, si negherebbe questa connessione, perché non esiste una precedente associazione. Con il tracciamento della connessione specifico per l'applicazione, il modulo guarderebbe "dentro" il contenuto del pacchetto per vedere se tale accordo è stato fatto e il firewall consentirebbe una nuova connessione in entrata sulla porta concordata, anche se prima non vi era alcuna connessione.