Perché non bloccare ICMP?

Penso di aver quasi completato la configurazione di iptables sul mio sistema CentOS 5.3. Ecco la mia sceneggiatura ...

# Establish a clean slate
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F # Flush all rules
iptables -X # Delete all chains

# Disable routing. Drop packets if they reach the end of the chain.
iptables -P FORWARD DROP

# Drop all packets with a bad state
iptables -A INPUT -m state --state INVALID -j DROP
# Accept any packets that have something to do with ones we've sent on outbound
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Accept any packets coming or going on localhost (this can be very important)
iptables -A INPUT -i lo -j ACCEPT
# Accept ICMP
iptables -A INPUT -p icmp -j ACCEPT

# Allow ssh
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Allow httpd
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Allow SSL
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Block all other traffic 
iptables -A INPUT -j DROP

Per il contesto, questa macchina è un host di app Web del server privato virtuale.

In una domanda precedente , Lee B ha detto che avrei dovuto "bloccare un po 'di più l'ICMP". Perché non bloccarlo del tutto? Cosa accadrebbe se lo facessi (cosa brutta cosa accadrebbe)?

Se non ho bisogno di bloccare ICMP, come posso fare per bloccarlo di più?

ICMP è molto più che "traceroute" e "ping". Viene utilizzato per il feedback quando si esegue un server DNS (porta non raggiungibile) che, in un moderno server DNS, può effettivamente aiutare a selezionare una macchina diversa per eseguire query più velocemente.

L'ICMP è anche, come menzionato sopra, utilizzato per il rilevamento del percorso MTU. È probabile che il tuo sistema operativo imposta "DF" (non frammentare) sui pacchetti TCP che invia. Si aspetta di recuperare un pacchetto ICMP "frammentazione richiesta" se qualcosa lungo il percorso non riesce a gestire quella dimensione del pacchetto. Se blocchi tutto l'ICMP, la tua macchina dovrà usare altri meccanismi di fallback, che fondamentalmente usano un timeout per rilevare un "buco nero" PMTU e non ottimizzeranno mai correttamente.

Inoltre, dovresti chiederti perché vuoi bloccare ICMP. Cosa stai specificamente cercando di prevenire qui? È abbastanza chiaro che non capisci a cosa serve ICMP, il che è piuttosto comune. Sarei estremamente cauto nel bloccare qualcosa che non capisci del tutto.

Per rendere ancora più difficile conoscere questo, molti libri di firewall comuni dicono "blocca ICMP" - è chiaro che i loro autori non hanno mai letto un RFC o hanno dovuto risolvere problemi relativi a tali consigli. È un cattivo consiglio bloccare tutto l'ICMP.

Ora, la limitazione della velocità può anche danneggiare. Se la tua macchina è occupata, o anche se non lo è, puoi ottenere una buona quantità di traffico ICMP. Il mio server web probabilmente riceve circa 10-100 pacchetti ICMP al minuto, la maggior parte dei quali è la scoperta di PMTU. Anche se qualcuno ha scelto di attaccare il mio server con pacchetti ICMP di qualche tipo, in realtà non è un grosso problema. Se la tua macchina accetta anche una sola connessione TCP (ssh, http, mail, ecc.) È probabile che sia un vettore di attacco più grande di quanto l'ICMP frainteso possa mai essere.

ICMP viene utilizzato per una serie di funzioni diagnostiche (ad es. Ping, traceroute) e di controllo della rete (ad es. Rilevamento PMTU). Il blocco indiscriminato di ICMP provoca altre persone ogni sorta di bruciore di stomaco e, a meno che tu non sappia esattamente cosa stai facendo, dovresti lasciarlo da solo.

Non ho mai capito perché la gente orologio ICMP, come detto sopra, provoca sempre e solo mal di testa a te stesso e agli altri. Puoi determinare se un host è abbastanza facile e fintanto che è abbastanza limitato da non essere usato come DOS, non ho mai sentito ragioni convincenti per bloccarlo. (Se qualcuno può trovare un motivo, per favore pubblica)

potresti semplicemente provare a limitare icmp in questo modo in modo che non possa essere usato come un attacco DOS. ma ci sono troppi strumenti di risoluzione dei problemi come ping, mtr (dimentico l'equivalente di Windows), traceroute (tracert), che usano icmp. lasciarli cadere completamente è solo sciocco. È un buon modo per verificare se l'istanza è attiva anche se non è possibile telnet su nessuna porta.

--limit 10/second

Ecco un punto di vista alternativo, nello spirito di ciò che la teoria della sicurezza suggerirebbe. Altri manifesti hanno ragione sul fatto che le pratiche di sicurezza sono spesso troppo zelanti, ma ci sono buone basi per gran parte di esse.

La teoria della sicurezza è generalmente che si abilita solo ciò di cui hai bisogno. Altre cose (che potrebbero essere utili, ad esempio le risposte al ping) possono essere utilizzate da un utente malintenzionato per individuare il sistema o, eventualmente, come vettore di attacco per alcune vulnerabilità ancora da scoprire.

Quindi, guardando i tipi di messaggi ICMP, cosa TI SERVE per il normale, corretto funzionamento del tuo sistema?

• echo reply (ping) - non così tanto
• destinazione non raggiungibile - molte informazioni utili qui. Disabilita questo e interromperai l'accesso al tuo server per alcuni client.
• estinzione della fonte: obsoleta dal 1995 e apparentemente rimossa dalle implementazioni dell'host dal (al più tardi) 2005. tools.ietf.org/html/rfc6633#section-1.
• reindirizzamento - quasi certamente no
• pubblicità e sollecitazione del router: non è necessario se si configurano staticamente i percorsi e potrebbero essere utilizzati per DoS. Lo bloccherei a meno che tu non sappia che ne hai bisogno e, se ne hai bisogno, forse codifichi una regola per accettare informazioni solo dai possibili router conosciuti.
• ttl superato - non solo per traceroute, ti dice che il tuo traffico non raggiunge la sua destinazione

...e così via. Se vuoi davvero capirlo, vai a conoscere i vari tipi di ICMP e a cosa servono. L' articolo di Wikipedia è un buon punto di partenza.

In pratica, quello veramente brutto è il reindirizzamento; se vuoi semplicemente fare qualcosa di rapido e utile, bloccalo e consenti il ​​resto.

Vorrei aggiungere che il monitoraggio delle connessioni IPtables consentirà i pacchetti ICMP di ritorno appropriati per le connessioni attive. Quindi, se stai eseguendo conntrack, dovresti essere in grado di bloccare la maggior parte degli ingressi ICMP, purché tu accetti i pacchetti CORRELATI (prima di bloccare ICMP nel tuo set di regole).

È uno strumento diagnostico utile per risolvere i problemi di connettività di rete.

Inoltre, consente di utilizzare connessioni altrove su Internet che utilizzano MTU più piccoli rispetto alla rete. Se si tenta di inviare un pacchetto in un punto troppo grande e non può essere frammentato, il dispositivo rilascia il pacchetto e invia al mittente un pacchetto necessario per la frammentazione ICMP. Se elimini tutti i pacchetti ICMP, perdi quelli e accadono cose strane sulla tua rete.

La vera domanda è "perché bloccare ICMP?" Cosa guadagni? Basta avere buone regole di filtraggio al confine e davanti ai tuoi beni stimati.

il ping è un ottimo strumento diagnostico, un giorno vorrai davvero averlo fatto. Sto usando questi:

-A icmp_packets -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A icmp_packets -p icmp -m icmp --icmp-type 11 -j ACCEPT

potresti anche voler strozzarlo.

Oggi anche la limitazione dei pacchetti ICMP sul lato server può creare mal di testa agli attacchi DDoS. Attacchi per lo più fatti inviando enormi richieste ICMP da finestra a un server e se il server sta cercando di rispondere a ciascuno di essi, indovina cosa succede?

La cosa principale che abbiamo un server di teamspeak che ottiene pacchetti cattivi ogni singolo giorno, ci sono stati alcuni giorni in due mesi in cui abbiamo avuto un po 'di "tempo libero". Ciò che abbiamo fatto è stato disabilitare / bloccare completamente le risposte ICMP, non abbiamo server DNS sul server, nessun server NTP, nessun server di posta, nessun server FTP, solo due apache e teampeak. tutte le porte non necessarie per i servizi sono disattivate. Stiamo programmando di bloccare anche l'ssh e lasciare aperte solo due porte. Oggi ci sono 21k (!) Divieti permanenti.

La situazione è che gli aggressori usano principalmente tunneling ICMP e poche linee di log davvero interessanti sono state discusse con gli amministratori del server e hanno detto di avere richieste ICMP sul server, quindi gli aggressori lo hanno usato per scavalcare l'attacco attraverso di loro e attaccarci. Sembra strano ma è vero.

Se non hai bisogno della diagnostica del tuo server e se sei in grado di bloccare completamente le richieste o filtrarle per eliminare enormi finestre, ad esempio, fallo. Ti suggerisco anche di bloccare completamente: Cina, Corea, Tailandia, Turchia perché la maggior parte degli indirizzi IP proviene da lì. Avevo elenchi completi di questi paesi, ma quasi ogni giorno ne arrivano di nuovi.

Dico quello che faccio, se non sei d'accordo, non farlo. Semplice come quella. In bocca al lupo

Come minimo, si dovrebbe consentire di passare i tipi icmp 3 (destinazione non raggiungibile), 4 (spegnimento della sorgente) e 11 (tempo superato). Tutti questi tipi vengono utilizzati per gestire i problemi di rete e non devono essere filtrati.

iptables -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT

(Il tipo di spegnimento della fonte è attualmente deprecato, ma non farà male lasciarlo aperto)

Autorizzo il traffico ICMP dall'intranet locale, lo blocco da Internet. In questo modo il mio server è quasi invisibile online (risponde solo su una porta SSH non standard).

iptables -I INPUT 7 -d 208.180.X.X -p icmp --icmp-type 8  -j DROP
iptables -I INPUT 8 -d 208.180.X.X -p icmp --icmp-type 0  -j DROP
iptables -I INPUT 9 -d 208.180.X.X -p icmp --icmp-type 11 -j DROP

Questo lo inserisce dopo il loopback standard, stabilito, whitelist LAN, whitelist provider VOIP e ACHPT porta SSH. Autorizzo il traffico che desidero, quindi faccio del mio meglio per mantenere il server invisibile al resto del mondo.