Filtros en tcpdump con VLANs

El uso de Port Mirroring constituye una manera sencilla de monitorizar lo que pasa en la red reenviando el tráfico recibido en las bocas seleccionadas del switch por otro puerto llamado “Monitoring Port” o “Mirror Port” según fabricantes.

A este “Monitoring Port” conectamos un servidor donde instalamos las herramientas de análisis de red que queramos (en mi caso, ntop).

Con esta configuración, el otro día me encontré con un comportamiento que en principio me resultó extraño al usar un filtro pcap.

Simplemente, trataba de ver el tráfico relacionado con un determinado host (IP: 172.16.100.38) por lo que ejecutaba el siguiente comando sin resultado alguno:

netmon-[root]-19:37:07:~# tcpdump -ni eth2 host 172.16.100.38
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes

...

Sin embargo, sabía a ciencia cierta que se recibía tráfico de dicha IP porque usando tcpdump sin ningún filtro y un grep, sí obtenía resultados:

netmon-[root]-19:40:26:~# tcpdump -ni eth2 |grep 172.16.100.38
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
19:41:24.072061 IP 172.16.100.221.35550 > 172.16.100.38.53: 17453+ A? partner.googleadservices.com. (46)
19:41:24.100965 IP 192.168.254.70.57042 > 172.16.100.38.53: 29347+ A? cdn.api.twitter.com. (37)
19:41:24.100969 IP 192.168.254.70.57042 > 172.16.100.38.53: 29347+ A? cdn.api.twitter.com. (37)
19:41:24.101414 IP 172.16.100.221.39927 > 172.16.100.38.3389: Flags [.], ack 333592813, win 36391, options [nop,nop,TS val 5105311 ecr 34470843], length 0
19:41:24.136059 IP 192.168.254.70.63856 > 172.16.100.38.53: 57874+ A? tags.expo9.exponential.com. (44)
19:41:24.136109 IP 192.168.254.70.63856 > 172.16.100.38.53: 57874+ A? tags.expo9.exponential.com. (44)
19:41:24.171701 IP 172.16.100.221.7436 > 172.16.100.38.53: 63839+ A? c.statcounter.com. (35)
19:41:24.174047 IP 192.168.251.83.45008 > 172.16.100.38.53: 18888+ A? map.media6degrees.com. (39)
19:41:24.174197 IP 192.168.251.83.45008 > 172.16.100.38.53: 18888+ A? map.media6degrees.com. (39)
19:41:24.224017 IP 212.49.129.4 > 172.16.100.38: ICMP time exceeded in-transit, length 36
19:41:24.310828 IP 192.168.153.184.58814 > 172.16.100.38.53: 56504+ A? www.google.com. (32)
19:41:24.310978 IP 192.168.153.184.58814 > 172.16.100.38.53: 56504+ A? www.google.com. (32)
19:41:24.311128 IP 172.16.100.38.53 > 192.168.153.184.58814: 56504 6/0/0 CNAME www.l.google.com., A 173.194.34.18, A 173.194.34.17, A 173.194.34.20, A 173.194.34.16, A 173.194.34.19 (132)

Después de volverme un poco loco revisando el man del pcap-filter, pensar en algún bug, etc, encontré la solución, que resulta de lo más sencilla.

Debido a que el tráfico recibido en el servidor corresponde a una boca “trunked“, los paquetes están marcados con el TAG de la VLAN correspondiente, por lo que para poder utilizar los filtros “normalmente” deberemos especificar el tag correspondiente mediante la palabra “vlan”, con la sintaxis:

netmon-[root]-19:43:45:~# tcpdump -ni eth2 vlan 2100 and host 172.16.100.38
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
19:51:41.207062 IP 212.49.129.4 > 172.16.100.38: ICMP time exceeded in-transit, length 36
19:51:41.226681 IP 172.16.100.221.39927 > 172.16.100.38.3389: Flags [.], ack 333671787, win 36181, options [nop,nop,TS val 5111483 ecr 34477014], length 0
19:51:41.265918 IP 212.49.129.4 > 172.16.100.38: ICMP time exceeded in-transit, length 36
19:51:41.320231 IP 192.168.251.216.55422 > 172.16.100.38.53: 7786+ A? www.tknologyk.net. (35)
19:51:41.337703 IP 172.16.100.221.39927 > 172.16.100.38.3389: Flags [.], ack 29, win 36174, options [nop,nop,TS val 5111484 ecr 34477015], length 0
19:51:41.491407 IP 192.168.253.184.64053 > 172.16.100.38.53: 21094+ A? api.twitter.com. (33)
19:51:41.517567 IP 192.168.253.192.54545 > 172.16.100.38.5223: Flags [P.], seq 2786195582:2786195683, ack 4108530684, win 501, options [nop,nop,TS val 3052977 ecr 34476418], length 101
19:51:41.518316 IP 192.168.253.192.54545 > 172.16.100.38.5223: Flags [.], ack 102, win 501, options [nop,nop,TS val 3052977 ecr 34477017], length 0
19:51:41.537483 IP 212.49.129.4 > 172.16.100.38: ICMP time exceeded in-transit, length 36
19:51:41.556503 IP 172.16.100.221.39927 > 172.16.100.38.3389: Flags [.], ack 57, win 36167, options [nop,nop,TS val 5111486 ecr 34477017], length 0
^C
10 packets captured
14 packets received by filter
0 packets dropped by kernel

Ahora ya podemos ver el tráfico correspondiente.

 

tags: ,
Escrito en Redes por Ignacio Vazquez

Follow comments via the RSS Feed | Dejar un comentario | Trackback URL

Leave Your Comment

 
desdelaconsola.es