¿Cómo puedo estar seguro de que no se puede acceder a una aplicación de intranet desde Internet?

Algunas configuraciones que vienen a mi mente:

• No coloque el servidor en una DMZ
• Acepte conexiones en las direcciones 192.168.0.0 en la configuración de Apache.
• Coloque una denegación de todos + acepte desde con el rango correcto de IP en su configuración de apache
• Denegar el reenvío de conexiones VPN (?) en su firewall (si corresponde).

Su aplicación web es muy parecida a cualquier otro servicio (intercambio de archivos, impresión) que tenga funcionando en su red interna.

Por lo general, los enrutadores de Internet realizarán funciones de firewall, que bloquean el tráfico de Internet a cualquier dirección IP interna, a menos que se indique lo contrario (a través de NAT estática o redirección de puertos), por lo que el acceso directo desde Internet a un servicio interno como su sitio web no será posible.

Si desea verificar esto, puede escanear su puerto de seguridad frente a Internet. Una forma sencilla de comenzar con esto sería usar algo como Shields Up de una máquina en el mismo red, que realizará una exploración de puertos de su dirección IP externa (esto supone una red relativamente pequeña con una única dirección IP externa).

En términos de acceso indirecto a su sitio web, es posible que alguien pueda obtener acceso a través de malware en una máquina en la misma red o alguna otra ruta indirecta, pero ese es un tema un poco diferente.

Lo primero que debe verificar son las reglas del firewall, para asegurarse de que no haya reglas que permitan el acceso externo directo a los diversos servicios en el host. Verifique las reglas de "reenvío de puerto" y de "traducción de dirección estática" para estar seguro.

Luego, verifique la seguridad de todos los hosts / servicios que SON accesibles desde Internet. Si un atacante puede comprometer un host diferente en su red, una vez que estén detrás del firewall, pueden "pivotar" y obtener acceso a otros hosts en la red, incluida su aplicación.

Si desea estar absolutamente seguro, entonces necesita hacer un espacio de aire en su servidor de Intranet. Sin embargo, probablemente sería demasiado oneroso de usar.

Acerca de lo que se me ocurra es asegurarme de que utilizas el esquema de direccionamiento RFC1918 y de que las direcciones internas se caigan en la interfaz externa de tu firewall.

Estar absolutamente seguro es muy difícil aquí. Por ejemplo, cualquier máquina en la red interna puede ejecutar el proxy HTTP en un puerto aleatorio, a veces incluso llevando la conexión SSH a la red externa y conectando el tráfico sobre ella. A menos que el puerto HTTP sea el único puerto abierto en su firewall en ambas direcciones y su Apache sea la única máquina en la red que tenga permiso para aceptar / iniciar conexiones con el mundo exterior, es difícil estar al 100% seguro.

Esto tampoco es solo un escenario teórico; He hecho configuraciones como esta (es decir, proxy HTTP + túnel SSH) a propósito, para acceder a la intranet corporativa cuando estoy trabajando en casa. Solo debe ser consciente de las implicaciones de seguridad al hacerlo.

En mi opinión, un servicio de intranet que necesita ser realmente seguro no debería depender únicamente de estar en una red privada, sino que debe usar SSL, cuentas de usuario y permisos específicos de la cuenta para controlar el acceso, incluso para estar remotamente seguro.

Suponiendo que probablemente emprenderá esfuerzos similares en un futuro cercano, creo que se requiere un enfoque diferente al que se ha propuesto en las respuestas anteriores. Me gustaría sugerirle que describa y establezca una estrategia para "asegurar" futuras aplicaciones / sistemas. Al utilizar una estrategia, puede garantizar la coherencia, delegar responsabilidades y mejorar su práctica a lo largo del tiempo.

Creo que la protección de un servidor no debe hacerse de manera ad hoc, sino de forma metodológica y coherente. Debe ser un proceso repetible con el menor margen de error posible. Nosotros, los humanos, somos notoriamente malos para recordar detalles, a menudo combinando fragmentos de información en algo completamente diferente.

En el escenario que describiste anteriormente, una perspectiva de Disponibilidad parece ser mayormente relevante y útil. Comience por describir el establecimiento de dependencias del sistema. ¿Qué otros sistemas deben ser accesibles para que la aplicación funcione? ¿Dependes de un directorio de usuarios externo? Las dependencias son importantes porque ayudan a comprender mejor las posibles "vías", o vectores, de ataque.

A continuación se detallan los detalles de quién debe tener acceso al sistema y al "terminal" de acceso principal (escritorio remoto, estación de trabajo, computadora portátil, teléfono móvil, etc.). Al hacer esto, habrá comenzado a establecer su marco de referencia, o límite del sistema, si lo desea.

Es muy probable que haya limitaciones organizativas a las que simplemente deba obedecer. Estos pueden incluir métodos de autenticación exigidos por la compañía, algoritmos de cifrado y otros, describir y documentar estas limitaciones. Es posible que también deba considerar los requisitos legales, y ahora puede ser un buen momento para averiguarlo.

Una vez que haya establecido los bloques de construcción más "fundamentales" de su sistema, es hora de una lluvia de ideas creativa. Intente y describa todas las vías posibles a través de las cuales usted (o un atacante) podría acceder al sistema utilizando la descripción del sistema anterior como una especie de limitación.

Lo que deberá hacer a continuación es determinar qué controles de seguridad garantizarían la protección más adecuada. Sí, lo sé, aquí es donde las cosas se complican porque es un proceso algo subjetivo pero independientemente de lo necesario. Cada contramedida que determine que es necesaria se asociará con un determinado costo (tiempo de instalación, configuración, mantenimiento y eventualmente retiro).

También querrá intentar y describir con algún tipo de medida cuantitativa cómo "bien" una colección de contramedidas mitiga un riesgo particular, o "limita" una avenida de ataque. Creo que esto es importante, especialmente para la "alta gerencia", habla un lenguaje de números. Por ejemplo, una "buena" implementación de contraseñas con sal eliminará por completo la amenaza de las tablas hash precomputadas y, por lo tanto, podría describirse como una contramedida de "alta seguridad".

En resumen:

1. Determine el objetivo / objetivo principal de seguridad (confidencialidad, integridad y disponibilidad)
2. Establecer dependencias del sistema
3. ¿Quién, cómo y cuándo?
4. Detalle de los requisitos / limitaciones / restricciones legales y / o organizacionales
5. Vectores de ataque de lluvia de ideas (supongo que podrías llamar a esto un análisis ligero de amenazas)
6. Elija las contramedidas apropiadas para el sistema en cuestión
7. Haz arco iris, gráficos coloridos y unicornios.

Una forma de asegurarse de que los paquetes que se originan en su aplicación no lleguen a terceros es mediante la manipulación del valor de ttl utilizando iptables. Supongo que está utilizando Linux para alojar su aplicación.

En un protocolo de enlace TCP, un atacante podría alcanzar su servidor web con un paquete SYN, pero su enrutador eliminará los paquetes que están destinados fuera de su red interna.

Un ejemplo de esto es avahi-daemon . Ignorará todos los paquetes que no tengan el IP TTL establecido en 255, lo que significa que tiene que provenir de su propio segmento de red.

En un sistema Linux, puede elegir entre modificar el ttl saliente para puertos específicos o globalmente a través de sysctl.

Esta solución no es infalible y probablemente presentará algunos problemas de disponibilidad, como: clientes que se conectan a través de VPN, multiplicar las rutas con saltos de red inigualables a las puertas de enlace fronterizas.

Iptables:

El tutorial de iptables para objetivo TTL explica cómo construir una regla para este problema . Esto también se explica aquí Cómo configurar ttl .

Sysctl:

echo "1" > / proc / sys / net / ipv4 / ip_default_ttl

Incluso si no se puede acceder al servidor directamente desde el exterior, los usuarios que se conectan al servidor tienen un enlace al exterior.

¿No es posible que algunos programas maliciosos se instalen en un sistema de usuarios, que luego se utiliza para acceder al servidor?

Por ejemplo, (un ejemplo no de malware, pero aún da la idea)

Teamviewer está instalado en una PC de usuarios

Alguien se conecta a Teamviewer desde afuera

El forastero usa la PC de los usuarios para conectarse al servidor