Wireshark. Analizando eventos SMB / CIFS – NetBIOS. Parte 2.

Seguimos avanzando en el análisis de eventos SMB / CIFS y NETBIOS. Ya vimos en la primera parte de esta serie (Wireshark. Analizando eventos SMB / CIFS – NetBIOS. Parte 1.) algunos eventos SMB, a través de Wireshark, involucrados en una conexión de un host a otro para usar un  determinado recurso compartido. En el primer artículo nos centramos en la petición de resolución de nombre de host mediante Name query NB. En esta segunda parte la dedicaremos a la respuesta Name query response NB.

volvemos a la captura de la Parte 1 de la serie:

wireshark  smb cifs netbios analisis

Paquete 11. NAME QUERY RESPONSE NB 192.168.76.1  (00)

Comienza la sesión con una petición de de resolución de nombre de host mediante Name query NB CLIENTE Esto se hace usando NetBios mediante broadcast (192.168.1.255).

Responde 192.168.1.30 con Name query response NB 192.168.76.1

NOTA: Observad que aparcece la IP 192.168.76.1 en vez de 192.168.1.30 que sería lo lógico. Esto es así porque el host CLIENTE tiene otra interface de red (virtual) que corresponde a VMWare. De cualquier forma, vemos que la NIC física está indicada en la captura en la columna Source: (192.168.1.30)

Al igual que Name query NB, response también usa el puerto UDP 137:

wireshark name query response

Vemos muchas más diferencias respecto a Name query NB, vamos a verlas.

Antes que nada nos fijamos en el campo Transaction ID. (0x8022) que ya vimos que se refería a la identificación del proceso de resolución de nombre. Pues esta identificación es la misma (0x8022) tanto para Name query NB como para Name query response. Esto es así para indentifica un mismo proceso, proceso de petición y de respuesta. Paquetes 7 y 11.

Vamos ahora al resto de campos.

… antes que nada la referencia de la cabecera:

header o cabecera nombre servicio netbios

  • Opcode. código de tipo de paquete. Se divide a su vez en dos campos: Response (1) en este caso inica un Message is a response y Opcode propiamente dicho (0) que indica un query.
  • Flags (0x8500) :
    • Truncated (0). Indica no truncado. Para establecer si el contenido es mayor que 576 bytes.
    • Recursion desired (1) se encuentra activado e indica que se trata de un query o pregunta recurrente.
    • Broadcast (0) desactivado, indica que no es un paquete broadcas y no se usa.

Se añaden otros flags / campos que son los siguientes:

    • Authoritative (1).
    • Recursion available (0)
    • Reply code (0) ó RECODE Muestra un código con el resultado de la petición name query (paquete 7de la captura wireshark). En este caso (0) indicando No error. Otros códigos son:
  • 0 indica que no hay error
  • 1 error de formato
  • 2 error de servidor
  • 3 error de nombre
  • 4 solicitud no compatible.
  • 5 por politicas de servidor, denegación de respuesta.
  • 6 Active error.
  • 7 error de nombre. Conflico.

Seguimos:

  • QUESTION ENTRIES ó Questions. (0) Número entero que indica en número de entradas coincidente con una pregunta por nombre. En este caso 0. Se trata de una respuesta.
  • ANCOUNT ó Answer RRs (1). Indica número de recursos o registros que se tratan de una respuesta.
  • NSCOUNT ó Authority RRs (0). Número de registros de la sección authority de Name Serivce packet
  • ARCOUNT ó Additional RRs. (0) Número indicando recursos adicionales.

El siguiente campo tratándose de un paquete Name query response NB, se llama Answers, al contratio de Queries, que veíamos en el capítulo anterior para un paquete Name query NB.

Este campo contiene la respuesta a la petición del Name query NB. REsponde con el nombre de host y su IP. Aquí vemos 3 IPs que corresponden a las tres interfaces de red: 2 VMWare y una física 192.168.1.30:

wireshark. Campo answer netbios con b-node.

Básicamente y de forma sencilla. En el procedimiento de resolución del nombres, que se basan en broadcast, en servidor o en ambos, se pueden usar:

  • broadcast a la red,
  • usando NETBIOS: NBNS ó WINS (sistemas Windows).

por ello, cada host se puede configurar:

  • solo usando broadcast
  • solo NBNS
  • primero broadcast y seguidamente NBNS en el  caso de no respuesta al broadcast.
  • lo contrario de lo anterior. Primero NBNS y en caso de no respuesta broadcasting.

Eso lo vemos en nuestra captura en los campos:

  • b-node (00). cuando solo se usa broadcast a la red
  • p-node (01). cuando solo se usa NBNS
  • m-node (10). cuando se usa primero broadcast y en caso de no obtenerr respuesta se usa NBNS.
  • h-node (11). cuando primero se realiza mediante NBNS y en caso de no respuesta broadcasting.

Vemos en nuestra captura que las 3 respuestas obtenidas para las tres IPs, se realizan bajo b-node (00) o broadcast a la red.

Apreciamos también otras informaciones como TTL (Time To Live), Type NB (Servicios de nombres de NETBIOS), Class (Resource Record Class), en este caso Internet Class.
———————————–

En el siguiente capítulo veremos los siguientes paquetes correspondientes a ICMP Echo request y Echo reply para  obtención de la dirección MAC, el establecimiento de conexión con el recurso, ngoaciación del protocolo Request y Response (SMB), etc.

Esta entrada fue publicada en Seguridad y redes, Wireshark . Tshark y etiquetada , , , , , , , , . Guarda el enlace permanente.

2 respuestas a Wireshark. Analizando eventos SMB / CIFS – NetBIOS. Parte 2.

  1. Pingback: Wireshark. Analizando eventos SMB / CIFS – NetBIOS. Parte 6. Comandos Tans2. | Seguridad y Redes

  2. Pingback: Wireshark. Analizando eventos SMB / CIFS – NetBIOS. Parte 5. | Seguridad y Redes

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s