¿Por qué el servidor está devolviendo 3 paquetes SYN + ACK durante una exploración SYN?

6

Cuando realiza una exploración SYN contra un puerto TCP abierto (no filtrado por Firewall), el servidor normalmente devuelve 3 paquetes SYN + ACK.

Entonces, ¿por qué 3 de eso?

El servidor de destino es una máquina Linux si está relacionada con esta pregunta, y el escáner en uso es NMAP.

    
pregunta daisy 20.04.2013 - 06:45
fuente

1 respuesta

13

El TCP normal consiste en un SYN de cliente a servidor, luego un ACK + SYN de servidor al cliente, luego un ACK del cliente al servidor. Sin embargo, TCP ha sido diseñado para proporcionar un transporte de datos confiable a través de un medio que no es confiable

Un servidor que ha recibido un SYN responde con un ACK + SYN, y luego espera un ACK como respuesta. Sin embargo, el servidor es consciente de que los paquetes pueden perderse, incluido su propio ACK + SYN. Entonces, el servidor envía el ACK + SYN, luego espera ... y si no recibe el ACK final del cliente, el servidor asume que su ACK + SYN podría haberse perdido, por lo que lo emite nuevamente. Y otra vez. Hasta que se reciba el ACK del cliente (que no sucederá cuando el cliente no sea un cliente verdadero, sino un escáner de puertos que solo envía SYN), o que el servidor pierda interés y se rinda.

Cada sistema operativo dado es responsable de decidir cuándo, y cuántas veces, se repetirá un SYN o SYN + ACK o ACK. En un sistema Linux, vea los archivos especiales en /proc/sys/net/ipv4/ llamados tcp_syn_retries y tcp_synack_retries : contienen la cantidad de veces que el kernel emitiría SYN (respectivamente SYN + ACK) en un intento de conexión dado cuando es un cliente (respectivamente servidor). En un kernel 3.2.0, veo que ambos archivos contienen "5", lo que significa que un servidor sujeto a una exploración de puertos emitirá cinco paquetes SYN + ACK. Si solo observa tres, entonces tal vez su servidor en particular fue configurado de esa manera (esto es tan simple como echo 3 > tcp_synack_retries ). O tal vez el servidor aún usa el valor predeterminado de 5, pero su sistema de detección no fue lo suficientemente paciente: las retransmisiones sucesivas utilizan retrasos exponenciales, por lo que los últimos reintentos pueden tomar una cantidad sustancial de segundos antes de ser retransmitidos.

Tenga en cuenta que, para poder retransmitir paquetes SYN + ACK, el servidor debe asignar necesariamente un poco de RAM a ese intento de conexión, para recordar este proto-cliente en particular y retransmitir el SYN. + ACK. Abusar de esta asignación es la base del ataque de inundación SYN . Reducir el número máximo de retransmisiones hará que el servidor sea más robusto contra tales ataques. En el caso extremo, las cookies SYN son una forma en que el servidor no recuerda nada; como consecuencia, cuando un servidor utiliza cookies SYN, responderá con un solo SYN + ACK en un SYN entrante. Dado que observa que el servidor en particular que está escaneando envía el SYN + ACK varias veces, ha demostrado que este servidor no emplea cookies SYN y, por lo tanto, es potencialmente vulnerable a las inundaciones de SYN.

    
respondido por el Thomas Pornin 20.04.2013 - 13:49
fuente

Lea otras preguntas en las etiquetas