Logo Studenta

Abril-2018

Vista previa del material en texto

Boletín de Seguridad 
Informática 
3. DÓNDE REALI-
ZAR LA CAPTURA 
DE DATOS 
El primer paso para poder 
auditar la red será definir 
dónde analizar el tráfico. 
Imaginemos un escenario 
común. Nos encontramos 
en un entorno conmutado 
formado por varios swit-
ches, unos cuantos equipos 
y un servidor de ficheros. El 
rendimiento de la red ha 
disminuido en los últimos 
días y desconocemos la 
causa. 
Carecemos de un IDS que 
pueda dar la voz de alarma 
sobre algún ataque o ano-
malía en la red y sabemos 
que el servidor de ficheros 
abastece, en cuanto a tasa 
de transferencia se refiere, 
a los equipos de nuestra 
LAN (Local Area Network) 
sin problema alguno. Ade-
más, nuestros equipos de 
red no cuentan con proto-
colos como Netflow para 
poder analizar tráfico re-
motamente por lo que de-
cidimos utilizar Wireshark. 
La primera duda que surge 
es dónde instalarlo. 
A pesar de parecer lógico 
instalar Wireshark en el 
propio servidor de ficheros 
para 
analizar el tráfico que transi-
ta por ese segmento de red, 
nos encontraremos con si-
tuaciones en las cuales no 
podamos tener acceso físico 
al servidor o simplemente, 
por motivos de seguridad, 
por ejemplo entornos SCA-
DA, no podamos instalar 
software en el mismo. 
En este caso se mostrarán 
algunas alternativas en el 
uso de técnicas que permi-
tan llevar a cabo una captura 
de tráfico sin necesidad de 
portar Wireshark al propio 
servidor. La excepción a esta 
regla la veremos en el últi-
mo caso, donde se propo-
nen varios métodos de cap-
tura remota en los que sí es 
necesario ejecutar o al me-
nosinstalar aplicaciones en 
el equipo que se quiere mo-
nitorizar. 
3.1. UTILIZANDO 
UN HUB 
Si conectásemos un equipo 
con Wireshark a uno de los 
puertos del switch, solo 
veríamos las tramas que 
transcurren entre el switch y 
nuestra máquina, y eso no 
es lo que pretendemos. El 
switch divide la red en seg-
mentos, creando dominios 
de colisión separados y eli-
minando, de esta forma, la 
necesidad de que cada es-
tación compita por el me-
dio. Únicamente envía las 
tramas a todos los puertos 
(pertenecientes a la misma 
VLAN) cuando se trata de 
difusiones broadcast (por 
ejemplo, para saber la di-
rección física de alguna 
máquina). 
Una de las alternativas que 
tenemos para alcanzar 
nuestro propósito es hacer 
uso de un hub, como se 
aprecia en la Figura 1- 
Modos de captura y conec-
tarlo en el mismo segmen-
to de red donde se encuen-
tra nuestro servidor. Al 
tratarse ahora de un medio 
compartido, todo el tráfico 
entre el switch y el servi-
dor podrá analizarse en 
nuestro equipo. 
3.2. PORT MIRRO-
RING O VACL (VLAN
-BASED ACLS) 
Siempre que tengamos 
acceso al switch, y soporte 
esta funcionalidad, será la 
manera más cómoda para 
capturar el tráfico de red. 
Dicho modo de trabajo, 
denominado modo SPAN 
en entornos Cisco, permi-
te duplicar el tráfico que 
transcurre por uno o varios 
ANÁLISIS DE TRÁFICO 
CON WIRESHARK Parte II 
Departamento de Seguridad Informática MINSAP 
Abril 2018 
Volumen 1, nº 1 
ANÁLISIS DE TRÁFICO 
CON WIRESHARK Parte II 
1 
Contenido: 
P á g i n a 2 B o l e t í n d e S e g u r i d a d I n f o r m á t i c a V o l u m e n 1 , n º 1 
puertos del switch y replicarlo al puerto 
que queramos. Hay que tener en cuen-
ta que el puerto configurado como 
mirroring tiene que ser tan rápido co-
mo el puerto/puertos a monitorizar 
para evitar pérdida de tramas. Este mé-
todo es empleado por muchos adminis-
tradores para instalar IDS u otras herra-
mientas de monitorización. 
Una ventaja que presentan las VACL 
frente al Port Mirroring es que permi-
ten una mayor granularidad a la hora de 
especificar el tráfico que se quiere ana-
lizar. Mientras que configurando Port 
Mirroring es posible redirigir el tráfico 
de un puerto o VLAN a otro, con VACL 
es posible especificar ACLs para selec-
cionar el tipo de tráfico en el que esta-
mos interesados 
En el siguiente ejemplo, se define una 
VLAN Access Map para reenviar y cap-
turar paquetes que coincidan con el 
tráfico definido en lab_10 y que poste-
riormente será aplicado a las VLANS 
14,15 y 16: 
Router(config)# vlan access-map bmf 10 
Router(config-access-map)# match ip 
address lab_10 
Router(config-access-map)# action for-
ward capture 
Router(config-access-map)# exit 
Router(config)# vlan filter bmf vlan-list 
14-16 
Router# show ip access-lists lab_10 
Extended IP access list lab_10 
permit ip 10.0.0.0 0.255.255.255 any 
Algunos dispositivos Cisco también 
disponen de una funcionalidad deno-
minada MiniProtocol Analyzer gracias a 
la cual se puede capturar tráfico desde 
una sesión SPAN y almacenar los pa-
quetes en un buffer local, pudiendo ser 
posteriormente exportados en un fi-
chero .cap. Esta funcionalidad tam-
bién permite especificar opciones de 
filtrado para limitar la captura de pa-
quetes, por ejemplo, podrían especifi-
carse aquellos paquetes que tengan 
un EtherType determinado o aquellos 
declarados en una ACL previamente 
configurada. Además, utiliza libpcap 
como formato de captura por lo que 
puede emplearse Wireshark o cual-
quier otro analizador de protocolos 
para un análisis posterior. 
3.3. MODO BRIDGE 
En caso de no tener acceso al switch, 
podremos utilizar un equipo con dos 
tarjetas de red para situarnos entre 
el switch y el servidor, como se ob-
serva en la Figura 1. 
Consiste en un MitM (Man in the 
Middle), a nivel físico, donde tendre-
mos un acceso pasivo a todo el caudal 
de tráfico. 
Tenemos varias alternativas para po-
ner nuestro PC en este modo de fun-
cionamiento,pero destacamos las 
bridge-utils (paquete de utilidades 
bridge para Linux) por su facilidad de 
instalación y configuración. Únicamen-
te tendremos que crear una interfaz 
de tipo bridge y posteriormente aña-
dir las interfaces físicas que forman 
parte de dicho puente. Por último, 
levantaremos la interfaz y ejecutare-
mos Wireshark. El inconveniente de 
éste método de captura es la pérdida 
de tramas durante su instalación, si-
tuación que en ciertos escenarios no 
es asumible. A continuación, se 
muestra un ejemplo de su configura-
ción: 
root@bmerino:~# brctl addbr mybrid-
ge 
root@bmerino:~# brctl addif mybridge 
eth1 
 
root@bmerino:~# brctl addif mybridge 
eth0 
root@bmerino:~# ifconfig mybridge up 
3.4. ARP SPOOF 
En contadas ocasiones, y en los casos 
en los que no podamos utilizar los mé-
todos anteriores, podemos hacer uso 
de herramientas como Ettercap o simi-
lares para llevar a cabo un MitM (Man 
in the Middle). Es importante entender 
que se trata de un método bastante 
ofensivo y que únicamente será útil en 
entornos no críticos, donde prima cier-
ta necesidad en interceptar tráfico en-
tre varias máquinas.Lo que conseguire-
mos será que el equipo que se desea 
monitorizar envíe todas las tramas a 
través de nuestro PC donde tendremos 
Wireshark ejecutándose. El proceso se 
lleva a cabo contaminando la cache de 
los equipos involucrados con una aso-
ciación IP/MAC falsa. Algunos swit-
ches disponen de funcionalidades que 
les permiten detectar este proceso 
(véase Dynamic Arp Inspection y 
DHCP Snooping ), por lo que es impor-
tante deshabilitar dicha funcionalidad 
en los dispositivos de red si no quere-
mos que nuestro puerto entre en modo 
shutdown. Para interponernos entre el 
servidor (10.0.0.100) y el gateway de 
nuestra LAN (10.0.0.1) bastará con 
ejecutar Ettercap de la siguiente forma: 
root@bmerino:~# ettercap -T -M 
arp:remote /10.0.0.1/ /10.0.0.100/ & 
3.5. REMOTE PACKET CAP-
TURE 
Además de los métodos citados ante-
riormente, existen varias posibilidades 
para capturar datos de forma remota. 
Una de ella es mediante RPCAP 
(Remote Packet Capture System), aun-
que en este caso sería necesario ejecu-
tar un programa servidor (rpcapd) junto 
con las librerías necesarias en el equipo 
a monitorizar yun programa cliente 
desde el cual se recuperarán y visualiza-
rán los mismos; en nuestro caso, Wires-
hark. 
Como hemos dicho anteriormente, este 
método es apropiado para entornos no 
críticos donde tenemos posibilidad de 
instalar software en el equipo cuyo trá-
fico queremos analizar, con el riesgo 
que ello conlleva para la estabilidad y 
rendimiento del mismo. 
Para la configuración del servidor, úni-
camente hay que ejecutar rpcapd.exe, 
incluido en la instalación de WinPcap 
4.0 (librerías libpcap en equipos Win-
dows) o superior. 
Se puede especificar el puerto de 
escucha y otras opciones como auten-
ticación, lista de clientes autorizados a 
conectar al servidor, etc. El modo de 
funcionamiento puede ser activo o 
pasivo. En el primer caso el demonio 
tratará de establecer una conexión 
hacia el cliente para que éste envíe los 
comandos adecuados al servidor. Este 
modo de funcionamiento será útil 
cuando el demonio esté detrás de un 
Firewall que no tenga NAT configurado 
para su conexión desde el exterior. En 
el segundo caso, será el cliente el que 
inicie la conexión con el servidor para 
comenzar a monitorizar datos. 
(Imagen 1) 
El cliente tendrá que especificar direc-
ción, puerto, credenciales (en el caso 
de que así fuera requerido por el servi-
dor) y la interface desde la cual se 
desean capturarpaquetes. En Wires-
hark, esto se realiza desde Capture >> 
Options y especificando en Interface 
el tipo Remote: (Imagen 2) 
Es importante destacar que, si la cap-
tura se realiza en la misma interfaz en 
la que se está utilizando el propio pro-
tocolo RPCAP para transferir los datos 
entre el demonio y el cliente, dichos 
paquetes también serán visualizados 
P á g i n a 3 B o l e t í n d e S e g u r i d a d I n f o r m á t i c a V o l u m e n 1 , n º 1 
en Wireshark pudiendocomplicar la 
interpretación de los mismos. Se pue-
de impedir que estos paquetes interfie-
ran con el resto. Para ello, tendremos 
que seleccionar la opción "Do not cap-
ture own RPCAP traffic" dentro de 
"Remote Settings". 
Otra alternativa aparte de RPCAP para 
la captura remota de datos es redirigir 
la salida de tcpdump desde una cone-
xión ssh. Lógicamente, en este caso el 
equipo a monitorizar necesita disponer 
de acceso ssh y tener tcpdump instala-
do (Imagen 3) 
Una vez configurada nuestra máquina, 
haciendo uso de cualquiera de los mé-
todosanteriores, podemos lanzar Wi-
reshark como root/administrador. Para 
iniciar la capturaseleccionamos la inter-
faz en el menú Capture >> Interfaces 
(en el caso de optar por el uso del mo-
do bridge, podemos utilizar cualquiera 
de las dos). (Imagen 4) 
A continuación, describimos brevemen-
te las áreas más interesantes que nos 
muestra Wireshark según comienza la 
toma de datos (Figura 5- Áreas de Wi-
reshark): 
 
B o l e t í n d e S e g u r i d a d I n f o r m á t i c a V o l u m e n 1 , n º 1 P á g i n a 4 
La zona 1 es el área de definición de 
filtros y, como veremos más adelante, 
permite definir patrones de búsqueda 
para visualizar aquellos paquetes o 
protocolos que nos interesen. 
La zona 2 se corresponde con la lista de 
visualización de todos los paquetes 
que se están capturando en tiempo 
real. Saber interpretar correctamente 
los datos proporcionados en esta zona 
(tipo de protocolo, números de secuen-
cia, flags, marcas de tiempo, puertos, 
etc.) nos va a permitir, en ciertas oca-
siones,deducir el problema sin tener 
que realizar una auditoría minuciosa. 
La zona 3 permite desglosar por capas 
cada una de las cabeceras de los paque-
tes seleccionados en la zona 2 y nos 
facilitará movernos por cada uno de los 
campos de las mismas. Por último, la 
zona 4 representa, en formato hexade-
cimal, el paquete en bruto, es decir, tal 
y como fue capturado por nuestra tarje-
ta de red. 
 
B o l e t í n d e S e g u r i d a d I n f o r m á t i c a V o l u m e n 1 , n º 1 P á g i n a 5 
Imagen 1: Captura de datos con rpcapd 
 
 
Imagen 2: Conexión a servidor rpcapd 
 
 
 
 
 
 
Imagen 3: tcpdump 
Imagen 4: Áreas de Wireshark

Otros materiales