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

Mi rendo conto che ci sono opinioni diverse, ma una delle principali attitudini di persone che sanno davvero di networking e sicurezza è che la maggior parte di queste regole iptables / sysctl sono ridondanti, se non dannose per te e la rete. Alcuni ti criticano in modo aggressivo per aver infranto il comportamento standard senza ragione. Alcuni esempi:

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

• Non è necessario eliminare pacchetti non validi o non validi, tutti questi attacchi hanno dieci anni. Gli sviluppatori del kernel di Linux sono molto più aggiornati di te riguardo al tipo di pacchetti validi e quali no. "E i difetti futuri", alcuni potrebbero obiettare. Bene, come fai a sapere che il difetto futuro sarà nel gestore TCP e non nel parser TCP 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 informati da un peer che il mio routing è cattivo, anche se non reagirebbe mai ("accept_redirects", default = 0) automaticamente.

• Con log_martians e altre regole di logging spero che tu abbia 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 bruteforce della password SSH in auth.log o altre cose. Stai effettivamente leggendo quei log su un desktop? Raccomando logcheck.

• Sembra che blocchi ICMP. Oltre al problema DHCP citato, ciò impedisce anche la scoperta di PMTU. Senza PMTUD, si otterrà uno strano comportamento quando si utilizza il sistema in luoghi con connessione DSL o altre impostazioni di rete. Alcuni pacchetti verranno semplicemente eliminati e nessuno ti spiegherà perché.

• Il filtraggio dei pacchetti in uscita è un po 'oscuro. Non ti fidi di te stesso? In genere non dovresti eseguire programmi di cui non puoi fidarti. I sistemi operativi delle materie prime sono per lo più incapaci di isolare questi programmi da intercettazioni o persino manipolazione di dati di altri programmi (ad es. Attacchi di temporizzazione della cache)

• Sono necessari NUOVI pacchetti per avere SYN. Questo si interromperà se una connessione TCP viene continuata dopo che il rispettivo stato in iptables è già scaduto. Non sei sicuro di quali siano i timeout predefiniti, ma alcuni utenti di netfilter ne hanno avvertito.

Quindi, quando un desktop dovrebbe avere un firewall?

• Se nelle notizie c'è un attacco specifico a cui sono vulnerabili il tuo sistema operativo o server 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 sostituito da alternative sicure.

• Sono presenti reti più complesse con diverse macchine virtuali e / o interfacce sul 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 utilizzando. Quindi basta disabilitare quelli che non ti servono o confinarli a 127.0.0.1.

Bonus se leggi fino a questo punto: i pacchetti sono ESTABLISHED, RELATED o NEW, qualsiasi altra cosa tu faccia cadere. Si rilascia anche NUOVO, a meno che non sia impostato solo SYN. Poiché ESTABLISHED, RELATED sembra controllare i flag, questo rende tutte le regole --tcp-flags e anche la regola -f ridondante. Lo stesso per OUTPUT, ma dato che nessun pacchetto è ACCEPTed per OUTPUT comunque, probabilmente non ha importanza.

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

Creerei due diversi set 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 LAN tipica.

Inoltre raccomando vivamente di aggiungere la registrazione a martian, drop in uscita, connessioni interrotte in entrata, ecc. Questo può essere cruciale per la risoluzione dei problemi e può essere più utile per il vostro SIEM da mangiare.

Per un PC client, connesso direttamente a Internet tramite 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. Permette tutto sull'interfaccia locale interna.
2. Consente a qualsiasi pacchetto di rispondere a un pacchetto inviato. Ciò include pacchetti all'interno di una connessione TCP, risposte a pacchetti UDP come piccole query DNS. Per il protocollo FTP non crittografato vecchio stile, questo include la connessione dati, supponendo che sia caricato ip_conntrack_ftp
3. Rifiuta tutti tenta di aprire una connessione TCP dall'esterno
4. Rifiuta tutti i pacchetti udp iniziali (non risposta)

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

Quindi, per elaborare la tua domanda, ecco cosa ho eseguito (e userò i tuoi esempi con le note, dato che le mie sono praticamente prive di commenti che sono state trasmesse a net fliter da quando IPCHAINS è morto tutti quegli anni fa. )

Potrebbe funzionare per un sistema interno, ma spesso passerai il tempo a configurare i tuoi iptables per le nuove applicazioni non prese in considerazione. Ho anche rimosso la mia regola SSH, ma quella è una versione abbastanza standard che vedrai (e in molte configurazioni l'unica che vedrai per consentire l'input.)

###############
# VARIABLE DEFINITIONS
IPTABLES=/sbin/iptables

#Your DHCP Server for input of ICMP packets
DHCPSERVER=127.0.0.1
PUBIF=eth0

# KERNEL PARAMETER CONFIGURATION
#
# DROP ICMP ECHO-REQUEST MESSAGES SENT TO BROADCAST OR MULTICAST ADDRESSES
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
#
# DONT ACCEPT ICMP REDIRECT MESSAGES
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
#
# DONT SEND ICMP REDIRECT MESSAGES
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
#
# DROP SOURCE ROUTED PACKETS
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
#
# ENABLE TCP SYN COOKIE PROTECTION FROM SYN FLOODS
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
#
# ENABLE SOURCE ADDRESS SPOOFING PROTECTION
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

# LOG PACKETS WITH IMPOSSIBLE ADDRESSES (DUE TO WRONG ROUTES) ON YOUR NETWORK
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

# DISABLE IPV4 FORWARDING
echo 0 > /proc/sys/net/ipv4/ip_forward
###############
$IPTABLES -F
###############
# LOGDROPPER
$IPTABLES -N LOGNDROP > /dev/null 2> /dev/null 
$IPTABLES -F LOGNDROP 
$IPTABLES -A LOGNDROP -j LOG --log-prefix "LOGNDROP: " 
$IPTABLES -A LOGNDROP -j DROP

###############
# LO allowance
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT

###############
# Only bring what you need to survive
$IPTABLES -A INPUT -p icmp -s $DHCPSERVER -j ACCEPT
$IPTABLES -A INPUT -i $PUBIF -s $DHCPSERVER -p tcp --sport 68 --dport 67 -j ACCEPT
$IPTABLES -A INPUT -i $PUBIF -s $DHCPSERVER -p udp --sport 68 --dport 67 -j ACCEPT
###############
# INPUT
#
# DROP INVALID
$IPTABLES -A INPUT -m state --state INVALID -j LOGNDROP

# ALLOW ONLY ESTABLISHED, RELATED
$IPTABLES -A INPUT -p tcp -i $PUBIF -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -p udp -i $PUBIF -m state --state ESTABLISHED,RELATED -j ACCEPT

# DROP INVALID SYN PACKETS
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j LOGNDROP
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOGNDROP
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j LOGNDROP

# MAKE SURE NEW INCOMING TCP CONNECTIONS ARE SYN PACKETS; OTHERWISE WE NEED TO DROP THEM
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOGNDROP

# DROP PACKETS WITH INCOMING FRAGMENTS. THIS ATTACK RESULT INTO LINUX SERVER PANIC SUCH DATA LOSS
$IPTABLES -A INPUT -f -j LOGNDROP

# DROP INCOMING MALFORMED XMAS PACKETS
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -j LOGNDROP

# DROP INCOMING MALFORMED NULL PACKETS
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j LOGNDROP

###############
# OUTPUT

# DROP INVALID
$IPTABLES -A OUTPUT -m state --state INVALID -j LOGNDROP

# DROP INVALID SYN PACKETS
$IPTABLES -A OUTPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j LOGNDROP
$IPTABLES -A OUTPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOGNDROP
$IPTABLES -A OUTPUT -p tcp --tcp-flags SYN,RST SYN,RST -j LOGNDROP

# DROP PACKETS WITH OUTGOING FRAGMENTS. THIS ATTACK RESULT INTO LINUX SERVER PANIC SUCH DATA LOSS
$IPTABLES -A OUTPUT -f -j LOGNDROP

# DROP OUTGOING MALFORMED XMAS PACKETS
$IPTABLES -A OUTPUT -p tcp --tcp-flags ALL ALL -j LOGNDROP

# DROP OUTGOING MALFORMED NULL PACKETS
$IPTABLES -A OUTPUT -p tcp --tcp-flags ALL NONE -j LOGNDROP

$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -A INPUT -j LOGNDROP
$IPTABLES -A FORWARD -j LOGNDROP

Se la rete è rumorosa o se ci sono molte cose in corso, questo riempirà rapidamente il volume del registro. Ma sono paranoico e anche le costolette della gente se creano configs che sono rumorosi inutilmente.