Accettare RELATED, STTABLISHED per tutte le fonti in iptables è considerato "troppo aperto"?

9

Ho visto spesso -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTapplicare la regola . Anche se non sono un esperto, quella particolare linea mi riguarda. È abbastanza ovvio che la regola consente tutto il traffico con la sola eccezione che la connessione deve essere stata stabilita o correlata a una connessione stabilita.

Scenario

Consentirò le connessioni alla porta SSH predefinita 22dalla LAN dei server nella sottorete 192.168.0.0/16o altro.
SuperInsecureApp®espone qualcosa sulla porta 1337, che aggiungo alla mia INPUTcatena.
Ho aggiunto la conntrackregola per accettare ESTABLISHEDe RELATEDda tutte le fonti
La politica a catena è DROP

Quindi in pratica quella configurazione dovrebbe consentire connessioni SSH solo dalla LAN, consentendo nel contempo il traffico in entrata sulla porta 1337 dal mondo.

È qui che fiorisce la mia confusione. Esporrebbe conntrackin qualche modo un difetto di sicurezza che consentirebbe di ottenere una connessione stabilita sul 1337 (dal momento che è aperto al mondo), e quindi utilizzerebbe quella connessione per ottenere l'accesso alla porta SSH (o qualsiasi altra porta per quella materia)?

security iptables ip tcp

— Dencker
fonte

8

Non considererei il traffico STABILITO e CORRELATO troppo aperto. Potresti essere in grado di omettere RELATED, ma dovresti assolutamente consentire STABILITO. Entrambe queste categorie di traffico utilizzano stati conntrack.

Le connessioni STABILITE sono già state convalidate da un'altra regola. Questo rende molto più semplice implementare regole unidirezionali. Ciò consente solo di continuare le transazioni sulla stessa porta.

Anche le connessioni CORRELATE sono convalidate da un'altra regola. Non si applicano a molti protocolli. Ancora una volta rendono molto più semplice configurare le regole. Assicurano inoltre il corretto sequenziamento delle connessioni laddove si applicano. Questo in realtà rende le tue regole più sicure. Sebbene ciò possa consentire la connessione su una porta diversa, tale porta dovrebbe essere parte di un processo correlato come una connessione dati FTP. Le porte consentite sono controllate da moduli conntrack specifici del protocollo.

Consentendo connessioni STABILITE e CORRELATE, puoi concentrarti su quali nuove connessioni desideri che il firewall accetti. Evita inoltre regole infrante intese a consentire il traffico di ritorno, ma che consentono nuove connessioni.

Dato che hai classificato il programma sulla porta 1337 come non sicuro, dovrebbe essere avviato utilizzando un ID utente non root dedicato. Ciò limiterà il danno che qualcuno può fare se riesce a decifrare l'applicazione e ottenere un accesso migliore.

È altamente improbabile che una connessione sulla porta 1337 possa essere utilizzata per accedere alla porta 22 in remoto, ma è possibile che una connessione alla porta 1337 possa essere utilizzata per eseguire il proxy di una connessione alla porta 22.

Si consiglia di assicurarsi che SSH sia protetto in modo approfondito:

Utilizzare hosts.allow per limitare l'accesso oltre alle restrizioni del firewall.
Impedisci l'accesso alla radice, o almeno richiedi l'uso di chiavi e limitane l'accesso nel file authorized_keys.
Verifica degli accessi non riusciti. Uno scanner per registri può inviarti rapporti periodici su attività insolite.
Considerare l'utilizzo di uno strumento come fail2ban per bloccare automaticamente l'accesso in caso di ripetuti errori di accesso.

— BillThor
fonte

Anche se questo è stato un esempio arbitrario, la prima cosa che faccio sui nuovi server è sempre disabilitare l'accesso root e l'autenticazione in chiaro in sshd - questo è un ottimo consiglio. Inoltre fail2ban è in realtà già installato sul setup della vita reale da cui è stato ispirato l'esempio. "Le connessioni STABILITE sono già state convalidate da un'altra regola" era la cosa esatta di cui non ero sicuro e rispondeva perfettamente alla mia domanda. Grazie per la tua risposta molto chiara!

— Dencker,

Domanda a margine: dal punto di vista delle prestazioni, cambia qualcosa se la conntrackregola è all'inizio o alla fine della catena? Da quanto ho capito iptables, avrebbe dovuto elaborare tutte le regole sulle connessioni stabilite se fosse alla fine, e solo quella singola regola se fosse stata inserita all'inizio?

— Dencker,

@Dencker Volete prima la regola STABILITA, CORRELATA. Accetterà di gran lunga la maggior parte del traffico. Oltre a ciò potresti voler avere le regole che accettano la maggior parte del traffico, anche se è meglio pesare pesantemente sulla leggibilità. Le mie regole sono raggruppate, sensibili alla latenza, traffico elevato (raggruppate per tipo), altre. Iptables ha dei contatori che ti permettono di vedere quanto traffico procede ogni regola. Uso Shorewall, che aggiunge alcune utili impostazioni predefinite e ha un file di regole di facile lettura per costruire i miei firewall.

— BillThor,

2

STABILITO e CORRELATO sono caratteristiche del filtro pacchetti "stateful", in cui il filtro non dipende solo da una serie di regole statiche ma anche dal contesto, all'interno del quale vengono considerati i pacchetti. È necessario ESTABLISHED per consentire il funzionamento delle connessioni ed è necessario RELATED per i messaggi ICMP rilevanti. Il filtro stateful consente di filtrare in modo più preciso rispetto alle regole stateless "stateless".

Diamo un'occhiata prima a STABILITO. Ad esempio, considerare TCP sulla porta 22. L'iniziatore (client) invia un SYNa serverIPaddr:22. Il server ritorna SYN+ACKal client. Ora è il turno del cliente di inviare un ACK. Come dovrebbe apparire la regola di filtro sul server, in modo tale che ACKsia accettata solo la "corrispondenza" ? Una regola generale apolide sarebbe simile

-A INPUT --proto tcp --port 22 -j ACCEPT

che è più liberale della regola statale secondo. La regola stateless consente segmenti TCP arbitrari, ad esempio ACKo FINsenza aver prima stabilito una connessione. Gli scanner delle porte possono sfruttare questo tipo di comportamento per l'impronta digitale del sistema operativo.

Ora diamo un'occhiata a RELATED. Viene utilizzato per i messaggi ICMP, principalmente messaggi di errore. Ad esempio, se un pacchetto dal server al client viene eliminato, viene inviato un messaggio di errore al server. Questo messaggio di errore è "correlato" alla connessione precedentemente stabilita. Senza la regola CORRELATA si dovrebbe o consentire i messaggi di errore in arrivo in generale (senza contesto) oppure, come è personalizzato per molti siti, eliminare del tutto ICMP e attendere i timeout sul livello di trasporto. (Si noti che questa è una cattiva idea per IPv6; ICMPv6 svolge un ruolo più importante per IPv6 rispetto a ICMP per l'eredità IP.)

— countermode
fonte