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.
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:
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:
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.
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.
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:
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.
[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.
[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.
[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... :)