Entiendo que se puede implementar un firewall para permitir solo el acceso a un servidor desde direcciones IP específicas, pero ¿no se puede falsificar la dirección IP de origen en un paquete TCP? ¿Cómo evita esto que personas sin escrúpulos accedan a su servidor?
Respuesta1
Lo que dijo Dude es la respuesta que buscas.
Creo que lo que estás pensando es esto:
SERVER.......................CLIENT
............[FIREWALL].........|
..|............................|
..|_>___[CHECK FOR AUTHORITY]_<_|
Este diagrama supone que tanto el servidor como el cliente tienen firewalls (normalmente los tienen).
Si la Autoridad falla, se ignora la llamada al Servidor/Cliente.
Entonces, si la IP del servidor es xxx.xxx.xxx.1 y el cliente es xxx.xxx.xxx.2 y el cliente intenta acceder al servidor enviando un comando sin autorización... el registro de su servidor sería así xxx.xxx .xxx.2 [Error de autorización - IGNORAR]
Si xxx.xxx.xxx.2 ocultó su IP como xxx.xxx.xxx.3, que está autorizado a acceder al servidor, entonces esto sucedería... xxx.xxx.xxx.3 -> Enviar paquete de comando a xxx.xxx.xxx .1 xxx.xxx.xxx.1 -> Responder al comando y enviar paquete a xxx.xxx.xxx.3
Entonces xxx.xxx.xxx.1 nunca obtendría el comando recuperado.
Ahora lo que probablemente estés pensando es¿CÓMO ES ESO SEGURO?
Bueno, la mayoría de los servidores en realidad funcionan así.
SERVER..............................CLIENT
..|______________[CONNECT]___________<_|
............|
...[TEST AUTHORIZATION]
...........|
......[PASSED]
..........|
...........[SEND CONNECTED RESPONSE]...|
Entonces, si el cliente está autorizado y realiza una llamada al servidor, el servidor responderá con una respuesta conectada para enviarla de regreso al cliente. Si el cliente recibe esta respuesta, el servidor sabe que este es el cliente correcto.
Respuesta2
Seguramente alguien puede falsificar su dirección IP para ENVIAR los paquetes TCP/IP, pero nunca obtendrá ninguna RESPUESTA porque irá a la dirección IP falsa que usó. ¡Así que esta forma es inútil para alguien que quiera establecer una comunicación bidireccional!
Respuesta3
Se ha observado que falsificar al remitente no es suficiente; también querrás obtener la respuesta para hacer mucho/cualquier cosa útil. Entonces necesitarías hacer un hombre completo en el medio.
Sin embargo, los cortafuegos normalmente no "permitirán" mucho basándose simplemente en la IP de origen.
Los cortafuegos se utilizan principalmente parabloqueando, pero no para autorización.
Es decir, una IP que no es de confianza ni siquiera sabrá que hay una VPN y no podrá conectarse al servicio VPN. O atacarlo fácilmente, de hecho. Pero la principal característica de seguridad es la propia VPN.
Dado que el filtrado basado en IP es barato, constituye una excelenteprimera línea de defensa. Rechazar cualquier paquete en el firewall significa que los servicios detrás tendrán que lidiar con muchos menos "ataques" (y otros ruidos). Ejecutar un DDoS contra un firewall es más difícil que ejecutar un DDoS contra un servicio real, porque necesita llenar la conexión a Internet, no la CPU del servidor que maneja las solicitudes.
Respuesta4
De hecho, es posible causar daños con conexiones unidireccionales (por ejemplo, con protocolos sin estado como UDP), pero esto se reduce a evitar la autenticación (insegura) basada en IP.
tcp
TCP generalmente no se ve afectado, ya que el establecimiento de la conexión requiere devolver un paquete al host de origen. Aquí es cómo va:
Alice está en la lista de hosts autorizados.
- Alice envía un paquete SYN a Bob.
- Bob devuelve SYN-ACK a Alice para indicarle que puede continuar.
- Alice continúa con un paquete ACK y continúa con la carga útil prevista.
Charlie intenta conectarse al servicio.
- Charlie envía un paquete SYN a Bob.
- El firewall bloquea el paquete, Bob no recibe nada (o una advertencia en los registros de que Charlie intentó conectarse con él).
- Charlie puede saber o no que su solicitud fue rechazada (dependiendo de la configuración del firewall, la solicitud expira o Bob envía explícitamente un paquete ICMP rechazado/inalcanzable)
Charlie de alguna manera sabe que Alice puede acceder al servicio.
- Charlie envía un paquete SYN a Bob, haciéndose pasar por Alice.
- El paquete pasa por el Firewall, Bob devuelve SYN-ACK a Alice.
- Alice responde RST-ACK (confirmación de reinicio) o ICMP inalcanzable, ya que no esperaba algo de Bob.
- Charlie nunca sabrá si la solicitud se aprobó.
Ahora bien, ¿qué pasa si la conexión ya está establecida? Para eso están los números de secuencia: otros no pueden (no deben) predecirlos, y ambas partes esperan que las secuencias siempre aumenten en uno.
- Cuando se establece la conexión, ambas partes seleccionan un número de secuencia preferiblemente aleatorio.
- En cada paquete que envían, el número de secuencia debe incrementarse en uno. Esto permite que el extremo receptor rechace paquetes con números de secuencia incorrectos y reordene aquellos que están dentro de la ventana aceptada.
Ahora Charlie no tiene forma de "inyectar" paquetes en una conexión existente entre Alice y Bob, ya que no puede predecir el número de secuencia, y Bob rechazará sus paquetes, junto con tal vez una advertencia o aviso en los registros.
UDP
Si el protocolo es UDP, es muy susceptible a la suplantación de identidad, ya que los pares pueden inyectar paquetes falsificados en Internet; por lo tanto, debe agregar un mecanismo de autenticación o cifrado en la capa de aplicación en lugar de transporte.
Mitigación
Los ISP agregarán medidas para evitar la suplantación de direcciones IP. Podría ser tan simple como rechazar todos los paquetes que no coincidan con sus propios bloques de red para que no salgan del enrutador y los paquetes que coincidan con sus bloques de red para que no entren en su red.
En una red local suele ser muy fácil realizar suplantación de identidad, ya que no existen muchos mecanismos para evitar que alguien lo haga.