Ci sono tre probabili comportamenti quando il pacchetto viene inviato dalla LAN al router:
- Il router applica il filtro della rotta inversa e rilascia il pacchetto.
- Il router non filtra. Invece il router lo tratta come qualsiasi altro pacchetto dalla LAN, il che significa che l'IP di origine viene sostituito con l'IP del router e il router crea una voce di tracciamento della connessione.
- Il router non applica filtri o NAT. Invece il router inoltra il pacchetto con l'indirizzo di origine falsificato.
Nel primo caso, non accade più nulla. Nel terzo caso, il pacchetto può essere eliminato o inoltrato dall'ISP. In uno di questi casi il pacchetto spoofato arriva fino al bersaglio. Ma nessuna risposta tornerà su questo router, perché andrebbe all'IP spoofato.
Il caso più interessante è quello in cui il NAT viene applicato al pacchetto. L'ISP non sarà più in grado di rilasciare il pacchetto in base all'IP di origine, poiché in questo caso l'IP di origine è in effetti valido per quanto riguarda l'ISP. Ma questo non è molto dannoso perché i pacchetti possono essere facilmente filtrati in base all'IP di origine una volta raggiunta la destinazione (supponendo che l'alluvione sia abbastanza grande da essere visibile nella destinazione). Inoltre non può essere facilmente abusato in un attacco di riflessione, perché le risposte tornano al router NAT.
Ciò che accade a tutte le risposte che ritornano al router NAT è più interessante. Corrispondono a una voce di tracciamento della connessione. Ma dopo che il NAT è stato applicato, l'indirizzo di destinazione non sarà all'interno della LAN, ma esternamente. A questo punto ci sono alcuni possibili risultati:
- Il router potrebbe rifiutarsi di inoltrare il pacchetto perché verrebbe reinviato all'interfaccia da dove proviene.
- Il router può inoltrare il pacchetto alla rete esterna non appena ha applicato NAT in base alla voce di tracciamento della connessione.
- Il router potrebbe tentare di eseguire nuovamente NAT sul pacchetto, perché lascerebbe l'interfaccia esterna.
Il primo caso in cui il pacchetto viene eliminato, non è particolarmente interessante o dannoso.
Il secondo caso in cui il pacchetto viene reindirizzato sulla rete esterna è più interessante. Questo è il caso in cui il NAT ha impedito lo spoofing in primo luogo, ma un effetto collaterale di questo è che all'elaborazione della risposta, produce effettivamente un pacchetto con IP di origine falsificato (in effetti l'IP di origine e di destinazione dell'originale pacchetto è stato invertito).
Se l'ISP non filtra il pacchetto a causa di un IP di origine non valido, il traffico di ritorno verrà quindi inoltrato all'IP che è stato contraffatto in primo luogo. E all'arrivo sembrerà più o meno lo stesso, se non ci fosse stato alcun NAT.
Ma dal momento che questo comporta tre viaggi attraverso la connessione esterna della rete che attacca, il tasso di traffico d'attacco è limitato rispetto a quello che avrebbe potuto essere.
Se il router prova nuovamente a NAT, la roba diventa un po 'interessante. Il problema qui è che non è il primo pacchetto di un flusso, quindi il livello NAT potrebbe non sapere come gestirlo. Quindi il pacchetto può essere eliminato a causa del NAT che viene applicato senza aver visto il primo pacchetto del flusso.
È anche possibile che venga creata una voce di tracciamento della connessione. Dal momento che la nuova voce di tracciamento della connessione creata non è stata ovviamente applicata al primo pacchetto del flusso, non è possibile che ciò funzioni per una connessione TCP. Ma altri protocolli potrebbero funzionare anche in uno scenario del genere. Tuttavia, poiché questo particolare pacchetto è dovuto allo spoofing, nulla di buono arriverà da NATing.
Se supponiamo che si trattasse di un pacchetto SYN-ACK TCP e il router esegua di nuovo il NAT nonostante non abbia alcun senso, allora il SYN-ACK sarà inoltrato dall'ISP. SYN-ACK attiverà una risposta RST (supponendo che la destinazione sia funzionale), l'RST tornerà indietro attraverso entrambe le voci di tracciamento della connessione e verrà inoltrato all'host da cui è arrivato SYN-ACK e pulito la connessione.
Come puoi vedere, ci sono molti if in questo flusso. E c'è probabilmente qualche risultato possibile, che non ho considerato.