Tutorial Debian 8 x64 com ISPConfig e NginX: Configurações Adicionais

Após a instalação e configuração do servidor e dos sites existem algumas tarefas diárias que devemos executar para monitorar os arquivos e os serviços.

Neste artigo adicional aprenda como direcionar os emails do root para uma conta válida pois não é possível fazer acesso POP na conta do root. E veremos ainda como criar alguns scripts que ajudam na administração.

Segurança: Scripts e Configurações Adicionais
1 Redirecione os emails do root para outra conta

Isso é importante pois alguns emails administrativos do servidor são enviados somente para o superusuário root na máquina local. Por exemplo: se alguém cadastrar um segundo usuário admin no ISPConfig um email será enviado ao root.

1a ⇒ Acesse o terminal SSH como root

1b ⇒ Edite o arquivo /root/.forward (para visualizar arquivos com um ponto no início “arquivos ocultos” digite o comando ls -al). Adicione a seguinte linha:

* Substitua o email abaixo por outro válido e que exista

[email protected]

1c ⇒ Método Alternativo: Caso o primeiro método não seja possível ou não funcione em seu sistema use esta segunda opção. Edite o arquivo /etc/aliases e no final adicione uma nova linha (DICA: direcione para outra conta interna no próprio servidor como a contato de algum site, caso o SMTP esteja bloqueado por algum motivo mesmo assim você poderá recuperar os emails via POP):

root: [email protected]

Após salvar o arquivo digite o comando:

root# newaliases

2 Script para monitorar alteração nos arquivos dos sites

Alguns leitores reportaram recentemente que tiveram os sites hackeados, não pelo motivo de terem invadido o servidor mas somente um site isolado (via code injection ou senha fraca cadastrada para o site). Após analisar os ataques nota-se que o invasor instala arquivos adicionais que enviam spam ou atacam outros sites a partir do VPS.

Veja abaixo como criar um script simples de monitoramento, muito útil para detectar infecções por malware e outras pragas.

2a ⇒ Crie um arquivo de script no diretório /root mudando as permissões para que somente o root consiga alterar e executar:

root# touch /root/site-monitor

root# chmod 700 /root/site-monitor

2b ⇒ Edite o arquivo e cole o seguinte conteúdo, substituindo os textos em vermelho por informações do seu servidor e pelos seus emails:

* Note que configurei o comando find para encontrar arquivos modificados nos últimos 60 minutos pois criaremos uma tarefa agendada para executar a cada hora

* Se nenhuma alteração for encontrada o email não será enviado

* Cole os comandos abaixo no arquivo de script sem alterar espaçamentos ou formatação, isso é importante pois usaremos um bloco de código here docs na configuração

* O site fatorbinario.com abaixo representado está em um caminho definido por padrão em instalações com ISPConfig. Para outros CPs ou sistemas veja qual o caminho definido para o site. (Pode-se ainda usar coringas de shell)

#!/bin/bash
# Monitora o site e verifica os arquivos alterados na ultima hora

SITEMONRESULTS=$(find /var/www/fatorbinario.com/web -type f -mmin -60 -exec ls -ls {} \;)
if [ ! -z "${SITEMONRESULTS}" ];
then
cat <<EOF | /usr/sbin/sendmail -t
To: [email protected]
Subject: Arquivos do site alterados na ultima hora
From: [email protected]

Os seguintes arquivos do site foram alterados:

$SITEMONRESULTS

EOF
fi

2c ⇒ Teste e veja se o script funciona. Copie um arquivo qualquer para o diretório do site e rode o script (se o arquivo for detectado você receberá um email com a path completa e demais detalhes):

root# /root/site-monitor

2d ⇒ Crie um agendamento no Cron para executar a verificação a cada hora. No exemplo abaixo executaremos o script sempre aos 30 minutos de cada hora.

* Caso solicite qual o editor você deseja configurar escolha o primeiro (nano)

root# crontab -e

Dentro do arquivo abra uma nova linha ao final e digite:

30 * * * * /root/site-monitor

Para sair e gravar tecle “CTRL + X” em seguida tecle “Y” e ENTER

Para consultar a alteração no crontab digite:

root# crontab -l

2e ⇒ ALTERNATIVA usando o comando mutt para enviar a mensagem com os resultados em arquivo anexado:

O método acima com sendmail é o que eu uso em meus scripts, mas notei que se houverem muitas atualizações de plugins em um site WordPress por exemplo o email fica com uma listagem muito grande. Neste caso a melhor alternativa é criar um arquivo texto temporário com os resultados e anexar ele na mensagem. Usaremos o comando mutt que permite uma facilidade maior para esse tipo de envio.

Siga os mesmos passos acima mas dentro do script cole o código abaixo substituindo o que está em vermelho (Note que em “From” pode-se alterar o nome do sender além do email dele):

#!/bin/bash
# Monitora o site e verifica os arquivos alterados na ultima hora

SITEMONRESULTS=$(find /var/www/fatorbinario.com/web -type f -mmin -60 -exec ls -ls {} \;)
if [ ! -z "${SITEMONRESULTS}" ];
then
cat > /tmp/sitemonresults.txt <<EOF
$SITEMONRESULTS
EOF
echo "Arquivos do site foram alterados recentemente, verifique a lista em anexo." | mutt -s "Arquivos do site alterados na ultima hora" -e 'my_hdr From:Email que Envia <[email protected]>' [email protected] -a /tmp/sitemonresults.txt
fi

* No script acima o comando FIND pode ser alterado para procurar em vários sites ao mesmo tempo.

Altere isso:

SITEMONRESULTS=$(find /var/www/fatorbinario.com/web -type f -mmin -60 -exec ls -ls {} \;)

Para isso (note que a única alteração é usar o asterisco como wildcard):

SITEMONRESULTS=$(find /var/www/*/web -type f -mmin -60 -exec ls -ls {} \;)

E para procurar em múltiplos sites e excluindo múltiplos diretórios de cache use a opção abaixo (este é o exemplo que uso em meu site ignorando os logs criados pelo UpdraftPlus e o cache gerado pelo WP Fastest Cache):

SITEMONRESULTS=$(find /var/www/*/web -not \( -path "/var/www/*/web/wp-content/updraft/*.txt" -prune \) -not \( -path "/var/www/*/web/wp-content/cache/*" -prune \) -type f -mmin -31 -exec ls -ls {} \;)
3 Script para reiniciar o MySQL automaticamente caso seja desligado

Como já expliquei em outros tutoriais quando a carga no servidor é muito grande alguns serviços começam a ser desligados por segurança. Na maioria das vezes o MySQL é o primeiro a cair.

Por exemplo: se algum site for atacado a CPU e memória ficam a quase 100% de uso por um longo período, drenando todos os recursos. O MySQL tentará fazer novas requisições mas não encontrará disponibilidade, sendo desligado em seguida. Nesses casos podemos simplesmente reiniciar o serviço que os sites voltarão ao normal.

* Não confundir com a falta de memória, que na maioria das vezes resolve-se facilmente adicionando uma partição SWAP ao sistema.

3a ⇒ Crie um arquivo de script no diretório /root mudando as permissões para que somente o root consiga alterar e executar:

root# touch /root/mysql-monitor

root# chmod 700 /root/mysql-monitor

3b ⇒ Edite o arquivo e cole o seguinte conteúdo:

* Este é o único script que funciona corretamente, os demais que aparecem em buscas do Google têm falhas e com certeza não foram devidamente testados.

#!/bin/bash
# Reinicia o MySQL em caso de desligamento
# Ajuda com os comparativos de if: man 1 test

UPMYSQL=$(lsof -i :3306 | grep mysql | wc -l);
if [ "$UPMYSQL" -le 0 ];
then
 /etc/init.d/mysql restart
fi

3c ⇒ Teste e veja se o script funciona:

root# /root/mysql-monitor

3d ⇒ Crie um agendamento no Cron para executar a verificação a cada 5 minutos:

root# crontab -e

Dentro do arquivo abra uma nova linha ao final e digite:

*/5 * * * * /root/mysql-monitor

Para sair e gravar tecle “CTRL + X” em seguida tecle “Y” e ENTER

Script para reiniciar o NginX e o PHP em horários predeterminados

Se você mantém muitos sites em um mesmo servidor ou se tiver um site com muitos acessos talvez já tenha notado que de vez em quando o acesso fica lento. Isso pode acontecer por vários motivos mas o que acontece muito é que se alguém tentar spoofar ou fazer um ataque os processos em memória e cache podem demorar a regenerar.

Um truque usado mundo afora é de simplesmente reiniciar os serviços do servidor de páginas web. Após analisar centenas de logs em servidores cheguei à conclusão que os melhores horários para fazer isso são os descritos na configuração do crontab abaixo.

4a ⇒ Crie um arquivo de script no diretório /root mudando as permissões para que somente o root consiga alterar e executar:

root# touch /root/webserver-reload

root# chmod 700 /root/webserver-reload

4b ⇒ Edite o arquivo e cole o seguinte conteúdo:

#!/bin/bash
# Reinicia o PHP-FPM e o NginX

/etc/init.d/php5-fpm restart
/etc/init.d/nginx restart

4c ⇒ Teste e veja se o script funciona:

root# /root/webserver-reload

4d ⇒ Crie um agendamento no Cron para executar a tarefa em horários predeterminados:

root# crontab -e

Dentro do arquivo abra uma nova linha ao final e digite:

30 1,7,12,20 * * * /root/webserver-reload > /dev/null

Para sair e gravar tecle “CTRL + X” em seguida tecle “Y” e ENTER

* A tarefa acima será executada às: 01:30, 07:30, 12:30 e 20:30. São horários mais tranquilos na maioria dos sites mas caso queira pode alterá-los.

* O reload dos serviços demora menos de 2 segundos.

* Adicionando este script aos sistema pode-se combater inclusive ataques DDoS.

5 Script personalizado e melhorado para o RKHunter

O RKHunter ainda é uma das ferramentas mais usadas para detecção de rootkits e malware em servidores. Neste exemplo mostrarei como usar a ferramenta (se você instalou o servidor seguindo o meu tutorial de Debian com ISPConfig o RKHunter já está instalado e ativo mas talvez você não esteja recebendo alertas por email)

No arquivo de configuração padrão o programa que envia emails é o “mail” que nem existe em nossa instalação. E para não ter que instalar mais uma brecha para hackers vamos simplesmente criar um novo script de verificação para o RKHunter e usar o sendmail como nos demais scripts acima.

5a ⇒ O RKHunter já está instalado mas é necessário fazer um primeiro update e atualizar o banco de dados com um “snapshot” dos arquivos atuais assim a ferramenta terá um ponto de comparação para acusar alterações:

root# rkhunter --versioncheck

root# rkhunter --update

root# rkhunter --propupd

5b ⇒ Crie um arquivo de script no diretório /root mudando as permissões para que somente o root consiga alterar e executar:

root# touch /root/rkhunter-monitor

root# chmod 700 /root/rkhunter-monitor

5c ⇒ Edite o arquivo e cole o seguinte conteúdo:

* Substitua as informações em vermelho e não altere o formato do script.

#!/bin/bash
# Executa o RKHunter e envia relatorio por email caso encontre algo suspeito

RKHMONRESULTS=$(/usr/bin/rkhunter --versioncheck --update --cronjob --report-warnings-only)
if [ ! -z "${RKHMONRESULTS}" ];
then
cat <<EOF | /usr/sbin/sendmail -t
To: [email protected]
Subject: Resultado do RKHunter para o servidor
From: [email protected]

Os seguintes avisos foram encontrados:

$RKHMONRESULTS

EOF
fi

5d ⇒ Teste e veja se o script funciona:

root# /root/rkhunter-monitor

NOTA: O comando poderá demorar uns 2 minutos para ser executado. Com a configuração padrão do arquivo /etc/rkhunter.conf você deverá receber um aviso por email mostrando que o login SSH do root está ativado, se quiser suprimir este aviso descomente a linha 306 e altere o parâmetro para “yes“.

OBS: Não há necessidade de ativar os  comandos de MAIL nas linhas 133 e 144 pois o script acima irá se encarregar disso.

5e ⇒ Crie um agendamento no Cron para executar a tarefa todos os dias às 07:40 hrs:

root# crontab -e

Dentro do arquivo abra uma nova linha ao final e digite:

40 7 * * * /root/rkhunter-monitor

Para sair e gravar tecle “CTRL + X” em seguida tecle “Y” e ENTER

6 Habilite o log do Cron

Por padrão o log das tarefas agendadas no Cron do sistema, via Crontab, não está habilitada no Debian. Para ativar siga os seguintes passos:

6a ⇒ Edite o arquivo /etc/rsyslog.conf e descomente a linha 63:

cron.* /var/log/cron.log

6b ⇒ E reinicie o serviço:

root# /etc/init.d/rsyslog restart

* Os logs das tarefas agendadas começarão a ser gravados em /var/log/cron.log

Índice do Tutorial:

©2014-2018 Fator Binário - Todos os direitos reservados

Fazer login com suas credenciais

ou    

Esqueceu sua senha?

Create Account