Server Web che risponde a una richiesta HTTP da un indirizzo IP falsificato

0

Ipoteticamente parlando - se il mio server Web riceve una richiesta http per un determinato file, ad esempio default.html, e diciamo che l'indirizzo IP richiesto è stato falsificato, cosa succede quando il mio server risponde alla richiesta? Manderebbe il file all'indirizzo (falso) IP? I dati in uscita sarebbero caduti da qualche parte lungo la strada? Il mio server otterrebbe un feedback che l'IP di destinazione non vuole i dati o non c'è mai stata alcuna connessione aperta all'IP di destinazione?

Per estendere ulteriormente questo aspetto, diciamo che il file è molto grande, diciamo 5 o 50 mb. Se il mio server riporta (nei registri) che il numero di byte trasferiti all'IP richiedente è effettivamente 5 o 50 mb, e che il trasferimento è avvenuto senza errori, allora posso concludere che l'IP richiedente non è stato falsificato ed era legittimo ?

Noterò che alcuni (o la maggior parte) aspetti della mia domanda sembrano essere stati affrontati in questo thread:

E 'possibile inviare pacchetti HTTP tramite IP falsificato?

Ma sembra che ci siano informazioni contrastanti in quel thread. Alcune persone dicono di no, non è possibile falsificare una richiesta http, mentre altri dicono "Se è possibile adattare la richiesta in un singolo pacchetto TCP, è possibile".

L'ultimo commento in quel thread dice flat-out, "È possibile falsificare l'IP di destinazione, quindi quando il server invia il payload TCP / IP, passa all'IP SPOOF e non al computer".

Quindi non mi è chiaro se l'indirizzo IP spoofed sarebbe esposto a qualsiasi traffico (o almeno una risposta syn-ack) come risultato della richiesta http falsa / falsificata sul mio server. E ancora, se i registri del mio server indicano che il 100% del file richiesto è stato trasferito senza errori, anche se fosse un file di grandi dimensioni, ciò potrebbe accadere solo se l'IP richiedente era legittimo (non falsificato)?

==============

La risposta proposta ( Is è possibile passare l'handshake TCP con un indirizzo IP falsificato? ) risponde alla domanda con un sì e un no. Nello specifico, ecco la parte di quella risposta che sembra dire "sì, si può fare, almeno per una breve transazione":

============

A meno che non sia disponibile il routing di origine o l'accesso a un router nel percorso di rete, questa non è una configurazione sostenibile. Il client può essere in grado di indovinare l'ISN, ma i numeri di sequenza successivi vengono incrementati dalla dimensione dei pacchetti inviati, che l'utente malintenzionato non vedrà e non può prevedere in modo affidabile. Quindi dovrebbero essere in grado di ottenere almeno un pacchetto dopo l'handshake a tre vie, ma non una conversazione. E a volte un pacchetto è sufficiente.

=============

Voglio solo sapere se è possibile che il mio server risponda alla richiesta http a un IP falsificato inviando il file richiesto e la registrazione della richiesta sia stata eseguita senza errori. Nelle condizioni in cui nessuna delle mie apparecchiature di rete (modem, router, ecc.) È compromessa e il file richiesto è piccolo (inferiore a 10kb) e non ci sono ulteriori richieste o transazioni come parte della sessione. Se la risposta è probabilistica (cioè - può succedere ma c'è qualche elemento di probabilità) allora andrò oltre e chiederò se c'è un modo in cui può accadere ogni momento in cui viene tentata (ma con l'IP spoofato che cambia tra i tentativi).

    
posta Peggy Schafer 29.01.2018 - 15:51
fonte

1 risposta

1

Di solito è molto difficile spoofing TCP, che è il protocollo sottostante di HTTP (quando si ignora QUIC, che ha la sua propria protezione spoofing). Ma non è impossibile e potrebbe essere più semplice in alcune configurazioni: vedi questo link sullo spoofing della connessione TCP cieco rapido fornito da ximaera per ulteriori informazioni .

Tuttavia, nel caso in cui l'aggressore riesca a stabilire con successo una connessione TCP con un IP di origine falsificato, il server invierà la sua risposta alla sorgente (spoofed) dichiarata della connessione. Poiché non esiste un'associazione corrispondente alla destinazione dichiarata, i pacchetti inviati dal server generano un RST dall'obiettivo falso o semplicemente andranno persi. Poiché TCP si basa su ACK dal peer (ovvero, il client HTTP in questo caso) per segnalare che ha ricevuto alcuni dati e questo ACK non viene inviato, il server si renderà conto che la connessione è interrotta. E mentre QUIC è un protocollo diverso da TCP, i risultati saranno simili.

    
risposta data 29.01.2018 - 17:20
fonte

Leggi altre domande sui tag