https://www.onlinetis.com
ferret-sidejack secuestro de sesiones HTTP mediante la interceptación de cookies no cifradas
Ferret (junto con su interfaz gráfica Hamster) es una herramienta clásica de análisis y captura de paquetes diseñada para realizar Sidejacking (secuestro de sesiones HTTP mediante la interceptación de cookies no cifradas).
Advertencia de Seguridad Legal
El sidejacking en redes ajenas sin autorización explícita es ilegal. Esta información se proporciona estrictamente con fines educativos y de auditoría de seguridad en entornos controlados.
¿Qué es el Sidejacking?
Cuando te conectas a un sitio web no cifrado (http://) en una red Wi-Fi abierta, el servidor envía una cookie de sesión a tu navegador. Un atacante en la misma red local puede capturar esas cookies en el aire sin necesidad de descifrar la contraseña del usuario y clonar la sesión activa.
Procedimiento de Uso en Kali Linux
1.Configurar la Interfaz en Modo Monitor:Paso 1.Pasa tu tarjeta de red inalámbrica a modo monitor para capturar todo el tráfico de la red.
Verificación: Ejecuta iwconfig y confirma que la interfaz cambió de nombre (ej. wlan0mon) y muestra Mode:Monitor.
2.Iniciar Ferret:Paso 2.Ejecuta Ferret apuntando a la interfaz en modo monitor para que empiece a sniffear paquetes y extraer cookies de sesión.
Verificación: Verás en la terminal cómo Ferret procesa paquetes en tiempo real y genera un archivo llamado hamster.txt.
3.Ejecutar Hamster:Paso 3.En una nueva terminal, inicia Hamster para crear un servidor proxy local que leerá las cookies extraídas por Ferret.
Verificación: La terminal indicará que el proxy se ha iniciado (por defecto en [http://127.0.0.1:1234](http://127.0.0.1:1234)).
4.Configurar el Navegador Web:Paso 4.Configura tu navegador (Firefox) para usar el proxy HTTP local de Hamster.
Dirígete a Ajustes > Configuración de Red.
Selecciona Configuración manual de proxy.
En Proxy HTTP, ingresa 127.0.0.1 y en Puerto 1234.
5.Inyectar la Sesión:Paso 5.Navega en tu explorador a la dirección http://hamster. Verás el panel de control de Hamster mostrando las direcciones IP de las víctimas capturadas y los sitios web a los que accedieron. Al hacer clic en un objetivo, Hamster clona las cookies y puedes acceder al sitio como si fueras la víctima.
Estado Actual y Mitigación
Hoy en día, herramientas como Ferret y Hamster han quedado prácticamente obsoletas debido a la adopción masiva de HTTPS y protecciones modernas:
HTTPS Everywhere / TLS: Cifra todo el tráfico HTTP, impidiendo que Ferret lea las cookies en texto plano.
Atributo Secure en Cookies: Asegura que las cookies de sesión solo se transmitan por conexiones HTTPS cifradas.
HSTS (HTTP Strict Transport Security): Obliga a los navegadores a conectarse exclusivamente mediante HTTPS.
Asegurar tanto la red como la aplicación web requiere un enfoque de defensa en profundidad. La captura de cookies (Sidejacking / Session Hijacking) ocurre principalmente cuando el tráfico no está cifrado en tránsito o cuando las cookies carecen de las banderas de seguridad adecuadas.
1. Hardening en la Aplicación Web (Servicios)
Para mitigar el robo y reutilización de cookies desde el lado del servidor/aplicación:
Configurar el atributo Secure: Fuerza al navegador a enviar la cookie de sesión únicamente a través de conexiones cifradas HTTPS.
Configurar el atributo HttpOnly: Impide que los scripts del lado del cliente (como JavaScript expuesto a ataques XSS) accedan a la cookie de sesión.
Establecer SameSite=Strict o Lax: Previene el envío no deseado de cookies en peticiones de origen cruzado, mitigando ataques de tipo CSRF.
Implementar HSTS (HTTP Strict Transport Security): Agrega la cabecera Strict-Transport-Security para obligar a los navegadores a comunicarse exclusivamente mediante HTTPS, evitando ataques de SSL Strip.
Rotación e Invalidación de Sesiones: Destruye y regenera el identificador de sesión inmediatamente después de cada autenticación, cambio de contraseña o cierre de sesión.
2. Controles de Seguridad en la Red y Transporte
Para evitar la interceptación de tráfico en la capa de red local:
Despliegue de TLS 1.3: Asegura que todo el tráfico web utilice cifrado TLS fuerte y deshabilita versiones obsoletas (SSLv3, TLS 1.0, TLS 1.1).
Inspección de ARP Spoofing (DAI): Activa Dynamic ARP Inspection (DAI) y DHCP Snooping en los switches de la red local para prevenir ataques Man-In-The-Middle (MITM) que permitan redirigir el tráfico.
Aislamiento de Clientes en Wi-Fi (Client Isolation): En redes inalámbricas corporativas o de invitados, habilita el aislamiento para evitar que los dispositivos conectados se comuniquen directamente entre sí en la misma VLAN.
Uso de Redes Privadas Virtuales (VPN): Cifra todo el tráfico desde el cliente hasta el concentrador de la red antes de salir a redes no confiables o Wi-Fi públicas.
DHCP Snooping y Dynamic ARP Inspection (DAI) son características de seguridad de capa 2 (Switching) diseñadas para prevenir ataques Man-In-The-Middle (MITM) como DHCP Spoofing y ARP Poisoning.
DHCP Snooping actua como un "firewall" de capa 2 que valida los mensajes DHCP entrantes y construye una tabla de enlace de confianza (DHCP Snooping Binding Database) mapeando MAC, IP, VLAN, interfaz y tiempo de concesión. DAI utiliza posteriormente esta base de datos para validar y filtrar los paquetes ARP en la red.
Requisitos Previos e Invariantes de Seguridad
Atención con la Secuencia de Despliegue
Siempre se debe configurar y verificar primero DHCP Snooping antes de habilitar DAI. Si activas DAI sin una base de datos de DHCP Snooping poblada y válida, el switch descartará inmediatamente todo el tráfico ARP de los clientes legítimos, provocando una denegación de servicio (DoS) generalizada en el segmento.
Puertos de Confianza (Trusted Ports): Puertos conectados a servidores DHCP legítimos, switches vecinos o gateways/routers.
Puertos Untrusted (Untrusted Ports): Todos los puertos de acceso donde se conectan los dispositivos finales (PCs, impresoras, servidores de acceso). Por defecto, todos los puertos inician como untrusted.
Configuración Paso a Paso (Cisco IOS / IOS-XE)
1.Habilitar DHCP Snooping Globalmente y en VLANs:Paso 1.Activa la función globalmente y especifica las VLANs que estarán bajo protección.
Nota: no ip dhcp snooping information option evita la inserción del Option 82 si los servidores DHCP locales rechazan peticiones con esta opción por defecto.
Verificación: Ejecuta show ip dhcp snooping para comprobar que el servicio está activo y mapeado a las VLANs correspondientes.
2.Definir Puertos de Confianza para DHCP:Paso 2.Marca la interfaz conectada al servidor DHCP legítimo o enlace Trunk ascendente como puerto de confianza.
Verificación: Confirma que las interfaces de usuario finales permanezcan como untrusted. Los paquetes DHCP Offer/Ack procedentes de interfaces untrusted serán descartados automáticamente.
3.Validar la Base de Datos Binding de DHCP:Paso 3.A medida que los clientes obtienen direcciones IP, la base de datos se poblará automáticamente.
Verificación: Ejecuta show ip dhcp snooping binding para confirmar que las direcciones MAC e IP de los clientes estén registradas correctamente antes de proceder a habilitar DAI.
4.Habilitar Dynamic ARP Inspection (DAI):Paso 4.Habilita la inspección de paquetes ARP sobre las VLANs objetivo.
Mecanismo: El switch interceptará cada solicitud/respuesta ARP en puertos untrusted y la comparará contra la tabla creada por DHCP Snooping. Si la relación IP-MAC no coincide, el paquete se descarta.
5.Definir Puertos de Confianza para DAI:Paso 5.Define los enlaces troncales y los puertos que van hacia routers/gateways como puertos de confianza para ARP.
Verificación: Ejecuta show ip arp inspection para ver el contador de paquetes ARP inspeccionados, permitidos y descartados por inconsistencia de enlace.
Casos Especiales: Equipos con IP Estática
Los dispositivos con dirección IP fija (como servidores o impresoras) no realizan peticiones DHCP y, por ende, no figuran en la tabla de DHCP Snooping. Para evitar que DAI bloquee su tráfico ARP, se debe crear una lista de acceso de inspección ARP (ARP ACL) manual:
El mecanismo de procesamiento en switches de Capa 2 envía las peticiones DHCP y las inspecciones ARP al plano de control (CPU del switch) para ser analizadas por los procesos de DHCP Snooping y DAI. Si un atacante inunda la red con solicitudes DHCP falsas o peticiones/respuestas ARP masivas (ARP Flooding), la CPU del switch se saturará al 100%, dejando de procesar protocolos de control críticos como STP, LACP o CDP.
Para prevenir esta Denegación de Servicio (DoS), se implementan límites de tasa (rate limiting) por interfaz. Si una interfaz supera el umbral configurado, el switch la coloca automáticamente en estado err-disable, aislando la fuente del ataque.
Valores de Referencia Recomendados
Configuración Paso a Paso (Cisco IOS / IOS-XE)
1.Configurar Rate Limiting para DHCP Snooping:Prevención de DHCP Flooding.Aplica el límite de tasa de tramas DHCP en los puertos de acceso de usuarios.
Verificación: Ejecuta show ip dhcp snooping para comprobar el campo Limit (pps) configurado en cada interfaz.
2.Configurar Rate Limiting para Dynamic ARP Inspection (DAI):Prevención de ARP Flooding.Establece el límite de paquetes ARP por segundo en la misma gama de interfaces.
Nota: Para permitir ráfagas breves de tráfico legítimo sin bloquear el puerto inmediatamente, se puede definir un intervalo en segundos agregando burst interval <segundos> (ej. ip arp inspection limit rate 30 burst interval 2).
Verificación: Ejecuta show ip arp inspection interfaces para revisar las tasas aplicadas y el estado de los puertos.
3.Configurar la Auto-Recuperación de Puertos (Errdisable Recovery):Automatización operativa.Cuando se sobrepasa el límite, el puerto se apaga (err-disable). Para evitar la intervención manual del administrador (shutdown / no shutdown), configura la recuperación automática tras un periodo de enfriamiento (ej. 300 segundos).
Verificación: Ejecuta show errdisable recovery para confirmar que las causas dhcp-rate-limit y arp-inspection están habilitadas y comprobar el temporizador de recuperación.
Diagnóstico y Resolución en Caso de Bloqueo
Si un puerto entra en estado de error por exceso de tasa, la consola registrará mensajes como los siguientes:
Para recuperar manualmente la interfaz sin esperar al temporizador de recuperación:
Control Plane Policing (CoPP) es un mecanismo de seguridad de infraestructura que trata a la CPU del switch/router como una interfaz dedicada. Permite filtrar, limitar la tasa (rate-limiting) y clasificar el tráfico destinado al plano de control (tráfico que la CPU debe procesar), protegiéndola contra ataques de denegación de servicio (DoS) o ráfagas masivas de paquetes sin afectar al plano de datos (hardware forwarding).
Tipos de Tráfico Dirigidos al Plano de Control
Tráfico de Control de Red: Protocolos de enrutamiento y gestión de topología (OSPF, BGP, EIGRP, STP, CDP, LLDP). Debe tener la prioridad más alta y nunca ser descartado.
Tráfico de Gestión: Accesos administrativos al equipo (SSH, SNMP, Telnet, NTP, TACACS+/RADIUS). Se debe limitar a tasas razonables desde direcciones autorizadas.
Tráfico "Punt-Driven" / Excepciones: Paquetes que el hardware (ASIC/TCAM) no puede conmutar directamente y envía a la CPU para procesamiento o generación de respuestas (peticiones ARP, trazas ICMP, opciones IP, coincidencias de TTL expirado). Es el vector principal de ataques DoS.
Requisitos Previos e Invariantes de Seguridad
Riesgo de Interrupción de Red
Una política CoPP mal diseñada puede descartar paquetes de keepalive de protocolos de enrutamiento (como OSPF o BGP) o tramas STP/CDP, lo que provocaría la caída de adyacencias, flapping de rutas y aislamiento del switch. Aplica siempre métricas conservadoras y analiza los contadores antes de aplicar acciones drop.
Configuración Paso a Paso (Cisco IOS / IOS-XE)
CoPP utiliza la arquitectura estándar Modular QoS CLI (MQC) basada en tres fases: Definición de Clases (class-map), Definición de Políticas (policy-map) y Aplicación al Control Plane (control-plane).
1.Definir las Access Control Lists (ACLs) de Clasificación:Paso 1.Crea ACLs para identificar y clasificar los tipos de tráfico que llegan al plano de control.
Verificación: Revisa con show ip access-lists la correcta delimitación de redes y puertos.
2.Crear los Class-Maps:Paso 2.Asocia las ACLs a mapas de clase para que MQC pueda aplicar acciones específicas sobre cada flujo.
Verificación: Ejecuta show class-map para validar la lógica de coincidencia (match-all o match-any).
3.Configurar la Política QoS (Policy-Map) y Tasas de Vigilancia:Paso 3.Aplica el mecanismo de vigilancia de ancho de banda (police) mediante la tasa de bits (bps) o paquetes por segundo (pps).
Nota: Durante la fase inicial de pruebas, es aconsejable configurar exceed-action transmit o únicamente transmit para medir el tráfico real mediante contadores antes de activar la desestimación mediante drop.
4.Aplicar la Política a la Interfaz del Plano de Control:Paso 4.Vincula la política directamente al plano de control del switch L3.
Verificación: Ejecuta show control-plane host receive-features para confirmar que la política esté correctamente enlazada.
Verificación y Diagnóstico en Tiempo Real
Para verificar el rendimiento del CoPP y confirmar si se están produciendo descartes (drops) indeseados o si se está conteniendo exitosamente un ataque:
Métrica a observar: Inspecciona el campo exceed bytes y drop dentro de cada clase. Si observas incrementos constantes en CLASS_COPP_ROUTING, aumenta inmediatamente la tasa del police para evitar caídas de vecino.
Para monitorear el consumo de la CPU del switch antes y después de aplicar la política:
https://www.onlinetis.com
