¿Cómo proteger el servicio web en una red privada?

La respuesta corta es "sí, debes preocuparte".

Los ataques modernos casi siempre se dirigen a los clientes; y una vez que un atacante tiene un punto en su red, puede pivotar hacia cualquier recurso al que tenga acceso el cliente. Él / ella también puede ser capaz de "manejar el medio" del tráfico en su LAN; O mejor aún: obtenga credenciales para los conmutadores / enrutadores y rastreadores de su red.

Por lo tanto, le sugiero que definitivamente use https (TLS 1.2 o superior) en el servicio web. Las sesiones también deben ser autenticadas: para conveniencia del usuario, es posible que necesite utilizar algún tipo de cookie de sesión o "inicio de sesión único" con Kerberos o similar.

Además: su servidor de base de datos debe estar protegido. ¿Hay alguna razón para que los clientes se conecten directamente a él? Probablemente no. Entonces, use algún tipo de servidor de seguridad frente al servidor de la base de datos para limitar las conexiones entrantes: ¡solo los servidores de aplicaciones / web y los servidores de administración de sistemas necesitan acceso!

Los cortafuegos en el perímetro son importantes, pero están lejos de ser la única defensa que necesitas. Para el fondo, considere algunas de las violaciones de alto perfil que hemos visto en las noticias recientemente. El acceso no se obtuvo a través de un cortafuegos, casi siempre se logró al comprometer a un cliente que ya está dentro de la red.

¿Debería preocuparme que tengamos un servicio web a través de http sin ninguna autenticación?

Sí, deberías !

  

Tu peor enemigo podría estar dentro de tu red. Le mostraremos cómo evitar que personas con información privilegiada compartan / destruyan sus datos críticos.

Dado que su base de datos será accesible desde todos los usuarios de su red, es mejor que tenga autenticados para que pueda determinar quién hizo qué ...

En muchas empresas, las siguientes prácticas recomendadas son solo para servicios web / aplicaciones web expuestas:

• Los HTTP se aplicarán de forma predeterminada. El costo de soportar https es insignificante. El único inconveniente es el certificado SSL, pero como es interno, puede crear su propia ca y distribuir el certificado CA raíz en sus máquinas internamente.
• AAA (autenticación, autorización y contabilidad). Siempre debe tener algún tipo de solución IAM / UAM para sus servicios web para cumplir con el principio de privilegios mínimos. Si las personas no necesitan tener acceso a los datos, ¡no les permita! La contabilidad (registro, monitoreo ...) puede proporcionar datos importantes cuando algo malo sucedió. No le dé mucha confianza a sus empleados / compañeros de trabajo. informe

Si hay usuarios que pueden acceder a estos servicios web internos con el mismo navegador que las solicitudes a sitios externos, una visita a una página externa podría desencadenar solicitudes a su sitio interno, es decir, CSRF. Si bien el atacante no podía leer los datos directamente de esta manera, al menos podía escribir datos y, con un ataque de reinicio de DNS adicional, incluso podría leer datos también.

Tenga en cuenta que TLS solo no ayudará en este caso. Lo que ayudará será el uso de certificados de clientes con TLS o con una contraseña, de modo que solo los clientes autorizados (es decir, sus otros servidores) puedan acceder al servicio web. Asumiré que estos servidores no ejecutarán navegadores normales, sino solo programas para acceder solo a su servicio web, por lo que no será posible usar un ataque CSRF con estos programas del lado del servidor.

En cambio, si su red privada está completamente separada del resto del sistema (no tiene acceso directo o indirecto), probablemente no tenga que preocuparse mucho por ahora. Pero tenga en cuenta que las estructuras de la red cambian y lo que hoy es una red aislada podría conectarse a otra red mañana y, a menudo, sin un análisis más profundo de las implicaciones de seguridad.

  

El "problema" realmente parecía estar desperdiciando el tiempo para configurar TLS para "nada".

Si puede garantizar que nadie en su red puede detectar el tráfico, es posible que TLS no sea necesario. Por supuesto, esto es fácil de decir pero es difícil de controlar: puede haber usuarios maliciosos, pero los sistemas más comprometidos probablemente sean más peligrosos. Debido a que sus comentarios muestran que los usuarios de su red pueden acceder a Internet, es probable que tarde o temprano un sistema cliente se vea comprometido. Y a menos que su red esté realmente protegida contra todas las formas en que se puede detectar la contraseña, probablemente se detecte (consulte también ¿Cuáles son los riesgos de ejecutar Team Fundation Server en HTTP? ).

Puede procesar por pasos y replicarlos para cada servidor.

Puede proteger el entorno de su servidor: prohibir el acceso a los exámenes físicos por parte de personas no autorizadas

Puede filtrar las direcciones IP a las que se permite acceder al servidor (tal vez el diálogo del servidor de la base de datos solo con el servidor web y el administrador). pc)

Puede limitar los puertos abiertos en sus servidores y limitar los servicios en ejecución.

Para cada servicio puede aplicar políticas de seguridad, por ejemplo, para su servicio web:

• forzar https, forzar la autenticación con una contraseña segura o certificats
• intentos de límite de conexión
• controla las conexiones con fail2ban o ohter
• aplique los derechos en sus bases de datos de la forma más estricta posible (el usuario puede leer y / o escribir en qué tabla), prohibir que el usuario root se conecte a su base de datos desde la red.

La idea subyacente es aplicar las buenas políticas en cada aspecto de su red y en sus servidores.

En tu caso,

  

el servicio web puede modificar los datos en nuestro   bases de datos por lo que si un atacante pudiera acceder a él, podría alterar   nuestros datos importantes.

parece importante aplicar estas políticas de seguridad esenciales.