Digamos que tengo un equilibrador de carga (HAProxy) y dos servidores web uno es hackeado ¿Puede el atacante hacer conexiones salientes cuando los servidores web no tienen acceso directo a Internet (solo servidores de actualización de ubuntu) y conexiones al equilibrador de carga?
¿Qué tal un proxy inverso (nginx)? ¿Esto evitaría conexiones directas salientes? ¿Cómo podrían engendrar una concha? (Deshabilitaría ICMP y DNS, y verificaría la integridad de los archivos de la aplicación web)
Entrante y saliente es solo sobre la dirección en la que se crea la conexión. Una vez establecida la conexión, los datos pueden fluir en ambas direcciones . Por lo tanto, se puede utilizar una conexión entrante para transmitir información al exterior.
Déjame dar algunos ejemplos:
Un error común relacionado con la seguridad es almacenar archivos cargados en una carpeta que el servidor web sirve directamente y para la cual no se deshabilitó la ejecución del script. Por lo tanto, un atacante puede cargar phpshell (o programas similares escritos en perl, python, jsp, asp, ...) y simplemente conectarse al shell utilizando una solicitud http normal. Sí, usted dijo que supervisa los archivos de la aplicación web, pero las carpetas de carga se excluirían de esa supervisión por diseño.
El ataque puede estar completamente en la memoria sin que se haya escrito ningún archivo en el disco; pensar en un ataque de Stackoverflow. Si ve algunas solicitudes de http hechas al servidor web, el atacante puede usarlas para comunicarse en ambas direcciones.
Dependiendo de los permisos, es posible realizar ataques similares usando inyección SQL : el atacante puede crear un procedimiento almacenado con el código del programa que "carga" dentro del ataque de inyección SQL. La vulnerabilidad de inyección SQL se utiliza desde el exterior para transmitir datos en cualquier dirección.
El protocolo clásico para hacer un túnel después de http (s) es DNS . Es muy fácil cerrar las conexiones http salientes y hacer excepciones para las conexiones a los servidores de actualización. Sin embargo, debido a la naturaleza distribuida del DNS, se requiere la inspección del protocolo para filtrarlo mientras se permite la búsqueda de los servidores de actualización.
La respuesta corta es SÍ , un atacante aún puede abrir un shell a pesar de estas condiciones.
Usando iptables puede negar todas las entradas entrantes, excepto tcp 80 y 443 para http y https respectivamente. Además, puede negar todo el tráfico saliente (pero aún así desearía permitir actualizaciones). Pero esto solo puede hacer mucho. Desea proteger su aplicación web y sería más beneficioso utilizar un Firewall de aplicaciones web (WAF) como mod_security .
En una plataforma de aplicaciones web debería estar más preocupado por el owasp top 10 y exploits de aplicaciones web . Una preocupación importante es que un atacante explota su sistema y luego instala una puerta trasera como el C99 shell . En este caso, iptables no significa nada, tiene que permitir http / https y eso es todo lo que necesita el atacante.
El bloqueo del acceso con iptables hace que el sistema sea más difícil de comprometer con un desbordamiento de búfer. Por ejemplo, download + exec shellocde es muy común porque es un ataque directo donde la víctima descarga y ejecuta una puerta trasera. Sin embargo, el atacante no necesita una conexión para cargar y ejecutar un archivo. Al utilizar un egg-hunter como puesta en escena una vulnerabilidad de desbordamiento de búfer, el atacante puede incluir una gran cantidad de complejidad en la carga útil. Por ejemplo, esto permitiría al atacante cargar su ejecutable en la memoria y luego escribirlo en un archivo.
La línea de fondo es Defensa en profundidad y seguridad en capas. Utilice los conjuntos de reglas de firewall más restrictivos que pueda.