Perché vedo un pacchetto RST, ACK invece di un pacchetto RST?

Guardando in Wireshark, vedo spesso TCP Streams terminare con un pacchetto RST, ACK anziché un pacchetto RST. Qualcuno sa perché questo è?

Un esempio di ciò che vedo:

SYN SYN, ACK ... dati ... RST, ACK

Wireshark non sta raccogliendo un pacchetto RST prima del pacchetto RST, ACK.

wireshark

— packetwrassler
fonte

Perché pensi che ci dovrebbe essere un segmento RST prima di RST / ACK? Forse potresti fornire un esempio di tale traccia di pacchetti?

— Gerben,

L'ACK ha trasportato sulle spalle l'RST nello stesso pacchetto?

— generalnetworkerror

Qualche risposta ti è stata d'aiuto? in tal caso, dovresti accettare la risposta in modo che la domanda non continui a comparire per sempre, alla ricerca di una risposta. In alternativa, potresti fornire e accettare la tua risposta.

— Ron Maupin

Ho ACK inviato richiesta \ fine connessione dati Fine connessione = RST

— motoko

Risposte:

Un RST / ACK non è un riconoscimento di un RST, come un SYN / ACK non è esattamente un riconoscimento di un SYN. L'istituzione TCP in realtà è un processo a quattro vie: l'avvio dell'host invia un SYN all'host ricevente, che invia un ACK per quel SYN. L'host ricevente invia un SYN all'host di avvio, che restituisce un ACK. Questo stabilisce una comunicazione stateful.

SYN --> 
    <-- ACK
    <-- SYN
ACK -->

Per renderlo più efficiente, l'host ricevente può ACK il SYN e inviare il proprio SYN nello stesso pacchetto, creando il processo a tre vie che siamo abituati a vedere.

SYN -->
    <-- SYN/ACK
ACK -->

Nel caso di un RST / ACK, il dispositivo riconosce tutti i dati inviati nei pacchetti precedenti nella sequenza con un ACK e quindi notifica al mittente che la connessione si è chiusa con l'RST. Il dispositivo sta semplicemente combinando i due pacchetti in uno, proprio come un SYN / ACK. Un RST / ACK di solito non è una risposta normale nella chiusura di una sessione TCP, ma non è necessariamente indicativo di un problema.

— Santino
fonte

Uno scenario di esempio per l'invio di RST / ACK è quando l'host ricevente non è in ascolto sulla porta TCP di destinazione.

— Indika K,

Si Certamente. Una volta ho provato a simulare un attacco DDoS (a scopo educativo;)) dalla macchina A a una macchina B sulla porta 80. Ma la porta 80 di B non è aperta. Quindi posso vedere la macchina B inviare un sacco di RST ACKrisposta all'indirizzo sorgente falso.

— smwikipedia,

La risposta RST / ACK può dipendere dal contenuto del pacchetto? Vale a dire il server riceve il pacchetto e poiché il contenuto del pacchetto corrispondeva a una condizione, la sessione veniva chiusa.

— skooog

Una volta stabilita la connessione, tutti i pacchetti devono avere ACK impostato e abbinare il numero progressivo dei pacchetti ricevuti per un trasporto / sicurezza affidabili. RST senza ACK non sarà accettato. Quando un lato invia RST, il socket viene chiuso immediatamente e anche il lato ricevente chiude il socket immediatamente dopo aver ricevuto RST valido. Non ha bisogno di essere e non può essere riconosciuto.

dopo l'handshake TCP

A ---> B Syn = x, Ack = y, len = z, Flag ACK

B ---> A Syn = y, Ack = x + z, len = o, Flag ACK

A ---> B Syn = x + z, Ack = y + o, len = p, Flag ACK

B ---> A Syn = y + o, ACK = x + z + p, len = q, RST, ACK Flag

B chiude il socket dopo aver inviato l'ultimo pacchetto e A chiude il socket dopo averlo ricevuto.

(non considerando la finestra TCP qui, oppure potrebbero esserci più pacchetti da un'estremità prima della conferma)

La bandiera ACK, il numero di riconoscimento e la procedura di riconoscimento sono correlati ma non sono la stessa cosa.

Secondo RFC793

RFC793

Numero di riconoscimento: 32 bit

If the ACK control bit is set this field contains the value of the
next sequence number the sender of the segment is expecting to
receive.  Once a connection is established this is always sent.

Ripristina elaborazione

In tutti gli stati tranne SYN-SENT, tutti i segmenti di ripristino (RST) vengono convalidati controllando i rispettivi campi SEQ. Un reset è valido se il suo numero di sequenza è nella finestra. Nello stato SYN-SENT (un RST ricevuto in risposta a un SYN iniziale), l'RST è accettabile se il campo ACK riconosce il SYN.

Il ricevitore di un RST lo convalida dapprima, quindi cambia stato. Se il ricevitore era nello stato ASCOLTA, lo ignora. Se il ricevitore si trovava nello stato SYN-RECEIVED ed era stato precedentemente nello stato LISTEN, il ricevitore ritorna allo stato LISTEN, altrimenti il ricevitore interrompe la connessione e passa allo stato CLOSED. Se il ricevitore si trovava in qualsiasi altro stato, interrompe la connessione e avvisa l'utente e passa allo stato CHIUSO.

— sdaffa23fdsf
fonte