Iptables: "-p udp --state STTABLISHED"

diamo un'occhiata a queste due regole iptables che vengono spesso utilizzate per consentire il DNS in uscita:

iptables -A OUTPUT -p udp --sport 1024:65535 --dport 53 
   -m state --state NEW,ESTABLISHED -j ACCEPT

iptables -A INPUT -p udp --sport 53 --dport 1024:65535
   -m state --state ESTABLISHED -j ACCEPT

La mia domanda è: come devo comprendere esattamente lo stato di STABILIMENTO in UDP? UDP è apolide.

Ecco la mia intuizione: vorrei sapere se o dove questo non è corretto:

La pagina man mi dice questo:

stato

Questo modulo, se combinato con il tracciamento della connessione, consente l'accesso a
stato di tracciamento della connessione per questo pacchetto.

  --state ...

Quindi, iptables in sostanza ricorda il numero di porta utilizzato per il pacchetto in uscita (cos'altro potrebbe ricordare per un pacchetto UDP?) , E quindi consente il primo pacchetto in arrivo che viene rispedito in breve tempo? Un utente malintenzionato dovrebbe indovinare il numero di porta (sarebbe davvero troppo difficile?)

A proposito di evitare conflitti:

Il kernel tiene traccia delle porte bloccate (da altri servizi o dai precedenti pacchetti UDP in uscita), in modo che queste porte non vengano utilizzate per i nuovi pacchetti DNS in uscita entro il periodo di tempo? (Cosa succederebbe se provassi accidentalmente ad avviare un servizio su quella porta entro il lasso di tempo - quel tentativo sarebbe negato / bloccato?)

Si prega di trovare tutti gli errori nel testo sopra :-) Grazie,

Chris

— Chris Lercher
fonte

Risposte:

Quindi, iptables in sostanza ricorda il numero di porta utilizzato per il pacchetto in uscita (cos'altro potrebbe ricordare per un pacchetto UDP?),

Sono abbastanza sicuro per UDP che le porte e gli indirizzi di origine e destinazione sono memorizzati.

Se si desidera controllare le tabelle di stato, installare conntrack e / o netstat-nat.

(Cosa succederebbe se provassi accidentalmente ad avviare un servizio su quella porta entro il lasso di tempo - quel tentativo sarebbe negato / bloccato?)

Dal momento che stai usando OUTPUT e INPUT stai parlando di servizi locali. La porta è già utilizzata Non credo che il tuo sistema ti consentirà di avviare un altro servizio poiché qualcosa sta già ascoltando su quella porta. Immagino che potresti interrompere il primo servizio e avviarne un altro se davvero lo desideri, in tal caso la risposta probabilmente arriverebbe al tuo servizio. Ciò che il servizio fa con il pacchetto dipende dal contenuto del pacchetto e dal servizio.

— Zoredache
fonte

Quindi, se ho iniziato a dire un'istanza Tomcat sulla porta 8080, avrò una probabilità 1: (65535-1023) che l'avvio non riuscirà, se accidentalmente una query DNS è in esecuzione sulla stessa porta? O aspetterà solo che scada il tempo? Per quanto tempo è l'impostazione predefinita?

— Chris Lercher,

Su Linux credo che l'intervallo di porte effimere sia comunemente 32768-61000 (vedi / proc / sys / net / ipv4 / ip_local_port_range) questo non includerebbe la tua porta di esempio 8080. Tende ad essere molto raro configurare i servizi per l'ascolto sulle porte all'interno della gamma effimera. Il tempo in cui una voce UDP viene indicato nella tabella è in genere di 30 secondi (consultare / proc / sys / net / netfilter / nf_conntrack_udp_timeout)

— Zoredache

+1 Grazie, in particolare per i percorsi / proc!

— Chris Lercher,

Nel caso in cui qualcuno desideri estendere udp_timeout, usaecho "net.netfilter.nf_conntrack_udp_timeout = 180" >> /etc/sysctl.conf

— Kiran

NB: questa risposta è stata modificata.

Nonostante ciò che dicono le pagine man, ESTABLISHEDsembra significare "stateful". Per UDP ciò significa semplicemente (come suggerisci) ricordare ogni pacchetto UDP in uscita ("src ip, src port dst ip, tst port" tuple) per un po 'e riconoscerne le risposte.

FWIW, le mie normali regole per il traffico DNS sarebbero qualcosa del genere:

# permit any outbound DNS request (NB: TCP required too)
iptables -A OUTPUT -p udp --sport 1024:65535 --dport 53  -j ACCEPT
iptables -A OUTPUT -p tcp --sport 1024:65535 --dport 53  -j ACCEPT

# accept any packet that's a response to anything we sent
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

vale a dire controllare il traffico sulla OUTPUTcatena e quindi lasciare che i iptablesmoduli di stato gestiscano tutto il resto della INPUTcatena.

Vedi anche questa domanda correlata .

— Alnitak
fonte

Sono consapevole che dovrei consentire anche TCP. Ma cosa significherebbe RELATED per UDP? Manpage: "CORRELATO significa che il pacchetto sta avviando una nuova connessione, ma è associato a una connessione esistente, ..." Connessioni per UDP? Forse ha davvero più senso di STABILITO, ma è quello che mi piacerebbe scoprire.

— Chris Lercher,

Quando utilizzo le tue regole, ma limito udp INPUT a RELATED, le mie query DNS non funzionano. Sembra che devo consentire STABILITO. C'è qualche motivo per consentire anche RELATED (per UDP)?

— Chris Lercher,

ok, sembra che STABILITO significhi più di quanto dice la pagina man. In ogni caso, se usi filtri OUTPUT come il mio e non accetti traffico inbonud, quella regola INPUT è l'unica di cui avrai mai bisogno.

— Alnitak,

Dato quello che abbiamo trovato, i pacchetti udp CORRELATI non esistono AFAIK. Tuttavia (ad esempio) se si esegue mai FTP in uscita da quella casella, è necessaria una regola di stato CORRELATA per il canale dati. La singola regola "STABILITO, CORRELATO" è AFAIK la regola singola più ottimale per il traffico in entrata.

— Alnitak,

in realtà, potrebbero esistere RELATEDpacchetti UDP per RTP.

— Alnitak,

Gli sviluppatori di iptables hanno considerato che lo stato "STABILITO" era la situazione in cui i pacchetti venivano visti in entrambe le direzioni indipendentemente dal protocollo tra due client.

l'estensione di stato fa parte di conntrack. Il kernel comprende lo stato dalla tabella

/proc/net/nf_conntrack

Esempio di stati iptable per UDP nella tabella nf_conntrack dal punto di vista del mittente. Immaginiamo di inviare una query DNS su UDP

udp   17 20 src=192.168.1.2 dst=192.168.1.10 sport=35237 dport=53 \
 [UNREPLIED] src=192.168.1.10 dst=192.168.1.2 sport=53 \
 dport=35237 use=1

È stato inviato un pacchetto. Non ha replicato e oh, la tabella contiene i dati per ciò che è previsto in cambio (il pacchetto per la risposta DNS).

udp   17 20 src=192.168.1.2 dst=192.168.1.10 sport=35237 dport=53 \
  src=192.168.1.10 dst=192.168.1.2 sport=53 \
 dport=35237 use=1

La risposta è arrivata, il flag non replicato è sparito, significa che questa connessione UDP è nello stato STABILITO per un breve periodo di tempo definito nel sistema.

— Nicolas Guérinet
fonte