Postfix: Desabilitando SSLv3 (Poodle Vulnerability)

Olá ! Neste post irei tratar de uma correção nas configurações do Postfix para uma vulnerabilidade reportada sobre o SSLv3, conhecido como POODLE. Caso deseje mais informações sobre a vulnerabilidade acesse estas documentações:

https://www.openssl.org/~bodo/ssl-poodle.pdf

http://www.sempreupdate.com.br/2014/10/ssl-e-vulneravel-ao-ataque-poodle-veja.html

Primeiramente, para verificar se o seu servidor está utilizando o SSL v3 utilize os comandos abaixo:

openssl s_client -connect SERVIDOR:465 -ssl3
openssl s_client -connect SERVIDOR:25 -ssl3 -starttls smtp
 

Se a conexão falhar com o erro “ssl handshake failure” seu servidor não está utilizando o SSL3, portanto não está vulnerável a este ataque.

Caso o seu servidor esteja utilizando o SSL3, modifique os seguintes parâmetros no arquivo de configuração (main.cf) do Postfix:

smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_protocols = !SSLv2,!SSLv3
smtp_tls_protocols = !SSLv2,!SSLv3

Efetue um RELOAD no serviço do Postfix e teste novamente.

Anúncios

Postfix + Autoresponder: Habilitando data de início e termino

Olá ! Essa dica é para quem possui o Postfix integrado com o YAA Autoresponder e o mesmo não está aplicando as datas de início e termino dos filtros.

No arquivo de configurção do YAA (Yet Another Autoresponder), localize o MAPA que está sendo utilizado ($lookup_maps) para modificar a consulta que está sendo efetuada. Neste exemplo está sendo utilizado uma base MYSQL:

$lookup_maps = {
         'my_sql_map' => {
                'driver' => 'SQL',
                'sql_dsn' => 'dbi:mysql:database=mail;host=localhost',
                'sql_username' => "myusername",
                'sql_password' => "mypassword",
                'sql_select' => "select active,message,subject,charset,forward,local_domains
                                from autoresponder_data where address = %m and active='1',
...



Observe que na SQL acima os campos de data de início e termino não estão sendo consultados.
Para aplicar, altere a entrada conforme abaixo:

$lookup_maps = {
         'my_sql_map' => {
                'driver' => 'SQL',
                'sql_dsn' => 'dbi:mysql:database=mail;host=localhost',
                'sql_username' => "myusername",
                'sql_password' => "mypassword",
                'sql_select' => "select active,message,subject,charset,forward,local_domains
                                from autoresponder_data where address = %m and active='1' and
                                tstart <= UNIX_TIMESTAMP() and tfinish >= UNIX_TIMESTAMP()",
....

Postfix: Artigos sobre defesa por camadas

Olá !

Como é de conhecimento de quem acessa o meu Blog, sou especialista em Postfix. Portanto, iniciarei uma série de artigos sobre defesa por camadas com Postfix, isto é, como combater SPAM e outros ataques com máxima eficiência.

As camadas que serão tratadas são:

  1. Postscreen
  2. Restrições SMTP
  3. Verificações no cabeçalho e corpo das mensagens
  4. Filtros exernos, como Anti vírus e Anti Spam

É Importante destacar que o peso das verificações aumenta após cada etapa, ou seja, a ideia é ter primeiramente linhas de defesa com menor custo computacional.

Postfix: Contornando comandos incorretos de conexões SMTP

Olá !

Anteriormente, eu publiquei um artigo (https://respirandolinux.wordpress.com/2013/09/20/postfix-contornando-501-syntax-helo-hostname/) sobre como contornar o erro de sintaxe quando clientes remotos enviam o comando HELO/EHLO de forma incorreta, principalmente sem inserir o hostname após o comando. Utilizando o procedimento do meu artigo anterior, não será mais possível aplicar restrições na etapa HELO/EHLO, uma vez que independentemente da entrada, o resultado sempre será “OK”.

É muito comum quando temos um servidor SMTP que será utilizado por aplicações, muitos comandos serem enviados com a sintaxe incorreta ou até mesmo estas aplicações enviarem comandos inválidos. Para contornar este problema, podemos utilizar o parâmetro “smtpd_command_filter” no Postfix.

A diretiva “smtpd_command_filter” (disponível a partir da versão 2.7) é descrita na documentação do Postfix como um último recurso para contornar clientes que enviam comandos incorretos ou inválidos de fato. Apesar das modificações que serão aplicadas, é possível aplicar restrições HELO após utilizar esse parâmetro.

Vejamos um exemplo que pode ser utilizado para contornar clientes que enviam o HELO/EHLO sem estar seguido do FQDN:

smtpd_command_filter = pcre:/etc/postfic/command_filters

Conteúdo do arquivo:

/^HELO\s*$/ HELO nome.desejado
/^EHLO\s*$/ EHLO nome.desejado

Desta forma, quando um cliente remoto enviar o HELO/EHLO sem estar seguindo do hostname, este comando será substituído por “HELO/EHLO nome.desejado”.

No log será exibida uma entrada conforme abaixo sempre que um comando por modificado pelo Postfix.:

replacing client command “HELO” with “HELO domain.invalid”

Zimbra: Aumentando as entregas simultâneas de mensagens

No Zimbra as mensagens são entregues nas caixas postais dos usuários do sistema através do protocolo LMTP, esta operação é bastante dispendiosa e caso não haja conexões LMTP disponíveis no momento da entrega a mensagem será enfileirada. É preciso se atentar que aumentar este parâmetro irá aumentar a utilização de recursos do seu servidor, portanto deve ser feito somente se estiverem ocorrendo enfileiramentos para entregas locais. É possível identificar se o protocolo LMTP está com gargalo procurando pela seguinte mensagem nos logs:

Zimbra LMTP server closing connection; service busy

Para aumentar o número de processos simultâneos do LMTP, que por padrão vem setado para 20, execute o comando abaixo:

zmprov ms nome.do.servidor zimbraLmtpNumThreads NOVO_VALOR

É preciso também modificar a configuração do Postfix, que é o  MTA do Zimbra para igualar a quantidade de entregas simultâneas com a disponibilidade do LMTP:

zmlocalconfig -e postfix_lmtp_destination_concurrency=NOVO_VALOR

Este valor também vem com padrão setado para 20 e deve sempre ser ajustado de acordo com o número de processos do LMTP.

Configurando o Amavis em um servidor dedicado

Olá ! Neste artigo apresento as configurações para separar o Amavis em um servidor dedicado. Em alguns ambientes isso pode ser necessário devido ao trafego de mensagens, onde o MTA (neste exemplo o Postfix)e Amavis precisam ser separados em servidores dedicados.

Neste exemplo o servidor Postfix é o host mail.matriz.com.br (192.168.200.116) e o servidor dedicado para o Amavis é o host amavis.matriz.com.br (192.168.200.115)

Primeiramente, no servidor Postfix edite o main.cf adicionando a seguinte linha:

content_filter = smtp-amavis:amavis.matriz.com.br:10024

Ainda no servidor Postfix, edite o arquivo master.cf adicionando o seguinte serviço:

0.0.0.0:10025 inet n – y – – smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o mynetworks=127.0.0.0/8,192.168.200.115/32
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
-o recipient_bcc_maps=
-o sender_bcc_maps=

Deve-se prestar atenção no parâmetro mynetworks do serviço, onde deve ser incluído o IP do servidor do Amavis para entrega das mensagens. Feito isso, após reiniciar o serviço, o Postfix já irá entregar as mensagens com as configurações feitas.

No servidor Amavis, precisamos colocar o serviço para escutar na porta 10024 e aceitar conexões do nosso MTA. No Debian e derivados o arquivo 20-debian_defaults pode ser editado para incluir as configurações ou o 50-user, que vem limpo justamente para as configurações adicionais. Para distribuições baseadas em Red Hat, o Amavis utiliza um único arquivo de configuração.

@inet_acl = qw(127.0.0.1 192.168.200.115 192.168.200.116 [::1]); # Controle acesso – Informar os IPs dos MTAs e do servidor amavis
$inet_socket_bind = ‘0.0.0.0’; # Onde escutar – Colocar as interfaces onde o Amavis deve aceitar conexões
$inet_socket_port = 10024; # Porta
### Encaminhando para o Postfix ###
$notify_method = ‘smtp:[mail.matriz.com.br]:10025’;
$forward_method = ‘smtp:[mail.matriz.com.br]:10025’;
###

Efetuada as configurações, reinicie o serviço do Amavis e tente enviar uma mensagem, nos logs do Amavis deve aparecer a conexão do MTA:

Feb  4 13:30:27 amavis amavis[3052]: (03052-01) Passed CLEAN {RelayedInternal}, MYNETS LOCAL [192.168.200.116]:51347 [192.168.200.116] <joao@matriz.com.br> -> <joao@matriz.com.br>, Message-ID: <67917efa9170c57c59fd791eb0e83c47@matriz.com.br>, mail_id: zQYc-U7HehsQ, Hits: -1.326, size: 596, queued_as: 46FAC5A6DC, dkim_new=default:matriz.com.br, 2981 ms

Postfix: Criando regras condicionais

É muito comum termos que criar regras condicionais em nosso MTA, que serão aplicadas a remetentes, destinatários ou domínios específicos. No Postfix isso pode ser feito através da diretiva smtpd_restriction_classes (http://www.postfix.org/RESTRICTION_CLASS_README.html).

Vamos imaginar o seguinte cenário, uma organização possui dois domínios (vamos assumir que sejam matriz.com.br e filial.com.br) e precisa criar regras para que determinados usuários enviem e-mail somente para os domínio internos ou até mesmo um único domínio interno. Iniciamos a configuração criando essas classes no main.cf:

smtpd_restriction_classes = somente_matriz, somente_filial, somente_interno

somente_matriz = check_recipient_access hash:/etc/postfix/condicionais/somente_matriz, reject

somente_filial = check_recipient_access hash:/etc/postfix/condicionais/somente_filial, reject

somente_interno = check_recipient_access hash:/etc/postfix/condicionais/somente_interno, reject

Portanto, com a diretiva smtpd_restriction_classes criamos as três classes e logo abaixo especificamos cada uma delas, sendo que após a verificação do arquivo, há a rejeição explícita.

Para definir a quem se aplica a regra, precisamos criar um arquivo para efetuar essa consulta, e como estamos criando um controle de destinatário, colocar a consulta em smtpd_recipient_restrictions:

check_sender_access hash:/etc/postfix/condicionais/regras_condicionais

Lembrando que esta regra deve vir em primeiro lugar, pois mesmo se o remetente estiver conectando de um host confiável ou autenticado, o bloqueio deve ser aplicado, por exemplo:

smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/condicionais/regras_condicionais,
permit_mynetworks,
reject_sender_login_mismatch,
permit_sasl_authenticated,
reject_unauth_destination,
reject_unlisted_recipient,
reject_unverified_recipient,
reject

O arquivo regras_condicionais é escrito da desta forma:

fulano@matriz.com.br                  somente_matriz

beltrano@filial.com.br                  somente_filial

sicrano@matriz.com.br               somente_interno

Neste exemplo, temos três usuários onde estamos aplicando classes diferentes, e outros usuários não estarão em nenhuma.

O arquivo somente_matriz fica da seguinte forma:

matriz.com.br OK

O arquivo somente_filial fica da seguinte forma:

filial.com.br OK

O arquivo somente_interno fica da seguinte forma:

matriz.com.br OK

filial.com.br OK

Portanto, para cada classe definimos o domínio de destino seguindo da diretiva OK, informando ao Postfix que deve ser permitido, e como após a consulta do arquivo definimos um reject o envio para domínios fora da regra será negado.