Firewall: Tutorial de Segurança no Servidor de Email do VPS

Ataques ao servidor de emails em um VPS são mais frequentes do que as pessoas imaginam, num único dia um servidor pode ser alvo de dezenas dessas tentativas de invasão. Técnicas de Spoofing e BackScatter podem “sujar” um endereço IP limpo pois conseguem  “forjar” um remetente (Quem nunca recebeu um email marcado como SPAM que foi enviado pelo seu próprio endereço?). Aprenda como se defender de ameaças e mantenha o IP do VPS limpo para que o mesmo não seja marcado em blacklists.

Este tutorial foi elaborado durante semanas de testes e busca por informações. Documentos atualizados falando sobre o assunto são difíceis de encontrar, e os mais antigos têm regras que não se aplicam atualmente. Nos próximos parágrafos tentarei explicar como analisar os arquivos de log e identificar ameaças, e ainda mostrarei como configurar alguns serviços para repelir quase 100% das tentativas de invasão. *Fizemos os testes em nosso servidor Debian 7 com ISPConfig 3, clique aqui para seguir o tutorial de como instalar um sistema completo com painel de controle.

Para que possamos defender o servidor de forma apropriada é importante certificar-se de que o sistema esteja configurado corretamente. Verifique se o nome do seu VPS seja FQDN e esteja ativo, não invente nomes fictícios de domínio, ele precisa existir para o DNS poder localizá-lo (caso tenha criado com o nome errado clique aqui e veja como alterar); Nosso MTA será o Postfix e usaremos o Fail2Ban com o Firewall do ISPConfig 3 para distribuir bans. Como camada extra de segurança eu indico a CloudFlare que tem um firewall próprio além de servir como proxy-cache do site (veja como configurar o DNS com CloudFlare).

*Se você está lendo este artigo e pensa que o seu VPS está seguro então é melhor dar uma olhada nos arquivos de log. Clique aqui para ler minha postagem falando sobre esses arquivos.

Antes de começar:
Postfix:

O MTA do nosso servidor será o Postfix que é responsável pelo controle dos emails enviados diretamente do VPS ou via SMTP por um cliente de email (Outlook, Thunderbird). *Erroneamente algumas pessoas pensam que o responsável pelo envio é o sistema operacional ou o painel de controle, veremos isso abaixo.

Quando instalamos o Postfix seguindo o tutorial ele ficou pronto para uso, criamos caixas de entrada e domínios de email. Agora veremos como “tunar” algumas opções para melhorar a segurança.

1 Arquivo /etc/postfix/main.cf:

*Talvez você possa ter alterado o arquivo original main.cf então vamos verificar algumas configurações. Procure no arquivo pelas seguintes linhas e veja se estão com estes parâmetros, adicione as que não houver (faça um backup do arquivo, um erro aqui e o Servidor de Email para de funcionar):

#Importante: Não altere a ordem em que as linhas aparecem no arquivo

smtpd_use_tls = yes

#Substitua o próximo parâmetro pelo nome FQDN que você deu ao VPS (Se voce seguiu o tutorial com ISPConfig os proximos dois parametros ja devem estar certos)
myhostname = vps1.fatorbinario.com

#Certifique-se de incluir o nome do VPS na próxima linha
mydestination = vps1.fatorbinario.com, localhost, localhost.localdomain

#Para melhor aceitacao no Gmail
inet_protocols = ipv4

#Comente a linha:
#smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf

#E substitua por este bloco (note as virgulas):
smtpd_recipient_restrictions = 
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_destination,
   reject_unknown_recipient_domain,
   check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf,
   permit

#Verifique ainda se as 2 linhas abaixo estão presentes no seu arquivo 
header_checks = regexp:/etc/postfix/header_checks
smtpd_tls_security_level = may

#Comente as linhas:
#smtpd_sender_restrictions = check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf
#smtpd_client_restrictions = check_client_access mysql:/etc/postfix/mysql-virtual_client.cf

#E substitua por este bloco de codigo abaixo adicionando parametros novos:
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_non_fqdn_helo_hostname,
   reject_invalid_helo_hostname,
   permit
smtpd_sender_restrictions = 
   permit_mynetworks,
   reject_non_fqdn_sender,
   reject_unknown_sender_domain,
   check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf,
   permit
smtpd_client_restrictions = 
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unknown_client_hostname,
   check_client_access mysql:/etc/postfix/mysql-virtual_client.cf,
   permit

Notas sobre a configuração: Em vários tutoriais você poderá encontrar uma linha com Reject para Invalid FQDN no bloco smtpd_recipient_restrictions, isso é uma regra que a Microsoft utiliza no hotmail por exemplo, e faz com que mensagens recebidas, e que não tenham origem de um servidor com nome/PTR FQDN, sejam REJEITADAS. Por isso que muita gente envia email de um VPS mal configurado e as mensagens nunca chegam, nem na caixa de entrada, e nem mesmo como SPAM, elas simplesmente desaparecem.

Note ainda que: Nos mesmos tutoriais é comum encontrar regras “reject_rbl_client” para spamhaus.org ou nerd.dk, não use isso. Aquelas blacklists não funcionam mais faz tempo.

2 Arquivo /etc/postfix/header_checks:

*Configuramos o arquivo main.cf para bloquear várias tentativas de ataques ao servidor de emails, mas podemos bloquear também o uso indevido do servidor por técnicas de spoofing. Veja alguns exemplos (Crie o arquivo se não existir):

/^X-Spam-Level: \*{15,}.*/ DISCARD
/^To: @deployai\.ddns\.me/ DISCARD
/^From: @deployai\.ddns\.me/ DISCARD
/^Return-Path: @deployai\.ddns\.me/ DISCARD
/^To: .*\.cloudapp\.net/ DISCARD
/^From: .*\.cloudapp\.net/ DISCARD
/^Return-Path: .*\.cloudapp\.net/ DISCARD
/^To: .*\.ddns\.me/ DISCARD
/^From: .*\.ddns\.me/ DISCARD
/^Return-Path: .*\.ddns\.me/ DISCARD
/@deployai\.ddns\.me/ DISCARD
/.*\.ddns\.me/ DISCARD
/.ddns\.me/ DISCARD
/.*\.cloudapp\.net/ DISCARD
/.cloudapp\.net/ DISCARD
/.*\.members\.linode\.com/ DISCARD
/.members\.linode\.com/ DISCARD

Verifique as configurações e reinicie o Postfix:

> postfix check
> /etc/init.d/postfix restart

Notas sobre o arquivo header_checks: A primeira linha é parte do pacote de segurança instalado com o ISPConfig e faz com que o servidor “aprenda” as técnicas dos spammers e faça o devido bloqueio. As demais linhas irão assegurar que alguns dos maiores redutos de spammers não possam usar o seu servidor como enviador de emails forjados (Aposto que você já deve ter recebido email da DeployAi sendo enviado do seu próprio servidor). E ainda nas duas últimas linhas infelizmente tive que acrescentar o subdomínio members da Linode, pois eles têm pouco controle sobre spammers e o meu servidor era atacado constantemente por eles. Se quiser pode deletar essas duas últimas linhas. Note ainda que em todas as linhas eu executo um DISCARD, descartando completamente a tentativa e evitando um flood de negação ao servidor de email (pode-se ainda optar por um REJECT com mensagem de retorno, mas não é aconselhável).

*Observação: Cuidado ao adicionar regras no arquivo header_checks, não tente bloquear países inteiros como por exemplo /.ru/ DISCARD ou /.cn/ DISCARD. Não irá funcionar. Após fazer qualquer alteração reinicie o Postfix e envie/receba alguns emails de teste pelo servidor e veja nos arquivos de log se as mensagens estão passando. Novos ataques serão marcados como REJECT ou DISCARD.

Firewall e Fail2Ban:

A Acionando o firewall do ISPConfig: navegue pelas opções de menu:

» Sistema → Firewall → Adicionar registro de firewall

Em seguida confirme a lista de portas que aparecem nos campos (aquelas serão as únicas portas liberadas pelo firewall, adicione outras se necessário mas não delete nenhuma porta se você não sabe o que está fazendo). Se por um acaso  errar e bloquear o seu login ao sistema siga um tutorial ensinando como restaurar o acesso clicando aqui.

*NOTA IMPORTANTE sobre o Firewall e acesso FTP: Alguns leitores reportaram que não conseguem acessar as contas FTP após acionar o Firewall. Isso acontece porque alguns programas de FTP (exemplo: Filezilla) são configurados por padrão para usar senhas criptografadas no modo PASV. Veja um tutorial de como configurar o Pure-FTPd no modo Passivo.

O ISPConfig não permite adicionar regras personalizadas pelo painel de controle mas pode-se fazer isso usando o terminal com quaisquer ferramentas de firewall/bloqueio como IPTables, UFW, IP Route, etc.. Veja um exemplo onde tive que bloquear uma tentativa de ataque originada no servidor da submarino.com.br:

No arquivo de log /var/log/mail.info havia várias linhas de registro como estas (O Postfix já estava rejeitando as tentativas porém criei uma regra extra de firewall e o fulano parou de incomodar):

postfix/smtpd[5197]: warning: hostname submarino.com.br does not resolve to address 162.250.126.248
reject: RCPT from unknown[162.250.126.248]: 450 4.7.1 Client host rejected: cannot find your hostname, [162.250.126.248];

Uma busca rápida mostrou que o IP pertence mesmo à submarino.com.br (clique aqui e veja como verificar um IP). Como eu não pretendo enviar ou receber email deles pelo meu servidor fiz um bloqueio no IPTables desta forma:

> iptables -I INPUT 1 -s 162.250.126.248 -j DROP

*Note que usei o parâmetro -I com o número 1 após o INPUT, isso faz com que a regra seja adicionada no topo da lista de regras do IPTables. Para listar as regras e a ordem em que serão executadas use o comando abaixo:

> iptables -nvL --line-numbers 

O ISPConfig permite isso e muito mais. *Note que você pode escrever um conjunto de regras IPTables personalizadas e carregá-las na inicialização do sistema.

B Configurando o Fail2Ban: Dentro do diretório /etc/fail2ban podemos encontrar vários arquivos de configuração incluindo ações, filtros e jails.

Quando instalamos o Debian com ISPConfig o Fail2Ban já ficou “incorporado” ao firewall bloqueando alguns ataques desde então. O Fail2Ban interage com os arquivos de log e encontra possíveis ameaças agindo contra as mesmas. Vamos melhorar essa detecção e distribuir muitos bans.

No arquivo /etc/fail2ban/jail.conf temos que alterar uma configuração para o Linux Debian, localize a configuração abaixo e altere de auto para polling:

# O Debian 7 tem um problema com o modo "auto" (gamin) para detectar alterações nos arquivos, configure para o modo polling
backend = polling

Edite o arquivo /etc/fail2ban/jail.local (o arquivo para configurar blocos de regras é o jail.conf mas quando houver um update do sistema as alterações serão perdidas, por isso usamos o jail.local):

[DEFAULT]

# Adicione alguns IPs internos e o DNS do Google na lista de redes confiaveis
ignoreip = 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 8.8.8.8

# Digite o seu email abaixo para ser avisado quando o Fail2Ban parar/iniciar e ainda, opcionalmente, quando uma ameaca for detectada (descomente a linha para ativar). Se optar por receber email de bans será necessário alterar também a linha "action":
#destemail = [email protected]

# ACTIONS
# Acao a ser usada em caso de deteccao. Por padrao uma regra dinamica sera criada no IPTables. Se voce tiver conflitos mostrados nos arquivos de log usando IPTables existe uma solucao com IP Route que explico neste tutorial (descomente para habilitar e altere se necessário):
#banaction = iptables-multiport

# As acoes possiveis podem ser encontradas no arquivo jail.conf. A padrao e "%(action_)s" (simplesmente banir) mas podemos alterar para "action_mw", banir e enviar email notificando (descomente a linha para habilitar):
#action = %(action_mw)s

# Antes de adicionar jails vamos configurar valores padrão de ban para usar em todas elas (pode-se alterar individualmente conforme mostrado nas secoes SSH e FTP abaixo).
# Os valores abaixo sao exemplos e estao em segundos: bantime (600 segundos); findtime (300 segundos); maxretry (4 tentativas):
bantime  = 600
findtime = 300
maxretry = 4

#
# JAILS
#
# Copie do arquivo jail.conf os blocos que quiser adicionar e altere para enable = true.

[pureftpd]
enabled  = true
port     = ftp
filter   = pureftpd
logpath  = /var/log/syslog
maxretry = 6

[dovecot-pop3imap]
enabled = true
filter = dovecot-pop3imap
action = iptables-multiport[name=dovecot-pop3imap, port="pop3,pop3s,imap,imaps", protocol=tcp]
logpath = /var/log/mail.log

[postfix]
enabled = true
port = smtp,ssmtp
filter = postfix
logpath = /var/log/mail.log

[sasl]
enabled = true
port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter = sasl
logpath = /var/log/mail.log

# Aplique bans mais longos para tentativas no SSH
[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
bantime = 1200
findtime = 300

#Bloqueando ataques DDoS no BIND9, servidor DNS. Note que mudamos o arquivo padrao de log e tambem trocamos o 
#action para hostsdeny, isso e necessario pois ataques ao DNS devem ser barrados logo na entrada do servidor
[named-refused-udp]
enabled = true
port = domain,953
protocol = udp
filter = named-refused
#logpath = /var/log/named/security.log
logpath = /var/log/daemon.log
action   = hostsdeny
bantime = 1800
findtime = 300
maxretry = 10

[named-refused-tcp]
enabled = true
port = domain,953
protocol = tcp
filter = named-refused
#logpath = /var/log/named/security.log
logpath = /var/log/daemon.log
action   = hostsdeny
bantime = 1800
findtime = 300
maxretry = 10

Em seguida reinicie o Fail2Ban:

> /etc/init.d/fail2ban restart

Note no código acima que é possível alterar alguns comportamentos padrão por bloco. No caso do SSH configuramos bans mais longos pois é o serviço mais visado. Pode-se ainda alterar o bantime para “-1” se quiser banir definitivamente, não aconselho a fazer isso, tome cuidado pois um problema que pode ocorrer é o de esquecer uma senha e ficar tentando até acertar, somente 4 tentativas serão aceitas, se banir pra sempre o único jeito será reiniciando o Fail2Ban ou o servidor (se caso isso acontecer reinicie o seu modem para trocar o IP de acesso).

Observação: Se você quiser escrever regras REGEX para os filtros aprenda como fazer no link abaixo onde mostro como modificar o filtro para o Postfix melhorando a detecção de ataques:

Tutorial como modificar regras REGEX para os filtros do Fail2Ban

*Sempre configure um ban exemplar para tentativas de login no servidor de email, nos arquivos de log existem dezenas de tentativas diárias. Cada linha no arquivo representa uma tentativa de “brute force” à usuários de email, veja um exemplo bem comum de log:

SASL LOGIN authentication failed: UGFzc3dvcmQ6

Depois que configurei o meu servidor para 10 horas de ban os “hackers” desapareceram.

NOTAS:

Defender um servidor contra ameaças não é uma tarefa fácil, mas acredito que com este tutorial você conseguirá livrar-se de quase 100% dos problemas diários registrados nos logs. Acompanhe os eventos nos arquivos e tente descobrir a origem dos ataques.

Note porém que o ISPConfig grava a cada 5 minutos algumas linhas com “keep alive” de alguns serviços, que não devem ser confundidas com ameaças.

Se tiver dúvidas ou quiser discutir sobre o tema por favor registre-se em nossa Comunidade.

Gestão em infraestrutura de Servidores Cloud VPS e Dedicados. Planos mensais acessíveis e consultoria diferenciada para agências de marketing.
Envie um email para [email protected] e solicite uma análise gratuita!

  • Para discutir sobre esta publicação por favor registre-se em nossa Comunidade clicando em LOGIN no menu.

    Após cadastrar-se acesse este link: https://fatorbinario.com/comunidade/topico/solucoes-para-servidores-de-email-com-problemas-na-entrega/

  • Romeu Pereira da Silva

    olá amigo, estou tento problema no envio das mensagens, eu recebo esse erro no log do fail2ban, e ja fiz de tudo e não consigo achar erro nos arquivos de configuração: pode me dar uma luz no que fazer?

    SASL: started on `uname -n`” [email protected] returned 7f00
    2016-06-28 21:41:52,099 fail2ban.actions.action: INFO HINT on 7f00: “Command not found”. Make sure that all commands in ‘printf %b “Hi,\nnThe jail SASL has been started successfully.\nnRegards,\nnFail2Ban”|mail -s “[Fail2Ban] SASL: started on `uname -n`” [email protected]‘ are in the PATH of fail2ban-server process (grep -a PATH= /proc/`pidof -x fail2ban-server`/environ). You may want to start “fail2ban-server -f” separately, initiate it with “fail2ban-client reload” in another shell session and observe if additional informative error messages appear in the terminals.

  • Bom dia Romeu,
    no console SSH logado como root digite uname -n e veja se aparece o nome FQDN do seu servidor.

    As configurações de firewall que apresento aqui nos tutoriais servem para analisar e barrar quase 100% dos ataques ao servidor e aos serviços de email, mas é necessário não pular nenhum passo e seguir as normativas, incluindo o FQDN.

    Você pode ainda verificar o status e detalhamento de cada serviço, exemplo para o fail2ban:
    /etc/init.d/fail2ban status