En resumen: Las conexiones salientes de un servidor se comprueban con ss -tunap o lsof -i, que asignan cada conexión a un proceso. Son normales las conexiones a base de datos, servidor de correo, servidores de actualización e interfaces conocidas. Las conexiones de procesos de PHP o del servidor web a destinos desconocidos, los puertos inusuales y las conexiones permanentes sin motivo son señales de alerta de control remoto o fuga de datos. A largo plazo ayuda un filtrado de salida que solo permita los destinos necesarios.
Por qué mirar hacia fuera revela tanto
Al buscar una intrusión, la mayoría mira los archivos. Pero un atacante quiere hacer algo con su acceso: descargar herramientas, recibir comandos, sacar datos o usar el servidor para spam o ataques a otros. Todo eso necesita conexiones hacia fuera.
Un servidor web por sí mismo establece pocas conexiones, y la mayoría son previsibles: consulta la base de datos, entrega correo, llama a interfaces de pago o envío y obtiene actualizaciones. Por eso las conexiones ajenas llaman aquí especialmente la atención. Según los informes de que disponemos, las conexiones salientes figuran entre las señales de alerta generales tras una intrusión; no hay indicadores de compromiso confirmados específicamente para PHP2Shell. Otros indicios los resume ¿Ya estoy comprometido?.
Enumerar las conexiones salientes y asignarlas a procesos
Los siguientes comandos solo leen. Ejecútelos como root; de lo contrario faltan los datos de proceso.
# Todas las conexiones TCP establecidas con proceso
ss -tnp state established
# TCP y UDP, incluidos los servicios a la escucha
ss -tunap
# Conexiones por programa y usuario, sin resolución de nombres
lsof -i -n -P | grep -v LISTEN
# Solo conexiones de procesos de los usuarios del servidor web
lsof -i -n -P -u www-data 2>/dev/null
En la salida, fíjese en tres columnas: el proceso, la dirección de destino con puerto y el usuario. Una conexión de php-fpm a la base de datos en el puerto 3306 es normal. Una conexión de un programa de nombre desconocido desde /tmp a una dirección ajena en un puerto inusual, no. Bajo qué usuario funciona PHP depende de la distribución y del panel.
¿Normal o sospechoso? Una clasificación
| Observación | Más bien normal | Más bien sospechoso |
|---|---|---|
| Destino | base de datos propia, servidor de correo, API conocidas, servidores de actualización | direcciones desconocidas sin relación con la aplicación |
| Proceso | php-fpm, servidor web, servicios de correo y de actualización | programas desconocidos, procesos de /tmp o /dev/shm |
| Puerto | 443, 3306, 5432, 587 | puertos altos inusuales, puertos típicos de IRC |
| Duración | breve, acorde a las peticiones | abierta de forma permanente, también de noche sin visitantes |
| Cantidad | baja y uniforme | picos repentinos en el volumen de datos saliente |
| Tráfico de correo | envío a través del servidor de correo previsto | muchas conexiones directas al puerto 25 |
Muchas conexiones al puerto 25 apuntan a envío de spam; para ello hay un artículo propio, El servidor envía spam.
Valorar un destino desconocido
Una dirección ajena en la lista todavía no es una prueba. Antes de decidir, aclare adónde lleva la conexión y quién la ha establecido. Estos pasos tampoco modifican nada:
- Determinar el proceso: tomar el PID de
ssy comprobar conls -l /proc/PID/exey la línea de comandos qué programa hay detrás. - Consultar el destino: con
dig -x <IP>averiguar el nombre y conwhois <IP>el operador de red. - Contrastar con la aplicación: pregunte al desarrollador o al proveedor de servicios si su aplicación usa ese servicio.
- Revisar el historial: los registros del cortafuegos y de la red muestran desde cuándo existe la conexión y cuántos datos han fluido.
- Asegurar los resultados: guardar las salidas con la hora antes de terminar o bloquear algo.
Cuente con resultados ambiguos. Muchos servicios legítimos funcionan en grandes proveedores de nube y CDN, cuyas direcciones no permiten deducir el cliente. A la inversa, también los atacantes usan servidores en la nube alquilados. Un operador de red conocido no es por tanto ni una señal de que no hay peligro ni una prueba; lo decisivo es si el proceso y la finalidad encajan con su aplicación.
Una instantánea con ss solo muestra lo que está abierto en ese momento. Las conexiones breves que se establecen cada minuto solo se ven en registros. Por eso, para la cuestión de una fuga de datos, los registros del cortafuegos o de flujos suelen ser más importantes que mirar el propio servidor.
Si los datos han podido salir de su servidor y hay datos personales afectados, puede existir una obligación de notificación según el RGPD, por lo general en 72 horas. Aclárelo pronto con su delegado de protección de datos; antecedentes en Obligación de notificación del RGPD en 72 horas. Esto no es asesoramiento jurídico.
No olvidar el DNS ni los contenedores
No toda fuga de datos necesita una conexión visible a una dirección ajena. Las resoluciones de nombres mediante DNS van al resolvedor de su centro de datos y apenas llaman la atención en la lista de ss. Los atacantes pueden empaquetar datos en subdominios largos de apariencia aleatoria y sacarlos así mediante consultas DNS. Los registros del resolvedor ofrecen indicios: un número inusual de consultas al mismo dominio ajeno, nombres muy largos o consultas en horas en las que nadie usa el sitio web.
Si sus aplicaciones funcionan en contenedores, el host suele ver las conexiones de los contenedores solo como tráfico de la red de contenedores. Revise entonces cada contenedor por separado, en la medida en que las herramientas estén allí, o analice las conexiones a nivel del host y del cortafuegos.
# Conexiones dentro de un contenedor (si ss está incluido en la imagen)
docker exec <container> ss -tnp 2>/dev/null
# En el host: conexiones seguidas por el kernel, si conntrack está instalado
sudo conntrack -L 2>/dev/null | head -50
Limitar el tráfico saliente de forma permanente
La prevención más eficaz es un filtrado de salida: el servidor solo puede alcanzar los destinos que realmente necesita; todo lo demás se bloquea y se registra. Para los atacantes resulta así bastante más difícil descargar herramientas o extraer datos, incluso si pueden ejecutar código.
El camino empieza con una lista de los destinos necesarios, que deduce de las conexiones recogidas más arriba. Después sigue una fase en la que las conexiones bloqueadas solo se registran, antes de activar el bloqueo de forma definitiva. Los servicios de pago, los servidores de actualización y las interfaces con direcciones cambiantes requieren aquí especial cuidado. Cómo se construye en conjunto un cortafuegos para servidores web lo describe Cortafuegos para servidores web: abrir solo los puertos necesarios.
¿Cómo ayuda PHP SOS en concreto?
- Revisar las conexiones: asignamos todas las conexiones activas a procesos y finalidades y valoramos los destinos desconocidos.
- Estimar la fuga de datos: analizamos los registros del cortafuegos y de la red y aclaramos si se transmitieron datos y cuándo.
- Limitar la salida: elaboramos con usted una lista de destinos permitidos y configuramos el filtrado de salida paso a paso.
- Vigilar de forma permanente: con la monitorización de seguridad avisamos de conexiones nuevas o inusuales.
Preguntas frecuentes
¿Qué conexiones salientes son normales en un servidor web?
Son típicas las conexiones a la base de datos, al servidor de correo, a servicios de pago y envío, a servidores de actualización y a interfaces conocidas de la aplicación. Todo lo que no se pueda asignar a ninguna de estas finalidades merece una mirada más atenta.
¿Cómo veo qué proceso ha establecido una conexión?
Con ss -tunap o lsof -i -n -P como root. Ambos muestran para cada conexión el ID del proceso y el nombre del programa. Así reconoce si la conexión procede de PHP, del servidor web o de un programa ajeno.
¿Significa una conexión desconocida que se han fugado datos?
No necesariamente. Pero es un indicio que debe aclararse. Si se transmitieron datos y cuáles, a menudo solo se puede responder con registros del cortafuegos o de la red. Si hay datos personales afectados, pueden existir obligaciones de notificación.
¿Debería un servidor web poder establecer conexiones salientes?
Solo hacia los destinos que necesita. Un filtrado de salida que bloquee todo lo demás dificulta mucho a los atacantes la descarga de herramientas y la fuga de datos. Pero debe probarse con cuidado.