Integrando o Amavisd-new, SpamAssassin e ClamAV com o Postfix no SuSE 9.3

Neste artigo veremos como instalar, configurar e integrar o Amavisd-new, SpamAssassin e ClamAV ao Postfix no SuSE 9.3, porém estes mesmos procedimentos podem ser utilizados em outras distribuições.

[ Hits: 41.014 ]

Por: Sandro Venezuela em 20/06/2007


Configuração



O arquivo de configuração do Amavisd-new é /etc/amavisd.conf, onde é sempre importante manter uma cópia do arquivo original de instalação para eventuais problemas.

# cd /etc
# cp -p amavisd.conf amavisd.conf.default


A partir do arquivo original vamos inserir alguns parâmetros e alterar outros. Abaixo estão apresentadas somente as diferenças entre o arquivo padrão e o novo arquivo:

$mydomain = 'linux2business.net.br';
$sa_tag_level_deflt = undef; # add spam info headers if at, or above that level
$sa_tag2_level_deflt = 5.0;
$sa_kill_level_deflt = 10.0; # triggers spam evasive actions
$sa_dsn_cutoff_level = 5.0; # spam level beyond which a DSN is not sent
$sa_spam_subject_tag = undef;
$final_virus_destiny = D_DISCARD;
$final_banned_destiny = D_DISCARD;
$final_spam_destiny = D_DISCARD;
$final_bad_header_destiny = D_PASS;
### http://www.clamav.net/
['ClamAV-clamd',
\&ask_daemon, ["CONTSCAN {}\n", "/var/lib/clamav/clamd-socket"],
qr/\bOK$/, qr/\bFOUND$/,
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],
# NOTE: the easiest is to run clamd under the same user as amavisd; match the
# socket name (LocalSocket) in clamav.conf to the socket name in this entry
# When running chrooted one may prefer: ["CONTSCAN {}\n","$MYHOME/clamd"]

Obs.: Na configuração dos antivírus, somente deixar descomentadas as opções para o ClamAV, comentando todas as outras se necessário.

Com a configuração proposta para o Amavisd-new, todos as mensagens que forem identificadas como um vírus ou que o contenham serão armazenadas no diretório /var/spool/amavis/virusmails e uma mensagem de alerta será enviada para o usuário virusalert, onde estes parâmetros podem ser alterados no arquivo /etc/amavisd.conf através das variáveis $QUARANTINEDIR e $virus_admin.

O usuário virusalert é um alias para o usuário root, que DEVE ser também um alias para outro usuário, como por exemplo: sysadmin. Este procedimento é uma questão de segurança, pois nada deve ser feito utilizando o usuário root.

O controle das mensagens identificadas como SPAM também pode ser configurado da mesma maneira que é realizado para mensagens com vírus, bastando adicionar ou alterar os parâmetros $spam_admin e $spam_quarantine_to.

Uma vez realizada a configuração do Amavisd-new, devemos configurar o ClamAV, através do arquivo /etc/clamd.conf. Abaixo temos as alterações realizadas a partir da configuração padrão:

LogFileMaxSize 2M
LocalSocket /var/lib/clamav/clamd-socket
#TCPSocket 3310
#TCPAddr 127.0.0.1

Em seguida devemos configurar o serviço FreshClam, responsável pela atualização da base de vírus do ClamAV. O arquivo de configuração é /etc/freshclam.conf, onde a partir do arquivo padrão devemos realizar as seguintes alterações:

UpdateLogFile /var/log/freshclam.log
DatabaseMirror db.BR.clamav.net
DatabaseMirror database.clamav.net

Com a configuração terminada, devemos primeiro carregar a base de dados do ClamAV através do comando:

# freshclam --verbose

Obs.: O comando acima deve finalizar corretamente sua operação.

Devemos também criar o arquivo /var/log/freshclam.log configurando as permissões corretas para seu funcionamento:

# touch /var/log/freshclam.log
# chown vscan.vscan /var/log/freshclam.log


Por último, devemos iniciar os serviços freshclam, clamd e amavis:

# rcfreshclam start
# rcclamd start
# rcamavis start


As atividades dos serviços acima podem ser monitoradas através do arquivo /var/log/mail e para o serviço Amavisd-new devemos verificar se a porta 10024/tcp foi iniciada.

# netstat -ntl | grep ":10024"
tcp   0   0 127.0.0.1:10024    0.0.0.0:*    LISTEN

Finalizando a integração, devemos alterar os arquivos /etc/postfix/main.cf e /etc/postfix/master.cf, adicionando os seguintes parâmetros em cada um deles.

No arquivo /etc/postfix/master.cf:

smtp-amavis unix -      -       n       -       2  smtp
   -o smtp_data_done_timeout=1200
   -o smtp_send_xforward_command=yes
   -o disable_dns_lookups=yes

localhost:10025 inet n  -       n       -       -  smtpd
   -o content_filter=
   -o local_recipient_maps=
   -o relay_recipient_maps=
   -o smtpd_restriction_classes=
   -o smtpd_client_restrictions=
   -o smtpd_helo_restrictions=
   -o smtpd_sender_restrictions=
   -o smtpd_recipient_restrictions=permit_mynetworks,reject
   -o mynetworks=127.0.0.0/8
   -o strict_rfc821_envelopes=yes
   -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 arquivo /etc/postfix/main.cf:

content_filter=smtp-amavis:[localhost]:10024

Obs.: Este procedimento de integração entre o Amavisd-new e o Postfix está descrito no arquivo /usr/share/doc/packages/amavisd-new/README_FILES/README.protocol.

Com as alterações realizadas é necessário reiniciar o Postfix.

# rcpostfix restart

Com o comando netstat devemos verificar a porta 10025/tcp iniciada:

# netstat -ntl | grep ":10025"
tcp   0   0 127.0.0.1:10025     0.0.0.0:*       LISTEN
tcp   0   0 ::1:10025           :::*            LISTEN

Os testes de integração podem ser realizados com o comando telnet, simplesmente enviando mensagens de um usuário para o outro e observando os registros no arquivo /var/log/mail.

A princípio nenhuma alteração precisa ser realizada para o funcionamento do SpamAssassin, porém é importante sempre melhorar as regras de verificação de SPAM, adicionando novas regras ao arquivo de configuração /etc/mail/spamassassin/local.cf.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. Configuração
   3. Referências
Outros artigos deste autor

Instalando o QEMU no Fedora Core 4

Configurando uma VPN IPSec Openswan no SUSE Linux 9.3

Instalando a placa de rede wireless DWL-G520+ no Fedora Core 3

Construindo um Firewall / Proxy com o Fedora Core 4

Leitura recomendada

Qpopper (POP seguro) no Slackware

Instalação e configuração do sendmail

Recuperando senhas de e-mails esquecidas usadas no Claws-Mail

Vacation fácil com o OpenVacation

Post-la - Gerador de relatórios para o Postfix

  
Comentários
[1] Comentário enviado por y2h4ck em 20/06/2007 - 09:00h

Cara bem legal seu artigo, tenho apenas uma crítica a fazer: Você baseou sua solução em cima de uma distribuição dada como Morta, ou seja SuSE 9.3 virou uma distribuição EOL (end of life), e não terá mais suporte a patches de atualizações de segurança e updates por parte da Novell.

Acho bem interessante a solução porém o uso da mesma pode acarretar em diversos problemas futuros, em especial com o upgrade do sistema, ocasionando falhas de segurança e possibilitante que toda a solução seja comprometida, uma vez que, não se conta com um sistema eficiente para Patch-Management.

Abraços.

Anderson

[2] Comentário enviado por s4ndr0 em 21/06/2007 - 09:49h

Eu já sabia desta questão quanto à distribuição, porém foi uma exigência do próprio cliente, que tem todos os servidores com SUSE 9.3 e que precisava de uma solução idêntica à outro servidor de correio existente.

Agora, estou trabalhando na atualização de todas as versões, que devem continuar com a distro SUSE. A escolha da distribuição também é do cliente, que já tem um histórico bem sucedido com esta escolha. (Não existem distribuição boa nem ruim, todas são LINUX!!! Lembre disto.)

Mesmo assim, obrigado pela observação e é claro que este artigo pode ser utilizado em qualquer distro.

Obrigado,
Sandro

[3] Comentário enviado por y2h4ck em 21/06/2007 - 11:34h

"(Não existem distribuição boa nem ruim, todas são LINUX!!! Lembre disto.)"

Sim me lembro disto, mas lembre que sendo boa ou ruim, uma distro desatualizada sempre vai causar problemas, sendo vc, o cliente ou o papa quem decidiu usar, e você como o analista encarregado do projeto tem que fornecer uma solução viavel para este tipo de coisa e não deixar que seja usado um sistema que Morreu.

Mesma coisa, um cliente chegar "Quero um Web server com conectiva 10". Por mais que você atualize vc nunca vai ter a garantia que conseguiu preencher todas as lacunas que a distribuição deixou. Dai você por ter atualizado meia duzia de libs manualmente fica com a falsa sensação de segurança, dai acham o seu servidor e B00m... :)


Abraços.

Anderson

[4] Comentário enviado por s4ndr0 em 21/06/2007 - 12:20h

Sim, concordo com você, tanto que agora, como disse, estou trabalhando na atualização das mesmas.

O que quiz dizer, foi que não existem distros boas nem ruins, comparando SUSE, Fedora, Debian, Slackware, etc... Todas são Linux!

Mas que a segurança é algo importante, isto não tenho dúvida.

Abraço,
Sandro


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts