Eu tenho um servidor LAMP Ubuntu 10.04. Existem muitos (> 140) usuários e muitos sites PHP diferentes (personalizados, diferentes estruturas PHP, CMS, etc.).
O problema é: às vezes o servidor envia “spam”. E o Exim local não é usado para isso. Eu descobri atividades estranhas como a seguinte:
/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)
...........
E não consigo descobrir quem executa esses processos Perl ou como eles são executados. Tentei analisar esses processos (por exemplo pid 15179): /proc/15179/cmdline - está vazio
/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 - aqui insira a descrição do link aqui
Tentei encontrar o processo pai: o pid pai de 15179 é 15176:
/proc/15176/cmdline – vazio também
e
/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
Acontece raramente (uma vez a cada 2 dias) e dura alguns minutos. Então é difícil conseguir mais informações. Todas essas informações são registradas usando um cron job que monitora a conexão smtp. Não tenho ideia de como identificar quem executa esses processos ou como eles são executados. Existe alguma tática para encontrá-los?
Responder1
Os dados que você exibiu já contêm muitas informações: o UID do usuário é 33, que no meu sistema corresponde awww-dados, e acho que provavelmente o mesmo se aplica ao seu sistema, porque os soquetes que você exibiu pertencem awww-dados.
Além disso, duvido que a linha de comando traga mais informações: o PPID do programa perl é 15176, mas o PPID de 15176 é 1 (ou seja,iniciar). Não há shell, nem sessão intermediária.
Os endereços IP contatados não são especialmente preocupantes: pertencem à Microsoft e ao Google, e esses caras sabem como se defender.
Então, onde está a evidência do crime? Concordo que o status SYN_SENT da conexão é realmente motivo de preocupação, porque significa que sua conexão não recebeu um SYN/ACK adequado e você ficou em espera.
Então, o que você pode fazer para obter mais informações? Você não pode tentar identificar o usuário diretamente: sua postagem já mostra que o usuário estáwww-dados, e que o processo não está diretamente conectado a um terminal ou sessão.
Mas você pode antes de tudo verificar se o seu IP está na lista negra, por exemploaqui: se estiver, isso seria uma evidência de spam.
Em segundo lugar, você deve verificar o log do seu mailer, em busca de algo incomum: sites que recusam a conexão porque você está em uma lista negra, múltiplas conexões do mesmo site, evidências de estar sendo usado como retransmissor,....
Terceiro, você pode monitorar suas portas com
ss -lntp
Isso informa os pids dos processos que usam uma porta (TCP) em um determinado momento, verificando mais uma vez se há múltiplas conexões. Você pode criar um script do comando acima para se repetir a cada segundo e armazenar sua saída (talvez em conjunto com a saída deUsuários) e um carimbo de data/hora, para saber mais informações sobre o que está acontecendo no momento das conexões suspeitas. Isso pode ser correlacionadopost-mortemcom usuários logados ou usuários conectados ao seu site.
Para obter mais informações, você pode simplesmente despejar todos os pacotes no site frequentemente recorrente da Microsoft, algo como
nohup tcpdump -n -i eth0 host 65.52.0.0/14 -w outfile &
O intervalo de endereços IP é todo o bloco pertencente à Microsoft, conforme saída dequem é 65.55.37.72; o comando acima provavelmente gerará alguns resultados, portanto, esteja preparado para aprimorar suas habilidades na filtragem de expressões comwireshark.
Se tudo isso falhar, esteja preparado para forçar os usuários a alterarem suas senhas.
Responder2
Apenas uma ideia. Percorra seus logs do Apache. Se você tiver tempo, quando os e-mails forem enviados, será fácil encontrá-los. Procure especialmente por scripts perl.
Responder3
Obtenha o usuário
Geralmente oUIDcampo mostra oUIDdo usuário que iniciou o processo.
No seu caso este será o iser com oUID 33.
Use getent passwd 33para ver o nome do usuário.
Rastreie o usuário
Você pode facilmente observar e registrar a atividade do usuário com um pequeno daemon C,
usandoessepequena biblioteca para ler o /proc/pid/statusarquivo e pesquisar o usuário.
Isso pode ajudá-lo a evitar problemas com o tempo de execução do servidor.
(Você também pode deixar o daemon executar killesses processos)