Nella sicurezza della rete, perché ci interessa sapere sessioni di handshake TCP incomplete? C'è una implicita sicurezza dietro questo?
Rispondi: inviando intenzionalmente le varie parti dell'handshake a 3 vie - a volte in ordine, a volte no & altre volte con set di flag aggiuntivi: un utente malintenzionato può eseguire la scansione di un IP e di una porta e determinare se quella particolare porta è aperta o chiusa.
Ci interessa sapere sapere che ciò sta accadendo perché si tratta di un utente malintenzionato che acquisisce informazioni sulla tua rete. Tuttavia la maggior parte delle volte non viene creata una voce di registro per le comunicazioni TCP fino al completamento dell'handshake, quindi se è stato interrotto da qualche parte, allora un log potrebbe non essere creato e un utente malintenzionato passare inosservato.
Spiegato: durante la scansione di un intervallo IP per mappare una rete, esistono diversi tipi di scansioni. Sono diversi in base a come inizializzano l'handshake - alcuni non li inizializzano nemmeno. La risposta fornita dalla destinazione indica se la porta specificata è aperta o chiusa, in base al ragionamento deduttivo.
Full Scan The scanner sends a standard SYN request with a port number. The type of response indicates whether the port is open. If a 'reset' request is received in response to the scan, the attacker knows the port is closed.
Half-Open Scan / Stealth Scan (see Vulnerability description at link)
The attacker sends the initial SYN and watches for a SYN/ACK request, however rather than sending the final ACK, sends a RST (reset) which interupts the connection part way. In this scan the information the device sends back is still used to decide if a port is open, but by terminating the connection part-way is avoiding a lot of logging that would make the attack obvious to an administrator.Xmas Tree Scans
Attacker sends a FIN/URG/PUSH and waits to hear back. RST indicates a port closed, whereas receiving no information back indicates the port is open. Requires that the target machine is compliant with RFC 793 which eliminates Windows machines as possible targets.FIN Scan
Attacker simply sends a FIN to mimic terminating a connection. If the machine doesn't know how to respond and gives none, then the port is open. If the machine sends a RST/ACK then the port is closed. Again, doesn't work for Windows.NULL Scan
Attacker sends a TCP packet with NO FLAG, which is known as NULL. It's sending nothing at all. If no response is received then the port is open. If a RST/ACK is received then port is closed. This only works on Unix based systems.Note: Above explanations are taken from the Ethical Hacking course on Pluralsight by Dale Meredith. I've provided small summaries. However because Pluralsight is behind a pay-wall I've provided URLs to other explanations of each scan.
Tutte le scansioni di cui sopra possono essere automatizzate su un intervallo IP utilizzando strumenti come Nmap. Alcuni di essi sono tuttavia particolarmente rumorosi (Full Scan) e renderà molto ovvio che qualcuno stia effettuando la scansione del sistema. Ad ogni modo, usando l'handshake TCP in un modo che non era inteso (la maggior parte delle volte) un utente malintenzionato può elaborare porte aperte e iniziare a individuare le vulnerabilità in quel sistema.
Molti scanner utilizzati per rilevare le porte aperte utilizzano handshake TCP incomplete o errate. A volte vengono utilizzati anche negli attacchi DDOS, ma se fosse vero avresti 100 a 1000 secondi al secondo.
Sono disponibili scansioni SYN, scansioni natalizie e altro. Stanno facendo forme di ricognizione sui tuoi indirizzi IP.
Vengo scansionato tutto il tempo, ad esempio 100+ al giorno.
Ci sono un paio di possibili risposte a questo - a seconda del contesto della tua domanda:
a. Un dispositivo invia un pacchetto SYN per chiedere / inferire se il dispositivo ricevente è aperto per una nuova connessione. b. Una volta che un dispositivo ricevente riceve un pacchetto SYN dal client, risponde e restituisce una ricevuta di conferma nota come pacchetto SYN / ACK per indicare che ha impostato correttamente una connessione in grado di ricevere pacchetti aggiuntivi. c. Infine, il dispositivo di origine segnala la sua accettazione della risposta SYN / ACK e segnala la sua intenzione di inviare più pacchetti inviando un pacchetto ACK.
Se i due dispositivi collegati rilevano che una parte dell'handshake non è stata completata, è possibile dedurre un'informazione sullo stato della connessione. Ad esempio, se il dispositivo di avvio non riceve SYN / ACK, è possibile dedurre che il dispositivo ricevente ha fallito nel tentativo di stabilire risorse per una connessione.
Quindi sostanzialmente entrambi i dispositivi indicano che la connessione non è stata stabilita correttamente.
Cosa succede quando un singolo IP invia un numero di pacchetti SYN / ACK o ACK a IP per i quali non è stato visto per la prima volta nessun pacchetto SYN? Potrebbe trattarsi di un utente malintenzionato che rileva la funzionalità del firewall poiché un pacchetto SYN / ACK è "supponiamo" di seguire un pacchetto SYN.
L'abuso della normale stretta di mano con l'invio di pacchetti inaspettati suggerisce qualcosa di fuori dalla norma.
Per rispondere a questa domanda: l'analisi di handshake TCP incompleti rivela molto di ciò che accade sulla rete in situazioni non normali tra due host.
Perché lo stesso handshake TCP incompleto è un'implicazione della vulnerabilità nel protcol. Può quindi essere sfruttato per ingannare una porta per rivelare informazioni su se stesso.
Leggi altre domande sui tag tcp network information-gathering penetration-test vulnerability-scanners