
Utilicé nmap en mi servidor de destino que devuelve los siguientes servicios
PORT STATE SERVICE VERSION
53/tcp open domain?
80/tcp open http Microsoft IIS httpd 10.0
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2021-03-17 07:07:34Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap
443/tcp open https?
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap
3269/tcp open tcpwrapped
3389/tcp open ms-wbt-server Microsoft Terminal Services
La pregunta es cómo identificar el verdadero servicio que se ejecuta en un puerto que Nmap podría haber identificado erróneamente. Por ejemplo, en el puerto 53, ¿cómo puedo asegurarme a través de un terminal de que se está ejecutando un servicio DNS en él?
¿Qué técnica puedo utilizar? No tengo acceso al servidor de destino, por lo que no puedo ver los procesos que se ejecutan en el servidor.
Respuesta1
Como señala Steffen, la forma de saber si el servidor X se está ejecutando en el puerto Y del host Z es ejecutando un cliente que habla el mismo protocolo que X y apuntándolo al puerto Y del host Z. Por ejemplo, para probar si un Dado que el servidor habla DNS, puede utilizar cualquiera de los muchos clientes DNS, como nslookup
.
Por supuesto, esto no le dice nada sobre lo que realmente se está ejecutando allí, aparte de que es compatible con el protocolo que utilizó. El servidor puede ser casi cualquier cosa. Por ejemplo, el escucha en el puerto 80 (de su ejemplo) podría ser simplemente un pequeño script que simplemente responde a cualquier protocolo de enlace TCP con `HTTP 201 Sin contenido\r\nServidor: Microsoft IIS httpd 10.0\r\n\r\n" , que es aproximadamente una respuesta HTTP válida (aunque podría enviarla incluso si el cliente no envió una solicitud HTTP) pero no significa que el oyente sea en ningún sentido útil un servidor web, y mucho menos que sea específicamente IIS 10.0.
Los scripts de reconocimiento integrados de Nmap probablemente sean mejores que usted para reconocer la mayoría de los servidores, aunque también son muy inflexibles y pueden ser engañados fácilmente si alguien lo intenta. Un humano que esté familiarizado con las herramientas y protocolos en cuestión puede muy posiblemente extraer más información que los scripts en casos inusuales (como cuando un servidor se hace pasar por otro, o cuando un administrador ha ocultado deliberadamente los "indicadores" habituales que identifican un servidor según a Nmap). Sin embargo, impartir incluso los conceptos básicos de ese tipo de familiaridad en general está más allá del alcance de esta respuesta, o incluso de este sitio.