Quando esegui una scansione SYN contro una porta TCP aperta (non filtrata da Firewall), il server normalmente restituisce 3 pacchetti SYN + ACK.
Quindi, perché 3 di questo?
Il server di destinazione è una macchina Linux se pertinente a questa domanda e lo scanner in uso è NMAP.
Il normale TCP handshake a tre vie consiste in un SYN dal client al server, quindi un ACK + SYN dal server al client, quindi un ACK da client a server. Tuttavia, TCP è stato progettato per fornire un trasporto affidabile dei dati su un supporto che è non affidabile: i pacchetti IP stand-alone possono essere persi, danneggiati, duplicati o trasmessi fuori ordine. Ecco perché TCP è necessario in primo luogo.
Un server che ha ricevuto un SYN risponde con un ACK + SYN, quindi si aspetta un ACK come risposta. Tuttavia, il server è ben consapevole del fatto che i pacchetti possono andare persi, incluso il proprio ACK + SYN. Quindi il server invia ACK + SYN, quindi attende ... e se non riceve l'ACK finale dal client, il server presume che il suo ACK + SYN potrebbe essere stato perso, quindi lo emette nuovamente. E di nuovo. Fino a quando non viene ricevuto l'ACK dal client (che non si verifica quando il client non è un vero client, ma un port scanner che invia solo SYN), o il server perde interesse e si arrende.
Ogni determinato sistema operativo è responsabile per decidere quando, e quante volte, un SYN o SYN + ACK o ACK saranno ripetuti. Su un sistema Linux, vedi i file speciali in /proc/sys/net/ipv4/ chiamato tcp_syn_retries e tcp_synack_retries : contengono il numero di volte che il kernel emettere SYN (rispettivamente SYN + ACK) su un determinato tentativo di connessione quando è un client (rispettivamente server). Su un kernel 3.2.0, vedo che entrambi i file contengono "5", il che significa che un server soggetto a una scansione della porta emetterà cinque pacchetti SYN + ACK. Se osservi solo tre, allora forse il tuo server particolare è stato configurato in quel modo (questo è semplice come echo 3 > tcp_synack_retries ). O forse il server usa ancora il valore predefinito di 5, ma il tuo sistema di rilevamento non era abbastanza paziente: le ritrasmissioni successive utilizzano ritardi esponenziali, quindi gli ultimi tentativi possono richiedere un considerevole numero di secondi prima di essere ritrasmessi.
Si noti che, per poter ritrasmettere i pacchetti SYN + ACK, il server deve necessariamente allocare un po 'di RAM per quel tentativo di connessione, al fine di ricordare questo particolare proto-client e ritrasmettere il SYN + ACK. Abusare di questa allocazione è la base dell ' attacco SYN flood . L'abbassamento del numero massimo di ritrasmissione renderà il server più robusto contro tali attacchi. Nel caso estremo, i cookie SYN sono un modo per il server di non ricordare nulla; di conseguenza, quando un server utilizza i cookie SYN, risponderà con un solo SYN + ACK su un SYN in entrata. Poiché osservi che il server specifico che stai scansionando invia SYN + ACK diverse volte, hai dimostrato che questo server non utilizza i cookie SYN, ed è quindi potenzialmente vulnerabile alle inondazioni SYN.
Leggi altre domande sui tag tcp