¿Qué tan seguro es el filtrado de la dirección IP?

Question

Estoy planeando implementar una aplicación interna que tenga datos confidenciales. Sugerí que lo pusiéramos en una máquina que no esté expuesta a Internet en general, solo a nuestra red interna. La cosa. El departamento rechazó esta sugerencia y dijo que no vale la pena reservar una máquina completa para una sola aplicación. (La aplicación tiene su propio dominio en caso de que sea relevante, pero me dijeron que no pueden bloquear las solicitudes basadas en la URL.)

Dentro de la aplicación lo programé para que solo respete las solicitudes si provienen de una I.P. dirección, de lo contrario solo muestra una página que dice "no se puede ver esto". Nuestras direcciones internas tienen un patrón distinto, por lo que estoy verificando la solicitud I.P. contra una expresión regular

Pero estoy nervioso acerca de esta estrategia. Se siente un poco jodido para mí. ¿Es esto razonablemente seguro?

Answer 1

filtrado IP es mejor que nada, pero tiene dos problemas:

1. direcciones IP pueden ser falseadas.

2. Si una máquina interna está en peligro (que incluye una estación de trabajo cliente, por ejemplo, mediante la instalación de un troyano), el atacante puede utilizarla como un host de salto o proxy para atacar su sistema.

Si esto es realmente datos sensibles, que no necesariamente necesita una máquina dedicada (aunque eso es mejor práctica), pero al menos debe autenticar a los usuarios de alguna manera, y no correr menos sensible (y más fácilmente atacado) aplicaciones en la misma máquina.

Y si es verdaderamente delicado, haga que un profesional de la seguridad revise lo que está haciendo.

editar: por cierto, si puedes, abandona la expresión regular y utiliza algo como tcpwrappers o las funciones de cortafuegos dentro del sistema operativo si tiene alguna. O bien, si puede tener una dirección IP diferente para su aplicación, use el firewall para bloquear el acceso externo. (Y si no tiene un cortafuegos, entonces puede darse por vencido y enviar sus datos por correo electrónico a los atacantes :-)

Answer 2

Preferiría ir con SSL y algunos certificados, o una simple protección de nombre de usuario/contraseña en lugar de IP.

Answer 3

Si está limitado por la dirección IP, aunque puedan falsificar la dirección IP, no podrán obtener la respuesta. Por supuesto, si está expuesto a Internet, aún puede recibir ataques que no sean contra la aplicación.

Answer 4

Mi primer pensamiento sobre el problema del recurso sería preguntar si no sería posible trabajar un poco de magia con una máquina virtual.

Aparte de eso, si las direcciones IP que comprueba son direcciones IP que sabe que pertenecen a computadoras que deben acceder a la aplicación o al rango de IP local, no veo cómo no podría ser lo suficientemente seguro (De hecho, estoy usando un enfoque de ATM similar en un proyecto, aunque no es increíblemente importante que el sitio se mantenga "oculto").

Answer 5

El hecho de que todas sus direcciones IP internas coincidan con una expresión regular determinada, eso no significa que todas las direcciones IP coincidan dado regex son internos. Por lo tanto, su expresión regular es un punto de posible falla de seguridad.

No sé qué tecnología utilizó para construir su sitio, pero si es Windows/ASP.net, puede verificar los permisos de la máquina solicitante en función de sus credenciales de Windows cuando se realiza la solicitud.

Answer 6

Como toda seguridad, es inútil por sí mismo. Si usted tiene que ponerlo en un servidor web público, el uso de listas blancas IP, con autenticación básica nombre de usuario/contraseña, con SSL, con una configuración de monitorización decente, con un servidor-actualizada solicitud.

Dicho esto, ¿para qué sirve tener acceso público al servidor y restringirlo solo a las direcciones IP internas? Parece que básicamente se trata de reinventar lo que NAT le ofrece de forma gratuita, y con un servidor interno, además de que debe preocuparse por los exploits del servidor web y los "me gusta".

No pareces a ganar nada por tenerla accesible desde el exterior, y hay muchos beneficios de tener teniendo que ser sólo interno ..

Answer 7

Depende exactamente lo seguro que realmente necesita que sea.

Supongo que su servidor está alojado externamente y no está conectado a través de una VPN. Por lo tanto, está comprobando que las direcciones de solicitud de su sitio HTTPS (está utilizando HTTPS, ¿no es así?) Están dentro de las redes de su propia organización.

Usar una expresión regular para hacer coincidir las direcciones IP suena dudoso, ¿no se puede simplemente usar una red/máscara de red como todos los demás?

¿Qué tan seguro es realmente necesario? La falsificación de direcciones IP no es fácil, los paquetes falsificados no se pueden usar para establecer una conexión HTTPS, a menos que también manipulen los enrutadores en sentido ascendente para permitir que los paquetes de retorno sean redirigidos al atacante.

Si necesita que sea realmente seguro, solo haga que su departamento de TI instale una VPN y enrute el espacio de direcciones IP privadas. Configure sus restricciones de direcciones IP para esas direcciones privadas. Las restricciones de direcciones IP donde el enrutamiento se realiza a través de una VPN basada en host aún son seguras, incluso si alguien pone en peligro una puerta de enlace predeterminada en sentido ascendente.

Answer 8

Si su aplicación está verificando la dirección IP, entonces es extremadamente vulnerable. En ese momento, no tiene ninguna protección en el enrutador, que es donde realmente debe estar el filtrado de IP. Su aplicación probablemente esté revisando la información del encabezado HTTP para la dirección IP de envío y esto es muy fácil de falsificar. Si bloquea la dirección IP en el enrutador, esa es una historia diferente y le comprará seguridad real sobre quién puede acceder al sitio desde dónde.

Si lo que está haciendo es acceder a la aplicación internamente, entonces SSL no le comprará mucho a menos que intente proteger la información de partes internas de la organización o requiera certificados de cliente. Esto supone que nunca accederá al sitio desde una conexión externa (las VPN no cuentan, porque está haciendo un túnel en la red interna y técnicamente es parte de ella en ese punto). No va a doler tampoco y no es tan difícil de configurar, simplemente no creo que va a ser la solución a todos sus problemas.

Answer 9

Su seguridad es tan fuerte como su enlace más débil. En el gran esquema de cosas, falsificar una IP es un juego de niños. Use SSL y requiera certificaciones de clientes.

Answer 10

Primero se hizo útil distinguir entre diferentes tipos de IP vpn según las relaciones administrativas, no la tecnología, interconectando los nodos. Una vez que se definieron las relaciones, se podrían usar diferentes tecnologías, dependiendo de requisitos tales como la seguridad y la calidad del servicio.

Answer 11

Quizás esto ayude?He estado buscando la misma respuesta, y encontré este stackoverflow así como esta idea de Red Hat Linux Ent. Lo intentaré pronto. Espero que ayude.

iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP 

Donde 0/24 es el rango de LAN que desea proteger. La idea es bloquear los dispositivos de "Internet" frente a (Delantero) para que puedan falsificar la red IP local.

Ref: http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-firewall-ipt-rule.html

Answer 12

Un servidor de seguridad adecuado puede proteger contra la falsificación de direcciones IP, y no es tan fácil como decir spoofing su identificador de llamadas, por lo que el argumento/no/a utilizar el filtrado de IP, debido al peligro suplantación de identidad es un poco anticuado. La seguridad se aplica mejor en capas, por lo que no depende de un solo mecanismo. Es por eso que tenemos sistemas WAF, nombre de usuario + contraseña, firewalls de capa 3, firewalls de capa 7, cifrado, MFA, SIEM y una serie de otras medidas de seguridad, cada una de las cuales agrega protección (con un costo creciente).

Si se trata de una aplicación web (lo que no quedó claro en su pregunta), la solución es bastante simple sin el costo de los sistemas de seguridad avanzados. Ya sea que use IIS, Apache, etc., tiene la capacidad de restringir las conexiones a su aplicación a una URL objetivo específica así como a la dirección IP de origen, sin necesidad de realizar cambios en su aplicación, por aplicación. Evitar la navegación web basada en IP de su aplicación, junto con las restricciones de origen de IP, debería brindarle una protección significativa contra la navegación/ataques casuales. Si no se trata de una aplicación web, deberá ser más específico para que la gente sepa si la seguridad basada en el sistema operativo (como ha sido propuesta por otros) es su única opción o no.

Answer 13

IP Whitelisting es, como han mencionado otros, vulnerable a la suplantación de IP y los ataques de Man in the Middle. En un MITM, considere que algún conmutador o enrutador se ha visto comprometido y verá las "respuestas". Puede monitorearlos o incluso alterarlos.

Considere también las vulnerabilidades con el cifrado SSL. Dependiendo del esfuerzo, esto también se puede frustrar en un MITM, así como también en los conocidos trucos con la reutilización de los números primos, etc.

Dependiendo de la sensibilidad de sus datos, no me conformaría con SSL , pero iría con StrongSWAN o OpenVPN para más seguridad. Si se maneja correctamente, estos serán mucho menos vulnerables a un MITM.

Depende de las listas blancas solo (incluso con SSL) Consideraría "de baja calidad", pero puede ser suficiente para sus necesidades. Solo sé muy consciente de las implicaciones y no caigas en la trampa de un "falso sentido de seguridad".