Descarga la aplicación para disfrutar aún más
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
Compartir