Loading
_ DESCIFRANDO CONEXIÓN SEGURA...

NAT y proxy, quién es quién según dónde se mire

5 tareas · 45 min · Principiante

La 5-tupla que ve un sensor depende de dónde está puesto el sensor. Del lado de adentro del cortafuegos, el origen es el equipo. Del lado de afuera, la traducción de direcciones (NAT) ha cambiado esa dirección por la de la empresa, y si hay un proxy de por medio, el origen que ve un sensor de la red interna es el proxy y no quien le pidió la página. Esta sala sirve para deshacer esos dos cambios con el registro de la traducción y con el del proxy. Jueves 8 de abril, sede de Puerto Lleras del Frigorífico del Ariari.

0 de 5 · 0%

Objetivo de la sala

La 5-tupla que ve un sensor depende de dónde está puesto el sensor. Del lado de adentro del cortafuegos, el origen es el equipo. Del lado de afuera, la traducción de direcciones (NAT) ha cambiado esa dirección por la de la empresa, y si hay un proxy de por medio, el origen que ve un sensor de la red interna es el proxy y no quien le pidió la página. Esta sala sirve para deshacer esos dos cambios con el registro de la traducción y con el del proxy. Jueves 8 de abril, sede de Puerto Lleras del Frigorífico del Ariari.

Casi todas las redes de empresa usan direcciones privadas por dentro y una sola dirección pública, o muy pocas, para salir a internet. El cortafuegos hace la traducción: cuando un puesto sale, cambia su dirección y su puerto de origen por la dirección pública de la empresa y un puerto que él mismo asigna, y apunta la correspondencia para devolver las respuestas al equipo correcto. Varios equipos comparten así una sola dirección pública, y lo único que los separa hacia afuera es el puerto.

Un sensor colocado afuera del cortafuegos, en el borde, ve la conversación ya traducida: dirección pública y puerto asignado. El equipo de adentro no aparece en ningún campo de esa línea. La alerta que sale de ese sensor, por buena que sea, no nombra a nadie de la red interna.

Responde para continuar

Un sensor del borde, afuera del cortafuegos, alerta sobre la conexión de un puesto de la sede. ¿Qué origen trae esa alerta?

Para volver del puerto público al equipo se usa el registro de traducciones del cortafuegos: una fila por traducción, con la dirección y el puerto internos, los públicos, el destino y las horas entre las que estuvo viva. La clave para encontrar la fila no es el puerto solo, porque el cortafuegos reutiliza los puertos públicos cuando una traducción se cierra. La clave es el puerto público, el destino y la hora de la alerta que caen dentro de la vida de esa fila.

Busca en el registro todas las veces que se usó el puerto de la alerta del borde y quédate con la que estaba viva cuando el sensor la vio. Si hay dos filas con el mismo puerto, la hora decide.

Responde para continuar

Escribe la dirección interna que estaba detrás de la conexión alertada por el sensor del borde.

Ver pista de ayuda

Ejecuta `SELECT * FROM sensor_borde` para leer el puerto, la hora y el destino de la alerta, y `SELECT * FROM nat_log WHERE puerto_publico = 41822` para ver cuál de las filas estaba viva a esa hora.

Hay una consecuencia práctica de que hacia afuera todo salga con una dirección compartida. Si un compañero propone cortar en el borde la dirección pública de la alerta, ese corte no distingue entre equipos: se corta lo que la misma dirección carga de todos los demás.

Mira cuántos equipos distintos de la sede salieron esa tarde con esa misma dirección pública, y qué quedaría sin salida si se bloqueara. La acción útil, cuando se pueda, es sobre el equipo de adentro o sobre el destino, que sí es del atacante, nunca sobre la dirección compartida.

Responde para continuar

Alguien propone bloquear en el borde la dirección pública que aparece en la alerta. ¿Qué pasaría?

Ver pista de ayuda

Ejecuta `SELECT * FROM nat_log` y cuenta cuántas direcciones internas distintas salen con la misma dirección pública.

Cuando los puestos navegan a través de un proxy, la conexión hacia internet la abre el proxy, no el puesto. Un sensor ubicado entre el proxy y la salida ve al proxy como origen de todo: una sola dirección interna que hace las peticiones de toda la oficina. Para saber quién pidió qué, hay que ir al registro del proxy, que sí apunta la dirección del cliente y el usuario de la sesión. Algunos proxys, además, pasan la dirección del cliente hacia el servidor en una cabecera, pero el sensor no la lee si el tráfico va cifrado.

La alerta interna de la tarde apunta a una dirección que es la del proxy. Cruza la hora y el destino con las peticiones del proxy y quédate con el cliente que lo pidió. El nombre del usuario es el dato que se le da al equipo de la persona para preguntarle.

Responde para continuar

Escribe el usuario que, a través del proxy, pidió el destino de la alerta del sensor interno a esa hora.

Ver pista de ayuda

Ejecuta `SELECT * FROM sensor_interno` para leer destino y hora, y `SELECT * FROM proxy` para ver quién pidió ese destino a esa hora.

Deshacer una traducción termina en una dirección interna, y esa dirección todavía no es un equipo. El paso final es el mismo de las salas anteriores: el inventario pone nombre a la dirección y área a la persona que responde, con la salvedad de comprobar que la dirección no cambió de manos a esa hora.

Responde para continuar

Escribe el nombre del equipo que tenía la dirección interna que salió por el puerto de la alerta del borde.

Ver pista de ayuda

Con la dirección de la tarea 2, `SELECT * FROM inventario`.

Inicia sesión para registrar tus puntos y progreso en el ranking.

Whoami-Labs Pro

Whoami-Labs Pro utiliza cookies

Utilizamos cookies y almacenamiento local para el funcionamiento del sitio, seguridad de sesión y, si lo autorizas, analítica y marketing. Puedes aceptar, rechazar o personalizar. Política de Privacidad