Servicios y puertos, qué escucha y desde dónde

La salida de ss -tlnp muestra, para cada puerto en escucha, la dirección en la que está. Si es 127.0.0.1, el servicio solo atiende conexiones que nacen en la misma máquina: desde otro equipo no hay forma de conectarse. Si es un asterisco, atiende todas las interfaces de red del servidor, y la exposición depende entonces del filtro de paquetes y de la red.

Esa diferencia es la base de una de las preguntas del oficio: ¿es alcanzable? Un fallo remoto en un servicio que solo escucha en loopback deja de ser remoto en la práctica, aunque la gravedad base siga siendo la misma.

El escáner de este servidor lista tres hallazgos del mismo CVE, uno por cada demonio que usa la biblioteca, y para cada uno dice un puerto. La salida de ss dice cuál de esos puertos atiende solo a la propia máquina.

Abre ss-escucha.txt y localiza el proceso tramad.

Un paquete instalado no es un servicio activo. systemctl list-unit-files muestra el estado de cada unidad: enabled arranca con el sistema; disabled no arranca solo, aunque se puede lanzar a mano; masked está bloqueada, y ni el sistema ni una persona pueden arrancarla sin antes quitar el bloqueo. Un hallazgo sobre una biblioteca que solo carga una unidad enmascarada tiene una exposición real mínima, y es normal que aparezca en un escáner que lee la lista de paquetes.

Revisa systemctl-unidades.txt y cruza con los puertos de ss-escucha.txt: la unidad del hallazgo MDT-L-0502 no está escuchando.

El tercer elemento es el filtro de paquetes. Un servicio puede escuchar en todas las interfaces y estar descartado por el filtro para casi todos los orígenes, o puede estar permitido desde cualquiera. Para saber cuáles puertos de verdad llegan a quien está fuera de las redes de administración, se cruzan las reglas con los puertos en escucha.

Lee reglas-firewall.txt y busca la regla cuyo origen es «cualquier origen».

El puerto 9104 escucha en todas las interfaces y el filtro solo lo permite desde el servidor de monitoreo. Eso reduce la exposición hoy, pero depende de que las reglas no cambien: un error de configuración o una regla nueva puede abrirlo mañana. Por eso un filtro es una mitigación que se registra, y el parche sigue en la cola, con prioridad más baja que lo expuesto a cualquiera.