descubra quem envia spam

2

Eu tenho um servidor LAMP Ubuntu 10.04. Existem muitos (> 140) usuários e muitos sites web PHP diferentes (personalizados, diferentes frameworks PHP, CMS, etc.).

O problema é: às vezes o servidor envia "spam". E Exim local não é usado para isso. Eu descobri uma atividade estranha 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. Eu 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

Eu tentei encontrar o processo pai: o pai pid de 15179 é 15176:

/ proc / 15176 / cmdline - também vazio

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. Por isso, é difícil obter mais informações. Todas essas informações são registradas usando uma tarefa cron que monitora a conexão SMTP. Não tenho ideia de como identificar quem executa esses processos ou como eles são executados. Existem táticas para encontrá-los?

    
por user1285716 05.01.2015 / 09:05

3 respostas

2

Os dados que você já exibiu contêm muitas informações: o UID do usuário é 33, que no meu sistema corresponde a www-data , e acho que é mais provável que o mesmo se aplique ao seu sistema, porque os sockets que você exibiu pertencem a www-data .

Além disso, duvido que a linha de comando traga mais informações: o PPID do programa em perl é 15176, mas o PPID de 15176 é 1 ( i.e. , init ). Isso não há shell, nenhuma sessão no meio.

Os endereços IP contatados não são especialmente preocupantes: eles pertencem à Microsoft e ao Google, e esses caras sabem como se defender.

Então, onde está a evidência de jogo sujo? Eu concordo que o status SYN_SENT para a conexão é realmente motivo de preocupação, porque significa que sua conexão não recebeu um SYN / ACK adequado, e você ficou pendurado.

Então, o que você pode fazer para encontrar mais informações? Você não pode tentar identificar o usuário diretamente: sua postagem já mostra que o usuário é www-data e que o processo não está diretamente conectado a um terminal ou sessão.

Mas antes de tudo você pode verificar se o seu IP está na lista negra, por exemplo aqui : se você estiver, isso seria uma evidência de spam.

Em segundo lugar, você deve verificar o log do seu mailer, por qualquer coisa incomum: sites recusando conexão porque você está em uma lista negra, várias conexões do mesmo site, evidência de ser usado como retransmissão, ....

Em terceiro lugar, você pode monitorar suas portas com

 ss -lntp

Isto diz-lhe o pid de processos usando uma porta (TCP) a qualquer momento, verificando mais uma vez várias conexões. Você pode fazer o script do comando acima para se repetir a cada segundo e armazenar sua saída (talvez em conjunto com a saída de usuários ) e um timestamp, para descobrir mais informações sobre o que está acontecendo no momento das conexões suspeitas. Isso pode ser correlacionado post-mortem com usuários conectados ou usuários conectados ao seu site.

Para mais informações, você pode simplesmente despejar todos os pacotes no site da Microsoft, algo como

  nohup tcpdump -n -i eth0 host 65.52.0.0/14 -w outfile & 

O intervalo de endereços IP é o bloco inteiro pertencente à Microsoft, conforme a saída de whois 65.55.37.72 ; É provável que o comando acima gere bastante alguma saída, portanto, esteja preparado para aprimorar suas habilidades na filtragem de expressões com o wireshark .

Se tudo isso falhar, esteja preparado para forçar seus usuários a alterarem suas senhas.

    
por 05.01.2015 / 14:50
1

Apenas uma ideia. Grep através de seus logs do apache. Se você tiver tempo, quando os e-mails foram enviados, pode ser fácil encontrá-los. Procure especialmente por scripts perl.

    
por 05.01.2015 / 11:49
0

Obtenha o usuário

Normalmente, o campo uid mostra o uid do usuário que iniciou o processo.

No seu caso, este será o iser com o uid 33 .

Use getent passwd 33 para ver o nome do usuário.

Rastreie o usuário

Você pode facilmente assistir e registrar a atividade do usuário com um pequeno daemon C,

usando esta pequena biblioteca para ler o arquivo /proc/pid/status e pesquisar após 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 kill destes processos)

    
por 05.01.2015 / 14:14

Tags