Rischio per la sicurezza di consentire ai pacchetti ICMP di "destinazione non raggiungibile" su AWS

Non esistono implicazioni ragionevoli per gli utenti DSL che bloccano i messaggi INBOUND ICMP (di qualsiasi tipo, in realtà) per i servizi ospitati in un'istanza di Amazon Cloud. Il motivo non ha alcun problema a bloccarli perché l'infrastruttura Amazon al di fuori del tuo cloud privato gestirà tutto ciò per te ... dopotutto, l'MTU all'interno del tuo private cloud non può superare il minimo MTU del percorso del percorso tra i potenziali clienti e i tuoi server.

L'unica volta in cui un ICMP irraggiungibile in ingresso dovrebbe verificarsi è se i server stanno cercando di raggiungere un indirizzo di destinazione per qualche motivo e un dispositivo nel percorso che è autorevole per il routing a quell'indirizzo di destinazione decide che non può raggiungere esso. Se il tuo server risponde a un potenziale cliente e tu ricevi una destinazione ICMP irraggiungibile, il "client" è probabilmente dannoso e sta falsificando il loro indirizzo di origine. Questo dovrebbe essere evidente perché se fosse un indirizzo legittimo che è stato indirizzato a te c'è quasi sicuramente un percorso indietro!

Sii prudente con un criterio BLOCK-ALL predefinito sulle istanze AWS. Metto un esplicito allow-my-management-IP su SSH e blocco tutto il resto una volta - e ho murato la mia istanza! Questo perché ci sono alcune comunicazioni DHCP e "Amazon" che il dispositivo deve supportare per poter comunicare. Lo stesso è probabile in un'istanza di cloud privato virtuale.

I non concur con l'affermazione di munkeyoto che c'è " nessun rischio " per consentire ai messaggi non raggiungibili di destinazione in uscita. Principalmente per le ragioni delineate da Mark e Jim. Gli hacker useranno qualsiasi cosa tu gli dia ... Se hanno solo bisogno di perdere una password, possono farlo attraverso i flag e le lettere maiuscole dei dati dei messaggi ICMP, quindi sarebbero necessari solo alcuni di questi messaggi (supponendo che non abbiano usato un blast- approccio out-all-data-at-once).

"ICMPTX" è un rischio molto, molto basso nella maggior parte delle situazioni del mondo reale. È fondamentalmente un modo per due programmi cooperanti di intrufolarsi tra i dati oltre un firewall che cerca solo l'estrazione dei dati sui protocolli tradizionali (TCP, UDP, ecc.). A meno che il tuo VPC AWS non sia infestato da malware e il tuo firewall sta ispezionando pacchetti per tentativi di estrazione dei dati, non me ne preoccuperei.

Il "rischio" generale di ping è preoccupante per qualcuno che utilizza il protocollo icmp per estrarre dati o controllare il malware. Penso che molte volte sia stato disabilitato come un "Non so perché ne ho bisogno, quindi lo disabiliterò mentalmente". Questo è il motivo per cui è diventata la regola predefinita. Anche se queste sono entrambe vere e proprie preoccupazioni se sei ancora nella mentalità "I have a perimeter" (al contrario di "Ho sicurezza dei dati, quindi l'identità è il mio perimetro"), quelle stesse preoccupazioni si applicano a ogni porta / protocollo che può entrare e uscire. ICMP è stato scelto in IPV4 perché era piacevole da usare, non avendo per lo più solo degli amministratori di rete infastiditi.

In IPV6 che consente a ICMP di essere non solo predefinito ma richiesto per diversi motivi, come la frammentazione che avviene solo all'origine (con icmp che invia un messaggio di tipo 2 all'host), SLAAC e NDP sono anche messaggi ICMP.

C'è nessun rischio associato alla disattivazione dei pacchetti non raggiungibili OUTBOUND . Diamo un'occhiata al motivo: la tua macchina stabilisce che qualcosa non può essere raggiunto FROM la tua macchina: "Qual è il significato di ciò che sei che blocca esplicitamente ?" Cisco suggerisce di bloccare la destinazione non raggiungibile, in quanto un utente malintenzionato può causare l'invio ripetuto della tua macchina messaggi che possono sopraffare la tua attrezzatura. Considera il seguente attacco:

Attacker (2.3.4.5) --> (spoofs 8.8.8.8) --> your server (N amount of times)
Your server --> destination unreachable --> 8.8.8.8

Nel lato OUTBOUND dell'equazione, a cosa serve questo VPC? Ad esempio, se il VPC ha una connessione specifica: Punto A < - > VPC che differenza fa se tutto il resto è bloccato. Questo è qualcosa a cui solo tu puoi rispondere. Tutto inizia con qual è lo scopo del VPC, chi e come ha bisogno di connettersi (da e verso).

Generalmente vuoi evitare di creare troppe regole, diventa complicato da gestire, quindi una regola più appropriata sarebbe qualcosa del tipo:

allow -- icmp messages (all) -- from.my.trusted.blocks
deny -- icmp messages -- all

Ciò garantisce che tutte le connessioni specificate siano in grado di ricevere messaggi per la possibile risoluzione dei problemi, mentre negano tutto il resto. Due regole contro dozzine | centinaia.