HTTP – Introducción

Hypertext Transfer Protocol (HTTP) es el protocolo de aplicación no orientado a la conexión mediante el cual se comunican navegadores y servidores web haciendo uso del intercambio de mensajes en texto plano. Se soporta en el protocolo TCP en la capa de Transporte.

Mensajes

Los mensajes HTTP viajan en texto plano y dependiendo de si el mensaje lo envía el cliente o el servidor pueden ser:

Request Message: Enviado desde el cliente web y tiene la siguiente estructura:

<method> <request-URL> <version>
<headers>
<entity-body>

Start Line

En la primera línea encontramos tres parámetros, el método (method) usado que puede ser GET, HEAD, PUT, entre otros que veremos más adelante, así como la ubicación (request-URL) del recurso solicitado al servidor y por último la versión de HTTP usada en la comunicación.

Cabeceras

Una cabecera es un par ordenado de nombre/valor separados por el símbolo “:”. Las cabeceras terminan en una obligatoria linea en blanco que da comienzo al cuerpo del mensaje.

Cuerpo del mensaje

Contiene el payload del protocolo HTTP, la información que se quiere transmitir, como por ejemplo cuando se usa el método POST.

No todas las peticiones cuentan con un cuerpo de mensaje, en el siguiente caso se usa el método GET y el mensaje fue generado cuando se intenta acceder a google desde el navegador Chromium en Debian GNU/Linux. El mensaje generado no contiene cuerpo (entity-boby) y se pueden ver diferentes tipo de cabeceras como: Host, Proxy-Connection, User-Agent entre otras que genera el navegador. (Listado completo de cabeceras HTTP).

GET http://google.com/ HTTP/1.1
Host: google.com
Proxy-Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17
Accept-Encoding: sdch
Accept-Language: es-419,es;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Response Message: Mensaje que surge desde el servidor web, respondiendo a una petición del cliente indicando el estado del recurso solicitado, tiene la siguiente estructura:

<version> <status-code> <reason-phrase>
<headers>
<entity-body>

Aquí solamente vemos nuevo los parámetros <status-code> y <reason-phrase>

Status code | Reason Phrase

Este código indica qué sucedió con nuestra  petición, se clasifican en cinco categorías: Informativos (100-199), Peticiones correctas (200-299), Redirecciones (300-399), Errores del cliente (400-499), Errores del servidor (500-599).  La reason-phrase es una pequeña frase que intenta describir de manera breve el status-code. (Listado de Status Code).

Métodos

No todos los navegadores implementan 100% el protocolo HTTP, para ser compatible con la versión 1.1 un servidor web debe implementar GET y HEAD, éstos métodos son denominados Safe methods ya que en teoría no deberían cambiar nada en el servidor, pero esto en realidad depende de los desarrolladores web.

GET

Es el método más utilizado, obtiene un documento (ya sean imágenes, archivos JavaScript, sonidos, etc) del servidor, la respuesta que se obtiene del servidor (código fuente del archivo) es interpretada por nuestro navegador.

GET /index.html HTTP/1.1
Host: http://www.ejemplo.com
Accept: *

En este caso una posible respuesta del servidor sería:

HTTP/1.1 200 OK
Content-type: text/html
Context-length: 621

<HTML>
<HEAD><TITLE>Página de ejemplo<TITLE>

En el caso anterior, se retornó un documento HTML y es muy común que en estos documentos los estilos de la página se guarden en archivos CSS para no mezclar código, de ser éste el caso, el navegador generará peticiones HTTP usando el método GET separadas para obtener dichos archivos del servidor. Lo mismo ocurre con las imágenes, archivos JavaScript y otro tipo de recursos que estén indicados en el HTML. Es decir, cuando escribimos la página web de nuestro interés en la barra de direcciones de nuestro navegador se desencadenarán una serie de peticiones (por lo general GET) al servidor web para construir de manera completa la página solicitada.

HEAD

Funciona igual que el método GET pero en este caso, el servidor no devuelve ningún cuerpo de mensaje. Gracias a la toda la información que brindan las cabeceras de la respuesta del servidor podemos usar este método para un sin número de motivos, por ejemplo: Determinar el tipo de recurso (Content-Type), verificar el tamaño del recurso (Content-Length) y en base a lo anterior tomar posibles decisiones. También verificar si el recurso solicitado existe observando el status code.

POST

Se usa para enviar información (input data) desde el cliente para que sea procesada por la aplicación. Cuando el mensaje utiliza el método POST sí debe contener el cuerpo de mensaje, ejemplo:

POST /script.php HTTP/1.1
Host: http://www.ejemplo.com
Content-type: text/plain
Context-length: 21

itemid=247

TRACE

En algunas ocasiones la petición debe pasar a través de diferentes dispositivos de red (firewall, proxy, etc) que pueden llegar a modificar la petición original y éste método permite al cliente observar la manera en que su petición llega al servidor, para poder determinar si la petición ha sido modificada. El servidor lo que hace es enviar de nuevo al cliente la petición que  recibió, es decir, el cuerpo del mensaje de respuesta de éste método es la petición completa que le llega al servidor:

Request Message:

TRACE /index.html HTTP/1.1
Accept: *
Host: http://www.ejemplo.com

Response Message

HTTP/1.1 200 OK
Content-type: text/plain
Content-length: 102
Via: 1.1 proxy.miempresa.com

TRACE /index.html HTTP/1.1
Host: http://www.ejemplo.com
Accept: *
Via: 1.1 proxy.miempresa.com

Como podemos  ver la petición al servidor ha llegado modificada, ya que se ha agregado la cabecera Via que generalmente agregan gateways y proxies.

OPTIONS

Con este método preguntamos al servidor web con qué métodos HTTP podemos comunicarnos. Los mensajes tanto del cliente como del servidor no contienen cuerpo del mensaje, el servidor responderá en la cabecera Allow los métodos HTTP permitidos separedos por coma:

OPTIONS * HTTP/1.1
Host: http://www.ejemplo.com
Accept: *

La respuesta puede ser:

HTTP/1.1 200 OK
Allow: GET, POST, OPTIONS, HEAD
Context-length: 0

PUT/DELETE

Por la naturaleza de estos métodos, no están disponibles en la mayoría de los servidores web, con ellos podríamos llevar o borrar archivos al servidor respectivamente, estos no nos interesan por el momento.

Lista completa de los métodos HTTP

Nmap Básico – Port Scanning III

UDP scan (-sU)

Escanear estos puertos puede ralentizar el escaneo de una manera dramática debido a la naturaleza de UDP. Si se recibe un paquete ICMP port unreachable quiere decir que el puerto está cerrado, debido a este comportamiento es que el rendimiento del escaneo puedo reducirse de manera notoria debido a varios factores:

  • Si no se recibe el paquete anterior, Nmap retransmitirá el paquete inicial para asegurarse que la respuesta no se perdió.
  • Inclusive cuando el puerto está cerrado y debería recibir el paquete ICMP, algunos sistemas limitan el envío de esta respuesta. En la documentación de Nmap nos colocan como ejemplo el kernel linux 2.4.20 que limita el envío de estas respuestas a 1 paquete por segundo.
  • Nmap detecta estos límites y reduce la velocidad de envío de paquetes UDP que terminarían siendo inútiles para nuestro propósito. Entonces si nos encontramos con el caso anterior y estamos escaneando los 65535 puertos UDP, nos demoraríamos poco más de 18 horas en terminarlo.

Cuando ocasionalmente se recibe una respuesta de algún servicio el puerto es clasificado como abierto, pero generalmente y debido a que la mayoría de servicios que utilizan UDP no envían respuestas un escaneo a un puerto UDP será catalogado como abierto/filtrado ya que se puede interpretar que el servicio está escuchando (y por eso no envía respuesta) o que algún dispositivo de red está haciendo drop a estos paquetes. Ejemplo:

# nmap -Pn -sU -p U:53,161,51000 --reason 192.168.1.254

 

Starting Nmap 6.01 ( http://nmap.org ) ...
Nmap scan report for 192.168.1.254
Host is up, received arp-response (0.0062s latency).
PORT      STATE         SERVICE REASON
53/udp    open|filtered domain  no-response
161/udp   open          snmp    udp-response
51000/udp closed        unknown port-unreach
MAC Address: ...

El ejemplo lo realicé con 3 puertos para mirar lo que explicaba anteriormente. El puerto 53 no recibe respuesta, el 161 recibe respuesta y con el puerto 51000 recibimos el paquete ICMP port unreachable.

IP protocol scan (-sO)

Este no es propiamente un escaneo de puerto, se usa para determinar que protocolos que usan IP (TCP, UDP, ICMP, etc) están soportados por el objetivo, la manera de indicarlos es usando los números asignados por IANA[1] [2]. Nmap hace esto cambiando entre cada paquete el número de protocolo en el correspondiente campo de la cabecera IP. Ejemplo:

nmap -Pn -sO -p 1,6,17,132 --reason 192.168.1.254
Starting Nmap 6.01 ( http://nmap.org ) ...
Nmap scan report for 192.168.1.254
Host is up, received arp-response (0.0058s latency).
PROTOCOL STATE         SERVICE REASON
1        open          icmp    port-unreach
6        open          tcp     proto-response
17       open          udp     port-unreach
132      open|filtered sctp    no-response
MAC Address: ...

Ya que no es un escaneo de puerto como tal, debemos analizar los resultados un poco diferente, en el reporte el open quiere decir que se encuentra implementado el protocolo (ICMP, TCP, UDP) y que no obtuvo respuesta del SCTP, y no puede determinar si está o no implementado (open|filtered). Cuando un protocolo no está soportado por el objetivo se recibe un paquete ICMP Protocol unreachablecon la excepción de ICMP ya que el recibir este paquete revela la presencia de éste en el objetivo.

Conclusiones

  • Los reportes de Nmap están basados en cómo ve la herramienta el puerto debido a dispositivos de red que alteran el resultado, pero puede no representar el estado real del puerto en el objetivo.
  • Solamente se puede usar un tipo de técnica de escaneo de puertos con la excepción de UDP scan, que puede ser usado con otras técnicas que hacen uso de TCP. Ejemplo
 # nmap -Pn -n -sS -sU -p T:80,21,443,U:53,68 --reason 192.168.1.254 

Se indica un escaneo TCP SYN scan para los puertos TCP 80, 21, 443 y se especifican los puertos UDP 53 y 68 para el UDP Scan. De esta manera obtenemos el informe para ambos tipos de puertos:

Starting Nmap 6.01 ( http://nmap.org ) ...
Nmap scan report for 192.168.1.254
Host is up, received arp-response (0.0040s latency).
PORT    STATE         SERVICE REASON
21/tcp  closed        ftp     reset
80/tcp  open          http    syn-ack
443/tcp open          https   syn-ack
53/udp  open|filtered domain  no-response
68/udp  open|filtered dhcpc   no-response
MAC Address: ...
  • Estos son las técnicas de Port Scanning básicas, pero Nmap cuenta con otras más avanzadas como lo son: TCP Window scan, TCP Null scan, TCP FIN scan, TCP Xmas scan, entre otras que no abordaremos en este momento.

Nmap Básico – Port Scanning II

TCP Connect Scan (-sT)

Es muy similar al escaneo TCP SYN pero se realiza un conexión TCP completa, además de que no se necesita tener privilegios de administrador. Ejemplo:

 # nmap -Pn -n -sT -p T:80 --reason 192.168.1.254 

Este tipo de escaneo es menos eficiente que el anterior ya que se necesitan más paquetes para obtener las misma información:

Starting Nmap 6.01 ( http://nmap.org ) ...
Nmap scan report for 192.168.1.254
Host is up, received user-set (0.0057s latency).
PORT   STATE SERVICE REASON
80/tcp open  http    syn-ack

Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds

Nmap reporta que el puerto está abierto ya que se ha recibido un paquete TCP SYN/ACK igual que sucedía con el método anterior, pero con la diferencia importante y como habíamos dicho antes, se realiza un conexión TCP completa como podemos ver en la captura de Wireshark:

1 0.000000   192.168.1.7     192.168.1.254   TCP   74   49933 > http [SYN] ...
2 0.005990   192.168.1.254   192.168.1.7     TCP   74   http > 49933 [SYN, ACK] ...
3 0.006057   192.168.1.7     192.168.1.254   TCP   66   49933 > http [ACK] ...
4 0.006197   192.168.1.7     192.168.1.254   TCP   66   49933 > http [RST, ACK] ...

En los paquetes 1,2,3 se realiza la conexión TCP completa para luego en el paquete 4 dar por terminada la conexión.

TCP ACK Scan (-sA)

Este tipo de escaneo es un poco diferente, se envía un paquete TCP ACK para buscar una respuesta TCP RST. Esto se hace para verificar que se puede llegar al puerto indicado en el objetivo, es decir, que el puerto no se encuentra filtrado por algún dispositivo de red a lo largo del camino. Debido a esto los puertos se clasifican únicamente como filtered/unfiltered, queriendo decir esto que se puede o no se puede llegar al puerto, pero  no se puede concluir si el puerto está abierto o cerrado . Ejemplo:

 # nmap -Pn -n -sA -p T:80 --reason 192.168.1.254 
1 0.019038   192.168.1.7     92.168.1.254   TCP  54   40758 > http [ACK] ...
2 0.021527   192.168.1.254   192.168.1.7    TCP  54   http > 40758 [RST] ...

Gracias al escaneo de la técnica anterior (TCP Connect Scan) sabemos que el puerto 80 se encuentra abierto, pero cuando verificamos con el TCP ACK Scan se clasifica como unfiltered, es decir que podemos llegar a el:

Starting Nmap 6.01 ( http://nmap.org ) ...
Nmap scan report for 192.168.1.254
Host is up, received arp-response (0.0048s latency).
PORT   STATE      SERVICE REASON
80/tcp unfiltered http    reset
MAC Address: ...

Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds

Custom TCP scan (–scanflags)

Aunque apenas estoy en el aprendizaje básico de Namp no sobra mencionar esta técnica que es más avanzada, con ella podemos generar los paquetes TCP con las flags que necesitemos activadas. Simplemente mencionaremos un ejemplo y mediante esta técnica vamos a realizar un TCP ACK Scan:

# nmap -Pn -n --scanflags ACK -p T:80 --reason 192.168.1.254
Starting Nmap 6.01 ...
Nmap scan report for 192.168.1.254
Host is up, received arp-response (0.0049s latency).
PORT   STATE  SERVICE REASON
80/tcp closed http    reset
MAC Address: ...

Nmap done: 1 IP address (1 host up) scanned in 0.17 seconds

Esta es una técnica que debemos usar con cuidado porque como podemor ver en el reporte de nmap nos dice que el puerto está cerrado y ya sabemos que esto es errado, esto sucedió porque se envió un paquete TCP ACK que como sabemos será respondido con un TCP RST, aquí lo importante es entender que Nmap está interpretando la respuesta como si se hubiera usado un TCP SYN Scan, técnica en la cual se reporta como cerrado un puerto si se recibe dicho paquete, para que el reporte sea adecuado a lo que queríamos realizar se le debe indicar que interprete el resultado como si se realizara un TCP ACK Scan, que era lo deseado.

# nmap -Pn -n -sA --scanflags ACK -p T:80 --reason 192.168.1.254
Starting Nmap 6.01 ( http://nmap.org ) ...
Nmap scan report for 192.168.1.254
Host is up, received arp-response (0.0051s latency).
PORT   STATE      SERVICE REASON
80/tcp unfiltered http    reset
MAC Address: ...

Nmap done: 1 IP address (1 host up) scanned in 0.28 seconds

Es importante resaltar que en este caso la opción -sA solamente cumple la función de indicar a Nmap cómo interpretar los resultados del escaneo, la generación del paquete está a cargo de la opción –scanflags y de las flags que le indiquemos.

Nmap Básico – Port Scanning I

Port Scanning

A continuación vamos a ver una serie de técnicas que funcionan con la misma lógica usada en la etapa de Host Discovery, pero a diferencia de dicha funcionalidad, en Port Scanning se usa para verificar el estado de los puertos, que como vamos a ver Nmap  divide los puertos es seis estados posibles:

Open: Cuando se detecta que alguna aplicación esta aceptando conexiones TCP, o recibiendo datagramas UDP se dice que el puerto está abierto.

Closed: El puerto está cerrado cuando se recibe un paquete TCP RST si escaneamos un puerto TCP o un paquete ICMP Destination Unreachable (Port unreachable) cuando escaneamos un puerto UDP. Hay que resaltar que a pesar de que en el destino no hay ninguna aplicación escuchando por dicho puerto, éste no se encuentra filtrado por ningún dispositivo de red siendo posible llegar al destino y segundo que gracias a este comportamiento (y a otros similares) se puede hacer ping con Nmap sin necesidad de hacer uso de peticiones ICMP Echo Request, como se hace de manera clásica, debido a esta última característica es común que un puerto que se encuetra cerrado NO se pueda alcanzar debido a que los paquetes dirigidos a dicho puerto son dropeados por algún dispositivo de red.

Filtered: Se clasifica un puerto de esta manera cuando Nmap no logra determinar si el puerto se encuentra abierto o cerrado ya que no se recibe ninguna respuesta por parte del objetivo, y puede suceder debido a configuraciones de algún dispositivo de red (o el mismo objetivo) que se encuentra a mitad de camino haciendo drop a los paquetes que envía Nmap.

Unfiltered: Aunque se puede llegar al destino, Nmap no puede determinar si el puerto está abierto o cerrado, solamente el Scan ACK reporta un puerto de esta manera

Open | Filtered: Aquí no se puede determinar si el puerto está abierto o filtrado, esto se puede dar entre otras posibilidades por la naturaleza del protocolo UDP.

Closed | Filtered: No se sabe si el puerto está cerrado o filtrado, solamente un IP ID idle scan clasifica un puerto de esta manera.

Tenemos que tener claro que el reporte de un Port Scanning quiere decir la manera en la cual Nmap ve el puerto y puede no representar el verdadero estado de éste, es decir, un Port Scanning se ve afectado por configuraciones de diferentes dispositivos de red como los son firewalls, routers, etc, pero depende de nuestra experiencia analizar correctamente los reportes de Nmap.

TCP SYN scan (-sS)

Es la opción por defecto si ejecutamos Nmap como el usuario root, intenta realizar media conexión TCP para determinar el estado del puerto TCP en cuestión, funciona de la siguiente manera: Se envía un paquete TCP SYN para iniciar una conexión al puerto indicado, si se recibe un paquete TCP SYN/ACK por parte del objetivo el puerto está abierto, si se recibe un TCP RST quiere decir que el puerto está cerrado, si no recibimos ningún tipo de respuesta durante un tiempo determinado y después de varios intentos el puerto se reporta como filtrado. TCP SYN Scan nunca termina la conexión TCP en caso que el puerto se encuentre abierto al recibir un paquete TCP SYN/ACK Nmap responderá con un paquete TCP RST terminando la conexión. Ejemplo:

# nmap -Pn -n -sS -p T:21,80 --reason 192.168.1.254 

Paso por paso:

-Pn Le indicamos a Nmap que no utilice ninguna técnica de Host Discovery; por defecto (en un análisis en el cual se realice Host Discovery/Port Scanning simultáneamente) Nmap  intenta verificar primero que el host se encuentre activo para luego realizar sobre el objetivo alguna técnica de Port Scanning, esto lo hace Nmap para agilizar todo el proceso ya que si se pasa como objetivo una red muy grande Nmap se ahorraría el envío de todos los paquetes en el Port Scanning a los host que no hayan respondido en la etapa de Host Discovery. En este caso como ya sabemos que el host se encuentra activo evitamos que se realice el Host Discovery para agilizar el escaneo. Como nos estamos moviendo en la red local, Nmap igual realizará el Ping ARP a menos que usemos el parámetro –send-ip.

-n Para no realizar resoluciones DNS inversas

-sS Aunque en este caso se indicó, no sería necesario porque es la técnica Port Scanning por defecto para el usuario root.

-p Con esto Nmap entenderá que vamos a indicar de manera específica los puertos a escanear

-T:21,80 Junto con la opción anterior indicamos que queremos escanear los puertos TCP 21 y 80. Si no se usaran estas opciones se intentaría escanear los 1000 puertos TCP más comunes.

–reason Esta opción nos brinda información adicional sobre el criterio que usó Nmap para generar los reportes.

Starting Nmap 6.01 ( http://nmap.org ) ...
Nmap scan report for 192.168.1.254
Host is up, received arp-response (0.0031s latency).
PORT   STATE  SERVICE REASON
21/tcp closed ftp     reset
80/tcp open   http    syn-ack
MAC Address: ...

Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds

Observando la linea 3 del reporte de Nmap, indica que el host está activo porque ha recibido una respuesta ARP (esta información es por el parámetro –reason). Lo relevante aquí son las lineas 5 y 6 que tiene el reporte concretamente sobre el Port Scanning, nos dice que el puerto TCP 21 se encuentra cerrado porque recibió un paquete TCP RST y el puerto TCP 80 se encuentra abierto porque recibió un paquete TCP SYN/ACK.

En la documentación de Nmap se indica además que se puede obtener dos reportes adicionales: El primero de un puerto clasificado como filtered si se recibe un paquete ICMP unreachable error (type 3, code 1, 2, 3, 9, 10, o 13). La segunda es un puerto clasificado como abierto si se recibe un paquete TCP SYN (sin el flag ACK activado) debido a una muy poco probable situación conocida como Split Handshale, de la cual no tenía conocimiento alguno. Por lo anterior es bueno tener el criterio que ha usado Nmap para clasificar los puertos (–reason), en las pruebas que he realizado no se ha presentado dichos reportes adicionales.

Nmap Básico – Host Discovery IV

Ping UDP (-PU)

Como su nombre lo indica hace uso del protocolo UDP para tratar de buscar algún tipo de respuesta en el destino, como ya sabemos este es un protocolo que no es orientado a la conexión, esto quiere decir que no envía acuses de recibo por cada paquete cuando se recibe en el destino, la única manera de que nos sea útil en este caso, es que el puerto al que estemos tratando de llegar este cerrado de manera que el objetivo nos envíe un paquete ICMP Destination unreachable (Port unreachable) revelando de esta manera su presencia den la red, ejemplo:

# nmap -sn -PU --send-ip -n  192.168.1.254

Las opciones anteriores se usan al igual que en los tipos de ping anteriores, para asegurar el comportamiento buscado de nmap, miremos ahora la captura de wireshark:

1 0.000000  192.168.1.6    192.168.1.254  UDP  42  Sour...  Destination port: 40125
2 0.001147  192.168.1.254  192.168.1.6    ICMP 70  Destination unreachable ...

Se puede observar que por defecto el paquete UDP se envía al puerto 40125, éste es un puerto alto en el cual es muy poco probable que algún sistema esté escuchando, mejorando las posibilidades de obtener el segundo paquete ICMP que nos revele la presencia del host destino en la red. Si el puerto está abierto el destino no enviará ninguna respuesta dada la naturaleza del protocolo UDP. Se pueden indicar otros puertos: -PU21,53,80.

Ping SCTP INIT (-PY)

SCTP es un protocolo relativamente nuevo de capa 4, nmap envía un paquete SCTP Init (primer paso del four-way-handshake) intentando así de establecer una asociación, si el puerto está cerrado se recibirá un paquete SCTP Abort, en caso de estar abierto se recibe un SCTP Init-ACK. Revelando en ambos casos la presencia del host en la red.

# nmap -sn -PY --send-ip -n  192.168.1.254
1 0.000000  192.168.1.6  192.168.1.254  SCTP  66  INIT
2 1.001028  192.168.1.6  192.168.1.254  SCTP  66  INIT

Aunque ya sebemos que el host destino se encuentra activo, no obtenemos ninguna respuesta de éste siendo no visible para nmap, esto sucede ya que mi router no está ni negando ni aprobando el intento de asociación, lo que nos puede llevar a pensar que mi precario router no tiene implementado en su stack de protocolos el SCTP.

Ping IP Protocol (-PO)

Con este tipo de ping indicamos que tipo de protocolo basado en IP queremos usar, recordemos que la cabecera de un paquete IP hay un campo que indica a que protocolo de capa superior se debe entregar el paquete, podemos encontrar una lista completa de los números de protocolos en la página de IANA. De tal modo que si usamos los números 1,6 correspondientes a ICMP, TCP respectivamente:

#nmap -sn -n -PO1,6 --send-ip 192.168.1.254 

nmap realizará dos tipos de ping, un Ping ICMP Echo (-PE) y un Ping ACK(-PA) descritos anteriormente, lo podemos comprobar con la captura:

1  0.000000000  192.168.1.6   192.168.1.254   ICMP  42  Echo (ping) request ...
2  0.000032000  192.168.1.6   192.168.1.254   TCP   54  62754 > 62754 [ACK] ...
3  0.003412000  192.168.1.254 192.168.1.6     ICMP  42  Echo (ping) reply ...
4  0.004111000  192.168.1.254 192.168.1.6     TCP   54  62754 > 62754 [RST] ...

Ya solo queda jugar con las diferentes combinaciones posibles. Recordar también que este tipo de ping sólo puede ser ejecutado como usuario root.

Conclusiones

Para terminar esta parte de Host Discovery unas cuantas conclusiones:

  • Si vamos a realizar un ping basado en IP (PS, PA, PE, PP, PM) y el objetivo está ubicado en nuestra misma red local, debemos  agregar la opción –send-ip para forzar que nmap no use el Ping ARP. Además usar –send-ip junto con -PR evitará que se envíen las peticiones ARP correspondientes y si no se usa otro tipo de técnica de descubrimiento no se enviará ningún paquete por parte de nmap, ejemplo:
# nmap -sn -n -PR --send-ip 192.168.1.254

De la anterior forma nmap no generará ningún paquete.

  • Dentro de nuestra red local el Ping ARP bastará para descubrir los host activos, por su rapidez y precisión, además: ¿Qué host no responde una petición ARP Request?
  • Creo que es mejor ejecutar siempre nmap como root para esperar siempre el comportamiento y los resultados esperados

Nmap Básico – Host Discovery III

Ping ACK (-PA)

Este técnica es similar al Ping SYN, con la diferencia que se envía al inicio un paquete TCP ACK, por lo que el host destino siempre deberá responder con un paquete RST, siendo esto suficiente para revelar la presencia del objetivo en la red, vamos a usar las mismas opciones que en el Ping SYN para asegurar que el comportamiento sea el esperado:

$ nmap -sn -PA --send-ip -n 192.168.1.254
1 0.000000  192.168.1.6      192.168.1.254  TCP  74  34408 > http [SYN] ...
2 0.008413  192.168.1.254    192.168.1.6    TCP  60  http > 34408 [SYN, ACK] ...
3 0.008445  192.168.1.6      192.168.1.254  TCP  54  34408 > http [ACK] ...
4 0.008500  192.168.1.6      192.168.1.254  TCP  54  34408 > http [RST, ACK] ...

Como se puede apreciar en la captura nmap no realizó la tarea esperada, ya que realizó un conexión TCP completa (paquetes 1,2,3) y por último terminó la conexión. Esto ocurrió por que un usuario sin privilegios como en el caso anterior no puede generar por si solo un paquete TCP ACK, esto sólo lo puede hacer el usuario root:

# nmap -sn -PA --send-ip -n 192.168.1.254
1 0.000000  192.168.1.6   192.168.1.254  TCP  54 45355 > http [ACK] ...
2 0.002604  192.168.1.254 192.168.1.6    TCP  60 http > 45355 [RST] ...

De esta manera obtenemos el comportamiento esperado del Ping ACK

Ping ARP (-PR)

Cuando estamos realizando el descubrimiento de red en nuestro mismo segmento de red, es recomendable que se use este tipo de ping ya que es el más rápido en esta situación.

$ nmap -sn -PR -n 192.168.1.254

Si ejecutamos la orden anterior no pasará nada porque la ejecutamos con un usuario sin privilegios y no podrá generar los paquetes ARP, por lo tanto la captura de paquetes con wireshark será vacía y el reporte de nmap será erróneo, ya que nos dirá que no encontró ningún host en la dirección indicada:

Starting Nmap 6.00 ( http://nmap.org ) at ...
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 0.00 seconds

Lo que tenemos que hacer entonces es ejecutar lo anterior como usuario root, de esta manera se produce el efecto buscado:

# nmap -sn -PR -n 192.168.1.254
Starting Nmap 6.00 ( http://nmap.org ) at ...
Nmap scan report for 192.168.1.254
Host is up (0.0046s latency).
MAC Address: ...
Nmap done: 1 IP address (1 host up) scanned in 0.12 seconds

Ahora el reporte nos dice que encontró el host objetivo, y la captura de nmap nos indica cómo ha funcionado el ping:

1 0.000000  ...  Broadcast  ARP  42  Who has 192.168.1.254?  Tell 192.168.1.6
2 0.004065  ...  ...        ARP  60  192.168.1.254 is at ...

Como este tipo de ping está basado en el protocolo ARP, lo que hace es una petición ARP Request mediante un mensaje Broadcast de capa 2 preguntando quien tiene la dirección IP indicada y el objetivo responde con una ARP Reply en la cual indica cual es su dirección MAC, con estos dos simples paquetes detectamos que el host objetivo está activo en la red.

Nota: Como hemos podido observar en varios ejemplos para sacarle mejor provecho a nmap es mejor ejecutarlo como el usuario root, los ejemplos de ahora en adelante serán ejecutados de esta manera. Recomiendo que ustedes mismos comparen las capturas y evidencien las diferencias del comportamiento de nmap al ejecutarlo como un usuario sin privilegios y como el usuario root.

Ping ICMP

Existen tres tipos de ping que hacen uso del protocolo ICMP:

Ping ICMP Echo (-PE)

De esta forma se hace la consulta clásica ICMP ping: nmap envía una petición ICMP Echo Request y espera un paquete ICMP Echo Reply.

# nmap -sn -PE --send-ip -n 192.168.1.254
1 0.000000  192.168.1.6     192.168.1.254  ICMP  42  Echo (ping) request ...
2 0.039843  192.168.1.254  192.168.1.6     ICMP  60  Echo (ping) reply   ...

Recordemos que en este caso tenemos que usar la opción –send-ip para buscar asegurar el comportamiento deseado, ya que de lo contrario nmap usaría el Ping ARP, por ser éste el ping por defecto cuando estamos haciendo un sondeo en el mismo segmento de red que nos encontramos.

Ping ICMP Timestamp(-PP)/Address Mask (-PM)

Aunque la solicitud de eco (Echo Request) es la consulta más utilizada de ICMP, nmap puede hacer uso de otras como los son ICMP Timestamp (type 13) la cual es un query timestamp, en donde el objetivo responderá con la hora del sistema (ICMP type 14).

# nmap -sn -PP --send-ip -n 192.168.1.254
Starting Nmap 6.00 ( http://nmap.org ) ...
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 2.09 seconds

El reporte de nmap nos dice que no ha encontrado ningún host activo, veamos por qué ha pasado esto:

1 0.000000  192.168.1.6  192.168.1.254  ICMP  54  Timestamp request...
2 1.001019  192.168.1.6  192.168.1.254  ICMP  54  Timestamp request...

La captura nos dice que nmap ha enviado dos peticiones ICMP Timestamp request, pero el destino no está respondiendo a estas haciendo que el dicho host sea invisible para nosotros ya que no se recibió ninguna repuesta. Ahora probemos la petición ICMP Address Mask Request (type 17), en la que el host destino responderá con su netmask (ICMP type 18).

# nmap -sn -PM --send-ip -n 192.168.1.254
1 0.000000  192.168.1.6  192.168.1.254  ICMP  46  Address mask request ...
2 1.001022  192.168.1.6  192.168.1.254  ICMP  46  Address mask request ...

Dichas peticiones tampoco están siendo respondidas por el objetivo, por lo que el reporte de nmap será negativo también de esta manera. Como podemos apreciar estos dos últimos nos serán muy acertados.

Nmap Básico – Host Discovery II (Ping SYN)

Ping SYN (-PS)

Con este ping hacemos uso de la negociación en tres pasos del establecimiento de conexión TCP,  recordemos que estamos en la fase de descubrimiento y no necesitamos que nmap nos realice un reporte de los puertos, no nos interesa saber si el puerto en cuestión está abierto o no, lo que buscamos es cualquier tipo de respuesta por parte del objetivo ya sea con un paquete TCP SYN/ACK (puerto abierto) o TCP RST/ACK(puerto cerrado) para verificar que está activo en la red, veamos un ejemplo:

$ nmap -sn -PS25 --send-ip -n 192.168.1.254

-sn Desactivamos el escaneo de puertos

-PS25 Hacemos uso del Ping SYN y le indicamos que intente realizar una conexión TCP la puerto 25 del objetivo, se pueden indicar más puertos separados por comas, ejemplo: -PS21,23,25,80,443

–send-ip Como nmap detecta que se está realizando un escaneo en la red local, por defecto intenta usar el Ping ARP, con esta opción obligamos a que se haga la operación mediante Ping SYN

-n Desactivamos las peticiones inversas DNS para que no se realice ningún tipo de Scan List

Con las opciones anteriores garantizamos el uso de Ping SYN para cualquier objetivo en nuestro segmento de red, cabe aclarar que si el objetivo estuviera fuera de nuestra red local, no necesitaríamos la opción –send-ip ya que obviamente no se podría llegar a el mediante el Ping ARP y nmap no intentaría usarlo por defecto en ese hipotético caso. Veamos la salida del ejemplo anterior:

1 0.000000  192.168.1.6   192.168.1.254  TCP  74  59602 > smtp [SYN] Seq=0 ...
2 0.021097  192.168.1.254 192.168.1.6    TCP  60  smtp > 59602 [RST, ACK] Seq=1 ...

Primero nmap envía al objetivo un paquete TCP SYN (primer paso de toda conexión TCP) al puerto 25, como en este caso se encuentra cerrado recibimos un paquete TCP RST negando cualquier intento de conexión al objetivo por este puerto, con este último paquete es suficiente para comprobar que el objetivo está activo en la red. veamos una captura haciendo lo mismo al puerto 80 (que se encuentra abierto):

$ nmap -sn -PS --send-ip -n 192.168.1.254
1 0.000000  192.168.1.6     192.168.1.254   TCP  74  60717 > http [SYN] Seq=0 ...
2 0.015076  192.168.1.254   192.168.1.6     TCP  60  http > 60717 [SYN, ACK] ..
3 0.015100  192.168.1.6     192.168.1.254  TCP  54  60717 > http [ACK] ...
4 0.015168  192.168.1.6     192.168.1.254  TCP  54  60717 > http [RST, ACK] ...

Como el puerto 80 es la opción por defecto de Ping SYN no hay necesidad de indicárselo. Se puede apreciar en la captura que se realiza una conexión TCP completa (SYN-SYN/ACK-ACK) y luego es terminada de nuestro lado con un paquete TCP RST. Si se hubiera hecho lo mismo pero con el usuario root el comportamiento sería diferente:

# nmap -sn -PS --send-ip -n 192.168.1.254
1 0.000000  192.168.1.6    192.168.1.254  TCP  58  37852 > http [SYN] ...
2 0.051149  192.168.1.254  192.168.1.6    TCP  60  http > 37852 [SYN, ACK] ...
3 0.051190  192.168.1.6    192.168.1.254  TCP  54  37852 > http [RST] ...

Cuando ejecutamos nmap como el usuario root, la herramienta tiene control total sobre los paquetes que puede generar, es así como se realiza media conexión TCP terminando la negociación (paquete 3) luego de recibir respuesta del objetivo (paquete 2) con el paquete TCP SYN/ACK, siendo de esta manera un poco más sigilosa nuestra actividad en la red.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.