¿A qué puede llegar todavía una pasarela web comprometida?
Una pasarela web limita lo que abre un visitante, no lo que puede marcar un host comprometido. Dos revisiones, una tabla de autoridad y comandos para medir el alcance.
Supongamos que el host de la pasarela está comprometido mientras su certificado sigue siendo válido. Todas las reglas que regían qué páginas puede solicitar un visitante siguen vigentes, y ninguna de esas reglas limita la conexión que el atacante abre ahora desde ese host hacia la subred de la base de datos. Esa brecha es la razón por la que un punto de entrada solo web no es la misma afirmación que una red segmentada. Las dos afirmaciones necesitan revisiones separadas, desde puntos de partida distintos, antes de que cualquiera de ellas pueda formularse con honestidad.
Dos afirmaciones, y solo una de ellas empieza en el visitante
La primera afirmación trata de una persona: un visitante con un navegador y una sesión válida puede abrir una aplicación y nada más. Un punto de entrada solo web responde bien a esa afirmación, porque el visitante recibe una página en lugar de una ruta. Esa respuesta merece conservarse, y también es la única afirmación que registran la mayoría de los diagramas.
La segunda afirmación trata de un componente: se supone que la pasarela, o el proceso de aplicación que hay detrás, está bajo el control de otra persona. A partir de ese supuesto, la pregunta cambia de qué URL se permiten a qué destinos e identidades puede seguir llegando el proceso.
Las dos afirmaciones tienen propietarios distintos, producen pruebas distintas y fallan de forma independiente. Un equipo de identidad puede demostrar la primera con una prueba de sesión; la segunda necesita política de red, revisión de la cuenta de servicio y controles del host. Un diseño que solo registra la mitad del visitante parece completo en una diapositiva de revisión y escaso durante un incidente, porque los controles que importan después de un compromiso nunca estuvieron en el alcance. Nombre qué afirmación respalda cada control, o una regla de pasarela se atribuirá a las dos.
Un servicio de gastos desarrollado, y las dos formas en que pierde
Tomemos un servicio de gastos: una pasarela pública en 10.60.4.10 autentica al personal y reenvía las solicitudes aprobadas a un receptor de aplicación en el puerto 8443, y esa aplicación llega a un único receptor PostgreSQL en 10.60.4.20:5432 como el rol expenses_app. No se pretende que los empleados reciban acceso interno general. En funcionamiento normal, el diseño sí entrega una entrada específica de la aplicación sin publicar el receptor de la base de datos en ningún sitio. Las direcciones importan, porque cada comprobación posterior en este artículo las nombra.
Ahora quite la pasarela del conjunto de confianza. ¿A qué destinos puede llegar 10.60.4.10 una vez que su proceso pertenece a un atacante? El filtro de URL que restringía a los visitantes no dice nada sobre una conexión que el host de la pasarela abre hacia la subred de la base de datos.
Quite en cambio el proceso de aplicación, y la autoridad cambia de forma: el rol expenses_app, los servicios que ese servidor puede alcanzar y los archivos que esa cuenta puede leer. En ambos casos la puerta de entrada puede seguir siendo solo web mientras falta el límite del backend. Por tanto, la etiqueta de la puerta de entrada no es respuesta a ninguna de las dos preguntas.
Mapee la autoridad que cada parte posee realmente
Un contrato escrito como permisos previstos tiende a repetirle el diseño. Escríbalo como autoridad poseída, la comprobación que refuta el exceso y el propietario de esa comprobación, y cada fila se vuelve comprobable. Esta tabla es una propuesta para el ejemplo anterior, no una afirmación de producto:
| Component | Authority it actually holds | Check that proves the denial | Owner of the check |
|---|---|---|---|
| Identity provider | Issues assertions and session cookies, and holds no network path of its own | A request to the application URL without a session is redirected to the login page | Identity team |
| Public gateway host | TCP reachability to whatever its routing table and egress rules permit | An egress rule drops 10.60.4.20:5432 and the probe reports the port filtered | Network platform team |
| Application role | SQL privileges granted to expenses_app inside the expenses database | A privilege query shows no ownership or create right on any other schema | Application team |
| Database listener | Accepts connections only from the source ranges named in its host-based rules | A connection from an unlisted address is refused before authentication | Database administrator |
| Management path | Administrative access reserved for patching, monitoring and recovery | A staff workstation cannot reach the administrative port or jump through it | Platform owner |
La propiedad sigue a la autoridad. El equipo de identidad posee las aserciones, el equipo de plataforma de red posee las rutas, el equipo de aplicación posee el rol de base de datos, el administrador de base de datos posee el receptor y sus reglas basadas en host, y el propietario de la plataforma posee el plano de gestión. Una denegación sin propietario es una frase en un documento, no un control.
La división también evita el doble cómputo. Una restricción de puerto no puede expresar un privilegio de tabla, y un rol de base de datos no puede impedir que un host abra un socket hacia una subred no relacionada.
Enumere a qué puede llegar la pasarela en lugar de afirmarlo
Una afirmación de límite vale tanto como la enumeración que la respalda. En el host de la pasarela, tres comandos cubren la selección de ruta, una sonda en vivo y la política de salida:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputLea la salida en ese orden. La ruta dice si 10.60.4.20 se selecciona siquiera desde ese host; la sonda dice si el receptor responde; el listado de reglas muestra si la política detiene el paquete o si nunca hubo nada en su camino.
Repita la enumeración desde el host de la aplicación. Desde allí, el lado de la base de datos es una consulta ejecutada como el rol de la aplicación:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'Una conexión correcta bajo un rol que no puede leer otro esquema es un resultado distinto de una conexión correcta bajo un rol propietario. Solo la segunda es un hallazgo.
Registre las denegaciones y después feche la revisión
La aceptación se escribe como resultados y no como intenciones: una sesión de empleado no puede llegar al receptor, el host de la pasarela no puede llegar a una subred no relacionada y el rol de la aplicación no puede crear una base de datos. Cada una es una comprobación separada con un propietario nombrado y una fecha.
Mantenga el monitoreo, el parcheo y la recuperación accesibles por la ruta de gestión diseñada para ellos. Un límite que también bloquea a su propietario se convierte en una interrupción, y la primera respuesta habitual a esa interrupción es volver a ampliar la regla. La guía de perímetro de la CISA pide limitar el acceso entrante y saliente a puertos y protocolos justificados, incluido el tráfico entre redes internas, que es la dirección iniciada por el backend que la mayoría de los diagramas omite.
Feche la revisión y nombre a su propietario. Vuelva a ejecutar la enumeración y la consulta de privilegios tras cualquier cambio en la imagen de la pasarela, la tabla de rutas o el rol de la aplicación.