Cómo prevenir los ataques de suplantación de IP
Dónde filtrar el origen, cuándo una comprobación estricta descarta tráfico válido y qué aportan la autenticación y los controles en IPv6.
En una recepción se puede comprobar si una entrega ha llegado por la vía prevista. Decidir quién puede entrar en el edificio requiere otra comprobación. En una red ocurre algo parecido: hay que validar de dónde dice venir el tráfico y autenticar el acceso al servicio.
Comprobar el origen cerca de donde sale el tráfico
El operador sabe qué rangos de direcciones deben llegar por la conexión de un cliente. Puede descartar allí los paquetes que declaren un origen ajeno, antes de que sigan circulando. Es el enfoque de validación de origen descrito en BCP 38.
En una empresa, revisa tanto el tráfico que entra desde Internet como el que sale. El mismo límite es una salida para una red y una entrada para otra. Define los orígenes esperados para cada conexión, incluidos los rangos delegados legítimamente, en lugar de aplicar una regla idéntica en todas partes.
Comprobar un rango no identifica a la persona que envía el paquete. También puede dejar margen para falsificar direcciones dentro del rango permitido. Es un control de frontera útil, no un certificado de identidad.
Adaptar la comprobación de retorno a las rutas reales
La comprobación de ruta inversa unicast, o uRPF, contrasta el origen del paquete con la información de encaminamiento. En modo estricto, la interfaz de entrada debe coincidir con la ruta de retorno seleccionada. Puede funcionar bien cuando los caminos son previsibles.
Sin embargo, el tráfico legítimo puede entrar por una conexión y tener su mejor ruta de vuelta por otra. Ocurre con rutas asimétricas o con varios proveedores. Una comprobación estricta puede entonces descartar comunicaciones válidas. El RFC 3704 explica estas decisiones. Los métodos de ruta factible consideran alternativas permitidas; las comprobaciones flexibles suelen limitarse a verificar que exista una ruta y son menos exigentes. Hay que elegir y probar el modo según la topología, también cuando falla un enlace.
Autenticar el servicio y al usuario
Conserva las restricciones por dirección donde sean útiles, pero no las uses como única prueba de identidad para accesos sensibles. Utiliza TLS correctamente validado en servicios web y protocolos con autenticación adecuada para la administración y los pares de red. El acceso a cuentas y sus permisos siguen necesitando controles propios.
TLS 1.3 autentica el servidor, puede autenticar también al cliente y protege el tráfico de la aplicación. No certifica cada dirección IP de origen ni impide que una avalancha de tráfico sature un enlace. El cifrado y la validación del origen cubren necesidades diferentes.
Evitar que un servicio actúe como reflector
Si administras DNS recursivo, limita la recursión a los clientes a los que quieres dar servicio. No es lo mismo que el DNS autoritativo, que puede necesitar responder al público por tus dominios. El RFC 5358 explica el riesgo de dejar abierta la recursión.
Revisa también otros servicios expuestos: si necesitan ser accesibles y si pueden generar respuestas desproporcionadas. Prevé ayuda contra DDoS con tu proveedor antes de un incidente. Filtrar en el servidor no recupera un enlace que ya está saturado antes de que el tráfico llegue a él.
IPv6 también necesita estos controles
Pasar a IPv6 no activa el cifrado ni evita automáticamente la falsificación del origen. IPsec exige configuración y gestión de claves, y puede utilizarse con ambas versiones de IP. La guía de seguridad operativa de IPv6 trata los controles que realmente hay que desplegar. En una red con doble pila, evalúa y prueba ambos caminos.
Proteger sin interrumpir el servicio
Documenta los rangos y las rutas esperados, prueba tráfico autorizado y cambios de enlace, y examina los descartes junto con la salud del servicio. Un sistema de detección de intrusiones puede alertar; para bloquear hace falta una función de prevención o la intervención del operador. Los registros ayudan a investigar, pero un origen declarado no demuestra una identidad.
Como usuario, céntrate en las actualizaciones, las conexiones autenticadas y la seguridad de tus cuentas. Puedes preguntar al proveedor por el filtrado de origen; no puedes corregir su validación desde el navegador. Para repasar, lee cómo funciona un origen falsificado o qué patrón de ataque aborda cada control.