Nmap informa que casi todos los puertos están abiertos

Lo más probable es que esté golpeando un dispositivo IDS / IPS bien configurado.

snort puede detectar fácilmente el escaneo de su puerto en progreso con el sfPortscan filter (el -sS es prácticamente una firma de" portscan in progress "), y además de registrar su ataque, puede configurarse para realizar una respuesta activa . Estas respuestas pueden ser tan simples como enviarle un RST, o tan rico como la regla " reaccionar ". El comportamiento predeterminado de la respuesta "reaccionar" es responder con un mensaje HTTP 403 Forbidden , pero también pueden configurarlo para enviar cualquier dato arbitrario que se desee. El comportamiento de reacción no se limita a las solicitudes del puerto 80, tampoco. snort enviará la respuesta independientemente del número de puerto .

Para probar esta teoría, mientras realiza un escaneo de puertos del objetivo, desde la misma máquina que realiza el escaneo, intente abrir cualquier puerto antiguo en ese objetivo con un navegador o netcat. Si recibe la respuesta prohibida de HTTP 403 de un puerto no HTTP, es probable que eso esté sucediendo.

Supongo que nmap no interpreta la respuesta, solo informa que se estableció la conexión de socket, por lo tanto, le informa a usted como un puerto abierto. Sin embargo, en lugar de adivinar, puedes configurar la opción --packet-trace en nmap para ver lo que realmente estás recuperando.

Puede leer el manual de snort aquí .

Tienes algunas opciones. Mi primer pensamiento sería que podría haber un sistema intermedio que responda con paquetes SYN / ACK a puertos prohibidos (con cortafuegos). Si este es el caso, puede distinguir los puertos verdaderamente abiertos por el TTL de la respuesta. Si guardó el salida XML de su escaneo ( -oX o -oA ), Puede comprobar el atributo //port/state/@reason_ttl . Esto es similar a la técnica de "firewalking". Puede encontrar información relacionada aquí: Firewalking with nmap .

Otra alternativa sería utilizar un tipo de escaneo diferente . El escaneo SYN de Nmap ( -sS o predeterminado al escanear como root) puede ser detectado por las opciones de TCP, MSS y tamaño de la ventana, por lo que una IDS / IPS podría responder a eso. Intente usar el escaneo TCP Connect ( -sT ) en su lugar. Se pueden usar otros tipos de escaneo (ACK, FIN, Maimon, etc.) para filtrar sus resultados; no mostrarán los puertos abiertos por sí mismos, pero podrían marcar algunos de estos puertos "abiertos" como cortafuegos, o al menos mostrar que se comportan de manera diferente. Sin embargo, tenga cuidado aquí, ya que estos envían paquetes "malos" muy notables y confían en comportamientos que a menudo no están presentes en los sistemas operativos modernos.

Finalmente, puede usar detección de versión de servicio de Nmap ( -sV ) para identificar los servicios que están detrás. Los puertos "abiertos". Es probable que los falsos positivos simplemente agoten el tiempo de espera o envíen un RST para cerrar la conexión poco después de abrirla. Esto ralentizará mucho su escaneo, pero a veces es importante ser preciso. Recomendaría comenzar con --version-intensity 0 , que simplemente hará una captura de banner y posiblemente cualquier sonda que esté etiquetada en el puerto específico que se está escaneando, en lugar de la predeterminada, que hace esto y hasta otras 8 pruebas.

Existe una técnica de ofuscación en la que un servidor simula la apertura de casi todos los puertos, lo que idealmente simula una firma de servicio válida en la mayoría de estos puertos.

Portspoof , por ejemplo, implementa este enfoque y maneja más de 8000 firmas de servicio.

Me ha pasado lo mismo. Fue Snort causándolo. Agregar los cambios -f y --badsum a nmap me permitió pasar el IDS / IPS. El comando completo era el siguiente:

nmap -sS -p 1-65535 -f --badsum -vv -Pn -oA target_nmap target

En el pasado ocurrieron cosas extrañas con el nmap cuando intento escanear demasiado rápido y, después de todo, se define -T4 como "agresivo". Intente cambiar la velocidad de escaneo a 3 y vea si obtiene los mismos resultados.

También es posible que se encuentre con errores de SO o nmap o problemas de interoperabilidad de algún tipo. Si tiene otro sistema, intente ejecutarlo y vea si obtiene el mismo resultado.

Puede haber alguna tecnología de firewall que esté alterando su tráfico, vea si puede eliminar cualquier cosa en el camino.

Podría haber una serie de cosas sucediendo aquí.

John mencionó que el snort u otro tipo de IDS / IPS es un peligro potencial que está detectando su análisis de sincronización. Puede intentar cambiar de -sS a -sT y especificar un período de tiempo de espera antes de intentar escanear otro puerto. Sfportscan está controlado por el tiempo, si está habilitado. (Fuente: ex empleado de Sourcefire)

Otras posibilidades incluyen firewalls de inspección con estado. He visto casos en los que si hay un dispositivo de firewall / NAT / filtro entre usted y su objetivo de escaneo, el firewall puede devolver un SYN / ACK, cuando de hecho el puerto a su destino real puede no ser accesible. Nuevamente, intente un escaneo -sT y el tono de cuántos puertos está intentando escanear a la vez.

La advertencia de usar -sT en lugar de -sS u otros tipos de escaneo es que, si un servicio está escuchando en un puerto, y si obtiene una respuesta, es muy probable que termine de iniciar sesión. Para ver un ejemplo de esto, lance un escaneo -sT a cualquier demonio ssh y luego verifique / var / log / secure.

Me enfrenté al mismo problema que tú. En mi caso, el IDS / IPS enviaría un SYN, ACK para todos los puertos, lo que provocó que nmap concluyera que todos los puertos estaban abiertos.

Sin embargo, aunque los paquetes deben retransmitirse cuando no se reconocen de acuerdo con la especificación de TCP , IDS / IPS NO retransmitió ningún paquete que no fue reconocido (lo cual es el caso en un escaneo TCP SYN),.

Por lo tanto, pude distinguir los puertos abiertos de los inaccesibles al mirar los paquetes retransmitidos en wirehark. Si un SYN, ACK se retransmitía, significaba que el puerto estaba abierto.

El filtro de wirehark que puedes usar para esto es:

 tcp.analysis.retransmission