Posición del sniffer en nuestra red c

1. Posición del sniffer en nuestra
red. Redes conmutadas y no
conmutadas.
Clase 4
14-03-2013

2.  Después de algún comentario y correos, vamos a estudiar el
posicionamiento o colocación de un sniffer en nuestra red para obtener
los resultados que esperamos.

3.  Todo depende de la topología de red y el uso de hub o switch.
 Esta presentación es válido para cualquier sniffer de los que ya hemos
visto. Wireshark, Tshark, WinDump / TCPdump, etc.

4. 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 promiscuo, 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, además, 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.

5. 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, a grosso
modo, 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.

6. 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.

7. Soluciones.
 Solución 2
 Podríamos también colocar el sniffer en el gateway de salida a internet, o
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.

8. Soluciones.
 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.

9. Soluciones.
 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.

10. Soluciones.
 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.

11. Soluciones.
 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 ).

12. Soluciones.
 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 ).

13. Soluciones
 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.