[FUGSPBR] Extenso: chegando na bifurcacao, pegue à esquerda... (ERA: Antivirus direto no MTA)

[Patrick Tracanelli]

Varias vezes eu me perguntei -- sei que isso sai um pouco fora do
assunto principal dessa thread --- se compensa pagar o preco de ser
bidirecional, e o preco e' muito, muito alto do ponto de vista de
utilizacao de recursos. Ainda nao tive minha resposta mais valida, e
fica sempre naquela que "cada caso e' um caso".

Boa parte das implementacoes de servidor de correio, utiliza a mesma
estacao servidora para fazer relay e para receber os e-mails para os
dominios. O numero de relay externo varia muito com o perfil do local,
do provedor, dos clientes, do servico prestado, etc.

Logico que nos casos onde se tem como MX um servidor e como saida
(relay) outro, melhor ate' do ponto de vista de controle, alem do obvio,
utilizacao de recursos.

Considerando essa variacao, em alguns casos o servidor pode ter a
maioria de sua carga utilizada para o recebimento (mensagens que chegam,
onde o servidor e' o destino final). Dependendo da situacao, a maior
parte para relay (o que sai pela fila remota com destino externo).

Em algumas situacoes, a situacao muda de forma dependendo do "horario",
ou seja tem picos de delivery, e tem picos de recebimento. Depende do
perfil de "que hora seu cliente faz o SPAM dele de cada dia". E
convenhamos, ha muitos os casos que nos temos que conviver onde nao
podemos sequer coibir essas acoes, pelo simples motivo que se aquele seu
cliente de ADSL alega que a "mala direta" dele e' apenas de clientes
cadastrados, ou se e' um autentico Spam, voce nao tem como contestar a
palavra dele...

Mas questoes politicas a parte, o que eu andei levantando e' que em
media, de todo o historico estatistico de virus encontrado nos
servidores, existe variacao de 80 a 98% dos casos das mensagens
"infectadas" estarem exclusivamente nas que sao recebidas. Ou seja nos
e-mails que chegam, e nao nos que saem.

Trocando em miudos, nos perfis de estatistica que eu levantei, o pico de
virus encontrado em "relay" e' de 20%, e nesses casos no "gran momentum"
  da infeccao de novos virus, como as recentes (2 meses) epidemia
recorde-sobre-recorde de virus. Mesmo nesses casos nao passa de 20% pois
a proporcao dos virus que chegam (os 80% da conta) e' muito maior do que 
os que saem.

E considerando que boa parte desses virus instalam proxy SMTP no windows
infectado ou eles mesmos agem como agentes de relay, nao dependendo
completamente de fazer relay pelo servidor autentico do cliente, nao da
para afirmar que "se todos servidores fossem competentes em evitar a 
contaminacao na saida, nao ocuparia toda a banda do trafego ate' a outra 
ponta".

Bom, como a situacao varia, tenho duas situacoes que eu me lembro. Na
primeira e' um provedor super comportado, que a media de concorrencia de
entregas remotas fica em 12 mensagens. A cada 5 ou 6 dias, de todos os 
e-mails verificados, 2 (ou menos) estao infectados. Fazendo uma regra de 
3 simples, analisando logs de 10 dias, verifiquei que isso equivale a 
0,8% dos deliveries.

Nos logs de datas de pico e' 2% hehe.

Conclusao simples...

2% de pico, 0,8 em situacoes comuns. Ainda que minhas analises precisem 
de refinamento, ou nao ser em apenas 2 ou 3 provedores apenas, e sim uma 
estatistica de todos, vamos dobrar esses valores, colocando 4% em pico e 
1.6% no dia-a-dia. Quer dizer que 96% ou mais de tudo que é scaneado na 
saida, é inutil.

Mas o que é inutil?

1- O wrapper pega a mensagem, faz uma copia e grava em disco
2- o wrapper descompacta se for anexo compactado, ou decodifica se for 
mimes estranhos, ou o famoso tnef
3- O wrapper chama o AV
4- O AV scaneia o temporario em disco, verifica que ta limpo (um error 
code simples, nao precisa processar a saida, verdadeiro ou falso basta)
5- O wrapper consta que ta limpo e manda a msg pra fila, pra sua entrega 
ser agendada
6- O wrapper apaga o temporario em disco.

Vamos supor que a VM/Buffer integrada do FreeBSD fosse perfeita (é o 
melhor que um sistema pode ter, mas a perfeição é relativa), então não 
precisamos contar custo de I/O em disco com a copia da fila pro disco e 
analise no disco. Considerando que tudo seja varrido nos caches, em 
memoria. Olha o tanto de memmoria e ciclos de CPU completamente 
inuteis... 96% de todos os deliveries.

Ta limpo? Otimo, mas cada cliclo de clock e instrucao foi concorrida com 
  as varreduras nos emails que estavam chegando, se for o mesmo servidor.

Se é um ambiente calminho, load avg de 2 (sim, nos dias de virus de 
ultimamente,  eu considero load de 2 um sussego), deixa varrer a saida...

Mas e se a saida e recebimento não são servidores separados? E se voce 
tem clientes que enviam "newsletter" (hehe vamos chamar assim, o que nos 
achamos que é Spam e eles dizem ser autentico) para mais de 400, 500 
destinos diferentes, varias vezes ao dia cada um...

Bom, esse e-mail nao tem a pretencao de resolver coisa alguma, mas só 
quis compartilhar algumas situações que me incomodam. Ainda estou 
seguindo a maxima que "cada caso é um caso" resume o fato.

Mas estou cada dia mais inclinado em retirar filtro-em-fila 
(qmail-scanner) da minha checklist, em prol de algumas linhas de 
maildrop ou do QMVC (que eu nem acredito que tenha mais performance que 
o QS porque é em pdksh e não perl, mas sim simpatizo por ser 
dot-qmail(5) a coisa...)

Especialmente pq, hj em dia apenas AV nao basta... tem que ter SA junto 
O_O ai inclua entao os ciclos do SpamAssassin subutilizados pra 
"reescrever cabecalho" em cada relay limpo...

[cut]
>> Um problema que vejo no QMVC, é o fato de ser unidirecional, ou seja, 
>> só verifica mensagens que chegam e não as que saem. Desta forma, as 
>> contas internas poderiam enviar vírus sem qualquer controle.
[cut]
-- 
Atenciosamente,

Patrick Tracanelli

FreeBSD Brasil LTDA.
The FreeBSD pt_BR Documentation Project
http://www.freebsdbrasil.com.br
patrick @ freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"


_______________________________________________________________
Para enviar um novo email para a lista: fugspbr em fugspbr.org
Sair da Lista: http://lists.fugspbr.org/listinfo.cgi
Historico: http://www4.fugspbr.org/lista/html/FUG-BR/