Pregunta

Estoy planeando implementar una aplicación interna que tenga datos confidenciales. Sugerí que lo pusiéramos en una máquina que no estuviera 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 aplicación. (La aplicación tiene su propio dominio en caso de que sea relevante, pero me dijeron que no pueden bloquear solicitudes basadas en la URL).

Dentro de la aplicación, la programé para respetar solo las solicitudes si provienen de un 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 revisando la solicitud I.P. contra una expresión regular.

Pero estoy nervioso por esta estrategia. Se siente un poco extraño para mí. ¿Es esto razonablemente seguro?

¿Fue útil?

Solución

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

  1. Las direcciones IP pueden ser falsificadas.

  2. Si una máquina interna se ve comprometida (eso incluye una estación de trabajo cliente, por ejemplo, mediante la instalación de un troyano), entonces el atacante puede usarla como un host de salto o proxy para atacar su sistema.

Si se trata de datos realmente confidenciales, no necesariamente necesita una máquina dedicada (aunque esa es la mejor práctica), pero al menos debe autenticar a sus usuarios de alguna manera y no ejecutar menos confidenciales (y atacarlos más fácilmente) aplicaciones en la misma máquina.

Y si es realmente sensible, solicite a un profesional de seguridad que revise lo que está haciendo.

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

Otros consejos

Prefiero usar SSL y algunos certificados, o una simple protección de nombre de usuario / contraseña en lugar del filtrado de IP.

Depende exactamente de cuán seguro realmente necesites que sea.

Supongo que su servidor está alojado externamente y no está conectado a través de una VPN. Por lo tanto, está verificando que las direcciones solicitantes para 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 que coincida con las direcciones IP suena dudoso, ¿no puedes usar una red / máscara de red como todos los demás?

¿Qué tan seguro debe ser realmente? La suplantación de direcciones IP no es fácil, los paquetes falsificados no se pueden utilizar para establecer una conexión HTTPS, a menos que también manipulen los enrutadores ascendentes para permitir que los paquetes de retorno se redirijan al atacante.

Si necesita que sea realmente seguro, simplemente solicite a su departamento de TI que instale una VPN y enrute el espacio de direcciones IP privadas. Configure las restricciones de su dirección IP para esas direcciones privadas. Las restricciones de dirección IP en las que el enrutamiento se realiza a través de una VPN basada en host siguen siendo seguras, incluso si alguien compromete una puerta de enlace predeterminada ascendente.

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. Es probable que su aplicación esté verificando la información del encabezado HTTP para la dirección IP de envío y esto es extremadamente fácil de falsificar. Si bloquea la dirección IP en el enrutador, esa es una historia diferente y le dará 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 esté tratando de proteger la información de las partes internas de la organización, o si necesita 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 momento). Tampoco dolerá y no es tan difícil de configurar, simplemente no piense que será la solución a todos sus problemas.

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

¿Mi primer pensamiento sobre el tema de recursos sería preguntar si no sería posible hacer algo de magia con una máquina virtual?

Aparte de eso: si las direcciones IP con las que comprueba son IP que conoce que pertenecen a computadoras que se supone que deben acceder a la aplicación o en el rango de IP local, entonces no puedo ver cómo no podría ser lo suficientemente seguro (I En realidad estoy usando un cajero automático de enfoque similar en un proyecto, aunque no es increíblemente importante que el sitio se mantenga "oculto").

El hecho de que todas sus IP internas coincidan con una expresión regular dada, eso no significa que todas las IP que coincidan con una expresión regular dada sean internas. Entonces, su expresión regular es un punto de posible falla de seguridad.

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

Como toda seguridad, es inútil por sí solo. Si tiene que ponerlo en un servidor web público, use la lista blanca de IP, con autenticación básica de nombre de usuario / contraseña, con SSL, con una configuración de monitoreo decente, con una aplicación de servidor actualizada.

Dicho esto, ¿cuál es el punto de hacer que el servidor sea de acceso público, luego restringirlo a solo direcciones IP internas? Parece que básicamente está reinventando lo que NAT le ofrece de forma gratuita, y con un servidor solo interno, además tiene que preocuparse por las vulnerabilidades del servidor web y los gustos.

Parece que no gana nada al tenerlo accesible externamente, y hay muchos beneficios de tenerlo solo para uso interno ...

Su seguridad es tan fuerte como su eslabón más débil. En el gran esquema de las cosas, falsificar una IP es un juego de niños. Use SSL y requiera certificados del cliente.

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

¿Quizás esto ayude? He estado buscando la misma respuesta y encontré este stackoverflow y 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 "internet" frente a dispositivos (hacia adelante) para que no puedan falsificar la red IP local.

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

Un cortafuegos adecuado puede proteger contra la falsificación de IP, y no es tan fácil como falsificar su identificación de llamada, por lo que el argumento / no / utilizar el filtrado de IP debido al peligro de falsificación 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, encriptación, 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 de la que está hablando (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 de destino específica, así como a la dirección IP de origen, sin cambios en su aplicación, por aplicación. La prevención de la navegación web basada en IP de su aplicación, junto con las restricciones de la fuente IP, debería brindarle una protección significativa contra la navegación / ataques casuales. Si no se trata de una aplicación web, tendrá que ser más específico para que las personas sepan si la seguridad basada en el sistema operativo (como han propuesto otros) es su única opción o no.

La lista blanca de IP es, como otros han mencionado, 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 puede frustrarse en un MITM, así como 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, sino que elegiría StrongSWAN u OpenVPN para mayor seguridad. Si se maneja adecuadamente, serán mucho menos vulnerables a un MITM.

Confianza en la lista blanca solo (incluso con SSL) Consideraría "bajo grado", pero puede ser suficiente para sus necesidades. Solo tenga mucho cuidado con las implicaciones y no caiga en la trampa de una "falsa sensación de seguridad".

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top