Suggerimenti per una configurazione sicura di iptables per difendersi dagli attacchi. (dalla parte del cliente!)

Mi rendo conto che ci sono opinioni diverse, ma uno dei principali atteggiamenti delle persone che conoscono veramente il networking e la sicurezza è che la maggior parte di queste regole di iptables/sysctl sono ridondanti, se non dannose per te e per la rete. Alcuni ti criticheranno in modo aggressivo per aver infranto il comportamento standard senza motivo. Alcuni esempi:

• Il comportamento standard di TCP/IP è REJECT in modo che il peer riceva qualche suggerimento su cosa sta succedendo. Forse qualcuno ha appena digitato un URL sbagliato o il tuo amministratore sta contando gli host o qualcuno vuole connettersi al tuo server di gioco ma ha digitato la porta sbagliata. Con DROP ottengono solo oscuri e fastidiosi timeout.

• Non è necessario eliminare pacchetti non validi o malformati, tutti questi attacchi risalgono a dieci anni fa. Gli sviluppatori del kernel Linux sono molto più aggiornati di te su quali tipi di pacchetti sono validi e quali no. "E i difetti futuri", potrebbe obiettare qualcuno. Bene, come fai a sapere che il futuro difetto sarà nel gestore TCP e non nel parser TCP di iptables?

• La maggior parte delle impostazioni di sysctl sono predefinite. Se non lo sono, di solito c'è una ragione. Ad esempio, perché disabilitare l'invio di reindirizzamenti? Trovo molto utile essere informato da un peer che il mio instradamento è sbagliato, anche se non reagirei mai("accept_redirects", default=0) automaticamente.

• Con i tuoi log_martians e altre regole di registrazione spero che tu abbia anche una quota su /var/log, o sarà molto divertente riempire da remoto il tuo disco, di solito uccidendo i tuoi servizi/app. Inoltre, dovresti utilizzare un limite di velocità per la registrazione o qualcuno potrebbe riempire la quota per impedirti di vedere i tentativi di forza bruta della password SSH in auth.log o altre cose. Stai davvero leggendo quei registri su un desktop? Raccomando logcheck.

• Sembri bloccare l'ICMP. Oltre al citato problema DHCP, ciò impedisce anche il rilevamento di PMTU. Senza PMTUD, otterrai uno strano comportamento quando utilizzi il sistema in luoghi con connessione DSL o altre impostazioni di rete. Alcuni pacchetti verranno semplicemente eliminati e nessuno ti dirà perché.

• Filtrare i pacchetti in uscita è piuttosto oscuro. Non ti fidi di te stesso? In genere non dovresti eseguire programmi di cui non ti puoi fidare. I sistemi operativi di base sono per lo più incapaci di isolare questi programmi dall'intercettazione o persino dalla manipolazione dei dati di altri programmi (ad es. attacchi con tempi di cache)

• Hai bisogno di NUOVI pacchetti per avere SYN. Ciò si interromperà se una connessione TCP viene continuata dopo che il rispettivo stato in iptables è già scaduto. Non sono sicuro di quali siano i timeout predefiniti, ma un tizio di netfilter l'ha avvertito.

Quindi, quando un desktop dovrebbe avere un firewall?

• Se c'è un attacco specifico nelle notizie a cui il tuo attuale sistema operativo o server è vulnerabile e una delle soluzioni rapide consigliate è una regola del firewall.

• Devi eseguire determinati servizi che non consentono la configurazione sicura. La maggior parte lo fa, e il resto è meglio sostituirlo con alternative sicure.

• Hai reti più complesse con diverse VM e/o interfacce sul tuo desktop.

Il primo e più importante strumento per la sicurezza della tua rete è l'aggiornamento del sistema. In secondo luogo, ci sono netstat e nmap, che dovresti usare per trovare e confermare quali servizi stai eseguendo. Quindi disabilita quelli che non ti servono o limitali a 127.0.0.1.

Bonus se leggi fino a qui:i pacchetti sono STABILITI, CORRELATI o NUOVI, tutto il resto che lasci cadere. Rilasci anche NEW a meno che non sia impostato solo SYN. Poiché ESTABLISHED,RELATED sembra controllare i flag, ciò rende ridondanti tutte le regole --tcp-flags e anche la regola -f. Lo stesso per OUTPUT, ma dal momento che nessun pacchetto viene comunque ACCETTATO per OUTPUT, probabilmente non ha importanza.

Farei attenzione a far parte dello stesso set di regole per i dispositivi all'interno di una rete attendibile e quelli in una DMZ. Utilizzando le regole che hai definito lì, non risponderai a un server DHCP che chiede (ICMP echo) se il tuo IP è in uso. Ciò potrebbe portare a una situazione di indirizzo duplicato.

Creerei due diverse serie di regole da applicare a ogni scenario, qualcosa di simile a quanto elencato sopra è una buona base per una macchina DMZ, ma crea alcune sfide su una tipica LAN.

Inoltre, consiglierei sicuramente di aggiungere la registrazione a marziani, interruzioni in uscita, connessioni interrotte in entrata, ecc. Questo può essere cruciale per la risoluzione dei problemi e può essere un dato più utile per il tuo SIEM da mangiare.

Per un PC client, connesso direttamente a Internet via ppp, il seguente set di regole è un buon inizio:

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp -j REJECT
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
ip6tables -A INPUT -j REJECT

1. Consente tutto sull'interfaccia locale interna.
2. Consente qualsiasi pacchetto che è una risposta per un pacchetto inviato. Ciò include pacchetti all'interno di una connessione TCP, risposte a pacchetti UDP come piccole query DNS. Per il vecchio protocollo FTP non crittografato, questo include la connessione dati, supponendo che ip_conntrack_ftp sia caricato
3. Rifiuta tutti i tentativi di aprire una connessione tcp dall'esterno
4. Rifiuta tutti i pacchetti udp iniziali (senza risposta).

In alternativa puoi usare -j DROP nelle ultime due regole. Per una discussione su questo argomento, vedi Rifiutare i pacchetti IP con un errore ICMP o eliminarli semplicemente?