Prized Season software

Eu sou um Freesco geek (ou fã incondicional, mais propriamente geek, de acordo com a tradução da Wikipedia em português), e como tal, proporciono o mirroring do Freescosoft (cópia num site português, para quem queira economizar o tráfego dito nacional): pt.freescosoft.net.

Há um script regular (chamado cron-job) que corre regularmente para sincronizar todos os ficheiros. Para quem está familiarizado com cron-jobs Unix, a linha em /etc/cron/root (ou fazendo crontab -l) é:

# Freescosoft mirroring
0 5 * * 3 exec /pkg/bin/rsync --modify-window=1 -rcztW --stats --delete --password-file=/pkg/usr/local/rsync-fs/.fs.rsyncpwd fs-mirrors@www.freescosoft.com::mirror/ /www/freescosoft >> /pkg/usr/local/rsync-fs/rsync-fs.log 2>&1
# (as linhas acima sem ashes/cardinal é apenas uma, na realidade)

Ou seja: às 05:00 (de madrugada), de todas as 4ªs-feiras.
Como bem explica esta página em português (www.devin.com.br/eitch/crontab/), os campos são os seguintes:

Campo	Função
1o.	Minuto
2o.	Hora
3o.	Dia do mês
4o.	Mês
5o.	Dia da semana
6o.	Programa pra execução

Onde:

Campo	Função
Minuto	0-59
Hora	0-23
Dia do mês	1-31
Mês	1-12
Dia da semana	0-6 (o zero é domingo, "1" segunda, etc)

Podem ser dadas wildcards (asteriscos, cujo símbolo em inglês se denomina por: asterisk, ou habitualmente star) totais (apenas um asterisco) ou parciais.

Por exemplo: o primeiro campo "*/5" significa de cinco em cinco minutos.


A minha contribuição humilde para o Freesco foi ter feito uma package inicial, aplicável à versão v0.3.1 e superiores, poderá visualizar esta package em pt.freescosoft.net/html/FREESCO/packages/v0.3.x/exim_---_moreira.htm, (no site original: moreira.dnsalias.net/home/freesco/pkg/).

Embora este pacote contenha a versão 4.34, já compilei o Exim 4.60, mais actual, ainda sem SQL-support (o qual eu não preciso). Até hoje só tive um problema com este pacote: na configuração que usei tenho /var/log/exim_mainlog (para minimizar os acessos ao disco); como a directoria /var está montada na RAM, a memória disponível é limitada; como não tenho o script de rotação do log, o espaço não foi suficiente, e o Exim, em vez de prosseguir airosamente, caput, parou. No exemplo em baixo, vêem 418 Kbytes livres, apenas.
(Neste exemplo os logs têm 5000 linhas -- somando exim_paniclog, exim_mainlog, exim_rejectlog e messages{,.1}).

% df | grep ram
/dev/ram0 2901 2483 418 86% /

De facto o Exim é, na minha opinião, o melhor MTA disponível (aquele que eu também de facto estou mais familiarizado). O Exim e o Freesco juntos, tornam-se excelentes.

O pacote greylistd da distribuição Debian é muito fácil de utilizar.
A instalação que fiz, estável, incluiu o Exim4 e posteriormente o greylistd.

Neste artigo foco as partes de configuração dos triplets, assumindo que o leitor já conhece os princípios gerais do greylisting.

O habitual é termos uma média de 10% de entradas grey (cinzentas) em relação às entradas white (brancas).
Ao dia de hoje, um conhecido servidor da internet tinha:

millis:~# greylist list --white | wc -l
4579
millis:~# greylist list --grey | wc -l
369
millis:~# greylist list --black | wc -l
6

A imagem em cima (gerada a partir do Munin) ilustra de forma sistemática a evolução destas entradas (pelo que a regra referida dos 10% é apenas uma estimativa aproximada do que acontece tipicamente a médio/longo prazo).
No seguinte exemplo vemos como se podem usar os comandos manuais de remoção de entradas cinzentas:

millis:~# greylist delete --grey '213.171.223.109' postmaster@localhost burlado@real_domain.xyz
error: Not found
millis:# greylist delete --grey "'213.171.223.109'" postmaster@localhost burlado@real_domain.xyz
Removed from greylist

Quando existem plicas nos endereços IPs, no caso de se usar uma shell bash (a shell default em Linux), tem que se evitar a substituição que a própria shell faz das plicas para esse argumento: logo a utilização de aspas torna-se necessária.

Pessoalmente a parte do greylistd para black-listed IPs não me convence: é demasiado onerosa. (Usar triplets para manualmente declarar um IP-source que temos a certeza que é um rato, ou um open-relay, ocupa demasiada memória física.) No entanto, o Exim4 possui mecanismos de procura linear.

Vejamos um exemplo de um rato regular que tenta colocar spam no meu MTA:

% host mail-kr.bigfoot.com
mail-kr.bigfoot.com. has address 211.115.216.228
mail-kr.bigfoot.com. has address 211.115.216.252
mail-kr.bigfoot.com. has address 211.115.216.222
mail-kr.bigfoot.com. has address 211.115.216.225

Corremos o Exim4 em modo debug da seguinte forma:

exim4 -d -bh 211.115.216.226

Se tivermos as regras habituais e um ficheiro em /etc/exim4/local_host_blacklist com o seguinte conteúdo

211.115.216.226

poderemos simular a entrega de spam, e o comando que corremos gerará o seguinte log:

check hosts = ${if exists{/etc/exim4/local_host_blacklist}{/etc/exim4/local_host_blacklist}{}}
host in "/etc/exim4/local_host_blacklist"? yes (matched "211.115.216.226" in /etc/exim4/local_host_blacklist)
deny: condition test succeeded
SMTP>> 550-sender IP address 211.115.216.226 is locally blacklisted here. If you think
550-sender IP address 211.115.216.226 is locally blacklisted here. If you think
SMTP>> 550 this is wrong, get in touch with postmaster
550 this is wrong, get in touch with postmaster
LOG: MAIN REJECT
H=mail-kr.bigfoot.com [211.115.216.226] F=xpto rejected RCPT guest@frog.prized: sender IP address 211.115.216.226 is locally blacklisted here. If you think this is wrong, get in touch with postmaster

Isto é trivial, embora exija a alteração manual do ficheiro referido, em relação aos triplets pretos do greylistd.
Os triplets são constituidos por 3 strings, na realidade, embora a primeira seja na realidade, por definição, o endereço IP de origem da mensagem (o SMTP-client) -- que pode conter outros caracteres delimitadores, como por exemplo a plica, e eventualmente descrito pelo CNAME.

% greylist list --grey | grep "'"

A lista de IPs linearizados acinzentados pode ser visualizada pelo comando em cima. Nem sempre os MTAs legítimos re-enviam as mensagens das suas filas em menos de 60 minutos; há um balanço cuidadoso entre a diminuição deste periodo (configurável no greylistd) e a resolução manual por white-lists: estes casos serão tipicamente assinalados com o valor 4 a 6, significa 4 a 6 tentativas de drop (neste caso, de servidores legítimos, espaçadas por periodos racionais).

gsinlistd - Version 0.2

A versão 0.2 está na forja: o modo proxy em especial tem um controlo efectivo de listas (black-/white-lists) para ser mais performante; os logs estão melhorados, e estou a ultimar a variância de passwords para blowfish-stream (a comunicaçãoo entre o proxy e o serviço master).

cat ~/rep-mail.txt | exim -bh 1.2.3.4

onde o ficheiro é:

mail from: real_name@sapo.pt
rcpt to: henrique@fuji.prized
data
Subject: ola

apaga.
.
quit

No exemplo de cima poderão ver no proxy a seguinte mensagem (com a opção --debug 9):

Retried buffer split (done: black-listed): --black 1.2.3.4 real_name@sapo.pt henrique@fuji.prized

Significa que a mensagem será "engonhada" (stalled, termo mais preciso) pelo gsinlistd-daemon.
Tendo em vista que em média as mensagens dos ratos (rats, no termo original) são sequenciais, isto significa uma economia enorme nas blowfish-streams enviadas para o serviço master.
O stalling obedece aos requisitos estabelecidos nas RFCs para o SMTP, isto é, de forma mais precisa, o MTA que usa este serviço responderá aos comandos RCPT e DATA apenas um pouco mais rápido do que o tempo de resposta máximo previsto no RFC 2821 (section 4.5.3.2 "Timeouts".) Na realidade, na versão actual, usa-se como rule of thumb cerca de 50% do periodo de timeout, para evitar cair no erro de não nos tornarmos consistentes com os requerimentos do referido RFC.

Este artigo ilustra as potencialidades da solução, que não será detalhada em demasia, dado o produto ter uma versão comercial planeada.

Há um ano publiquei um estudo sobre User-mode Linux (UML). No preâmbulo pode ler-se: this study intends to show practical examples of networks running UML, ou seja, "este estudo pretende mostrar exemplos práticos de redes, usando-se para tal o UML": http://moreira.dnsalias.net/my_uml/...pdf.

Na primeira figura pode ver-se a intranet física (rede local) e depois mostro, através de exemplos, uma rede (constituida por servidores virtuais). A primeira dificuldade para quem nunca utilizou UML é perceber o conceito: trata-se de um programa que corre num servidor (denominado host system) e que emula uma máquina Linux, esta designada por visitante (guest, no original).

Na realidade esse programa não é mais do que um desagradável patch ao Kernel (penoso para quem queira saber exactamente qual a versão do Kernel a utilizar, da série 2.4, ou porventura acertar com a versão estável da árvore do Kernel 2.6; talvez 2.6.xx, xx>=12?) com a flag de compilação (*):

• host% make ARCH=um

(*) Encontram um tutorial minimalista em http://user-mode-linux.sourceforge.net/compile.html

Depois de escolher um file-system adequado (pool_h01), optar pelas opções correctas de lançamento do executável que resultou da compilação especial do Kernel, terá a agradável surpresa de ver lançada a sua máquina virtual. Até aqui tudo corre de forma linear, embora a curva de aprendizagem seja fortemente dependente da forma como pretende entender o que se passa. Por outras palavras, se quiser experimentar um sistema qualquer, o melhor será usar o Debian, e instalar o pacote 'linux', correndo na linha de comando, como um qualquer utilizador (não necessariamente root), o executável 'linux'.

À primeira vista, é tão simples que até arrepia, mas existem enúmeras opções que farão desesperar o hacker mais hábil. As opções de utilização da consola! Certamente terá à primeira tentativa coisas como: a consola não fica visível, o utilizador root é recusado, a rede é inexistente ou mal configurada, ou, se tudo mais correr bem, o mounting point raíz do sistema (slash, i.e. '/') é /dev/ubd/0 (ou /dev/ubd0) -- em vez do habitual /dev/hda1 (ou /dev/hd?? no caso de um disco IDE).

No último caso, para o file-system Debian Woody (pool_h01/fs_deb3C_1.ex2.bz2), verá previsivelmente o seguinte:

...
Serial line 0 assigned device '/dev/ptyp0'
Virtual console 2 assigned device '/dev/pts/8'
Debian GNU/Linux testing/unstable fazpipe ttys/0
fazpipe login: root
Password:
Login incorrect
fazpipe login: guest
Password:
Last login: Sun Nov 12 13:47:50 2006 from 10.1.0.254 on pts/0
Linux venus 2.4.24-1um #3 Sun Apr 18 14:11:25 WEST 2004 i686
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have mail.

A password standard para estes file-systems pre-feitos é guest, usando-se geralmente o utilizador guest. Neste caso o executável UML é baseado no Kernel 2.4.24, patch do Blaisorblade, um dos patches que eu considero mais estável -- para obter um guest system com qualidade e estabilidade.

fazpipe:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/ubd/0 485M 409M 51M 90% /
tmpfs 31M 0 31M 0% /dev/shm
fazpipe:~# cat /proc/swaps
Filename Type Size Used Priority
/dev/ubd/1 partition 131064 33576 -1

Estes dois comandos no guest (cujo nome escolhido é 'fazpipe') são interessantes: primeiro verificamos que o sistema de raíz está montado algures, e usamos uma partição de swap (já veremos onde está fisicamente).

O host, por seu lado, poderá (ou melhor, para ser mais performante, deverá) ter suporte para Skas-3 mode:
Linux fuji 2.4.26skas #8 SMP Sun Jun 6 20:37:52 WEST 2004 i686 unknown

Eu não percebo grande coisa ao nível do Kernel para dissecar as diferenças entre o mode thread (TT) versus Skas-3, apenas posso referir que este modo optimiza a execução dos diversos guests que o sistema anfitrião (host) aloja. Dito de outro modo, os recursos do host são utilizados mais eficientemente quando se usa o modo Skas, em particular o modo Skas-3 (que é a última geração do modo Skas). De forma mais directa, se depois de lançar um guest verificar que existem múltiplas threads do processo (o nome do processo é linux) está em modo TT; se por outro lado verificar apenas duas threads para o guest lançado, então está a usar um Kernel com suporte para modo Skas.

Um aspecto importante na gestão dos sistemas existentes é a possibilidade de se utilizar um sistema de layers do próprio file-system, o qual se denomina por Copy On Write, ou COW. A par do file-system utilizado, pode utilizar outro file-system especial -- COW -- para evitar estar a escrever no file-system original. Há enúmeras vantagens para esta utilização, das quais destaco a poupança de espaço: vários guests podem ser lançados a partir do mesmo file-system de base, sem que para tal tenha que replicar literalmente toda a informação. Vejamos um exemplo simples: o file-system Debian Woody (cujo cog-nome é deb3H) tem cerca de 500 Mbytes; se utilizar um COW file-system ficará com um segundo ficheiro (no host, obviamente) que, embora aparente ter um tamanho semelhante (na ordem dos 500 Mbytes, conforme o exemplo em baixo), e que espelha as alterações que se vão fazendo no deb3H, é na realidade um ficheiro sparsed (com o comando 'du -k' verá que se trata apenas de uns meros 85 Kbytes de tamanho no disco).

host% ls -l...
524288000 Oct 22 01:17 fs_deb3H_3.ex2
520497664 Nov 15 00:15 fs_deb3H.cow

O tamanho real do ficheiro COW:

(Kbytes)(File-system name)
512504 fs_deb3H_3.ex2
85476 fs_deb3H.cow

Outra vantagem significativa da utilização do COW é a possibilidade de voltar atrás (undo) num simples passo: basta para tal parar o guest, apagar o ficheiro COW e relançar o guest novamente com a opção de COW.

Voltando ao assunto que aqui me trouxe: o UML tem uma aplicabilidade directa nas universidades, para teste e desenvolvimento de produtos (como por exemplo permitir a coexistência de diversas compilation farms minimizando o equipamento necessário para tal) e
igualmente para fins comerciais. São exemplos de companhias de sucesso aquelas que, pela utilização do UML, conseguiram disponibilizar servidores na internet a um custo de cerca de 1/5 do preço. Este benefício é inerente à possibilidade de se instalarem diversos sistemas guests para o mesmo servidor físico, o que constitui uma poupança real nos custos do provider -- que se traduz de forma quase directa no custo dos clientes interessados.

(**) Na imagem deste artigo podem ver o host (hkernel2.4.26skas-8...), o router (Freesco), e duas máquinas virtuais (guest systems) ligadas a uma bridge virtual.

gSinListd no modo proxy contempla white-/black lists baseadas em IPs, mas ainda não verifica os dados após o fork; e o source-IP que envia a ligação, no modo proxy, será o do MTA.
Este modo (proxy) é realmente dos mais interessantes, embora o modo server o mais poderoso.
A opção '--emulate' permite testar a hash-list que serve de camada de protecção para IPs em white-lists.

gsinlistd - Version 0.1

gsinlistd mode [OPTIONS] [server-socket-file]

Mode is: server, client, master or proxy

Default Unix TCP socket file is: /var/run/gsinlistd/socket

Options are:
-m (--master) X to specify the master.
-w (--white-list) X to specify the white-list 'itb'.
-b (--black-list) X to specify the black-list 'itb'.
-e (--emulate) X to emulate connection from IP X.

Para aqueles que ao gSinListd não disser nada, esqueçam que esta pequena publicação existe.

Detesto blogs, mas às vezes dá-me jeito ser narciso, e escrever o que vou fazendo ao longo do tempo. Podem crer que arruma as ideias; isto de a gente escrever para a blogosfera, sem preconceitos, e falar livremente do que vai fazendo, embora fútil, dá-nos a noção de contribuirmos para o bem comum... e afectarmos um bocadinho o ambiente. Sim, porque isto de escrever uns quantos parágrafos é engraçado, mas ocupa espaço em disco, e os discos não são 100% renováveis. Mas para o que eu escrevo, vale bem o esforço. Não gosto de falsas modéstias, assim é que é!

Dizia eu no título, um aperitivo para o que é o anti-spam cooperativo, em português: para quem se der ao trabalho de ler isto, basicamente significa que várias máquinas amigas, de amigos, ou melhor, de pessoas de confiança, geridas por gajos competentes, podem ser uma mais valia em nos reportar anomalias de ratos. Ratos é o vulgo termo rat, que significa quem propaga o spam.
Traduzindo, spam, é lixo que vos chega à caixa de correio electrónico, ou no sentido mais lato, que vos chega à vossa caixa de correio. Fazer anti-spam cooperativo, mal comparado, é vocês terem uma rede no vosso correio: quando o carteiro lá chega, tem que perguntar a alguém se pode deixar lá os folhetos do Continente. Mas pergunta a quem? Aí está o truque: imaginem lá.
Ao vosso gestor de conta? Não. Ao vosso pai? Não. É mais ou menos à porteira do prédio ao lado, que é uma senhora decente, curiosa, e que espiolha tudo o que lhe passa nas mãos. É mesmo a alcoviteira lá do vosso sítio, está a par de tudo e é muito criteriosa na seleção do lixo, ou melhor, do correio que vos pode chegar. Se for lixo, então o bijagós (http://pt.wikipedia.org/...bijagós) que queria lá despejar a propaganda recebe um 5NN (desculpem lá a linguagem, mas é que estou um bocado viciado no SMTP - códigos de retorno entre 500 e 599 são rejeições mandatórias, por exemplo "permanently rejected messages") no caso de se ligar ao Spamassassin durante a transação de "DATA" (o conteúdo do email propriamente dito), ou no caso que eu acho, pessoalmente, mais interessante, 451 (temporary failure, please retry).

Seguindo o nosso exemplo, a vossa caixa de correio é o MTA que está a gerir os vossos mails, o bijagós é o rato, e a porteira é o servidor de pecados. A cooperação entre a vossa máquina que corre o MTA e o "servidor de pecados" estabelece-se usando blowfish-streaming (para encriptar a comunicação de forma segura - desculpem o incómodo, mas não posso revelar estea variante de encriptação do blowfish, porque quero tornar este método num RFC); o servidor geralmente corre algo que elimina 90% a 95% do spam, o melhor exemplo que conheço actualmente é o Greylistd (http://en.wikipedia.org/...Greylist), e o vosso MTA limita-se a papaguear os triplets que recebeu para o servidor de pecados. Embora o nome pareça religioso, o algoritmo usado pelo dito servidor não tem nada de transcendente: no caso linear de se usar Greylist no servidor ele actua como o master de todos os triplets, conectando-se ao socket do greylistd directamente. Há outras formas mais poderosas, e ainda mais simples, de como o master pode actuar - mas estas formas não podem ser tornadas públicas para já.

Na realidade o vosso MTA (a correr em modo gsinlistd proxy) pode ser moderadamente estúpido: se for o Exim, por exemplo, terá apenas umas linhas de configuração do género apresentado em baixo, na secção acl_check_rcpt.


Pode parecer complicado, mas se conhecerem o Exim isto é canja: antes de aceitar o destinatário, escrever no Unix (Stream) socket e ficar à espera, durante um máximo de 3 minutos, pela resposta. Na realidade quem está à escuta (ou mais precisamente, quem faz o bind do socket) é o gsinlistd, que re-envia o pedido encriptado para o servidor de pecados, na nossa analogia, a ciosa porteira.

Qual a vantagem de centralizar os pedidos de vários MTAs numa porteira, é uma pergunta interessante. Para o mesmo triplet ({ip, from, to}) a resposta não depende de qual o MTA que serve o pedido, conquanto os MTAs sejam MX-backups uns dos outros.

Um exemplo mais elucidativo: o mail do Google tem vários servidores MX. Vejam o comando seguinte:

% dig mx google.pt | grep MX
google.pt. 1777 IN MX 10 smtp1.google.com.
google.pt. 1777 IN MX 20 smtp2.google.com.
google.pt. 1777 IN MX 30 smtp3.google.com.

Estes 3 MXes certamente actuam contra spam independentemente. O modus-operandi dos ratos medianamente inteligentes presta-se a tentar em cada um destes rapidamente. Se o primeiro MX for a porteira, e os dois seguintes duas caixas de correio adicionais, usando-se o greylist como veículo para a cooperação, o rato bate na trave três vezes seguidas. A porteira (neste caso o smtp1.google.com) passa a ter 3 hits, quantos mais hits tiver, mais tempo demorará a mensagem a ser aceite. O princípio do greylist é precisamente o de recomeçar o tempo dos 60 minutos a partir de todos os hits inferiores a um periodo de 60 minutos.
Para abrilhantar o mecanismo, as respostas das transações com o servidor de pecados abrandam quanto maior for o número de hits, mantendo como dogma cerca de 160 segundos como máximo tempo de resposta (para haver congruência do protocolo SMTP, conforme recomendações dos RFCs.)

Quando dantes eu tinha uma média de 30 mails de spam no meu servidor dedicado, agora tenho zero, e acreditem ou não, nem sequer uso esquemas de detecção de spam através do conteúdo (como é o caso do Spamassassin).

Claro que tenho que ser intelectualmente honesto e referir que há servidores legítimos erroneamente configurados, mas isso é um tema da discussão das white-lists no âmbito do Greylist, não o anti-spam cooperativo em si.

Para não pensarem que isto é conversa fiada, apresento-lhes uma imagem, essa sim, definitivamente, como aperitivo... para o produto que não posso ainda divulgar completamente.