Tengo un servidor LAMP Ubuntu 10.04. Hay muchos (>140) usuarios y muchos sitios web PHP diferentes (personalizados, diferentes marcos PHP, CMS, etc.).
El problema es que a veces el servidor envía "spam". Y el Exim local no se utiliza para eso. Descubrí una actividad extraña como la siguiente:
/usr/bin/lsof -ni | grep smtp |grep -v ^exim4
perl 15177 www-data 510u IPv4 1101127040 0t0 TCP server_ip:46401->65.55.37.72:smtp (SYN_SENT)
perl 15178 www-data 510u IPv4 1101127059 0t0 TCP server_ip:51002->98.136.217.202:smtp (SYN_SENT)
perl 15179 www-data 510u IPv4 1101126982 0t0 TCP server_ip:39232->74.125.205.26:smtp (SYN_SENT)
perl 15180 www-data 510u IPv4 1101126975 0t0 TCP server_ip:53339->65.55.37.72:smtp (SYN_SENT)
perl 15181 www-data 510u IPv4 1101127014 0t0 TCP server_ip:45429->65.55.37.72:smtp (SYN_SENT)
perl 15182 www-data 510u IPv4 1101126984 0t0 TCP server_ip:49985->74.125.205.26:smtp (SYN_SENT)
perl 15183 www-data 510u IPv4 1101126971 0t0 TCP server_ip:42199->65.55.37.72:smtp (SYN_SENT)
..........
...........
perl 15184 www-data 510u IPv4 1101126968 0t0 TCP server_ip:36641->74.125.205.26:smtp (SYN_SENT)
perl 15186 www-data 510u IPv4 1101126979 0t0 TCP server_ip:57690->98.138.112.32:smtp (SYN_SENT)
...........
Y no puedo descubrir quién ejecuta estos procesos de Perl ni cómo se ejecutan. Intenté analizar estos procesos (por ejemplo, pid 15179): /proc/15179/cmdline - está vacío
/proc/15179/status
Name: perl
State: S (sleeping)
Tgid: 15179
Pid: 15179
PPid: 15176
TracerPid: 0
Uid: 33 33 33 33
Gid: 33 33 33 33
FDSize: 1024
Groups: 33
VmPeak: 10400 kB
VmSize: 10372 kB
VmLck: 0 kB
VmHWM: 8140 kB
VmRSS: 8092 kB
VmData: 6980 kB
VmStk: 88 kB
VmExe: 1200 kB
VmLib: 1980 kB
VmPTE: 32 kB
Threads: 1
SigQ: 0/16382
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000080
SigCgt: 0000000180017427
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed: f
Cpus_allowed_list: 0-3
Mems_allowed: 1
Mems_allowed_list: 0
voluntary_ctxt_switches: 6431
nonvoluntary_ctxt_switches: 34
lsof -n -p 15179 - aquí ingrese la descripción del enlace aquí
Intenté encontrar el proceso principal: el pid principal de 15179 es 15176:
/proc/15176/cmdline - vacío también
y
/proc/15176/status
Name: perl
State: S (sleeping)
Tgid: 15176
Pid: 15176
PPid: 1
TracerPid: 0
Uid: 33 33 33 33
Gid: 33 33 33 33
FDSize: 1024
Groups: 33
VmPeak: 11116 kB
VmSize: 11116 kB
VmLck: 0 kB
VmHWM: 8712 kB
VmRSS: 8692 kB
VmData: 7772 kB
VmStk: 88 kB
VmExe: 1200 kB
VmLib: 1940 kB
VmPTE: 32 kB
Threads: 1
SigQ: 0/16382
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000010080
SigCgt: 0000000180007427
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed: f
Cpus_allowed_list: 0-3
Mems_allowed: 1
Mems_allowed_list: 0
voluntary_ctxt_switches: 14467
Ocurre raramente (una vez cada 2 días) y dura unos minutos. Entonces es difícil obtener más información. Toda esta información se registra mediante un trabajo cron que monitorea la conexión SMTP. No tengo idea de cómo identificar quién ejecuta estos procesos ni cómo se ejecutan. ¿Existe alguna táctica para encontrarlos?
Respuesta1
Los datos que ha mostrado ya contienen mucha información: el UID del usuario es 33, que en mi sistema corresponde awww-datos, y creo que lo más probable es que se aplique lo mismo a su sistema, porque los sockets que mostró pertenecen awww-datos.
Además, dudo que la línea de comando le brinde más información: el PPID del programa perl es 15176, pero el PPID de 15176 es 1 (es decir,en eso). Esto no hay shell, ni sesión intermedia.
Las direcciones IP contactadas no son especialmente preocupantes: pertenecen a Microsoft y a Google, y esos tipos saben defenderse.
Entonces, ¿dónde está la evidencia de juego sucio? Estoy de acuerdo en que el estado SYN_SENT de la conexión es motivo de preocupación, porque significa que su conexión no ha recibido un SYN/ACK adecuado y quedó colgado.
Entonces, ¿qué puedes hacer para obtener más información? No puedes intentar identificar al usuario directamente: tu publicación ya muestra que el usuario eswww-datos, y que el proceso no esté conectado directamente a una terminal o sesión.
Pero primero puede comprobar si su IP está en la lista negra, por ejemploaquí: si es así, sería evidencia de spam.
En segundo lugar, debe comprobar el registro de su remitente de correo para detectar cualquier cosa inusual: sitios que rechazan la conexión porque está en una lista negra, conexiones múltiples desde el mismo sitio, evidencia de que se ha utilizado como retransmisión,...
En tercer lugar, puede monitorear sus puertos con
ss -lntp
Esto le indica los pid de los procesos que utilizan un puerto (TCP) en un momento dado, comprobando una vez más si hay múltiples conexiones. Puede programar el comando anterior para que se repita cada segundo y almacenar su salida (quizás junto con la salida deusuarios) y una marca de tiempo, para obtener más información sobre lo que estaba sucediendo en el momento de las conexiones sospechosas. Eso puede tener correlación cruzadaPost mortemcon usuarios conectados o usuarios conectados a su sitio.
Para obtener más información, simplemente puede volcar todos los paquetes en el sitio de Microsoft que se repite con frecuencia, algo así como
nohup tcpdump -n -i eth0 host 65.52.0.0/14 -w outfile &
El rango de direcciones IP es el bloque completo que pertenece a Microsoft, según el resultado dequién es 65.55.37.72; Es probable que el comando anterior genere bastante resultado, por lo tanto, prepárese para perfeccionar sus habilidades para filtrar expresiones contiburón de alambre.
Si todo esto falla, prepárese para obligar a sus usuarios a cambiar sus contraseñas.
Respuesta2
Solo una idea. Revise sus registros de Apache. Si tiene tiempo, cuándo se enviaron los correos podría ser fácil encontrarlos. Busque especialmente scripts en Perl.
Respuesta3
Obtener el usuario
Generalmente elfluidoEl campo muestra elfluidodel usuario que inició el proceso.
En su caso este será el iser con elfluido 33.
Úselo getent passwd 33para ver el nombre del usuario.
Seguimiento del usuario
Puedes observar y registrar fácilmente la actividad del usuario con un pequeño demonio C,
usandoestePequeña biblioteca para leer el /proc/pid/statusarchivo y buscar al usuario.
Esto podría ayudarle a evitar problemas con el tiempo de ejecución del servidor.
(También puedes dejar que el demonio killestos procesos)