¿Qué tan seguro es el filtrado de direcciones IP?

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

Si su aplicación está comprobando la dirección IP, entonces es extremadamente vulnerable. En ese punto, no tiene ninguna protección en el enrutador, que es donde realmente debe estar el filtrado de IP. Su aplicación probablemente está comprobando 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 generará cierta seguridad real sobre quién puede acceder al sitio desde dónde.

Si eres 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 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 momento). No va a doler tampoco y no es tan difícil de configurar, solo no creo que va a ser el solución a todos sus problemas.

Depende exactamente de lo seguro que realmente necesita que sea.

Asumo 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 para su HTTPS (está utilizando HTTPS, ¿no??) están dentro de las redes de su propia organización.

El uso de una expresión regular para que coincida con las direcciones IP suena dudoso, ¿no se puede utilizar una red/máscara de red como todos los demás?

¿Qué tan seguro tiene que ser realmente? La suplantación de direcciones IP es 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 ascendentes para permitir que los paquetes devueltos sean redirigidos al atacante.

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

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

Mi primer pensamiento sobre el problema de los 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 que verifica son IP que SABE 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 (en realidad estoy utilizando un atm de enfoque similar en un proyecto, aunque no es increíblemente importante que el sitio se mantenga "oculto").

Solo porque todas sus IP internas coincidan con una regex dada, eso no significa que todas las IP que coincidan con una regex dada sean internas. Por lo tanto, su expresión regular es un punto de posible fallo de seguridad.

No se qué tecnología utilizaste para construir tu sitio, pero si es Windows/ASP.net, puedes comprobar los permisos de la máquina solicitante basándose en sus credenciales de Windows cuando se realiza la solicitud.

Como toda seguridad, es inútil por sí sola. Si tiene que ponerlo en un servidor web público, use una 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 tener el servidor accesible públicamente, y luego restringirlo a solo direcciones IP internas? Parece que básicamente está reinventando lo que NAT te da de forma gratuita, y con un servidor solo interno, además de que tiene que preocuparse por exploits de servidores web y similares.

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

Tu seguridad es tan fuerte como tu eslabón más débil. En el gran esquema de las cosas, suplantar una IP es un juego de niños. Utilice SSL y requiera certificados de cliente.

Primero fue útil distinguir entre diferentes tipos de IP vpn basado en las relaciones administrativas, no en la tecnología, que interconecta los nodos. Una vez definidas las relaciones, se podrían utilizar diferentes tecnologías, dependiendo de requisitos como la seguridad y la calidad del servicio.

Tal vez esto ayudará ? 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 LAN que desea proteger. La idea es bloquear los dispositivos orientados a" Internet " (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 firewall adecuado puede proteger contra la suplantación de IP, y no es tan fácil como decir suplantación de su identificador de llamadas, por lo que el argumento /no/ para usar el filtrado de IP debido al peligro de suplantació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, cortafuegos de capa 3, cortafuegos 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 esta es una aplicación web de la que estás hablando (lo cual no estaba claro en tu pregunta), la solución es bastante simple sin el costo de los sistemas de seguridad avanzados. Ya sea usando 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 (no es necesario realizar 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 origen de IP, debe darle protección significativa contra la navegación casual / ataques. Si esto no es una aplicación web, tendrá que ser más específico para que la gente sepa si la seguridad basada en el sistema operativo (como ha sido propuesto por 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 Man-in-the-Middle. En un MITM, considere que algún switch o enrutador ha sido comprometido y verá las "respuestas". Puede monitorearlos o incluso alterarlos.

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

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

La confianza en la lista blanca solo (incluso con SSL) consideraría "bajo grado", pero puede ser suficiente para sus necesidades. Simplemente sea muy consciente de las implicaciones y no caiga en la trampa de una "falsa sensación de seguridad".