Cómo prevenir los ataques de suplantación de IP
Dónde debe aplicarse el filtrado de origen, cuándo las comprobaciones estrictas de ruta inversa rompen tráfico válido y por qué la autenticación y IPv6 requieren atención separada.
Comprobar la ruta de una entrega y decidir quién puede entrar son tareas distintas. La validación del origen y la autenticación necesitan controles propios.
Un mostrador de recepción puede comprobar si una entrega llegó por una ruta esperada. La persona que la recibe aún debe decidir quién puede entrar en el edificio. Las redes tienen una división de trabajo parecida: validar de dónde afirma proceder el tráfico y después autenticar el acceso al servicio.
Coloca la primera comprobación cerca del origen
Un operador de red sabe qué rangos de direcciones deben llegar por la conexión de un cliente. Los paquetes que declaran un origen ajeno pueden rechazarse allí, antes de avanzar. Este es el enfoque de validación de origen descrito en el BCP 38.
En una red empresarial, comprueba tanto el tráfico que sale hacia Internet como el que llega desde fuera. El mismo límite es la salida de una red y la entrada a otra. Define los orígenes esperados para cada conexión, incluidos los rangos delegados legítimos, en lugar de aplicar una regla general en todas partes.
Una comprobación de rangos no identifica a la persona que está detrás de un paquete. También puede dejar margen para falsificaciones dentro de un rango permitido. Trátala como un control fronterizo útil, no como un certificado de identidad.
Adapta las comprobaciones de ruta inversa a las rutas reales
El reenvío por ruta inversa de unidifusión, o uRPF, compara el origen de un paquete con la información de enrutamiento. En modo estricto, la interfaz de entrada debe coincidir con la ruta de retorno seleccionada. Esto puede funcionar bien cuando las rutas son predecibles.
Sin embargo, el tráfico legítimo puede llegar por una conexión mientras que la mejor ruta de retorno utiliza otra. Ocurre con el enrutamiento asimétrico y en redes que utilizan varios proveedores. Las comprobaciones estrictas pueden descartar entonces tráfico válido. El RFC 3704 explica estas compensaciones. Los enfoques de rutas factibles consideran alternativas permitidas; las comprobaciones laxas suelen preguntar si existe una ruta, por lo que ofrecen una prueba más débil. Elige y verifica el modo según la topología real, incluido el cambio por conmutación de respaldo.
Autentica el servicio y al usuario
Mantén las restricciones de dirección donde sean útiles, pero no las conviertas en la única prueba de identidad para el acceso sensible. Utiliza TLS validado correctamente para los servicios web y protocolos autenticados adecuados para la administración y los pares de red. La autenticación de cuentas y los permisos tienen además sus propias funciones.
El TLS 1.3 autentica el servidor, también puede autenticar al cliente y protege el tráfico de la aplicación. No certifica todas las direcciones IP de origen ni evita que una inundación agote un enlace. El cifrado y la validación de origen protegen cosas distintas.
Reduce las oportunidades de reflexión
Si operas DNS recursivo, limita la recursión a los clientes a los que pretendes dar servicio. Esto es distinto del DNS autoritativo, que puede tener que responder públicamente por tus dominios. El RFC 5358 explica por qué la recursión abierta puede convertir un servidor en un reflector.
Comprueba otros servicios expuestos en busca de accesibilidad innecesaria y respuestas demasiado grandes. Planifica la asistencia contra DDoS de los proveedores ascendentes antes de un incidente: el filtrado en tu propio servidor no puede restaurar una conexión ya saturada antes de que el tráfico llegue a ella.
IPv6 también exige estas decisiones
Pasarse a IPv6 no activa automáticamente el cifrado ni evita la suplantación de origen. IPsec requiere configuración y gestión deliberadas de claves y puede utilizarse con ambas versiones de IP. La guía de seguridad operativa de IPv6 trata los controles que realmente hacen falta. En una red de doble pila, evalúa y prueba ambos caminos.
Comprueba que la protección funciona sin romper el servicio
Registra los rangos y las rutas esperados, prueba el tráfico autorizado y la conmutación por fallo y después examina las pérdidas y el estado del servicio. Un sistema de detección de intrusiones puede avisarte de patrones; bloquear requiere una función de prevención o la respuesta de un operador. Los registros deben ayudar a explicar qué ocurrió, no convertir un origen declarado en una identidad presunta.
Como usuario corriente de Internet, céntrate en las actualizaciones, las conexiones autenticadas y la seguridad de las cuentas. Pregunta a tu proveedor por el filtrado de origen si lo necesitas; no puedes corregir la validación de paquetes ascendente desde un navegador. Para conocer el contexto, lee cómo funciona un origen falsificado o qué patrón de ataque aborda cada control.