Comenzamos aquí lo que será la primera parte de Herramientas para la interpretación de capturas de red que dedicaremos a Windump (Windows), y TCPDump para sistemas basados en GNU/Linux-UNIX. Hablaremos de los dos indistíntamente.
El propósito de Windump / TCPDump es la captura y análisis del tráfico de red. Es un sniffer. Aquí teneís información sobre detección de sniffers: Detectando Sniffers en nuestra red. Redes conmutadas y no conmutadas.
Estan basados en la librería de captura de paquetes Pcap / Winpcap. Estas dos librerías son usadas por otras herramientas como Ethereal o Snort, e incluyen un lenguaje de filtros común para todos. Quizás, como ya hablamos en la introducción, Windump/TCPDump no sea la herramienta perfecta atendiendo a la interpretación fácil de los datos reportados, pero sí que es de las mejores en cuanto a su potencia y flexibilidad. Veremos el uso de estas herramientas desde un enfoque lo más práctico posible.
Enlaces para descarga de TCPDump y Windump:
- Linux: http://www.tcpdump.org/
- Windows: Winpcap (http://www.winpcap.org/windump/) Windump (http://www.winpcap.org/windump/)
Una vez instalada la librería y el programa en sí, tan sólo debemos de introducir en la línea de comandos (haremos referencia a Windump, para Windows, aunque casi todo es válido para su versión GNU/Linux).
Comenzando.
Antes que nada tendremos que averiguar cuales son las interfaces de red de que disponemos y, de ellas, cual vamos a usar:
root@bt:~# tcpdump -D
1.eth0
2.usbmon1 (USB bus number 1)
3.usbmon2 (USB bus number 2)
4.any (Pseudo-device that captures on all interfaces)
5.lo
Las opciones básicas para comenzar a usar son las siguientes:
-i(interface) interface que vamos ausar para la captura
-n no resolver los nombres de host
-v -vv cantidad de información que nos devuelve
-t elimina marcas de tiempo.
-q estableceremos el indicador de salida rápida que hará que nos devuelva menos información y que las líneas sean más cortas. Se puede combinar con -v y -vv
Vemos estas opciones iniciales con un ejemplo:
root@bt:~# tcpdump -i1 -qtn
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
02:01:00:00:00:00 > ff:ff:ff:ff:ff:ff, Unknown Ethertype (0x886f), length 66:
arp who-has 192.168.1.200 tell 192.168.1.250
arp who-has 192.168.1.200 tell 192.168.1.250
arp who-has 192.168.1.200 tell 192.168.1.250
arp who-has 192.168.1.200 tell 192.168.1.250
IP 192.168.1.5.3351 > 204.13.8.76.80: tcp 0
IP 204.13.8.76.80 > 192.168.1.5.3351: tcp 0
IP 192.168.1.5.3351 > 204.13.8.76.80: tcp 0
IP 192.168.1.5.3351 > 204.13.8.76.80: tcp 671
IP 204.13.8.76.80 > 192.168.1.5.3351: tcp 0
IP 204.13.8.76.80 > 192.168.1.5.3351: tcp 370
IP 204.13.8.76.80 > 192.168.1.5.3351: tcp 20
IP 192.168.1.5.3351 > 204.13.8.76.80: tcp 0
IP 192.168.1.5.3351 > 204.13.8.76.80: tcp 0
Si queremos añadir más información a la salida, usarmos -v o -vv:
root@bt:~# tcpdump -i1 -qtnvv
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
arp who-has 192.168.1.200 tell 192.168.1.250
arp who-has 192.168.1.200 tell 192.168.1.250
arp who-has 192.168.1.200 tell 192.168.1.250
arp who-has 192.168.1.200 tell 192.168.1.250
arp who-has 192.168.1.200 tell 192.168.1.250
02:01:00:00:00:00 > ff:ff:ff:ff:ff:ff, Unknown Ethertype (0x886f), length 66:
IP (tos 0x0, ttl 128, id 41547, offset 0, flags [none], proto UDP (17), length 229) 192.168.1.245.138 >
192.168.1.255.138: UDP, length 201
arp who-has 192.168.1.200 tell 192.168.1.250
arp who-has 192.168.1.200 tell 192.168.1.250
IP (tos 0x0, ttl 128, id 59341, offset 0, flags [DF], proto TCP (6), length 48) 192.168.1.5.3353 >
204.13.8.76.80: tcp 0
IP (tos 0x0, ttl 128, id 41576, offset 0, flags [none], proto TCP (6), length 48) 204.13.8.76.80 >
192.168.1.5.3353: tcp 0
IP (tos 0x0, ttl 128, id 59342, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.5.3353 >
204.13.8.76.80: tcp 0
IP (tos 0x0, ttl 128, id 59343, offset 0, flags [DF], proto TCP (6), length 710) 192.168.1.5.3353 >
204.13.8.76.80: tcp 670
IP (tos 0x0, ttl 128, id 41581, offset 0, flags [none], proto TCP (6), length 40) 204.13.8.76.80 >
192.168.1.5.3353: t
IP (tos 0x0, ttl 128, id 41584, offset 0, flags [none], proto TCP (6), length 410) 204.13.8.76.80 >
192.168.1.5.3353: tcp 370
IP (tos 0x0, ttl 128, id 41585, offset 0, flags [none], proto TCP (6), length 60) 204.13.8.76.80 >
192.168.1.5.3353: tcp 20
IP (tos 0x0, ttl 128, id 59344, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.5.3353 >
204.13.8.76.80: tcp 0
IP (tos 0x0, ttl 128, id 59355, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.5.3353 >
204.13.8.76.80: tcp 0
IP (tos 0x0, ttl 128, id 41588, offset 0, flags [none], proto TCP (6), length 40) 204.13.8.76.80 >
192.168.1.5.3353: tcp 0
Como veis en el ejemplo anterior, se añade información de campos de protocolo.
El formato de Salida.
Llegado a este punto vamos a ver como interptetar la salida. Esta interpretación depende del protocolo. En principio veremos los dos más importantes: TCP y UDP.
TCP:
El formato de salida de datos para el protocolo TCP sería:
fecha src > dst: flags data-seqno ack window urgent options
- fecha nos da la hora en que se produjo el evento en formatohora:minutos:segundos.microsegundos o milisegundos. Depende su aparición de la opción -t
- src y dst son las direcciones IP y puertos TCP/UDP de las conexiones origen y destino.
- > dirección de flujo de los datos
- flags son una combinación de los posibles banderas de un segmento/datagrama TCP/UDP: S (SYN), F (FIN), P (PUSH), R (RST) y «.» (no hay flags).
- data-sqno describe el número de secuencia de la porción de datos.
- ack es el número de secuencia del próximo byte que espera recibir el otro extremo TCP/UDP.
- window es el tamaño de la ventana que advierte el receptor al transmisor.
- urgent indica que hay datos urgentes en ese segmento/datagrama.
- options son las opciones TCP que suelen estar entre corchetes del tipo < >, por ejemplo el tamaño máximo del segmento.
Lo vemos con dos ejemplos:
04:11:50.046117 IP 91.121.18.72.80 > 192.168.1.100.43488: . 29327:30775(1448) ack 1181 win 64355 <nop,nop,timestamp 31733863 2551340> 04:11:50.048238 IP 91.121.18.72.80 > 192.168.1.100.43488: P 30775:31374(599) ack 1181 win 64355 <nop,nop,timestamp 31733863 2551340>
Analizamos el primero:
Fecha: 04:11:50.046117
src y dst: 91.121.18.72.80 > 192.168.1.100.43488 (tenemos también la dirección de flujo >)
Flags: . (e neste caso no hay flags) En el segundo ejemplo si (PSH).
data-sqno: 29327:30775(1448)
ack: ack 1181
window: win 64355
Opciones: <nop,nop,timestamp 31733863 2551340>
UDP:
fecha src > dst: udp (len)
windump -i1 -qn udp
windump: listening on \Device\NPF_{024A36DD-4864-4F08-918F-2C5CBA916541}
10:21:19.657479 IP 192.168.1.56.137 > 192.168.1.255.137: UDP, length 50
10:21:20.407221 IP 192.168.1.56.137 > 192.168.1.255.137: UDP, length 50
10:21:21.157236 IP 192.168.1.56.137 > 192.168.1.255.137: UDP, length 50
Veremos más adelante otros protocolos.
Otras opciones.
Vamos a ver aquí otras opciones que usaremos más adelante, en siguientes artículos, cuando interpretemos algunas capturas.
-s (tamaño) se trata del snaplen. si lo ponemos a 0 estamos cogiendo los paquetes completos. Si hubiéramos puesto -s 512 se capturarían sólo los primeros 512 bytes del paquete a capturar.
-w archivo para guardar los datos capturados en un archivo tipo .pcap.
-r archivo para abrir y tratar un arhcivo .pcap previamente grabado con la opción -w.
-x salida hexadecimal
-xx muestra ademas el header de la de la capa de enlace.
-X salida hexadecimal y ASCII.
-XX muestra ademas el header de la de la capa de enlace.
-e para mostrar la direcciones MAC de origen y destino.
-c x para mostrar solo los x primeros paquetes.
Los veremos con ejemplos en próximos capítulos.
Los filtros.
La gran cantidad de datos que nos puede mostrar Windump o TCPDump nos hace muy dificil su interpretación o localización de la información que deseamos obtener. Por ellos, casi simpre, será encesario filtrar el tráfico. Vamos a pararnos un poco aquí porque el establecimeinto de filtros es muy importante para interpretación eficaz de los datos, además, nos servirá de base para el resto der artículos que vamosa dedicar a Wireshark, Tshark, etc.
Libpcap y BPF.
Es más complicado, pero de básicamente. Los filtros que vamos a comentar, están basados en la librería de funciones Libpcap, cuyos procesos se realizan a nivel de usuario. Los procesos de captura, sin embargo, se realizan e niveles más bajos, a nivel de Kernel. Los filtros establecidos mediante las librería libpcap los gestiona, intercediendo entre los dos nieveles comentados, BPF (BSD Packet Filter).
Primitivas y modificadores.
La sintaxis que conforma un filtro está compuesta de primitivas y modificadores. Las primitivas son datos, que pueden ser un número, o un nombre que está precedido un uno o más modificadores.
Modificadores.
Los modificadores los podemos dividir en tres tipos: modificadores de tipo, de dirección y de protocolo.
Modificadores de tipo.
- host que especifica una máquina
- net se refiere a una red
- port refierido a puertos
Como ejemplos de host podenos establecer host 192.168.1.5 ó host midominio.com
Net puede ser net 192.168.1.0 ó 192.168.1.0/24 ó net 192.168. También se puede indicar una mascara: net 192.168.1.0 mask 255.255.0.0
Con port indicamos un puerto: port 24 ó port 443 ó también podemos indicar de esta forma:
dst port http para puerto destino 80
dst port imap para puerto destino 143
Modificadores de dirección.
- scr espcifica la dirección del flujo de tráfico que se va a tener en cuenta. En esta caso scr indica origen del flujo.
- dst expecifica la dirección del flujo de tráfico que se va a tener en cuenta. En esta caso dst indica destino del flujo del flujo.
Por ejemplo, con dst host 192.168.1.1 establecemos un filtro para capturar el tráfico con destino al host 192.168.1.1. Con scr port 25 establecemos un filtro para capturar todo el flujo de paquetes cuyo orgen es el puerto 25.
Modificadores de protocolo.
Indicamos el protocolo del flujo o trafico a capturar. Puede ser IP, ICMP, UDP, TCP, arp, etc.
Por ejemplo: proto \udp ó proto \tcp
Primitivas especiales.
Tenemos, además, una serie de primitivas especiales que son:
- gateway nombre-equipo
- broadcast referido al tráfico broadcast
- less tamaño_bytes para especificar si el tamaño del paquete es menor que el indicado
- greater tamaño_bytes para especificar si el tamaño del paquete es mayor que el indicado
Otras primitivas. Banderas TCP.
Otras primitivas relacionadas con las banderas o flags TCP son: tcp-fin, tcp-syn, tcp-rst, tcp-push, tcp-ack,tcp-urg.
En el siguiente ejemplo capturamos los paquetes tcp con origen y destino puerto 80 y con el flag TCP SYN activado. (Quitamos de las opciones el -q para deshabilitar la salida rápida y obervar la notación S que indica SYN).
NOTA: Para ilustrar estas primitivas usaré los operadores lógicos que explico un poco más abajo.
Vamos con el ejemplo:
windump -i1 -tn tcp and port 80 and "tcp[tcpflags] & tcp-syn !=0"
IP 192.168.1.5.9163 > 209.85.229.147.80: S 3039346897:3039346897(0) win 64512
ss 1460,nop,nop,sackOK>
IP 209.85.229.147.80 > 192.168.1.5.9163: S 233934048:233934048(0) ack 3039346898
win 16384
IP 192.168.1.5.9165 > 209.85.227.99.80: S 3343761330:3343761330(0) win 64512
s 1460,nop,nop,sackOK>
IP 209.85.227.99.80 > 192.168.1.5.9165: S 2556988707:2556988707(0) ack 334376133
1 win 16384
Capturamos ahora SYN-ACK:
windump -i1 -tn tcp and port 80 and "tcp[tcpflags] & (tcp-syn|tcp-ack) ==
(tcp-syn|tcp-ack)"
windump: listening on \Device\NPF_{024A36DD-4864-4F08-918F-2C5CBA916541}
IP 209.85.229.105.80 > 192.168.1.5.9177: S 2072283203:2072283203(0) ack 37790426
24 win 16384
IP 209.85.229.102.80 > 192.168.1.5.9179: S 2500730366:2500730366(0) ack 1387012
win 16384
Flag Push activado:
windump -i1 -tn tcp and port 80 and "tcp[tcpflags] & tcp-push == tcp-push"
IP 192.168.1.5.9181 > 209.85.229.106.80: P 2359059300:2359059982(682) ack 115692
6173 win 64512
IP 209.85.229.106.80 > 192.168.1.5.9181: P 1:267(266) ack 682 win 64853
IP 209.85.229.106.80 > 192.168.1.5.9181: P 267:544(277) ack 682 win 64853
IP 192.168.1.5.9183 > 209.85.229.106.80: P 4285501829:4285502505(676) ack 126691
8661 win 64512
IP 209.85.229.106.80 > 192.168.1.5.9183: P 1:225(224) ack 676 win 64859
IP 209.85.229.106.80 > 192.168.1.5.9183: P 1685:2048(363) ack 676 win 64859
IP 209.85.229.106.80 > 192.168.1.5.9183: P 2048:3037(989) ack 676 win 64859
Combinación de expresiones. Operadores lógicos. Agrupación.
Los filtros o expresiones pueden ser combinadas, mediante operadores lógicos, de las siguientes formas:
- Negación ! ó not
- Concatenación && ó and
- Alternativa || ó or
Ejemplos:
-
host 192.168.1.5 and host 192.168.1.45 -
host user01 && host user03 -
host 192.168.1.5 && !host 192.168.1.56 -
host user02 or host user56 -
host 192.168.5 and port 80 and !host 192.168.1.245 -
host 192.168.1.5 and !port 80
Podemos agrupar las expresiones con paréntesis:
tcp and (dst port 80 or dst port 143) con lo que filtramos para que solo nos aparezca el tráfico tcp con destino al puerto 80 o destino puerto 143:
IP 192.168.1.5.6883 > 67.15.36.37.80: tcp 1294
IP 192.168.1.5.6879 > 72.233.113.162.80: tcp 0
IP 192.168.1.5.6879 > 72.233.113.162.80: tcp 0
IP 192.168.1.5.6879 > 72.233.113.162.80: tcp 0
IP 192.168.1.5.6879 > 72.233.113.162.80: tcp 0
IP 192.168.1.5.6883 > 67.15.36.37.80: tcp 0
IP 192.168.1.5.6883 > 67.15.36.37.80: tcp 0
IP 192.168.1.5.6879 > 72.233.113.162.80: tcp 0
IP 192.168.1.5.6889 > 192.168.2.41.143: tcp 0
IP 192.168.1.5.6889 > 192.168.2.41.143: tcp 0
IP 192.168.1.5.6889 > 192.168.2.41.143: tcp 20
IP 192.168.1.5.6889 > 192.168.2.41.143: tcp 18
IP 192.168.1.5.6889 > 192.168.2.41.143: tcp 124
IP 192.168.1.5.6889 > 192.168.2.41.143: tcp 198
Ejemplos com primitivas y modificadores:
- Capturamos el tráfico con destino u origen MAC 00:04:75:ED:89:DF
windump -i1 -qtn ether dst 00:04:75:ED:89:DF windump: listening on \Device\NPF_{024A36DD-4864-4F08-918F-2C5CBA916541} IP 192.168.1.245.53 > 192.168.1.5.64878: UDP, length 183 IP 192.168.1.245.53 > 192.168.1.5.32780: UDP, length 148 IP 209.85.229.103.80 > 192.168.1.5.7603: tcp 0 IP 192.168.1.245.53 > 192.168.1.5.58703: UDP, length 153 IP 192.168.1.245.53 > 192.168.1.5.35411: UDP, length 151 IP 192.168.1.245.53 > 192.168.1.5.12444: UDP, length 136 IP 192.168.1.245.53 > 192.168.1.5.62124: UDP, length 55 windump -i1 -qtn ether src 00:04:75:ED:89:DF windump: listening on \Device\NPF_{024A36DD-4864-4F08-918F-2C5CBA916541} IP 192.168.1.5.7603 > 209.85.229.103.80: tcp 682 IP 192.168.1.5.7603 > 209.85.229.103.80: tcp 0 IP 192.168.1.5.7605 > 209.85.229.103.80: tcp 676 IP 192.168.1.5.7605 > 209.85.229.103.80: tcp 0 IP 192.168.1.5.7603 > 209.85.229.103.80: tcp 0 IP 192.168.1.5.22178 > 192.168.1.245.53: UDP, length 36 IP 192.168.1.5.7605 > 209.85.229.103.80: tcp 0
- Errores al usar ether. Mejor con un ejemplo:
windump -i1 -qtn ether host 192.168.1.5 windump: listening on \Device\NPF_{024A36DD-4864-4F08-918F-2C5CBA916541} windump: illegal link layer address windump -i1 -qtn ether host 00:04:75:ED:89:DF windump: listening on \Device\NPF_{024A36DD-4864-4F08-918F-2C5CBA916541} IP 192.168.1.5.17963 > 192.168.1.245.53: UDP, length 42 IP 192.168.1.5.8600 > 209.85.227.147.80: tcp 0 IP 192.168.1.245.53 > 192.168.1.5.17963: UDP, length 183 IP 209.85.227.147.80 > 192.168.1.5.8600: tcp 0
windump -i1 -qtn host 00:04:75:ED:89:DF
windump: listening on \Device\NPF_{024A36DD-4864-4F08-918F-2C5CBA916541}
windump: ethernet address used in non-ether expression
- Capturamos los paquetes dirigidos a las direcciones de broadcast y multicast:
windump -i1 -qtn broadcast windump: listening on \Device\NPF_{024A36DD-4864-4F08-918F-2C5CBA916541} arp who-has 192.168.1.201 tell 192.168.1.250 arp who-has 192.168.1.10 tell 192.168.1.245 arp who-has 192.168.1.29 tell 192.168.1.245 IP 192.168.2.3.137 > 192.168.2.255.137: UDP, length 50 02:01:00:00:00:00 > ff:ff:ff:ff:ff:ff, Unknown Ethertype (0x886f), length 66: IP 192.168.1.136.138 > 192.168.1.255.138: UDP, length 209 IP 192.168.2.2.137 > 192.168.2.255.137: UDP, length 5windump -i1 -qtn multicast windump: listening on \Device\NPF_{024A36DD-4864-4F08-918F-2C5CBA916541} IP 192.168.1.36.138 > 192.168.1.255.138: UDP, length 201 02:01:00:00:00:00 > ff:ff:ff:ff:ff:ff, Unknown Ethertype (0x886f), length 66:windump -i1 -qtn ip multicast windump: listening on \Device\NPF_{024A36DD-4864-4F08-918F-2C5CBA916541} IP 192.168.1.1 > 224.0.0.1: igmp IP 192.168.1.89 > 224.0.0.2: igmp IP 192.168.1.136 > 239.255.255.250: igmp IP 192.168.1.202 > 224.0.1.60: igmp
- Capturamos paquetes dependiendo del protocolo:
windump -i1 -qtn arp windump: listening on \Device\NPF_{024A36DD-4864-4F08-918F-2C5CBA916541} arp who-has 192.168.1.36 tell 192.168.1.239 arp who-has 192.168.1.55 tell 192.168.1.239 windump -i1 -qtn tcp windump: listening on \Device\NPF_{024A36DD-4864-4F08-918F-2C5CBA916541} IP 192.168.1.5.7924 > 72.233.113.162.80: tcp 0 IP 72.233.113.162.80 > 192.168.1.5.7924: tcp 0 IP 192.168.1.5.7924 > 72.233.113.162.80: tcp 0
Ejemplos.
- Filtros basados en hosts.
host 192.168.1.20 Captura todos los paquetes con origen y destino 192.168.1.20
src host 192.168.1.1 Captura todos los paquetes con origen en host 192.1681.1
dst host 192.168.1.1 Captura todos los paquetes con destino en host 192.168.1.1
dst host SERVER-1 Captura todos los paquetes con destino en host SERVER-1
host www.terra.com Captura todos los paquetes con origen y distino www.terra.com
- Filtros basados en puertos.
port 21 Captura todos los paquetes con puerto origen y destino 21
src port 21 Captura todos los paquetes con puerto origen 21
not port 21 and not port 80 Captura todos los paquetes excepto origen y destino puertos 21 y 80
portrange 1-1024 Captura todos los paquetes con puerto origen y destino en un rango de puertos 1 a 1024
dst portrange 1-1024 Captura todos los paquetes con puerto destino en un rango de puertos 1 a 1024
- Filtros basados en protocolos Ethernet / IP
net 192.168.1.0 Captura todo el trafico con origen y destino subred 1.0
net 192.168.1.0/24 Captura todo el trafico para la subred 1.0 mascara 255.0
dst net 192.168.2.0 Captura todo el trafico con destino para la subred 2.0
net 192.168.2.0 and port 21 Captura todo el trafico origen y destibo puerto 21 en subred 2.0
broadcast Captura solo el trafico broadcast
not broadcast and not multicast Captura todo el trafico excepto el broadcast y el multicast
Filtros Avanzados.
El formato genérico para crear un filtro avanzado es el siguiete:
expresión relación expresión
relación puede ser >,<, >= <=, = y !=
expresión puede ser el protocolo, una expresión aritmética, operadores binarios, palabra reservada, etc,
De esta manera, si estudiamos el filtro siguiente:
windump icmp[0] = 8
- vemos que la expresión es la palabra reservada icmp (protocolo) junto a un valor 0
- la relación que es = y otra expresión cuyo valor es 8
Además. Podemos especificar el tamaño de lo datos.Para ello tenemos la siguiente sintaxis:
[expresión:tamaño]
De esta manera, si estudiamos el filtro siguiente:
windump udp[0:2] < 1024
- vemos que la expresión es la palabra reservada udp (protocolo) junto a un valor 0:2
- la relación que es = y otra expresión cuyo valor es1024
Que significa este filtro udp[0:2] < 1024:
[0:2] Esto significa que se sitúe en el comienzo del octeto 0 o primer octeto de la cabecera udp y a partir de ahí lea 2 octeos, es decir, que lea el campo de «Puerto de origen». < 1024 y que ese puerto de origen sea menor que 1024.
Es decir que la notación [x:y] significa: x es el octeto ó byte de comienzo y significa: «leer» y bytes a partir del byte x. Si sólo aparece [x] es lo mismo que decir [x:1], es decir leer sólo el byte x. Esto lo hace TCPDump por defecto.
Estos dos octetos serían, según el gráfico de más abajo, los bits 0 al 15:
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Puerto de | Puerto de |
| Origen | Destino |
+--------+--------+--------+--------+
| | |
| Longitud | Suma de Control |
+--------+--------+--------+--------+
|
| octetos de datos ...
+---------------- ...
Si queremos establecer un filtro para que nos muestre solo los paquetes cuyo puerto de destino sea mayor que 4000:
windump «udp[2:2] > 4000″
Como veis es bastante sencillo y solo hay que tener en cuenta y saber «leer» las cabeceras de los protocolos.
Seguimos. Vamos a analizar ahora el filtro tcp[13] = 2
Vamos a echarle un ojo al octeto 13 y simulemos que el flag SYN está activo, pero antes, recordemos el Formato de la cabecera del TCP:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Puerto de origen | Puerto de destino |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Número de secuencia |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Número de acuse de recibo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Posic | |U|A|P|R|S|F| |
| de los| Reservado |R|C|S|S|Y|I| Ventana |
| datos | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suma de control | Puntero urgente |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opciones | Relleno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Datos |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¿Qué significa realmente tcp[13] = 2?
En el flag SYN, que es utilizado para la sincronización de los números de la secuencia tendremos:
U A P R S F
------------------
0 0 0 0 0 0 1 0 (en binario)
------------------
7 6 5 4 3 2 1 0
vemos que el byte 7 y 6 están reservados, el 5 es para URGENT, el 4 es para ACK, el 3 es para PUSH, el 2 es para RESET y el byte 0 para FIN. Tenemos entonces el octeto completo.
En binario quedaría como acabamos de ver: 0 0 0 0 0 0 1 0, que pasado a base decimal, vemos que es el 2, de ahí viene tcp[13] = 2.
Es fácil deducir entonces que para detectar un SYN/ACK: 0 0 0 1 0 0 1 0, el 18 en base decimal, entonces tcp[13] = 18.
Ya sabemos que significa cada uno de los valores. Vamos entonces a averiguar de dónde sacamos el 13 de la expresión tcp[13] = 2.
Vamos a analizar la cabecera TCP del gráfico anterior por filas:
- puerto origen = 2 bytes u octetos o 16 bits
- puerto destino = 2 bytes u octetos. La cuenta siempre empieza por el 0, con lo cual los octetos van del 0 al 3
- número secuencia = 4 bytes u octetos, es decir del 4 al 7
- número acuse recibo = 4 bytes u octetos del 8 al 11
OJO: Tenemos doce octetos (0,1, …11) Hemos de tener en cuenta que se empieza a contar desde cero, es decir, el primer byte es el octeto 0.
El siguiente octeto es el 12 (el décimo tercero) va desde el bits 0 al 7 que corresponden a la posición de datos u offset (4 bits) y a Reservado (4+2); dos bits de Reservado pertenecen ya al siguiente octeto: el 13, que tiene los 2 bits reservados anteriores y 6 que son los flags (UAPRSF). 6 + 2 = 8 bits que es el octeto o byte 13 (o décimo cuarto).
Vamos a analizar ahora de donde viene el valor 2 de la expresión tcp[13] = 2
Esta es la representación de octeto ó byte 13. Si ponemos el flag SYN activado y el resto NO activados, resulta que SYN lo ponemos a 1 y el resto a 0:
Queda entonces: 0 0 0 0 0 0 1 0 (los dos primeros bits dijimos que eran reservados y siempre están a 0)
U A P R S F
------------------
0 0 0 0 0 0 1 0 (en binario)
------------------
7 6 5 4 3 2 1 0
Si pasamos este número (0 0 0 0 0 0 1 0 ), que es binario, a decimal nos queda el número decimal 2 (2 elevado a 1), que es el valor que debemos de introducir para que la expresión quede así:
tcp[13] = 2
Esto le dice a Windump o TCPDump que busque en la cabecera TCP el valor 2 que se encuentra en el byte u octeto 13. Y ya sabemos que corresponde al flag SYN activado (y los otros flags/banderas estarán desactivados).
Seguimos avanzando.
Expresione en formato Hexadecimal.
Para especificar una dirección IP, TCPDump / Windump, etc trabaja mejor con el formato hexadecimal.
Para una dirección 192.168.1.5, su equivalente en hexadecimal sería:
- 192 > C0
- 168 > A8
- 1 > 01
- 5 > 05
es decir: C0A80405
Para windump añadimos el indicativo de que se trata de formato hexadecimal: 0x
y nos quedaría: 0xC0A80105
Apliquemos esto a nuestros ejemplos de filtros y a lo ya estudiado:
Datagramas IP cuyo IP de origen sea 0xC0A80105 o 192.168.1.5
windump -i1 -qtn "ip[12:4] = 0xC0A80105"
IP 192.168.1.5.26495 > 192.168.1.245.53: UDP, length 30
IP 192.168.1.5.5879 > 192.168.1.245.53: UDP, length 31
IP 192.168.1.5.12565 > 209.85.229.99.80: tcp 0
IP 192.168.1.5.12565 > 209.85.229.99.80: tcp 0
IP 192.168.1.5.12565 > 209.85.229.99.80: tcp 621
IP 192.168.1.5.12565 > 209.85.229.99.80: tcp 0
IP 192.168.1.5.12565 > 209.85.229.99.80: tcp 0
IP 192.168.1.5.12565 > 209.85.229.99.80: tcp 0
IP 192.168.1.5.12567 > 209.85.229.102.80: tcp 0
IP 192.168.1.5.12567 > 209.85.229.102.80: tcp 0
IP 192.168.1.5.12567 > 209.85.229.102.80: tcp 640
Datagramas IP cuyo IP de origen sea mayor que 192.168.1.5
windump -i1 -qtn "ip[12:4] > 0xC0A80105"
IP 192.168.1.200 > 224.0.0.251: igmp
IP 192.168.1.11 > 239.255.255.250: igmp
IP 192.168.1.202 > 224.0.0.251: igmp
IP 192.168.1.201 > 224.0.1.60: igmp
IP 209.85.229.99.80 > 192.168.1.5.12565: tcp 0
IP 209.85.229.99.80 > 192.168.1.5.12565: tcp 0
Datagramas Ip cuyo valor TTL sea mayor que 5
windump -i1 -qnt "ip[8]> 5" IP 192.168.1.239.138 > 192.168.1.255.138: UDP, length 201 IP 192.168.1.30.138 > 192.168.1.255.138: UDP, length 201
Bien, hasta aquí con los filtros. En el siguiente capítulo seguremos con ellos y hablaremos de las máscaras, otras formas de creación de filtros y aplicaremos los filtros a la realidad de nuestra red y necesidades.
.
La posición del sniffer en nuestra red.
.
Todo depende de la topología de red y el uso de hub o switch.
Posición del sniffer en red no conmutada (HUB).
El escenario más básico lo encontramos en una red conectada mediante hub. En este caso posicionamos el sniffer en cualquier ranura o boca del hub y obtendremos, con la tarjeta en modo promíscuo, todo el tráfico de la red. Esto es así porque en un hub todos los paquetes son transmitidos a todos los hosts conectados en el mismo segmento de red. Se divide el ancho de banda entre cada host de la red, ademas, se transmiten los paquetes a la velocidad del dispositivo más lento del segmento. Se producen también colisiones que derivan en una red más lenta debido a las retransmisiones.
Posición del sniffer en red conmutada (SWITCH).
En este caso, a cada host conectado al switch, le llega solo el trafico dirigido a el (unicast ) y el broadcast/multicast. El tráfico dirigido a otros host NO lo veremos. No divide el ancho de banda, esto significa, básicamente, que en un switch 10/100 cada puerto es capaz de transmitir a un máximo de 100 dedicado. Es más eficiente que las redes no conmutadas.
Resumiendo entonces, si ubicamos un sniffer en cualquier puerto del switch, solo veremos el tráfico dirigido solo al host donde se encuentre el sniffer y el tráfico broadcast/multicast tal como ARP.
Soluciones.
Solución 1
Una posible solución podría ser el envenenamiento ARP, un Arp Poison. Pero esto es totalmente desaconsejable porque podemos «destabilizar» la red y crear mayores problemas.
Solución 2
Podríamos también colocar el sniffer en el gateway de salida a internet, ó en un host firewall de varias tarjetas, indicar cual de las interfaces nos interesa «olfatear», de esta forma veremos algo más de tráfico que no sea el broadcast/multicast.
Pero para ver todo el tráfico entre dos hosts las soluciones más eficaces son otras.
Solución 3
Una de ellas es aprovechar alguna de las características de un switch administrable como el SPAN (Switch Port Analysis) o llamado de otra forma el Port Mirroring. Esta es una caraterística que lo que hace es, básicamente, copiar el tráfico entre dos puertos a un tercero (ubicación del host sniffer) del switch. Eel Port mirroring tiene el problema que multiplica la carga del switch.
Solución 4
Pero ¿ que pasa si el switch es antiguo y/o no administrable, o simplemente no soporta Port Mirroring ?.
Para este caso tenemos otra opción. Se trata de conectar un hub a una de las salidas o puerto del switch y a este hub conectar el host sniffer (C) y uno de los host a capturar el tráfico (B). El otro host llamémosle (B) sigue en su ubicación del switch . De esta forma C puede ver el tráfico entre A y B. ( B puede ser cualquier otro host conectado al switch o un servidor ).
Esta opción, al igual que el Arp Poison, es algo problemática y desaconsejable.
Solución 5
Otra opción de la que disponemos es instalar otra interface de red en el host sniffer de forma que tenga dos interfaces de red. Una de las tarjetas la conectamos al switch y la otra a uno de los hosts a analizar. Esta opción se considera pasiva, pero necesita de configuración del host sniffer a nivel de interfaces de red para establecer el modo Bridge. (http://technet.microsoft.com/en-us/library/bb457038(TechNet.10).aspx).
Solución 6
Esta solución, quizá la más eficiente y aconsejable aunque también más costosa y quizás más incomoda. Consiste en hacer uso de un Network TAP o «Test Access Port» (Puerto de acceso de pruebas). Con este dispositivo podemos capturar el tráfico de una red conmutada de forma pasiva, es decir, no interfiere en el flujo o tráfico de nuestra red.
Sobre la construcción de un TAP:
http://www.snort.org/docs/tap/
Más información, en mi Blog, sobre sniffers en redes conmutadas y no conmutadas. Su detección:
Detectando Sniffers en nuestra red. Redes conmutadas y no conmutadas.
–
Hasta aquí el primer capítulo dedicado a Herramientas para la interpretación de capturas de red. En el próximo veremos:
- Interpretación de capturas. Veremos algunas ejemplos de capturas, la interpretaremos y analizaremos.
- Seguiremos con la segunda parte de los filtros avanzados Pcap para Windump, TCPDump y, en general, cualquier capturador de red basados en librerias Libpcap. Ejemplos.
Saludos y hasta la próxima.
