Dicas de Segurança da ACME!

Home Page da ACME! Computer Security Research - UNESP Rio Preto

Dicas enviadas pelo Arnaldo Cândido Jr (18/jun/08)

A primeira coisa a ser feita é parar o envio de mensagens de e-mail da máquina 200.136.80.4. Para isto, vocês devem logar na máquina e verificar se há um servidor de e-mail instalado (exemplo: postfix, exim, sendmail ou mailq).

Se houver, será necessário limpar a fila de e-mails (o modo de limpar a fila varia conforme o servidor de e-mail) e desativar o servidor temporariamente. Se não houver, alguém pode ter instalado um programa para fazer isso. É bom verificar todos os processos carregados e matar os suspeitos com o comando kill. Os softwares chkrootkit e rkhunter ajudam a detectar softwares maliciosos na máquina.

O segundo passo é descobrir a causa do envio de spam. Não necessariamente houve invasão na máquina. Existe uma vulnerabilidade muito explorada na função mail do php, que permite que o spam seja enviado através do preenchimento incorreto de formulários html do tipo "fale conosco". Se houver um formulário desse tipo, ele deve ser desativado para que o programador que o criou tenha tempo para corrigi-lo.

Descoberta a causa do envio, o terceiro passo é saná-la. Convém usar um firewall (como o iptables) na própria máquina para evitar que ela se conecte a outros servidores através das portas 25 e 587. Além disso, convém desabilitar alguns serviços que podem ser acessados via Internet. Fiz um levantamento dos serviços disponíveis na máquina através do nmap:

22/tcp    open  ssh
53/tcp    open  domain
80/tcp    open  http
2049/tcp  open  nfs
5001/tcp  open  commplex-link
8080/tcp  open  http-proxy
8443/tcp  open  https-alt
32779/tcp open  sometimes-rpc21

Creio que da lista acima, apenas o http e o http-proxy sejam importantes (é bom deixar o ssh fechado temporariamente, até sanar o problema).

Por fim, se constatada a invasão, é altamente recomendável formatar o servidor e instalar o sistema do zero. A princípio, parece mais provável algum problema com os forms PHP. Se for isso, a solução será bem mais simples e não será necessário formatar o servidor.

Dicas enviadas pelo Jorge Luiz Corrêa (18/jun/08)

Pelas mensagens trocadas, me parece que alguns cuidados com o serviço de email já foram tomados tais como verificar se o relay não está aberto permitindo que terceiros enviem emails por este servidor. Se não, é importantíssimo que isto seja feito.

Como disseram em alguma das mensagens, as vezes o problema foi causado pelo envio de um simples email para uma lista. Já tive problemas aqui, de entrar em RBL, simplesmente por fazer alguns testes enviando emails por linha de comando com telnet. Alguns servidores recebem estes emails com cabeçalhos fora do padrão e acabam considerando como SPAM. Basta que um falso positivo ocorra que vamos parar na RBL, mesmo não enviando SPAMs.

Como parece se tratar de um cluster, é conveniente verificar se as aplicações não enviam emails com resultados de processos. Se uma aplicação enviar emails desta forma, pode ser que o receptor esteja em um destes servidores que considerarão as mensagens como SPAMs, contribuindo para que o host entre para uma RBL.

Vejo por uma mapeamento daqui que o host possui alguns serviços abertos:

root@flecha:/home/jorge# nmap 200.136.80.4

Starting Nmap 4.53 ( http://insecure.org ) at 2008-06-18 14:19 BRT

Interesting ports on osg-ce.sprace.org.br (200.136.80.4):
Not shown: 1020 filtered ports, 686 closed ports
PORT      STATE SERVICE

22/tcp    open  ssh
53/tcp    open  domain
80/tcp    open  http
2049/tcp  open  nfs
5001/tcp  open  commplex-link
8080/tcp  open  http-proxy
8443/tcp  open  https-alt
32779/tcp open  sometimes-rpc21

Nmap done: 1 IP address (1 host up) scanned in 42.274 seconds

Podem verificar também quem tem acesso a este proxy-http. Determinadas configurações de proxy permitem exploração para o envio de emails. Verifiquem se tem algum controle de quem usa o proxy e se não existe nenhum proxy transparente. Proxies transparentes também pode gerar problemas, devido ao reencaminhamento de portas. Uma situação comum é forçar todo tráfego da porta 80 passar pelo proxy. Alguém pode descobrir esta configuração e usar o proxy para enviar SPAMs. Pior, no caso de ter um formulário php como o Arnaldo comentou este pode ser utilizado para envio de SPAMs.

Para determinar se a máquina enviou SPAMs pode-se verificar os arquivos de log. No caso de um postfix, por exemplo, o /var/log/mail.log mostrará todas as tentativas de envio de mensagens. Caso a máquina tenha enviado em massa, será fácil detectar.

Por fim, pode-se monitorar todo o tráfego de mensagens SMTP do host, a fim de determinar para quais servidores as mensagens estão sendo enviadas e de quem se está recebendo. Isto pode ser feito com o tcpdump.

tcpdump -i  port 25 -w smtp.dump

Para analisar este dump basta usar

tcpdump -r smtp.dump 

OBS.: este processo ficará rodando em um terminal. Para que o arquivo seja gerado é necessário pará-los com CTRL+C. Outra maneira é rodar em background

tcpdump -i  port 25 -w smtp.dump

e depois de um tempo capturando, matar o processo. Para isso use o comando

ps aux | grep tcpdump

e veja o PID do processo. Depois é só dar um kill -9

Assim pode-se obter maiores informações sobre o tráfego smtp deste host.

-- RogerioIope - 19 Jun 2008

Topic revision: r2 - 2008-06-28 - RogerioIope
 

This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback

antalya escort bursa escort eskisehir escort istanbul escort izmir escort