Tengo un portal web corporativo que se utiliza para la colaboración del personal, incluida una interfaz de correo basada en la web conectada a la base de datos MySQL, calendario corporativo, almacenamiento de archivos, datos de contactos de clientes con números de teléfono y correos electrónicos, y todo tipo de datos. Por supuesto, algunos de esos datos son confidenciales, ya que se relacionan con asuntos corporativos internos y con la privacidad del cliente.
Todo el sitio está escrito en PHP + JavaScript con la base de datos MySQL en Ubuntu (Apache). Busqué todo el código y reemplacé todas las declaraciones SQL en declaraciones preparadas para evitar las inyecciones de SQL. Ninguno de los formularios web permitía a los usuarios enviar datos HTML, solo texto en relieve, tampoco almaceno HTML en tablas MySQL para evitar las secuencias de comandos entre sitios. Puse una defensa de fuerza bruta al retrasar el siguiente intento de un usuario después de escribir una contraseña incorrecta. La autorización se realiza en dos pasos y el usuario primero escribe su nombre y contraseña y luego el sistema envía SMS a ese usuario con un código de autorización. Todo el sitio funciona solo a través de HTTPS y conectado a Internet a través de un firewall que permite solo 443 puertos para conexiones entrantes, es decir, sin FTP, samba, sin conexión externa MySQL o cualquier otro servicio disponible. La página principal del sitio está vacía y los motores de búsqueda ni siquiera pueden encontrar una página de inicio de sesión para indexar, por lo que si uno no sabe la dirección exacta, ni siquiera podría iniciar un proceso de autorización. No conozco ninguna otra forma de piratearlo.
Sin embargo, estaba intentando obtener una consulta de un especialista en seguridad y, a pesar de todas las medidas tomadas, insiste en conectar a cualquier cliente externo a través de un cliente VPN (L2TP IPSec) que está integrado en cualquier sistema operativo moderno de Windows o Linux. Ya que este no es un sitio público, podría hacerlo, pero eso requerirá un trabajo adicional con los clientes para explicarles cómo conectarlos y darles un par más de contraseña de inicio de sesión. También me dijeron que PHP originalmente era un lenguaje de página de inicio personal sin atención a la seguridad y que aún podía tener vulnerabilidades de seguridad. No pudo dar ningún ejemplo. Me pregunto si realmente existen y cuáles son. ¿Realmente aumentaría la seguridad cambiando a los clientes al acceso de VPN en lugar de HTTPS directo o simplemente les molestará inútilmente?
ACTUALIZACIÓN (un mes después)
Después de jugar con el túnel VPN y los clientes VPN, no creo que sea una buena idea crear un túnel VPN a través de HTTPS porque lo que tengo es un servidor WEB con HTTPS detrás de NAT. Tengo todos los puertos bloqueados, excepto el 443, así que Solo creo que un usuario puede hacer es acceder a eso.
Si creo un canal VPN, les permito a los usuarios acceder a mi red local para que tengan acceso al enrutador NAT desde adentro (desde los puertos LAN) y tengan acceso a todo el servidor que cumple la función del servidor WEB. Por lo tanto, un usuario malintencionado que hackeó el inicio de sesión / contraseña de VPN y se introdujo dentro de LAN, es decir, se puso detrás del NAT y ahora puede comenzar a piratear no solo el servidor en todos los puertos, sino también el enrutador. Para evitar que necesite otro servidor de seguridad y, probablemente, otro dispositivo para crear redes LAN virtuales.
¿Realmente vale la pena?
Más sobre el diagrama de red
En cuanto al diagrama de red, el servidor local tiene dos interfaces de red: una para la red interna y otra para la conexión a Internet.
El acceso a Internet en ese servidor local a través de dos puntos NAT:
1) La conexión a Internet va desde la IP externa a través de Windows Server 2008. Ese servidor de Windows comparte la conexión a Internet con las personas en la oficina y también tiene RRAS configurado para reenviar el puerto 443 a una de las direcciones locales (digamos que funciona) a 192.168.0.100). También hay un firewall de terceros que permite conexiones entrantes solo en el puerto 443.
2) Luego tengo un enrutador en esa dirección local (192.168.0.100) que puede manejar túneles VPN de solo reenvío de puertos. Por ahora, solo reenvía el puerto 443 a su LAN a la que está conectado el servidor local. Eso hace que el servidor local se separe de todos los demás equipos que están obteniendo Internet del Win Server 2008.
Aparte de eso, hay una red independiente completa sin conexión a Internet. El servidor local es parte de él utilizando su segunda interfaz de red. No hay ningún enrutador allí, solo un interruptor.