iptables: differenza tra i pacchetti NUOVI, STABILITI e CORRELATI

Parte di un firewall su un server:

iptables -A INPUT -p tcp --dport 22 -m state NEW --state -m recent --set

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 100 --hitcount 10 -j DROP

Quando cerco online vedo sempre NUOVO usato in quella regola, ma faccio fatica a capire perché ESTABLISHED e RELATED non vengono utilizzati.

Come questo :

iptables -A INPUT -p tcp --dport 22 -m state NEW,ESTABLISHED,RELATED --state -m recent --set

iptables -A INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED,RELATED -m recent --update --seconds 100 --hitcount 10 -j DROP

Qualcuno può spiegarmi quando esattamente un NUOVO pacchetto cambia in STABILITO e CORRELATO?

firewall iptables packet

— Kris
fonte

Risposte:

Considerare un NUOVO pacchetto come una telefonata prima che il ricevitore abbia ricevuto. Un pacchetto STABILITO è il loro "Ciao". E un pacchetto CORRELATO sarebbe se stavi chiamando per parlargli di una e-mail che stavi per inviarli. (L'email è CORRELATA.)

Nel caso in cui la mia analogia non sia così eccezionale, penso personalmente che le pagine man la gestiscano bene:

NOVITÀ: significa che il pacchetto ha avviato una nuova connessione o altrimenti associato a una connessione che non ha visto i pacchetti in entrambe le direzioni e

STABILITO - significa che il pacchetto è associato a una connessione che ha visto i pacchetti in entrambe le direzioni,

CORRELATO - significa che il pacchetto sta avviando una nuova connessione, ma è associato a una connessione esistente, come un trasferimento di dati FTP o un errore ICMP.

iptables (8) - Pagina man di Linux

— Aaron Copley
fonte

Per curiosità, sai come determina i pacchetti CORRELATI? Esiste un meccanismo che le applicazioni possono utilizzare per segnalare a iptables che una connessione sarà una connessione correlata o fa parte puramente della parte stateful di iptables?

— Matthew Scharley,

È gestito da una serie di moduli del kernel chiamati ip_conntrack_ *, ciascuno scritto per un protocollo particolare che utilizza connessioni non correlate (come FTP). Per rispondere alla tua domanda, penso che dovresti caricare un modulo simile per la tua applicazione.

— Kyle Smith

Ok grazie. Ma tornando alla regola con NEW in esso, non è possibile che un pacchetto possa essere fatto sembrare STABILITO e quindi non bloccato dalla regola?

— Kris

@Kris: È abbastanza difficile falsificare i pacchetti in uscita, quindi dal testo della pagina man nella risposta, non vedo come. Hai ragione sul fatto che è possibile falsificare un pacchetto che sembra destinato a una connessione aperta, ma anche senza un firewall, lo stack TCP lascerebbe cadere il pacchetto sul pavimento se non fosse già a conoscenza di una connessione aperta dal mittente. Se questo è su un firewall su un router, è ancora possibile mantenere questo stato controllando i pacchetti SYN/ ACK/ RST/ etc mentre passano attraverso il router e mi aspetterei che iptables lo faccia.

— Matthew Scharley,

@Kris: qualcosa di simile a questo (anche se non tecnicamente identico) viene utilizzato dal software VNC come TeamViewer per eseguire il tunneling attraverso firewall / router. Il processo si chiama perforazione . In breve, si dispone di un PC host (che potrebbe essere protetto da un firewall limitato) a cui si desidera connettersi da un dispositivo diverso (tramite Internet). Entrambi i PC aprono una singola connessione a un server separato (ad es. Il TeamViewer Server), che "media" tra loro, in modo che i loro firewall sembrino collegati ai pacchetti, e quindi tali PC sono in grado di stabilire una connessione separata con ciascuno altro.

— Levita,

Assumendo sia per server che per client un approccio restrittivo INPUTe aperto OUTPUT, ovvero:

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT

E da iptables-extensions (8) sull'esempio di FTP in modalità attiva:

1. NOVITÀ

NOVITÀ Il pacchetto ha avviato una nuova connessione o comunque associato a una connessione che non ha visto i pacchetti in entrambe le direzioni.

Il client sulla porta 50000(qualsiasi porta casuale non privilegiata) si connette al server FTP sulla porta 21, il server avrebbe bisogno almeno di questo per accettare questa connessione in entrata:

iptables -A INPUT --dport 21 -m state --state NEW -j ACCEPT

2. STABILITO

STABILITO Il pacchetto è associato a una connessione che ha visto i pacchetti in entrambe le direzioni.

Ora sul lato client, ha aperto una connessione in uscita al server sulla porta 21utilizzando una porta locale 50000e ha bisogno dei seguenti iptables per permettere la risposta per arrivare da server (21)a client (50000):

sudo iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

3. CORRELATO

CORRELATO Il pacchetto sta avviando una nuova connessione, ma è associato a una connessione esistente, come un trasferimento di dati FTP o un errore ICMP.

Ora dopo che la connessione FTP è stata stabilita e sta per essere eseguita una connessione dati, il client aprirà un socket del server (sì, con il client FTP attivo diventa un server per la connessione dati) sulla porta 60000(per la mia comprensione il client contrassegnerà questa porta 60000per quanto RELATEDriguarda l'altra connessione da 50000->21) e invierà questo numero di porta al server usando il PORTcomando FTP . Quindi il server FTP aprirà una nuova connessione dalla sua porta 20alla porta 60000sul client e bene, ora il client richiede quanto segue per consentire a questa nuova connessione di riuscire:

sudo iptables -A INPUT -m state --state RELATED -j ACCEPT

Infine, affinché funzioni, è necessario abilitare il ip_conntrack_ftpmodulo del kernel per consentire al sistema di contrassegnare connessioni / pacchetti come RELATED(questa è la mia comprensione, non ho approfondito troppo):

modprobe ip_conntrack_ftp

— Jaime Hablutzel
fonte

stabilito richiede solo un flusso unidirezionale originariamente localizzato, non la stretta di mano a 3 vie tcp, la mia comprensione è corretta?

— sdaffa23fdsf,

Grazie per la risposta, per aver stabilito che hai detto "iptables per consentire la risposta dal server (21) al client (50000)" se è DA server a client perché è INPUT e non OUTPUT?

— Medya,

@Medya, perché dal punto di vista del client, i pacchetti inviati dal server (21) al client (50000) sono pacchetti in entrata, quindi per il client è un INPUT.

— Jaime Hablutzel,