Il protocollo Echo ICMP (solitamente noto come "Ping") è per lo più innocuo. I suoi principali problemi relativi alla sicurezza sono:

• In presenza di richieste con un indirizzo di origine falso ("spoofing"), possono fare in modo che una macchina di destinazione invii pacchetti relativamente grandi a un altro host . Si noti che una risposta Ping non è sostanzialmente più grande della richiesta corrispondente, quindi non vi è alcun effetto moltiplicatore: non darà ulteriore potenza all'attaccante nel contesto di un attacco Denial of Service. Tuttavia, potrebbe proteggere l'attaccante dall'identificazione.

• La richiesta di ping onorato può fornire informazioni sulla struttura interna di una rete. Ciò non è rilevante per i server visibili pubblicamente, tuttavia, poiché questi sono già visibili pubblicamente.

• C'erano falle di sicurezza in alcune implementazioni TCP / IP diffuse, dove un ping non valido richiesta potrebbe mandare in crash una macchina (il "ping of death"). Ma questi sono stati debitamente corretti durante il secolo precedente e non sono più un problema.

È pratica comune disabilitare o bloccare Ping su server visibili pubblicamente, ma essendo comune non è la stessa cosa che essere consigliato . www.google.com risponde alle richieste di ping; www.microsoft.com non lo fa. Personalmente, consiglierei di lasciare che tutti gli ICMP passino per server visibili pubblicamente.

Alcuni tipi di pacchetti ICMP NON DEVONO essere bloccati, in particolare il messaggio ICMP "destinazione irraggiungibile", perché il blocco si interrompe il percorso MTU discovery, i sintomi sono che gli utenti DSL (dietro un livello PPPoE che limita MTU a 1492 byte) non possono accedere ai siti Web che bloccano quei pacchetti (a meno che non utilizzino il proxy Web fornito dal proprio ISP) .

ICMP ha una componente dati. Può essere usato per costruire tunnel, e questa non è solo una questione teorica, è disponibile in natura. È stato trovato da diversi ricercatori come parte di toolkit di malware. Per non parlare dell'esistenza di un importante howto su questo argomento, per non parlare del wiki o del hackaday

ICMPTX utilizza l'eco ICMP e la risposta ICMP . ICMP echo non è sempre innocuo, poiché contiene un componente dati, può essere esfiltrato dati o essere utilizzato come canale di controllo, o essere utilizzato (nel caso di ICMPTX) come protocollo di tunneling.

Attuale implementazione nella distribuzione, con howto, (ICMPTX): http://thomer.com/icmptx/

Scenario di attacco reale che utilizza la trasmissione di dati ICMP per payload injection: Open Packet Capture

Utilizzo di un protocollo di trasmissione dati ICMP tramite metodi simili a ICMPTX (2006) per trojan C&C ed Exfiltration: Network World

È vero che ICMP può essere utilizzato dagli aggressori per ottenere informazioni, trasportare dati di nascosto, ecc. È anche vero che ICMP è estremamente utile e che disabilitarlo può spesso causare problemi. Traceroute utilizza in effetti ICMP, quindi disabilitare determinati tipi di ICMP lo interromperà.

La domanda evidenzia il classico equilibrio tra sicurezza e funzionalità e sta a te determinare quanta funzionalità sei disposto a perdere per guadagnare x quantità di sicurezza.

Una raccomandazione è di consentire solo alcuni tipi (i più comunemente usati) e disabilitare tutti gli altri. Ecco le mie regole di iptables. Tieni presente che questi sono consentiti perché tutto il resto è disabilitato per impostazione predefinita.

  # Consenti ICMP in arrivo: ping, rilevamento MTU, TTL scaduto / sbin / iptables -A INPUT -i eth0 -p icmp -d $ YOURBOX --icmp-type 8/0 -j ACCEPT / sbin / iptables -A INPUT -i eth0 -p icmp -d $ YOURBOX --icmp-type 3/4 -j ACCEPT / sbin / iptables -A INPUT -i eth0 -p icmp -d $ YOURBOX --icmp-type 11/0 -j ACCETTA  

Penso che la risposta echo in uscita sia più pericolosa della richiesta echo in entrata a causa dell'amplificazione ICMP (o limite di velocità o nega questo traffico). Tuttavia, dopo decenni di riflessione su questo argomento, ho concluso che ICMP è più pericoloso che utile e quindi dovrebbe essere bloccato in entrambe le direzioni, con l'accesso al traffico in uscita potenzialmente contraffatto.

Il meglio di all worlds è percorsi nulli su tutto ciò che potrebbe essere con stato ma non desiderato (connessioni TCP) e ACL riflessivi (guidati dalle prestazioni) per qualsiasi cosa con stato ma consentito e / o non completamente con stato (datagrammi UDP), mentre la rimozione di altri Tipi di protocollo IP, poiché non sono necessari. IPsec AH / ESP non è necessario, usa invece OpenVPN (o simile).

Dopo aver bloccato il traceroute ICMP, devi anche fare i conti con il traceroute basato su UDP, così come con concetti tecnologici come quelli trovati nel 0trace, LFT e osstmm_afd.

Anche se le scansioni di Natale di Nmap non vengono rilevate da Snort / Suricata, per non parlare di attacchi basati su SQLi o Javascript (in qualsiasi direzione), dobbiamo riconoscere l'importanza dei rischi legati agli attacchi alla sicurezza della rete e delle applicazioni contro l'infrastruttura moderna. Dovremmo negare, testare e verificare qualsiasi tipo di traffico di impronta e non vedo perché questo non includerebbe l'ICMP, ma in realtà non si avvia o si ferma qui.

Ping e Traceroute sono necessari per la risoluzione dei problemi delle reti. Con i firewall moderni e gli strumenti di sicurezza ce n'è molto poco e rasenta la possibilità che uno dei due protocolli venga utilizzato con successo in modo dannoso.

Nel 1996, sicuramente era un problema, ma ora è il 2015, quasi 20 anni dopo, e bloccarli porta solo a un drastico aumento dei tempi per risolvere la connettività e le prestazioni. Paralizzare la capacità dei team di livello 1/2 di identificare e risolvere semplici problemi di instradamento e di rete è un problema di fornitura del servizio che influisce sulla soddisfazione del cliente per qualsiasi servizio di rete fornito.

Invece di rispondere alla domanda principale "quali sono i rischi per la sicurezza del ping", risponderò alla tua domanda secondaria "È una buona idea bloccare / disabilitare sui server web di produzione"

Penso che qui possiamo trovare un equilibrio tra sicurezza e utilità. Il personale di supporto generalmente trova il ping utile durante il controllo della latenza o della disponibilità di un determinato nodo. Il personale addetto alla sicurezza è preoccupato per molti dei problemi di sicurezza delineati in questa pagina e spesso sono i "cattivi".

Perché non considerare di disabilitare Ping in un formato whitelist / blacklist e farlo sapere al tuo supporto personale. Se il tuo pubblico principale si trova in una determinata area geografica, limita la possibilità di eseguire il ping in base all ' allocazione IP IANA

Dopo un primo accesso al tuo server, un software dannoso può utilizzare il protocollo ping come mezzo di comunicazione con il suo server di comando e controllo. Ad esempio, una shell inversa che utilizza il protocollo ping: https://github.com/inquisb/icmpsh

In "Requirement for internet hosts", una rispettata autorità responsabile della standardizzazione di ICMP, TCP, IP e altri protocolli, IETF, specifica che gli host devono rispondere alle query ICMP. Quindi non solo la pratica è sicura, ma è considerata obbligatoria per la conformità con i loro standard:

Ogni host DEVE implementare una funzione del server Echo ICMP che riceve le richieste di eco e invia le corrispondenti risposte di eco. Un host DOVREBBE implementare anche un'interfaccia a livello di applicazione per inviare una richiesta di eco e ricevere una risposta di eco, per scopi diagnostici.

Nel linguaggio IETF standard, DEVE significa che "l'elemento è un valore assoluto requisito della specifica. " Sebbene DOVREBBE significare che "possono esistere valide ragioni in particolari circostanze per ignorare questo elemento, ma tutte le implicazioni dovrebbero essere comprese"

Ciò significa che un server deve rispondere a una domanda echo ICMP, ma potrebbe non fornire loro un'interfaccia utente.

Il documento fa riferimento a un ampio dibattito che ha avuto luogo prima della data della redazione 1989:

"Questa disposizione neutra è il risultato di un appassionato dibattito tra coloro che ritengono che l'eco ICMP a un indirizzo di trasmissione fornisca una preziosa capacità diagnostica e coloro che ritengono che l'uso improprio di questa funzione possa creare troppo facilmente tempeste di pacchetti. "

Anche dopo più recenti ( 2010) discussioni sugli attacchi teorici tramite ICMP su RFC 5927, l'IETF non ha ancora declassato le risposte ECHO dell'ICMP da un MUST a un DOVREBBE. L'obiettivo di questa RFC sono i fornitori e gli implementatori di ICMP e TCP, non i consumatori. Gli scenari peggiori descritti sono il degrado del servizio.

In breve, ICMP è sicuro. La disabilitazione non è consigliata.

Se rispetti le spalle dei giganti su cui ti trovi, rispetti la loro decisione ed eviti di deviare dalle convenzioni.