In che modo un'azienda può ridurre l'esposizione allo spoofing dei pacchetti? Quale soluzione dovrebbe esistere, ma no?

Nel caso generale, può essere molto difficile differenziare i pacchetti con indirizzi falsificati. La maggior parte dei sistemi (server o dispositivi di rete) avrà una sola NIC, quindi tutto il traffico arriverà sulla stessa porta. Le voci MAC statiche possono aiutare a mitigare i danni collaterali, ma molto rapidamente diventano un incubo gestionale. Uno dei pochi posti in cui è possibile rilevare e filtrare il traffico con spoofing si trova su un router.

Il tuo confine di rete è, senza dubbio, il posto più facile per fare questo filtraggio. Qui dovresti avere una molto buona idea su quale direzione devono fluire gli indirizzi IP. Vorrei prima bloccare tutti gli indirizzi di Bogon. Se stai utilizzando BGP, Team Cymru ha una buona annotazione sul Progetto Bogon Route Server . Includere anche un ACL per bloccare il proprio spazio di indirizzi all'esterno, ASA (sostituendo X.X.X.X con la propria allocazione e Y.Y.Y.Y con la maschera di rete):

access-list outside_access_in extended deny ip X.X.X.X Y.Y.Y.Y any 

A livello di istituto istituto regole firewall strettamente confinate. Qui devi definire strettamente pubblico e servizio, seguito da un rifiuto predefinito.

I firewall ei router moderni possono filtrare in base a vari criteri (come altri hanno notato):

• Intervalli di indirizzi privati - questi non devono essere visualizzati su un'interfaccia pubblica
• Gli indirizzi interni non dovrebbero arrivare dall'esterno (filtraggio delle entrate)
• Filtro di uscita: un'organizzazione deve sapere quale indirizzo interno è valido per i pacchetti che escono dalla rete
• Bogons come menzionato dai pacchetti.
• Gli indirizzi interni dovrebbero essere facili da validare in quanto è possibile abbinare l'indirizzo MAC all'indirizzo IP (per sottorete / dominio broadcast).
• Router: con instradamento simmetrico, se l'indirizzo di origine indirizzasse un'interfaccia diversa da quella in entrata, è falsificato o non si è simmetrici.
• Proteggi contro attacchi sequenza DNS - assicurati che i numeri di sequenza siano randomizzati - minimizzi l'effetto dello spoofing per un attacco DNS
• Impedisci l'accesso esterno all'indirizzo broadcast (sicurezza generale, attacco smurf)

It seems that IP spoofing is permitted out of ISP laziness & cost savings efforts, or there could be a legitimate technical reason

La ragione tecnica / di costo è che alcuni router di base gestiscono una quantità così grande di traffico che farebbe male alle prestazioni filtrare (almeno 5 anni fa comunque).

I think that a reduction in IP Spoofing will also significantly reduce one's exposure to numerous types of attacks (DDOS...)

DDoS generalmente non usa lo spoofing. Non è necessario proteggere gli zombi che eseguono l'attacco. IMHO, l'antispoofing su Internet non è decollato perché il costo supera di gran lunga la riduzione degli attacchi. Gli attaccanti designati che utilizzano spoofing probabilmente hanno le competenze per utilizzare un certo numero di altri metodi e potrebbero facilmente ottenere l'accesso agli zombi e utilizzare indirizzi IP validi. (Non sono aggiornato qui però)

Riferimenti aggiuntivi

• Esercitazione CCNA: IP Spoofing e RFC 3704/2827 Filtering
• Articolo ACM (paywall)

Se sei interessato a gestire il traffico di rete verso una o più interfacce, fisiche o virtuali, ci sono un certo numero di soluzioni valide, tuttavia, questo sarebbe molto semplice da realizzare con un firewall. Se, ad esempio, ho una macchina con due interfacce fisiche connesse alla stessa rete e voglio solo accettare il traffico della porta 80 su una di esse, allora potrei creare una regola firewall, iptables in questo caso, come:

DROP all - anywhere non-80-IP tcp dpt:80

Questo è un esempio molto grezzo, ovviamente, ma non causerebbe l'invio di alcun pacchetto di ritorno a nessuna richiesta ricevuta sulla porta 80 su TCP all'interfaccia specificata da IP.

Naturalmente, se si controlla o si ha accesso al router upstream per la rete in questione, sarebbe più sensato semplicemente non instradare il traffico indesiderato, la porta TCP 80 nell'esempio sopra, alle interfacce in questione . Ovviamente questo non limiterebbe l'accesso alla rete interna.

Se sei interessato al controllo marziano, ci sono alcune opzioni ma un'altra regola del firewall costruita come:

DROP all - 10.0.0.0/8 iface-IP

che rilascia, non invia risposta, tutti i pacchetti originati dalla rete 10.0.0.0/8. Ovviamente questo potrebbe essere troppo pesante per la tua particolare configurazione di rete, ma con una regolazione minima dovrebbe servire ad eliminare i marziani per la / e rete / i in questione.

Anche se non sono molto un ragazzo delle reti (ho dimenticato la maggior parte di ciò che sapevo da quando ero nel team di sviluppo di uno dei firewall dei grandi produttori), mi sembra di pensare che la maggior parte dei firewall almeno ( probabilmente anche i router) non eseguono il routing automatico tra le interfacce, a meno che non siano impostate esplicitamente in questo modo.
Qualsiasi firewall o router che si rispetti non dovrebbe instradare i pacchetti provenienti dall'interfaccia sbagliata. Ma dovresti essere in grado di verificare facilmente le regole per quello ...

Anche in questo caso, si presume che si stia effettuando questa rilevazione sul bordo della rete, non sull'host.

Una volta che il traffico legittimo si è mescolato con il traffico di spoofing dallo stesso IP sorgente, c'è poco che puoi fare, tranne provare a rafforzare le applicazioni contro lo spoofing. Il blocco efficace del traffico di spoofing deve essere vicino alla fonte.

Le regole manuali funzionano bene per impedire che il traffico spoofed entri da piccoli clienti e colleghi con reti semplici, ma non si adattano bene ai grandi clienti / peer.

Un'opzione più automatizzata è il reverse path filtering (urpf). Fondamentalmente controlli gli indirizzi di origine contro le tue rotte conosciute e rilascia pacchetti che non provengono da dove ti aspetti che provengano.

Ci sono due varianti del filtro del percorso inverso "strict" e "fattibile", entrambi hanno i loro problemi.

Con la modalità "strict" si confronta con il percorso "migliore" con la fonte. Il problema è che questo è troppo severo per reti complesse (incluso Internet). Il routing è spesso asimmetrico

Con la modalità "fattibile" si confronta con qualsiasi percorso possibile verso la fonte, anche se non è il percorso migliore corrente. È meno probabile che questo faccia cadere traffico legittimo, ma è difficile da implementare (i router generalmente mantengono il percorso migliore in una tabella veloce e gli altri percorsi fattibili in una tabella più lenta).