Download PDF
ads:
Leonardo Bispo de Oliveira
TrustMail: Um modelo
de confian¸ca entre servidores de e-mail
Disserta¸c˜ao de Mestrado apresentada ao Pro-
grama de P´os-Gradua¸c˜ao em Inform´atica
Aplicada da Pontif´ıcia Universidade Cat´olica
do Paran´a como requisito parcial para
obten¸c˜ao do t´ıtulo de Mestre em Inform´atica
Aplicada.
Curitiba
2005
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
Leonardo Bispo de Oliveira
TrustMail: Um modelo
de confian¸ca entre servidores de e-mail
Disserta¸c˜ao de Mestrado apresentado ao Pro-
grama de P´os-Gradua¸c˜ao em Inform´atica
Aplicada da Pontif´ıcia Universidade Cat´olica
do Paran´a como requisito parcial para
obten¸c˜ao do t´ıtulo de Mestre em Inform´atica
Aplicada.
´
Area de Concentra¸c˜ao: Metodologia e
T´ecnicas de Computa¸c˜ao
Orientador: Prof. Dr. Carlos Alberto
Maziero
Curitiba
2005
ads:
Oliveira, Leonardo Bispo de Oliveira
TrustMail: Um modelo
de confian¸ca entre servidores de e-mail. Curitiba, 2005.
Disserta¸c˜ao de Mestrado - Pontif´ıcia Universidade Cat´olica do Paran´a Pro-
grama de P´os-Gradua¸c˜ao em Inform´atica Aplicada.
1. Redes de relacionamento 2. Servidores de e-mail 3. Confian¸ca em servi-
dores de e-mail I.Pontif´ıcia Universidade Cat´olica do Paran´a. Centro de
Ciˆencias Exatas e Tecnologia. Programa de P´os-Gradua¸c˜ao em Inform´atica
Aplicada II - t
Dedico este trabalho `a minha fam´ılia e ami-
gos.
Agradecimentos
Agrade¸co aos meus pais, por me apoiarem durante todo o tempo. Aos meus irm˜aos
que me ajudaram em todos os aspectos.
A Daniele, que sempre teve paciˆencia e compreens˜ao nos momentos em que fiquei
ausente e pela sua ajuda, que foi fundamental na avalia¸c˜ao dos testes.
Agrade¸co ao Carlos Maziero, pelas oportunidades que me proporcionou durante
todo o desenvolvimento do trabalho.
Agrade¸co tamb´em aos integrantes da Banca Examinadora por suas contribui¸c˜oes
que foram muito importantes para a finaliza¸c˜ao deste trabalho.
Sum´ario
Agradecimentos ii
Sum´ario iii
Lista de Figuras vi
Lista de Tabelas viii
Lista de Abrevia¸c˜oes ix
Resumo xi
Abstract xii
Cap´ıtulo 1
Introdu¸c˜ao 1
1.1 Motiva¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Organiza¸c˜ao do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Cap´ıtulo 2
Infra-estrutura de e-mail na internet 4
2.1 Infra-estrutura de transporte de e-mail . . . . . . . . . . . . . . . . . . . . 4
2.2 O protocolo SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Comandos e respostas SMTP . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Modelo de SMTP Estendido . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Estrutura de um e-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 MIME - Multi-purpose internet mail extensions . . . . . . . . . . . . . . . 13
2.5 Conclus˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Cap´ıtulo 3
iii
Amea¸cas ao servi¸co de e-mail 17
3.1 Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Scam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 T´ecnicas de conten¸c˜ao de Spam . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Trojans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 V´ırus e worms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6 Conclus˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Cap´ıtulo 4
Autentica¸c˜ao de remetentes 23
4.1 Autentica¸c˜ao baseada em certificados . . . . . . . . . . . . . . . . . . . . . 24
4.1.1 Padr˜ao X.509 e S/MIME . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2 PGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Sender Policy Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1 Fundamentos do SPF . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.2 Registros SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Limita¸c˜oes da arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Sender ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.1 Registros Sender ID e o PRA (Purpoted Responsible Address) . . . 33
4.4.2 ESMTP SUBMITTER . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.3 Limita¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5 DomainKeys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5.1 Fundamentos do DomainKeys . . . . . . . . . . . . . . . . . . . . . 36
4.5.2 Registros DomainKeys . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6 Vantagens e Limita¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.7 Conclus˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Cap´ıtulo 5
Redes de Confian¸ca 41
5.1 Confian¸ca hier´arquica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Grupos sociais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.1 Composi¸c˜ao dos grupos sociais . . . . . . . . . . . . . . . . . . . . . 46
5.2.2 Rela¸c˜ao entre grupos . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 Redes de relacionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3.1 Escalas de medidas . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4 Algoritmos de confian¸ca/desconfian¸ca e reputa¸c˜ao . . . . . . . . . . . . . . 53
iv
5.4.1 Propaga¸c˜ao de confian¸ca e desconfian¸ca . . . . . . . . . . . . . . . . 54
5.4.2 EigenTrust: algoritmo de gerenciamento de reputa¸c˜ao em redes
peer-to-peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.5 Conclus˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Cap´ıtulo 6
Um sistema de confian¸ca entre servidores de e-mail 62
6.1 Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2 Arquitetura do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.3 Gerˆencia de confian¸ca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.3.1 Confian¸ca local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.3.2 Confian¸ca global . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.3.3 C´alculo da confian¸ca final . . . . . . . . . . . . . . . . . . . . . . . 71
6.4 Armazenamento de confian¸ca . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.5 Propaga¸c˜ao de confian¸ca . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.5.1 Notifica¸c˜oes de ajuste de confian¸ca . . . . . . . . . . . . . . . . . . 75
6.5.2 Propaga¸c˜ao da confian¸ca global . . . . . . . . . . . . . . . . . . . . 76
6.6 Benef´ıcios e limita¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.7 Trabalhos correlatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.7.1 MailRank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.7.2 Leveraging Social Networks to Fight Spam . . . . . . . . . . . . . . 81
6.8 Conclus˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Cap´ıtulo 7
Implementa¸c˜ao e resultados 83
7.1 TrustMail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.1.1 Fluxo do programa . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.2 Avalia¸c˜ao do prot´otipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.2.1 Massa de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.2.2 An´alise do funcionamento . . . . . . . . . . . . . . . . . . . . . . . 88
7.2.3 An´alise do desempenho . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.3 Considera¸c˜oes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.4 Conclus˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Conclus˜ao 97
Referˆencias Bibliogr´aficas 99
Lista de Figuras
Figura 2.1 Infra-estrutura de Transporte . . . . . . . . . . . . . . . . . . . . . 6
Figura 2.2 Modelo SMTP[Pos82] . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Figura 4.1 Exemplo de uma Infra-estrutura de Chave P´ublica X.509 [CDN05] . 25
Figura 4.2 Modelo SPF[Won04] . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 4.3 Funcionamento do Sender ID [WML04] . . . . . . . . . . . . . . . . 32
Figura 4.4 Funcionamento do DomainKeys [DY04] . . . . . . . . . . . . . . . . 37
Figura 5.1 Confian¸ca entre indiv´ıduos distintos . . . . . . . . . . . . . . . . . . 42
Figura 5.2
´
Arvore de confian¸ca . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 5.3 Vetor de confian¸ca . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 5.4 Confian¸ca entre n´os de uma ´arvore . . . . . . . . . . . . . . . . . . 44
Figura 5.5
´
Atomo Social [Wei82] . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figura 5.6 Um exemplo de ´arvore hier´arquica . . . . . . . . . . . . . . . . . . 49
Figura 5.7 Relacionamento entre grupos sociais . . . . . . . . . . . . . . . . . 50
Figura 5.8 Exemplo de co-cita¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 6.1 Modelo de recebimento de mensagens . . . . . . . . . . . . . . . . . 64
Figura 6.2 Modelo de propaga¸c˜ao de confian¸ca . . . . . . . . . . . . . . . . . . 64
Figura 6.3 Arquitetura proposta . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figura 6.4 Modelo de armazenamento . . . . . . . . . . . . . . . . . . . . . . . 73
Figura 6.5 Modelo de comunica¸c˜ao s´ıncrono . . . . . . . . . . . . . . . . . . . 75
Figura 6.6 Modelo de propaga¸c˜ao ass´ıncrono . . . . . . . . . . . . . . . . . . . 76
Figura 7.1 Prot´otipo implementado . . . . . . . . . . . . . . . . . . . . . . . . 84
Figura 7.2 Grupo de confian¸ca . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Figura 7.3 Acompanhamento do Grau de Confian¸ca do Servidor 1 . . . . . . . 89
Figura 7.4 Acompanhamento do Grau de Confian¸ca do Servidor 3 . . . . . . . 90
vi
Figura 7.5 Acompanhamento do Grau de Confian¸ca do Servidor 4 . . . . . . . 91
Figura 7.6 Acompanhamento do Grau de Confian¸ca do Servidor 5 . . . . . . . 91
Figura 7.7 Acompanhamento do Grau de Confian¸ca do Servidor 6 . . . . . . . 92
Figura 7.8 Acompanhamento de Grau de Confian¸ca de Servidores . . . . . . . 93
Lista de Tabelas
Tabela 2.1 Comandos SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Tabela 4.1 Quadro comparativo modelos de autentica¸c˜ao de remetentes . . . . 40
Tabela 5.1 Mem´oria de Confian¸ca de A . . . . . . . . . . . . . . . . . . . . . . 42
Tabela 5.2 Rela¸c˜oes de confian¸ca . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Tabela 5.3 Matriz de atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Tabela 7.1 Tempo de reposta do TrustMail para o servidor de e-mail . . . . . 94
Tabela 7.2 Tempo m´edio de comunica¸c˜ao entre os servidores do grupo de con-
fian¸ca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
viii
Lista de Abrevia¸c˜oes
CGS Confian¸ca do Grupo no Servidor
CLS Confian¸ca Local do Servidor
CMLS Contador de mensagens leg´ıtimas no servidor
CMMS Contador de mensagens maliciosas no servidor
CMS Contador de Mensagens
CS Confian¸ca do Servidor
CS Confian¸ca do Servidor
CS Confian¸ca Final
DHT Distributed Hash Table
EIG Eigenvalue Propagation
IANA Internet Assigned Numbers Authority
IMAP4 Internet Message Access Protocol Vers˜ao 4
IPC Interprocess Communication
MAA Mail Access Agent
MC Mensagens de Confian¸ca
MDA Mail Delivery Agent
MIME Multi-Purpose Internet Mail Extensions
MTA Mail Transfer Agent
ix
MUA Mail User Agent
P2P Peer-To-Peer
PGP Pretty Good Privacy
PKI Public Key Infrastructure
POP3 Post Office Protocol Vers˜ao 3
PRA Purpoted Responsible Address
QM Quandidade de Mensagens
QMS Quantidade de Mensagens Servidor
S/MIME Secure/Multipurpose Internet Mail Extentions
SIDF SenderID Framework
SMTP Simple Mail Transfer Protocol
SPF Sender Policy Framework
TTL Time To Live
UML User-Mode Linux
WLC Weighted Linear Combination
Resumo
O e-mail ´e uma ferramenta essencial na Internet. No entanto, a arquitetura dos sistemas
de e-mail convencional apresenta problemas que deixam o sistema vulner´avel a diversos
tipos de amea¸cas. Alternativas vˆem sendo propostas para sanar essas deficiˆencias e prover
maior escalabilidade e confiabilidade aos sistemas de e-mail. Esta disserta¸c˜ao apresenta
um modelo de confian¸ca que cria listas de servidores confi´aveis e n˜ao confi´aveis de forma
dinˆamica e descentralizada, atrav´es da auto-exclus˜ao de servidores utilizados como propa-
gadores de mensagens maliciosas. Para tal, diversas t´ecnicas foram empregadas, como um
modelo de redes de relacionamento, filtros de mensagens e um modelo de gerenciamento,
armazenamento e propaga¸c˜ao de confian¸ca. A implementa¸c˜ao da arquitetura proposta e
os testes demonstram o modelo da implementa¸c˜ao.
Palavras-chave: Servidores de e-mail, Redes de relacionamento, Confian¸ca em servi-
dores de e-mail.
Abstract
E-mail services are an essential tool in the internet, however, the standard e-mail system
architecture present problems that lat this kind of system vulnerable to several types of
threats. Alternatives have been proposed to solve some problems related with e-mail ser-
vices, offering reliability and escalability to those systems. This work presents a reliable
model to create a dynamic and descentralized trustworty server lists, through the self-
exclusion of servers used as spreaders of slyness messages. Many techniques had been done
as a social network model, message filters and management, storage and reliable propaga-
tion model. The proposed of the architecture implementation and the tests demosntrate
the implementation model.
Keywords: E-mail servers, Social networks, E-mail servers reliable.
xii
Cap´ıtulo 1
Introdu¸c˜ao
Este trabalho apresenta um modelo de confian¸ca entre servidores de e-mail que
faz a gerˆencia de confian¸ca, armazenamento das informa¸c˜oes sobre servidores confi´aveis
e n˜ao confi´aveis e propagaga¸c˜ao das informa¸c˜oes de confian¸ca geradas. A propaga¸c˜ao da
confian¸ca ´e transmitida pela rede para um determinado grupo de relacionamento atrav´es
de m´etodos de redes de relacionamento.
1.1 Motiva¸c˜ao
Os sistemas de e-mail est˜ao sendo comumente utilizados pelas empresas e usu´arios
de computadores como ferramenta padr˜ao de comunica¸c˜ao, por ser simples de utilizar
e pelo seu baixo custo, tanto de uso quanto de implanta¸c˜ao. O aumento no uso desses
sistemas acarretou no surgimento de problemas causados por fragilidades n˜ao previstas na
elabora¸c˜ao do protocolo original. As principais fragilidades no protocolo de transporte de
e-mail residem na falta de mecanismos robustos de autentica¸c˜ao, mecanismos capazes de
prover privacidade, confiabilidade e integridade das mensagens e mecanismos de reputa¸c˜ao
de usu´arios e servidores de e-mail. Estudos est˜ao sendo propostos para criar ferramentas
que implementam tais mecanismos. Os principais modelos s˜ao:
• Filtros de classifica¸c˜ao de conte´udo de mensagens que procuram por padr˜oes
em mensagens que s˜ao recebidas pelo servidor de e-mail para classific´a-las como
leg´ıtimas ou maliciosas;
• Uso de chaves assim´etricas nos clientes de e-mail utilizadas para assinar e cifrar as
mensagens a serem trafegadas pela rede;
• Autentica¸c˜ao de servidores de e-mail que utilizam os servidores DNS para disponi-
bilizar informa¸c˜oes sobre servidores habilitados a enviar mensagens para um deter-
2
minado dom´ınio;
• Ferramentas de classifica¸c˜ao de mensagens maliciosas a partir de redes de rela-
cionamento que classificam cada e-mail/usu´ario como maliciosos, leg´ıtimos ou n˜ao
classific´aveis.
Por mais que essas ferramentas sejam um grande avan¸co nos sistemas de e-mail, as
mesmas continuam com problemas, pois os m´etodos de classifica¸c˜ao s˜ao lentos e pass´ıveis
de erro; as chaves assim´etricas nos clientes necessitam de m´etodos de troca de chaves de
forma confi´avel e segura ou autoridades capazes de publicar as chaves confi´aveis, tornando
este sistema pouco escal´avel; os m´etodos de autentica¸c˜ao de servidores de e-mail n˜ao
impedem que usu´arios maliciosos continuem enviando informa¸c˜oes maliciosas p ela rede.
1.2 Proposta
A falta de mecanismos de autentica¸c˜ao em servi¸cos de e-mail e a simplicidade
do protocolo de comunica¸c˜ao de envio de e-mail faz com que diversos problemas rela-
Atrav´es de filtros de mensagem ´e poss´ıvel se classificar uma mensagem como
leg´ıtima ou maliciosa. Com as mensagens j´a classificadas, o sistema de confian¸ca uti-
lizar´a c´alculos de gerˆencia de confian¸ca em conjunto com a confian¸ca de um conjunto de
servidores para definir o qu˜ao confi´avel um servidor pode ser considerado. A confian¸ca ger-
ada atrav´es dos c´alculos de gerˆencia de confian¸ca implicar´a diretamente na quantidade de
mensagens que um servidor receptor aceitar´a receber de um emissor em um determinado
per´ıodo de tempo.
1.3 Organiza¸c˜ao do trabalho
Este trabalho ´e composto por 8 cap´ıtulos incluindo este e est´a organizado da
seguinte forma: o cap´ıtulo 2 apresenta um estudo sobre a arquitetura SMTP, mostrando
os principais conceitos do protocolo; o cap´ıtulo 3 apresenta os principais problemas en-
contrados no servi¸cos de e-mail devido `as fragilidades do protocolo SMTP; o cap´ıtulo 4
apresenta as t´ecnicas de autentica¸c˜ao de usu´arios e servidores de e-mail que utilizam chaves
e informa¸c˜oes armazenadas no servidor DNS para prover um modelo de autentica¸c˜ao nos
sistemas de e-mail; o cap´ıtulo 5 conceitua as redes de confian¸ca que ser˜ao utilizadas na
proposta; o cap´ıtulo 6 cont´em a proposta da disserta¸c˜ao; o cap´ıtulo 7 o prot´otipo im-
plementado, os ensaios realizados e a an´alise cr´ıtica dos resultados obtidos; por fim, ´e
apresentada uma conclus˜ao sobre a disserta¸c˜ao, apontando os benef´ıcios alcan¸cados e os
trabalhos futuros relacionados `a proposta e sua implementa¸c˜ao.
Cap´ıtulo 2
Infra-estrutura de e-mail na internet
O sistema de e-mail ´e um dos meios de comunica¸c˜ao mais utilizados nos dias
atuais. Isso se d´a pelo seu baixo custo, facilidade de comunica¸c˜ao e por ser simples de
implementar.
Este ambiente ´e baseado na arquitetura cliente-servidor, onde o cliente de e-mail
proporciona uma interface amig´avel para enviar, receber e organizar as mensagens de um
usu´ario; o servidor recebe as mensagens enviadas por clientes de e-mail e encaminha ao
seu destino final, que pode ser um usu´ario local ou externo. Esta troca de mensagens ´e
feita utilizando os protocolos baseado em comando SMTP/ESMTP [Pos82, Kle01a] para
o envio das mensagens e IMAP [Cri96] e POP [MR96] para a entrega das mensagens ao
usu´ario final.
A troca de mensagens pela rede ´e feita por agentes de transporte de e-mail, que
tratam a mensagem como um arquivo ASCII composto por um cabe¸calho e um corpo.
Al´em disso, arquivos podem ser codificados e incorporados `as mensagens em formato
ASCII sob forma de anexo. Todo o esfor¸co de codifica¸c˜ao e decodifica¸c˜ao desses arquivos
anexos ´e feito pelos clientes de e-mail durante o envio e a recep¸c˜ao da mensagem.
Este cap´ıtulo apresenta a infra-estrutura de e-mail na internet e est´a estruturado
da seguinte forma: a se¸c˜ao 2.1 traz uma vis˜ao geral sobre os agentes de transportes de e-
mail; a se¸c˜ao 2.2 apresenta o protocolo de comunica¸c˜ao SMTP e seus principais comandos;
a se¸c˜ao 2.3 mostra a forma com que uma mensagem ´e estruturada; a se¸c˜ao 2.4 analisa o
suporte de e-mails a arquivos anexados; por ´ultimo, a se¸c˜ao 2.5 conclui o cap´ıtulo.
2.1 Infra-estrutura de transporte de e-mail
A infra-estrutura de transporte de e-mail ´e constitu´ıda por quatro agentes que
funcionam como emissores e/ou receptores de mensagens. Atrav´es deles um e-mail pode
5
ser enviado, recebido ou ent˜ao repassado atrav´es de uma rede de computadores. Esses
agentes podem ser classificados como:
• MTA (Mail Transfer Agent) ou “servidor de e-mail”: o MTA ´e o programa re-
spons´avel por receber e enviar mensagens de usu´arios atrav´es de redes de computa-
dores. Sua fun¸c˜ao ´e criar rotas de mensagens, enviar mensagens de MUAs e repassar
mensagens entre MTAs. O sendmail e o Microsoft Exchange s˜ao exemplos de MTAs.
• MUA (Mail User Agent) ou “cliente de e-mail”: o MUA ´e o programa que permite
um usu´ario acessar e gerenciar mensagens, incluindo ler, compor, imprimir, reenviar
e mostrar mensagens. O MUA disponibiliza uma interface entre o usu´ario e o MTA.
O Eudora e o Outlook s˜ao exemplos de MUAs.
• MDA (Mail Delivery Agent): o MDA ´e o agente de entrega de e-mail. MDAs s˜ao
softwares respons´aveis por receber uma mensagem de um MTA e fazer com que esta
mensagem seja armazenada ou reencaminhada. O procmail ´e muito utilizado como
um MDA em sistemas UNIX.
• MAA (Mail Access Agent): o MAA ´e o programa que permite que os MUAs tenham
acesso aos e-mails que est˜ao na caixa de correio do usu´ario. Na pr´atica, esta fun¸c˜ao ´e
exercida pelos servidores POP3 (Post Office Protocol Vers˜ao 3 ) e IMAP4 (Internet
Message Access Protocol Vers˜ao 4 ).
Mais especificamente, os agentes de transporte s˜ao os respons´aveis por todo o envio
de e-mail na internet. A intera¸c˜ao entre eles possibilita que uma mensagem seja enviada
por um emissor e recuperada por um receptor de maneira simples e eficiente em qualquer
ponto da rede. Essa intera¸c˜ao pode ser vista na Figura 2.1.
Nesta Figura o computador A utiliza um MUA para enviar uma mensagem ao
MTA do computador B (servidor de e-mail do cliente MUA no computador A) que
recebe a mensagem integralmente e deposita em um diret´orio tempor´ario (este procedi-
mento ´e conhecido como “store and forward” e garante que a mensagem seja entregue ao
destinat´ario sem risco de perdas na transmiss˜ao). Depois da mensagem ser depositada no
6
Figura 2.1: Infra-estrutura de Transporte
diret´orio tempor´ario, o MTA do computador B comunica-se com um outro MTA. Esse
processo continua at´e que a mensagem chegue ao MTA do destino final (no caso o com-
putador C). O endere¸co do computador C dever´a ser obtido atrav´es de uma consulta
ao servidor de DNS que requisita o endere¸co Mail eXchanger do dom´ınio em quest˜ao.
Quando a mensagem for integralmente recebida pelo computador C, o MTA faz uma
chamada ao MDA que deposita localmente a mensagem recebida na caixa de correio de
destino. Por fim, o usu´ario final (computador D) inicia uma comunica¸c˜ao com o MAA
e recebe as mensagens armazenadas no servidor. A comunica¸c˜ao de um MUA com um
MTA e de um MTA com outro MTA ´e feita utilizando o protocolo SMTP. A comunica¸c˜ao
do MUA com o MAA ´e feita utilizando o protocolo POP ou IMAP.
2.2 O protocolo SMTP
O SMTP (Simple Mail Transfer Protocol) ´e o protocolo de transferˆencia de e-mail
definido pela RFC 821 [Pos82] e revisado pela RFC 2821 [Kle01a] que atua sobre o pro-
tocolo TCP/IP para transportar mensagens. Este protocolo foi inicialmente projetado
pela Universidade do Sul da Calif´ornia em 1982 com o objetivo de ser independente de
um sistema de transmiss˜ao particular. Para a transmiss˜ao de uma mensagem ´e necess´ario
apenas um canal de comunica¸c˜ao entre um determinado emissor (emissor SMTP) e re-
ceptor (receptor SMTP). O modelo gen´erico de uma aplica¸c˜ao que utiliza o protocolo
SMTP pode ser visto na Figura 2.2.
7
Figura 2.2: Modelo SMTP[Pos82]
Neste modelo o usu´ario inicia uma transa¸c˜ao de envio de mensagem a partir do
emissor com o receptor. O envio de uma mensagem consiste na troca de comandos e
respostas entre aplica¸c˜oes SMTP. Essa troca de comandos e respostas ´e feita seq¨uencial-
mente. Quando um usu´ario faz uma requisi¸c˜ao ao emissor, um canal de comunica¸c˜ao
bidirecional ´e estabelecido com o receptor (pode ser o ´ultimo destino ou um destino
intermedi´ario). Atrav´es deste canal, comandos SMTP s˜ao gerados pelo emissor e envi-
ados para o receptor. De acordo com os comandos enviados o receptor dever´a enviar
respostas ao emissor.
Quando um canal de comunica¸c˜ao ´e estabelecido, o emissor envia o comando
MAIL indicando o autor da mensagem. Se o comando for aceito pelo receptor, ser´a
gerada uma resposta de OK para o emissor, do contr´ario, ser´a gerada uma resposta re-
jeitando o conte´udo (esta resposta n˜ao implica no encerramento do canal de transmiss˜ao).
Caso o comando MAIL tenha sido aceito, o emissor envia o comando RCPT mais o des-
tinat´ario da mensagem (este comando poder´a ser utilizado v´arias vezes). Se o comando
RCPT for aceito, ser´a gerada uma resposta OK, sen˜ao uma resposta de erro ser´a enviada
ao emissor.
Depois de terem sido enviados todos os destinat´arios da mensagem, o emissor
dever´a enviar um comando DATA que indica o inicio da transmiss˜ao do conte´udo do e-
mail. O receptor tratar´a todas as informa¸c˜oes enviadas ap´os o comando DATA como
sendo conte´udo da mensagem at´e que seja enviada uma linha que contenha apenas um
ponto final (o ponto indica o final do conte´udo). Este ponto final n˜ao dever´a implicar
no encerramento do canal de transmiss˜ao estabelecido. Utilizando o canal, emissor e
receptor poder˜ao negociar o envio de diversas mensagens. Quando n˜ao existirem mais
mensagens na fila de e-mail do emissor, o comando QUIT ´e enviado ao receptor e a
conex˜ao ´e fechada.
´
E bom lembrar que toda mensagem a ser enviada deve estar armazenada no sistema
8
de arquivos do emissor e toda mensagem recebida dever´a ser armazenada em um sistema
de arquivos do receptor.
2.2.1 Comandos e respostas SMTP
Os comandos SMTP s˜ao constitu´ıdos por uma linha de texto iniciada por uma
“palavra especial” de quatro letras, que poder´a ser seguida de argumentos. Na maioria
dos casos as respostas a comandos s˜ao constitu´ıdas de uma ´unica linha, contudo, m´ultiplas
linhas de resposta tamb´em s˜ao poss´ıveis.
A Tabela 2.1 apresenta os comandos utilizados pelo SMTP. Todos os comandos
at´e o QUIT devem ser implementados no protocolo. Os demais s˜ao opcionais e podem
ser ignorados pelo receptor.
Tabela 2.1: Comandos SMTP
Nome Comando Descri¸c˜ao
HELO HELO <SP> <domain> <CRLF> Identificador do emissor
MAIL MAIL <SP> FROM:<reverse-path> <CRLF> Identifica o criador do e-mail
RCPT RCPT <SP> TO: <forward-path> <CRLF> Identifica o destinat´ario do e-mail
DATA DATA <CRLF> Transferˆencia de mensagem texto
RSET RSET <CRLF> Aborta a transa¸c˜ao de e-mail atual
NOOP NOOP <CRLF> Sem opera¸c˜ao
QUIT QUIT <CRLF> Fecha a conex˜ao TCP
SEND SEND <SP> FROM:<reverse-path> <CRLF> Envia e-mail para terminal
SOML SOML <SP> FROM:<reverse-path> <CRLF> Envia e-mail para terminal, quando
poss´ıvel
SAML SAML <SP> FROM:<reverse-path> <CRLF> Envia e-mail para terminal e mailbox
VRFY VRFY <SP> <string> <CRLF> Confirma nome do usu´ario
EXPN EXPN <SP> <string> <CRLF> Retorna o membro da lista de e-mail
HELP HELP [<SP> <string>] <CRLF> Envia documenta¸c˜ao espec´ıfica do sis-
tema
TURN TURN <CRLF> Reverte regra do destinat´ario e do re-
ceptor
As respostas SMTP s˜ao formadas de trˆes d´ıgitos seguidos por uma informa¸c˜ao
adicional, onde o primeiro digito indica a categoria da resposta; os demais d´ıgitos indicam
o erro em si. Essas respostas s˜ao classificadas como:
• Resposta de conclus˜ao positiva: a¸c˜oes de requisi¸c˜ao foram completadas com
sucesso. Uma nova requisi¸c˜ao deve ser iniciada.
– 211: status do sistema ou resposta de ajuda do sistema
– 214: mensagem de ajuda
9
– 220: <domain> servi¸co pronto
– 221: <domain> fechando servi¸co de canal de transmiss˜ao
– 250: requisi¸c˜ao de a¸c˜ao de e-mail OK , completada
– 251: usu´ario n˜ao faz parte do dom´ınio; a mensagem ser´a reencaminhada para
<forward-path>
• Resposta intermedi´aria positiva: o comando foi aceito, mas est˜ao faltando
informa¸c˜oes para a a¸c˜ao requisitada. O emissor deve enviar um outro comando
especificando esta informa¸c˜ao. Esta resposta ´e utilizada quando ´e necess´aria uma
seq¨uˆencia de comandos.
– 301: inicio do envio do e-mail; finalizar com <CRLF>.<CRLF>
• Resposta de conclus˜ao temporariamente negativa: o comando n˜ao foi aceito
e a a¸c˜ao requisitada n˜ao ocorreu. Contudo, a condi¸c˜ao de erro ´e tempor´aria e pode
ser requisitada novamente.
– 421: <domain> servi¸co indispon´ıvel: perdendo canal de transmiss˜ao
– 450: requisi¸c˜ao negada: caixa de correio indispon´ıvel
– 451: requisi¸c˜ao abortada: erro local no processo
– 452: requisi¸c˜ao negada: espa¸co insuficiente
• Resposta de conclus˜ao permanentemente negativa: o comando n˜ao foi aceito
e a requisi¸c˜ao n˜ao poder´a ser feita novamente.
– 500: erro de sintaxe, comando n˜ao reconhecido
– 501: erro de sintaxe nos parˆametros ou argumentos
– 502: comando n˜ao implementado
– 503: seq¨uˆencia errada de comandos
– 504: parˆametro n˜ao implementado
– 550: requisi¸c˜ao negada: caixa de correio indispon´ıvel
– 551: usu´ario n˜ao faz parte do dom´ınio; tente <forward-path>
– 552: requisi¸c˜ao de e-mail abortada: excedido espa¸co de aloca¸c˜ao
– 553: requisi¸c˜ao negada: caixa de correio indispon´ıvel
– 554: erro na transa¸c˜ao
10
Em posse dessas informa¸c˜oes, comandos e respostas s˜ao geradas e trocadas entre
servidores e clientes de e-mail at´e que a mensagem seja entregue ao seu destino final.
O c´odigo a seguir apresenta um exemplo de comunica¸c˜ao entre servidores utilizando o
protocolo SMTP (as linha iniciadas por um C correspondem ao comandos emitidos pelo
cliente; as linhas iniciadas por um S correspondem `as respostas do servidor SMTP):
1 S : 220 ppgia . pucpr . br Simple Mail Transfer Service Ready
2 C : HELO acme . com . br
3 S : 250 ppgia . pucpr . br greets acme . com . br
4 C : MAIL FROM :< joao@ acme . com .br >
5 S : 250 OK
6 C : RCPT TO :< maria @ppgi a . pucpr . br >
7 S : 250 OK
8 C : RCPT TO :< jose@ ppgia . pucpr .br >
9 S : 550 No such user here
10 C : RCPT TO :< anto nio@ppgia . pucpr . br >
11 S : 250 OK
12 C : DATA
13 S : 354 Start mail input ; end with < CRLF >. < CRLF >
14 C : Bom Dia ,
15 C : [] Joao
16 C : .
17 S : 250 OK
18 C : QUIT
19 S : 221 ppgia . pucpr . br Serv ice closi ng transmis sion channel
Neste exemplo, joao (usu´ario do dom´ınio acme.com.br) envia um e-mail
para maria (usu´ario do dom´ınio ppgia.pucpr.br), antonio (usu´ario do dom´ınio
ppgia.pucpr.br) e jose. O e-mail enviado para antonio e maria s˜ao aceitos por
ppgia.pucpr.br; jose n˜ao ´e um usu´ario v´alido, ent˜ao, uma mensagem de erro ´e ger-
ada por ppgia.pucpr.br para acme.com.br.
2.2.2 Modelo de SMTP Estendido
Em um esfor¸co iniciado em 1990, aproximadamente uma d´ecada ap´os a RFC 821,
o protocolo SMTP foi modificado para suportar o modelo de servi¸co estendido. Este
modelo permite que clientes e servidores compartilhem funcionalidades diferentes das que
foram definidas no protocolo SMTP original, dando uma maior flexibilidade ao sistema de
11
transporte, devido ao fato de ser poss´ıvel inserir novos comandos e respostas ao protocolo
sem que seja necess´ario alterar servidores e clientes j´a implementados.
Os mecanismos estendidos do protocolo ESMTP definem como um cliente e um
servidor devem reconhecer um ao outro. Al´em disso, o servidor pode informar ao cliente
os servi¸cos estendidos que s˜ao suportados [Kle01a]. O framework de servi¸cos estendidos
consiste em:
• O comando SMTP EHLO substituindo o HELO;
• Um registro de servi¸cos estendidos SMTP;
• Parˆametros adicionais para os comandos MAIL e RCPT ;
• Substitui¸c˜ao opcional para os comandos definidos na RFC 821, tal como o comando
DATA ser capaz de transportar informa¸c˜oes que n˜ao estejam em formato texto (n˜ao
ASCII).
Segundo [Kle01a], as implementa¸c˜oes SMTP precisam ter suporte b´asico aos
mecanismos estendidos. Servidores precisam suportar o comando EHLO mesmo que
n˜ao implementem qualquer tipo de servi¸co estendido. Os clientes devem preferencial-
mente utilizar o EHLO ao inv´es do HELO, contudo, para haver uma compatibilidade
com implementa¸c˜oes antigas, clientes e servidores SMTP precisam suportar o mecanismo
de HELO. Al´em disso, dever´a existir um registro de cada servi¸co estendido associado
a um comando na IANA (Internet Assigned Numbers Authority). O IANA ´e o ´org˜ao
respons´avel em manter todos os registros de servi¸co de estendido SMTP. Este registro
dever´a possuir:
• Nome do servi¸co SMTP estendido;
• Chave associada com a extens˜ao;
• Sintaxe e poss´ıveis valores dos parˆametros associados `a chave;
• Qualquer comando SMTP adicional associado com a extens˜ao;
• Qualquer novo parˆametro de extens˜oes associadas aos comandos MAIL e RCPT ;
• Um descritor de como suportar diferen¸cas no comportamento de clientes e servidores
SMTP causados pela extens˜ao.
Se um campo estendido n˜ao estiver registrado no IANA, a chave do comando
dever´a ser iniciada por um “X”. O “X” indica que um campo ´e de uso estritamente local.
12
2.3 Estrutura de um e-mail
O padr˜ao SMTP utiliza a RFC 822 [Cro82] como formato de constru¸c˜ao da men-
sagem que ser´a transmitida por ele. A RFC 822 trata o e-mail como um arquivo em
formato ASCII composto por cabe¸calho (header) e corpo (body) separados por uma linha
em branco (vazia). Todas as informa¸c˜oes de um e-mail encontram-se no cabe¸calho e s˜ao
denominadas “header tags”. Os “header tags” s˜ao representados por linhas na forma
Nome: valor. Os “header tags” mais comuns s˜ao From, To, Subject e Date, al´em do
Message-ID que cont´em um identificador ´unico associado `a mensagem. Essa estrutura
pode ser vista no exemplo a seguir:
1 From j oao@ac me . com . br Wed Feb 18 0 7:35:47 2 004
2 Return-Path: < joao@ac me . com . br >
3 Received : from joa o@ acme . com . br ( acme . com . br [2 00.200. 200. 200 ])
4 by ppgia . pucpr . br (8 .12. 5/8.12.5) with ESMTP id i1 IAZjXR005 568
5 for < maria@ppgia . pucpr . br >; Wed , 18 Feb 2 004 0 7:35:45 -0300
6 Message-ID: < 107710 4322.40 334 ec2d39a3 >
7 Date: Wed , 18 Feb 20 04 08 :38:42 -0 300
8 From: j oao@ac me . com . br
9 To: maria@ ppgia . pucpr . br
10 Subject : Email Plano
11 MIME- Version : 1.0
12 Content -Type: text / plain ; charset =iso -8859 -1
13 Content - Transfer -Encoding : 8 bit
14 User - Agent : In te rn et Messa ging Progr am ( IMP ) 3.2.2
15 X - Originating - IP : 2 00.1 92.1 13.5 6
16 X -ACME -LOCAL : lo cal_sca n v1 .0
17 X -ACME -SPAM : 2.4
18 X - AntiV ir us : sc anned for vir uses by AMaViS 0. 2. 1 ( http :// amavis . org /)
19
20 Este e um exe mplo de Email
21
22 [] Joao
Este exemplo apresenta uma mensagem enviada p or [email protected] para
[email protected]. Conforme visto na se¸c˜ao 2.2.2 todos os “header tags” inicia-
dos por um “X” s˜ao locais ao servidor que recebeu a mensagem. A vantagem dos e-mails
estarem no formato texto ´e a facilidade de enviar, receber e armazenar as mensagens.
13
2.4 MIME - Multi-purpose internet mail extensions
Na concep¸c˜ao da arquitetura do protocolo SMTP n˜ao foram previstos outros tipos
de codifica¸c˜oes de mensagens e uso de arquivos anexados (imagens, sons, programas, etc.)
`a mensagem. Com o aumento do uso do correio eletrˆonico, pesquisadores da ´area sen-
tiram a necessidade de incorporar tais caracter´ısticas ao sistema. V´arios estudos foram
realizados, at´e que em 1993, foi proposto o padr˜ao MIME (Multi-Purpose Internet Mail
Extensions) definido em [FB96a, FB96b, Moo96, FKP96, FB96c]. O padr˜ao MIME cod-
ifica os arquivos de anexo para o formato t6e8net seguida este t6e8n ´e inserido na
mensagem. Com essa abordagem n˜ao foram necess´arias altera¸c˜oes no protocolo SMTP
original. A especifica¸c˜ao MIME inclui os seguintes elementos:
1. Cinco novos “header tags” foram definidos,odendo ser inclu´ıdos no cabe¸calho de
mensagens conforme padr˜ao RFC 822. Estes campos possuem informa¸c˜oes sobre o
corpo da mensagem. S˜ao eles:
• MIME-Version: Declara a vers˜ao MIME e informa que a mensagem est´a
neste formato, permitindo que os processadores de e-mail distinguam uma men-
sagem deste tipo de outras mais antigas;
• Content-Type: Utilizado para especificar o tipo de m´ıdia e sub-tipo de dados
utilizado no corpo da mensagem;
• Content-Transfer-Encoding: Especifica as transforma¸c˜oes de codifica¸c˜ao
que foram aplicadas ao corpo da mensagem (normalmente para port´a-la para
7 bits ASCII);
• Content-ID: Usado para identificar o conte´udo do corpo da mensagem;
• Content-Description: Usado para descrever o conte´udo do corpo da men-
sagem. Deve ser atribu´ıdo quando o objeto n˜ao pode ser lido (ex: ´audio).
2. S˜ao definidas transferˆencias codificadas que habilitam a convers˜ao de qualquer for-
mato do conte´udo em uma forma que ´e protegida de altera¸c˜oes pelo sistema de
e-mail. Podem ser:
• 7bit: Cont´em t6e8n codificado em 7 bits (conjunto de caracteres US-ASCII);
• 8bit: Cont´em t6e8n com alguns caracteres que necessitam de 8 bits para serem
codificados (conjunto de caracteres n˜ao US-ASCII). Caso uma mensagem deste
tipo passe por uma “zona” da rede que permite transportar somente caracteres
14
de 7 bits, todos os caracteres que necessitam de 8 bits chegar˜ao ao destino com
erro;
• binary: Cont´em caracteres n˜ao US-ASCII e linhas mais longas do que o per-
mitido na RFC 821. Caso uma mensagem deste tipo passe por uma “zona” da
rede que permite transportar somente caracteres de 7 bits, todos os caracteres
que necessitam de 8 bits chegar˜ao ao destino com erro;
• quoted-printable: Transforma caracteres n˜ao US-ASCII em com-
bina¸c˜oes de caracteres US-ASCII. Programas que suportam codifica¸c˜ao
“quoted-printable” traduzem a combina¸c˜ao de caracteres para o caractere
original. Exemplo: “S~ao Paulo” se torna “S=E3o Paulo” quando transmitido
no modo “quoted-printable”;
• base64: Cont´em bin´arios codificados. Todos os caracteres s˜ao codificados
como grupos de caracteres de 7 bits, de tal modo que o bin´ario n˜ao ser´a alterado
ao trafegar pela rede.
• x-token: O x-token possibilita a inclus˜ao de um mecanismo de codifica¸c˜ao
diferente dos apresentados anteriormente. Para utilizar o x-token, o cliente
deve suportar o tipo de codifica¸c˜ao especificada. O x-token pode ser definido
por qualquer string de caracteres e deve ser precedido por um “x-” ou “X-”.
Atrav´es do MIME, um usu´ario pode incluir arquivos em um e-mail de diferentes
formatos e/ou diferentes codifica¸c˜oes em um e-mail. Grande parte do sucesso do padr˜ao
MIME deve-se ao fato do mesmo ser opaco aos servidores de e-mail (o corpo de cada e-mail
´e visto em formato ASCII, conforme a defini¸c˜ao original da RFC 822). Todo o esfor¸co de
codifica¸c˜ao e decodifica¸c˜ao dos e-mails ´e realizado pelos softwares clientes, durante o envio
e a recep¸c˜ao do e-mail. O exemplo a seguir mostra uma mensagem com dois arquivos
anexados ao seu corpo (anexo.txt e anexo.tar.gz):
1 From j oao@ac me . com . br Wed Feb 18 0 7:48:03 2 004
2 Return-Path: < joao@ac me . com . br >
3 Received : from acme . com . br ( acme . com . br [ 200.200 .200 .20 0])
4 by ppgia . pucpr . br (8 .12. 5/8.12.5) with ESMTP id i1 IAlwXR005 737
5 for < maria@ppgia . pucpr . br >; Wed , 18 Feb 2 004 0 7:47:58 -0300
6 From: Joao < joao@ acme . com .br >
7 To: maria@ ppgia . pucpr . br
8 Subject : Email com Anexo
9 Date: Wed , 18 Feb 20 04 08 :53:04 -0 300
10 User - Agent : KMail /1.6
15
11 MIME- Version : 1.0
12 Content - Di sp os it io n : inline
13 Content -Type: M ultipa rt / Mixed ;
14 bound ary = " Boundary -00= _gI 1MAo B3Q7 5V6 + b"
15 Message- Id : <2004 02180 853.0 4435. bisp o@ppg ia . pucpr .br >
16 X - PPGIA - LOCAL : loc al_sc an v1 .0
17 X - PPGIA - SPAM : 5.6
18 X - AntiV ir us : sc anned for vir uses by AMaViS 0. 2. 1 ( http :// amavis . org /)
19
20
21 -- Boundary -00= _gI 1MAo B3Q7 5V6 +b
22 Content -Type: text / plain ;
23 charset =" us - ascii "
24 Content - Transfer -Encoding : 7 bit
25 Content - Di sp os it io n : inline
26
27 Este e um exe mplo de Email com Anexo
28
29 [] Joao
30
31 -- Boundary -00= _gI 1MAo B3Q7 5V6 +b
32 Content -Type: text / plain ;
33 charset =" us - ascii " ;
34 name = " anexo . txt "
35 Content - Transfer -Encoding : 7 bit
36 Content - Di sp os it io n : a ttach ment ;
37 f il en ame = " anexo . txt "
38
39 Ex emplo de arquivo anexado
40 -- Boundary -00= _gI 1MAo B3Q7 5V6 +b
41 Content -Type: appli catio n /x - tgz ;
42 name = " anexo . tar . gz "
43 Content - Transfer -Encoding : base64
44 Content - Di sp os it io n : a ttach ment ;
45 f il en ame = " anexo . tar . gz "
46
47 H4 sIABRSM0A AA +3 SQQrCMB CF4 Rxl TiC Tmu YGH iTQ LIT qaEwlxzc guO iir ooI /7
eZx bzFY 5h0z c0O
48 tVW3H / WqMQSnb + upehx cj / gQR42 +57 wPgzrR HTt9L I + aio grZps3 + Lb /
U6eWL7 fZZM qSy n05P 01S
49 f4k02a + bAQAAAAAAAAAAAAAA AAC 2vA CqD u77 ACg AAA ==
50
51 -- Boundary -00= _gI 1MAo B3Q7 5V6 +b --
Analisando este exemplo ´e poss´ıvel verificar a inclus˜ao de novos “header tags” no
cabe¸calho da mensagem e informa¸c˜oes adicionais no corpo da mensagem que informam
o tipo de codifica¸c˜ao, o nome do arquivo anexado e outras informa¸c˜oes pertencentes ao
padr˜ao MIME.
2.5 Conclus˜ao
Neste cap´ıtulo foi apresentada a arquitetura geral dos sistemas de e-mail na Inter-
net e os agentes de e-mail MTA, MUA, MDA e MAA respons´aveis pelo transporte das
mensagens; o protocolo de comunica¸c˜ao SMTP e ESMTP utilizados pelos MUAs e MTAs
para envio/recebimento de mensagens; a estrutura de um e-mail (cabe¸calho, corpo, etc)
e o padr˜ao MIME que especifica uma forma de enviar informa¸c˜oes n˜ao textuais no corpo
de uma mensagem.
Conhecer a infra-estrutura de transporte de e-mail ser´a importante para a com-
preens˜ao dos pr´oximos cap´ıtulos. O pr´oximo cap´ıtulo apresenta as principais amea¸cas ao
servi¸co de e-mail nos dias atuais e algumas t´ecnicas para minimizar essas amea¸cas.
Cap´ıtulo 3
Amea¸cas ao servi¸co de e-mail
O sistema de e-mail foi inicialmente projetado para ser simples, pois seu p´ublico
alvo era restrito `a comunidade acadˆemica. O protocolo SMTP n˜ao provˆe mecanismos
robustos para autentica¸c˜ao e controle de acesso e sua extens˜ao para prover esses servi¸cos
n˜ao ´e trivial. Com a explos˜ao do uso da Internet, o sistema de e-mail ganhou grande im-
portˆancia expondo, com isto, as fragilidades das tecnologias envolvidas e v´arios problemas
n˜ao previstos inicialmente. Dentre esses problemas destacam-se os spams, trojans, v´ırus e
scams que comprometem o desempenho, robustez, seguran¸ca e usabilidade dos sistemas
de e-mail atuais.
´
18
mensagens n˜ao solicitadas a milhares de usu´arios da rede. Essas mensagens s˜ao conhecidas
como spam ou UCE (Unsolicited Commercial E-mail) e consomem recursos importantes
dos sistemas de computa¸c˜ao. Al´em das propagandas indesej´aveis, spammers utilizam os
sistemas de e-mail para propagar mensagens com programas maliciosos que prejudicam
o uso dos correios eletrˆonicos [CL98]. Para um ter¸co dos usu´arios da internet, cerca de
80% das mensagens recebidas s˜ao spams [GHR05]. No ano passado, o Brasil ocupou o
5
o
lugar no ranking de pa´ıses que mais enviam spams no mundo, representando 3,34%
do total [GHR05]. Estima-se que o tr´afego m´edio di´ario de spams seja de 17 bilh˜oes de
mensagens e que a tendˆencia ´e aumentar para 23 bilh˜oes at´e 2007 [IDC04].
Os spams ocasionam diversos inconvenientes para usu´arios e administradores de
rede como, por exemplo, o n˜ao recebimento de e-mails v´alidos (pela satura¸c˜ao das caixas
de correio), o gasto desnecess´ario de tempo para receber mensagens indesejadas (fator
cr´ıtico em conex˜oes discadas), a perda de pro dutividade (aumento no tempo necess´ario
para a leitura de e-mails), impacto na banda de rede (o tr´afego de spams diminui a banda
´util de rede das corpora¸c˜oes), entre outros [Lin99].
Existem dois tipos principais de spams. O Cancellable Usenet spam que s˜ao
mensagens enviadas para 20 ou mais newsgroups da Usenet e tem como objetivo advertir
usu´arios sobre postagem de mensagens irrelevantes e proporcionar aos administradores
e donos de grupos um melhor gerenciamento de t´opicos. Os spams s˜ao mensagens n˜ao
solicitadas enviadas a v´arios usu´arios diretamente a suas caixas de correio. Os desti-
nat´arios de spam s˜ao gerados atrav´es de scaneamento de mensagens da Usenet, roubo de
listas de e-mail, pesquisas na Web a procura de endere¸cos, entre outros. Na maioria das
vezes spammers utilizam ferramentas especializadas para pesquisa de endere¸co e envio de
mensagens. As principais t´ecnicas utilizadas para o envio de spam s˜ao:
• Entrega direta: programas de entrega montam um servidor SMTP no computador
spammer (gerador de spam) que enviam grandes volumes de mensagens diretamente
a outros servidores de e-mail;
• Open relay: um erro freq¨uente de configura¸c˜ao nas listas de controle de acesso
de servidores de e-mail, conhecido como open relay, permite que um servidor mal-
configurado seja usado como propagador involunt´ario de grandes volumes de spam;
• Remetentes forjados: fragilidades no proto colo SMTP permitem forjar campos
dos cabe¸calhos de e-mail, entre os quais o remetente; essa fragilidade ´e amplamente
explorada por spammers e v´ırus, juntamente com as t´ecnicas anteriores.
De acordo com [Str03], o custo total das empresas dos Estados Unidos no ano de
19
2003 com spam foi de US$ 8.9 bilh˜oes. Esse custo foi baseado na perda de produtivi-
dade de usu´arios que gastam uma m´edia de 4,4 segundos para classificar uma mensagem
como spam e tomar uma a¸c˜ao; no aumento do tr´afego da banda de rede, gasto com ar-
mazenamento e processamento de mensagens; e com problemas de responsabilidade legal
de mensagens que trafegam pela rede da corpora¸c˜ao.
3.2 Scam
O scam ´e um subconjunto de spam que faz uso de engenharia social em conjunto
com fragilidades no protocolo SMTP, visando enganar os destinat´arios, convencendo-os a
informar dados banc´arios, n´umeros de cart˜oes de cr´editos e outras informa¸c˜oes confiden-
ciais ou instalar spywares, que ´e o objetivo mais freq¨uente hoje em dia.
Os phishing scams s˜ao os scams mais comuns atualmente. O objetivo deste ataque
´e criar mensagens falsificadas de sites e empresas que sejam capazes de enganar usu´arios,
convencendo-os a informar senhas e informa¸c˜oes confidenciais. Estimativas apontam que
a efic´acia deste tipo de ataque varia de 1% a 20% dependendo da falsifica¸c˜ao (atacantes
podem facilmente copiar imagens, links e textos de sites leg´ıtimos para que seus e-mails
pare¸cam leg´ıtimos [Kop04]). Clientes de muitos bancos e institui¸c˜oes financeiras tˆem
sido alvos deste tipo de ataque, sendo roubadas senhas e n´umeros de cart˜oes de d´ebito e
cr´edito.
Organiza¸c˜oes e companhias preocupadas com os phishing scams est˜ao propondo
altera¸c˜oes na infra-estrutura de e-mail visando diminuir os spams que minimizar´a con-
sideravelmente os ataques de scam. Dentre as propostas destacam-se autentica¸c˜oes em
transa¸c˜oes eletrˆonicas, desenvolvimento de anti-spam e anti-v´ırus mais eficazes, desen-
volvimento de softwares de privacidade, entre outros [Abd04]. Uma solu¸c˜ao para este
problema consiste em utilizar sistemas de assinatura/certificado digital ou ent˜ao tecnolo-
gias que validem a autenticidade do servidor ou do remetente da mensagem. Algumas
dessas t´ecnicas ser˜ao vistas no cap´ıtulo 4.
3.3 T´ecnicas de conten¸c˜ao de Spam
V´arias t´ecnicas vˆem sendo usadas para controle de spam. As principais s˜ao
baseadas em listas de servidores confi´aveis e n˜ao-confi´aveis, ou na filtragem das mensagens
recebidas com base em seu conte´udo. Essas t´ecnicas est˜ao relacionadas com a habilidade
de servidores de e-mail serem capazes de distinguir spams de mensagens leg´ıtimas.
´
E
20
poss´ıvel classificar as t´ecnicas de anti-spam da seguinte forma:
• Listas Negras (Black Lists): servidores RBL (Realtime Blackhole Lists) dis-
tribu´ıdos na Internet mantˆem listas de endere¸cos IP de geradores ou propagadores
de spam. Estas listas podem ser consultadas por meio de DNS pelos servidores de e-
mail para verificar a confiabilidade de um remetente [JS04]. S˜ao mantidas por meio
de v´arios mecanismos, como contribui¸c˜oes de usu´arios, resultados de varreduras
autom´aticas, etc.
• Listas Brancas (White Lists): cada servidor de e-mail pode manter uma lista de
21
c´odigos maliciosos para facilitar a entrada em m´aquinas. Esses programas n˜ao podem
executar sozinhos.
´
E necess´ario a ajuda de usu´arios para que o c´odigo malicioso seja
introduzido no computador [HKS01]. Existem trˆes tipos de trojans em sistemas de com-
putadores:
• Programa cavalo de Tr´oia: programa malicioso que se disfar¸ca para contornar a
seguran¸ca de computadores em segredo;
• C´odigo-fonte troiano: uma c´opia de c´odigo fonte de programas modificados para
conter alguma backdoor ou brecha na seguran¸ca;
• Utilit´arios troianos: ap´os uma invas˜ao, um atacante pode substituir bin´arios
do sistema por vers˜oes que cont´em backdoors ou que ocultam suas atividades no
sistema.
O programa geralmente ´e atraente ao usu´ario (jogo, cliente IRC, sistema de men-
sagem instantˆanea). Sempre que esses programas s˜ao executados, eles acabam tendo as
mesmas permiss˜oes do usu´ario da m´aquina. Crackers mal intencionados utilizam grandes
listas de correio eletrˆonico (Spam) para enviar c´odigos Trojans, esperando que um dos
destinat´arios o execute. A propaga¸c˜ao ocorre tamb´em entre amigos, que enviam o pro-
grama com “boa aparˆencia” para suas listas de correio eletrˆonico. Programas Trojans s˜ao
um meio f´acil de um cracker inserir c´odigos maliciosos em diversos computadores.
Um exemplo ´e o Trojan Remote Shell do Linux, tamb´em conhecido como RST.b. Se
um atacante puder enganar um usu´ario para baixar e executar o bin´ario RST.b, infectar´a
os arquivos do sistema /bin, se poss´ıvel, e executar´a na porta 5503 uma backdoor. O
atacante poder´a se conectar a essa porta e emitir comandos UNIX executados como o
usu´ario que iniciou o Trojan RST.b [HKS01].
3.5 V´ırus e worms
Os v´ırus de computadores s˜ao programas capazes de infectar outros programas,
escondendo uma c´opia de si pr´oprio em programas normais [Coh90]. O worms s˜ao progra-
mas capazes de executar e se propagar automaticamente entre diversas m´aquinas atrav´es
de conex˜oes na rede. Diferente dos v´ırus, os worms n˜ao alteram programas, contudo eles
podem carregar c´odigos maliciosos tal com um v´ırus [SHF90]. Ambos (v´ırus e worms)
s˜ao programas que tˆem como objetivo inutilizar sistemas, destruir arquivos, roubar in-
forma¸c˜oes importantes de uma m´aquina ou simplesmente propagar-se ao extremo. Um
v´ırus de e-mail normalmente ´e constitu´ıdo por um e-mail com um anexo execut´avel (ou um
c´odigo HTML que permita carregar um arquivo execut´avel armazenado remotamente).
Esse c´odigo execut´avel pode ser ativado pelo usu´ario ou at´e mesmo de forma autom´atica,
explorando vulnerabilidades no cliente de e-mail.
A propaga¸c˜ao de um worm em sistemas de e-mail acontece por meio da explora¸c˜ao
de fragilidades nos clientes de e-mail atrav´es do uso da lista de contatos do usu´ario
[Kle01b]. M´aquinas infectadas por v´ırus podem oferecer backdooors que permitem seu
uso em diversos tipos de atividades nocivas.
Empresas de software desenvolvem anti-v´ırus e mantˆem bases de assinaturas j´a
conhecidas. Por´em, o atraso na atualiza¸c˜ao dessas bases pode ocasionar infesta¸c˜oes e
propaga¸c˜ao de v´ırus pela rede. Usu´arios de computadores pessoais precisam atualizar
constantemente seus sistemas de anti-v´ırus. Com o intuito de minimizar este problema
em servi¸cos de e-mail, provedores de acesso est˜ao implantando anti-v´ırus na entrada das
mensagens, diminuindo a possibilidade de transporte de v´ırus anexados em mensagens.
Todavia, estudos recentes demonstram que a abordagem baseada nas assinaturas de v´ırus
nunca resolver´a o problema, pois novos v´ırus se propagam mais rapidamente que as atu-
aliza¸c˜oes dos anti-v´ırus [ZGT02].
3.6 Conclus˜ao
Neste cap´ıtulo foram apresentadas as principais amea¸cas em sistemas de e-mail.
Usu´arios maliciosos s˜ao capazes de roubar informa¸c˜oes, danificar sistemas e afetar o de-
sempenho da rede utilizando programas que s˜ao propagados atrav´es dos sistemas de e-mail
e mensagens n˜ao solicitadas enviadas a diversos usu´arios da rede. Para minimizar esses
problemas, propostas em diversas ´areas tem sido realizadas, contudo, o problema est´a
longe de ter uma solu¸c˜ao definitiva devido `a complexidade de classifica¸c˜ao de mensagens
inv´alidas e autentica¸c˜ao de usu´arios na rede.
O pr´oximo cap´ıtulo apresenta as principais propostas baseadas em cliente e em
servidor que visam a autentica¸c˜ao de remetente em sistemas de e-mail.
Cap´ıtulo 4
Autentica¸c˜ao de remetentes
A autentica¸c˜ao de remetentes ´e implementada em clientes e/ou servidores de e-
mail para atestar usu´arios de sistemas de transporte de e-mail. Autenticar os usu´arios
desses sistemas ´e o primeiro passo para contra-atacar os problemas apontados no cap´ıtulo
anterior, visto que os spams, scams e programas maliciosos s˜ao geralmente propagados
por usu´arios/dom´ınios forjados. As principais propostas de autentica¸c˜ao de remetentes
s˜ao o PGP, S/MIME, SPF, SenderID eDomainKeys.
O S/MIME [Ram04] e o PGP [Zim95] s˜ao ferramentas implantadas em computa-
dores de usu´arios de e-mail, sendo transparente aos servidores de e-mail, para assinar e
cifrar arquivos e/ou documentos a serem enviados pela rede. Essas ferramentas garantem
a privacidade, integridade e autenticidade de mensagens utilizando sistemas baseados em
chaves assim´etricas para cifrar e assinar mensagens. Quando uma mensagem for cifrada
com a chave p´ublica de um receptor, apenas o receptor ser´a capaz de decifr´a-la. Da mesma
forma, quando uma mensagem for assinada por um emissor utilizando sua chave privada,
apenas a chave p´ublica deste emissor ser´a capaz de decifrar a assinatura, garantindo a
autenticidade do remetente.
O SPF (Sender Policy Framework) [Won04] cria uma infra-estrutura de verifica¸c˜ao
de autenticidade entre servidores de e-mail, sendo transparente aos clientes. O SPF utiliza
os servi¸cos de DNS para prover ao servidor destinat´ario informa¸c˜oes sobre o servidor
de origem de um e-mail. Essas informa¸c˜oes s˜ao descritas em uma linguagem pr´opria
e armazenadas em um registro espec´ıfico do servidor DNS do dom´ınio de origem da
mensagem. Ao receber uma mensagem, o servidor destinat´ario realiza uma consulta de
DNS para obter as informa¸c˜oes do dom´ınio de origem e comprovar a autenticidade do
remetente.
O SenderID [WML04] ´e uma melhoria do SPF que modifica a linguagem SPF e
prop˜oe um conjunto de novas especifica¸c˜oes para resolver os problemas relacionados `a
24
autentica¸c˜ao de mensagens encaminhadas (forwarded messages) encontrados no SPF.
O DomainKeys [DY04] utiliza uma infra-estrutura de chaves p´ublicas para validar
a autenticidade de um servidor de e-mail. A chave privada ´e armazenada localmente em
cada servidor, sendo utilizada para gerar uma assinatura no cabe¸calho de cada e-mail a
ser enviado. A chave p´ublica ´e armazenada em um registro de DNS do dom´ınio local,
sendo requisitada pelos servidores destinat´arios para validar a assinatura de cada e-mail
recebido.
Este cap´ıtulo apresenta os sistemas de autentica¸c˜ao de remetentes de e-mail e
est´a estruturado da seguinte forma: a se¸c˜ao 4.1 apresenta arquiteturas de autentica¸c˜ao
baseadas em certificados; a se¸c˜ao 4.2 apresenta a especifica¸c˜ao do SPF e a forma como ele
disponibiliza informa¸c˜oes sobre usu´arios do dom´ınio; a se¸c˜ao 4.4 apresenta o Sender ID,
uma extens˜ao do SPF; a se¸c˜ao 4.5 aborda o DomainKeys, um sistema de autentica¸c˜ao de
servidores baseado em chaves; por ´ultimo, a se¸c˜ao 4.7 conclui o cap´ıtulo.
4.1 Autentica¸c˜ao baseada em certificados
Os certificados digitais foram criados para atestar a autenticidade de
usu´arios/participantes de uma rede de computadores. Os certificados s˜ao criados a partir
do algoritmo RSA de criptografia de chave p´ublica [Sch94] (m´etodo desenvolvido em 1977
por Ron Rivest, Adi Samir e Len Adleman). Um certificado digital nada mais ´e que
uma credencial com uma assinatura gerada a partir de uma chave privada RSA, a chave
p´ublica correspondente `a chave privada e informa¸c˜oes adicionais sobre o certificado, tais
como validade, dono, tamanho da chave de criptografia, etc.
A autenticidade de um certificado digital ´e garantida pelas propriedades de chaves
assim´etricas definidas em [Sch94], onde, uma informa¸c˜ao cifrada com uma chave poder´a
ser decifrada apenas utilizando a chave assim´etrica correspondente a chave que cifrou
a informa¸c˜ao. Sendo assim, o certificado assinado por uma chave privada poder´a ser
decifrado apenas pela sua chave p´ublica correspondente, garantindo assim a autenticidade
do certificado. Os padr˜oes de Criptografia de Chave P´ublica encontrados na literatura
s˜ao: X.509 e PGP.
4.1.1 Padr˜ao X.509 e S/MIME
O X.509 ´e um padr˜ao para PKI (Public Key Infrastructure) que faz uso de autori-
dades certificadoras para criar e atestar certificados digitais na rede. O modelo do X.509
25
´e baseado em uma estrutura de ´arvore hier´arquica onde a raiz desta ´arvore representa o
principal fornecedor de certificado chamado de autoridade certificadora raiz (CA raiz). A
figura 4.1 mostra a estrutura de uma PKI.
Figura 4.1: Exemplo de uma Infra-estrutura de Chave P´ublica X.509 [CDN05]
O padr˜ao X.509 garante a confian¸ca de um certificado a partir da aceita¸c˜ao do
certificado da CA raiz como confi´avel. Por causa da estrutura de ´arvore do X.509, um
usu´ario dever´a confiar automaticamente em todos os certificados criados pela CA. Os
principais navegadores WEB e clientes de e-mail implementam o padr˜ao X.509 e pos-
suem um conjunto de certificados digitais de CAs mais conhecidas (tais como Verisign e
Trustcenter) para validar os certificados criados por tais autoridades.
O S/MIME (Secure/Multipurpose Internet Mail Extentions) ´e um modelo definido
por um grupo de empresas (incluindo RSA Security, Microsoft, a Lotus, Novel, etc), que
possibilita enviar mensagens atrav´es do sistema de e-mail de uma maneira segura. Clientes
de e-mail que tenham suporte ao S/MIME s˜ao capazes de adicionar facilmente assinaturas
digitas em mensagens e cifr´a-las [Ram04].
O S/MIME foi baseado na especifica¸c˜ao do MIME. O S/MIME disponibiliza um
servi¸co de cifragem que possui algoritmos de criptografia especificados pelo usu´ario; au-
tentica¸c˜ao por meio de chaves p´ublicas X.509; e n˜ao rep´udio por meio de mensagens
assinadas criptograficamente. Com o S/MIME ´e poss´ıvel:
• Cifrar uma mensagem, quando se interessa somente sigilo ou confidencialidade;
• Assinar uma mensagem, quando se interessa somente autenticidade e integridade;
26
• Cifrar e assinar uma mensagem, quando se interessa confidencialidade, autenticidade
e integridade.
A confidencialidade das mensagens que utilizam o S/MIME ´e garantida pelo uso
de algoritmos de criptografia sim´etricos. Nos Estados Unidos o algoritmo de exporta¸c˜ao
autorizado ´e o RC2-40 com chaves de 40 bits. Por isso os mailers utilizam algoritmos RC2-
40. Fora dos Estados Unidos pode ser utilizado o DES com chave de 56 bits ou ent˜ao
3DES com chaves de 168 bits. No caso da integridade e autenticidade de mensagens,
o S/MIME utiliza assinaturas digitais que s˜ao certificadas por CAs a partir do padr˜ao
X.509.
A grande falha no X.509 ´e que se de alguma forma a raiz CA for comprometida,
nenhum dos certificados criados por ela poder˜ao ser considerados confi´aveis. Al´em disso
a estrutura de ´arvore n˜ao ´e muito flex´ıvel [Ram04].
4.1.2 PGP
O PGP (Pretty Good Privacy) [Zim95] ´e uma ferramenta de criptografia e cer-
tifica¸c˜ao digital que utiliza criptografia assim´etrica (utilizando chaves p´ublica e privada)
para cifrar/decifrar e assinar mensagens a serem trafegadas pela rede. Esta ferramenta foi
desenvolvida como alternativa ao X.509 que possui falhas em sua estrutura hier´arquica.
Ao contr´ario do X.509 o PGP utiliza um modelo de confian¸ca baseado em sistemas ponto
a ponto (peer-to-peer) descentralizando os certificados digitais. Isto significa que cada
usu´ario ´e sua pr´opria raiz CA. A confian¸ca ´e expressa atrav´es da assinatura da chave
p´ublica de um usu´ario com a chave assim´etrica correspondente `a chave p´ublica (confian¸ca
direta) ou por inferˆencia de confian¸ca atrav´es de uma base de chaves local (confian¸ca
indireta).
O PGP usa chaves de sess˜ao que s˜ao criadas a partir de um n´umero gerado aleatori-
amente a cada cifragem. As chaves de sess˜ao s˜ao utilizadas para cifrar os dados utilizando
algoritmos de criptografia sim´etrica. A chave de sess˜ao ´e cifrada utilizando a chave p´ublica
do destinat´ario. Ao receber uma mensagem cifrada, o destinat´ario utiliza a chave privada
para recuperar a chave de sess˜ao e decifrar o texto. O motivo pelo qual os autores optaram
por chaves de sess˜ao se d´a pelo fato dos algoritmos de criptografia sim´etrica serem muito
mais r´apidos (tanto na cifragem quanto na decifragem) que os algoritmos RSA. Mesmo
que o dado tenha sido gerado por uma chave n˜ao segura, esta chave ´e cifrada pela chave
p´ublica do usu´ario e enviada pela rede garantindo a privacidade, velocidade de decifragem
27
e seguran¸ca da informa¸c˜ao.
As assinaturas digitais s˜ao geradas de maneira similar a cifragem dos dados. A
diferen¸ca ´e que o PGP utiliza a chave privada para gerar a assinatura digital. Para
comprovar a autenticidade da assinatura, um usu´ario dever´a utilizar a chave p´ublica do
poss´ıvel emissor para decifrar a assinatura. Se a assinatura for corretamente decifrada isto
indica que a chave foi gerada pelo seu par (privada - p´ublica). Do contr´ario a assinatura
foi gerada por um emissor malicioso.
As abordagens baseadas em ponto a ponto s˜ao mais flex´ıveis que a abordagem
hier´arquica X.509. A fragilidade desta abordagem reside na falta de propaga¸c˜ao de valores
de confian¸ca, contudo, pesquisas recentes foram iniciadas para desenvolver algoritmos de
propaga¸c˜ao de reputa¸c˜ao e confian¸ca. Alguns desses estudos ser˜ao abordados no decorrer
do cap´ıtulo.
4.2 Sender Policy Framework
O SPF (Sender Policy Framework ) [Won04] ´e uma especifica¸c˜ao de autentica¸c˜ao de
servidores de e-mail que visa diminuir o tr´afego de mensagens indesej´aveis em servidores
de e-mail (SMTP), atrav´es de pol´ıticas e filtros no recebimento das mensagens utilizando
um ambiente que trabalha em conjunto com servidores DNS.
As pol´ıticas e os filtros do SPF s˜ao definidos a partir de uma linguagem simples que
descreve o dom´ınio de um determinado servidor de e-mail. A partir dessas informa¸c˜oes,
servidores ser˜ao capazes de avaliar se uma mensagem foi originada por um determinado
dom´ınio. Caso seja comprovada uma fraude de dom´ınio, administradores de servidores
de e-mail ser˜ao capazes de descartar, analisar ou ent˜ao manipular o e-mail fraudulento de
acordo com as pol´ıticas do servidor.
4.2.1 Fundamentos do SPF
Servidores que utilizam a especifica¸c˜ao SPF dever˜ao possuir atributos ´unicos que
ser˜ao utilizados por outros servidores de e-mail para validar a autenticidade de mensagens.
Esses atributos fazem parte de um registro SPF (detalhado a seguir) que ser´a utilizado por
servidores de e-mail (receptores) para classificar uma mensagem, possibilitando assim que
mensagens com remetentes falsos sejam descartadas. Para facilitar a consulta de outros
28
servidores, os registros SPF s˜ao armazenados no servidor DNS em um campo TXT. A
figura 4.2 apresenta o funcionamento b´asico da especifica¸c˜ao SPF.
Figura 4.2: Modelo SPF[Won04]
Nesta figura o servidor emissor do dom´ınio 1 abriu um canal de comunica¸c˜ao
SMTP com o servidor receptor do dom´ınio 2 e est´a enviando mensagens. Ao receber
uma mensagem, o servidor receptor dever´a requisitar ao SPF a valida¸c˜ao do dom´ınio do
usu´ario emissor. Em seguida o SPF far´a uma consulta ao servidor de DNS do dom´ınio
1 verificando a autenticidade do dom´ınio. Em seguida o SPF dever´a retornar ao servidor
de e-mail uma das seguintes respostas:
1. None: n˜ao existem registros publicados pelo dom´ınio de origem;
2. Neutral: deve ser tratado exatamente como o resultado None;
3. Pass: cliente est´a autorizada a enviar o e-mail com a identidade “Mail From”.
Pol´ıticas de checagem podem ser processadas com confian¸ca baseadas na identidade
“Mail From”;
4. Fail: n˜ao est´a autorizado a utilizar o dom´ınio. Se o software de checagem escolher
rejeitar o e-mail durante a transa¸c˜ao SMTP, ent˜ao ele dever´a retornar um c´odigo
SMTP 550;
5. SoftFail: o dom´ınio acredita que o host n˜ao est´a autorizado mas n˜ao pode definir
com seguran¸ca o estado. O software n˜ao deve rejeitar a mensagem baseado no
resultado, mas dever´a tratar a mensagem como suspeita;
29
6. TempError: o servidor de recebimento encontra-se numa transi¸c˜ao de erro na
checagem. O software pode escolher aceitar ou rejeitar temporariamente a men-
sagem. Se a mensagem for rejeitada durante a transa¸c˜ao SMTP, o software dever´a
responder com um c´odigo SMTP 450.
7. PermError: o domin´ıo n˜ao pode interpretar a identidade de “Mail From” correta-
mente. O software poder´a rejeitar a mensagem. Se for rejeitada durante a transa¸c˜ao
de SMTP, dever´a responder com um c´odigo SMTP 550.
4.2.2 Registros SPF
Um registro SPF armazena informa¸c˜oes sobre o dom´ınio de e-mail na internet (tais
como hosts, servidores MX, IP de servidores MX e outros) que indicam quais entidades
possuem permiss˜ao para utilizar o nome do dom´ınio em quest˜ao. Os registros SPF s˜ao
publicados em servidores DNS de seu dom´ınio, que dever˜ao ser consultados toda vez que
existir a necessidade de valida¸c˜ao da autenticidade de uma mensagem. Os campos de um
registro SPF s˜ao: vers˜ao SPF, mecanismos, prefixos e modificadores. Como por exemplo
de registro SPF:
“v=spf1 +mx +a +ptr include:myspf.com.br exp=spf -err +all”
onde:
• v=spf1: vers˜ao do SPF;
• mx, a, ptr, include, err e all: mecanismos do SPF;
• + e -: prefixos do SPF (devem precede os mecanismos). Se n˜ao existir um prefixo
especificado o padr˜ao ser´a (+);
• exp: modificador (pode ser zero, um ou dois modificadores).
A seguir s˜ao detalhados cada um dos componentes que fazem parte do registro
SPF.
Vers˜ao
30
A vers˜ao SPF mant´em a compatibilidade de poss´ıveis altera¸c˜oes no protocolo/reg-
istros SPF. Todos os registros SPF dever˜ao ser iniciados com a vers˜ao SPF. Os clientes
SPF dever˜ao utilizar apenas registros que s˜ao da mesma vers˜ao ou ent˜ao vers˜oes com-
pat´ıveis ao processador SPF do cliente. Todos os registros com vers˜ao incompat´ıvel ao
processador de registros SPF do cliente dever˜ao ser ignorados.
Prefixos
Os prefixos definem como um mecanismo dever´a se comportar caso um registro
SPF seja encontrado. Os prefixos s˜ao: + (pass), − (fail), ∼ (softfail) e ? (neutral). Se o
prefixo n˜ao estiver definido, o SPF utilizar´a como padr˜ao o prefixo +. Como por exemplo:
“v=spf1 +mx +ptr include:myspf.com.br exp=spf -err +all”
onde, todos os mecanismos antecedidos por um prefixo ser˜ao testados e dever˜ao retornar
pass ou fail de acordo com a informa¸c˜ao pesquisada.
Mecanismo
Os mecanismos SPF s˜ao respons´aveis por identificar endere¸cos IP autorizados a
enviar mensagens a partir de um determinado dom´ınio. Existem dois mecanismos b´asicos
definidos no SPF relacionados `as categorias de IPs (internos e externos ao dom´ınio): all
e include. Os demais mecanismos s˜ao respons´aveis por autorizar e designar emissores.
Os mecanismos s˜ao:
• all: testa se todas as informa¸c˜oes coincidem (mecanismos ap´os o all n˜ao ser˜ao
testados);
• include: executa uma consulta recursiva ao SPF;
• a: verifica se o host de envio ´e um endere¸co IP v´alido;
• mx: verifica se o host de envio ´e um host MX do dom´ınio;
• ptr: testa se o nome do host de envio encontra-se em um determinado dom´ınio;
31
• ip4/ip6: testa se o host de envio est´a utilizando uma rede IP;
• exists: constr´oi um nome de host arbitr´ario que ser´a utilizado numa consulta
de registro DNS A. Isto possibilita um esquema complicado envolvendo partes ar-
bitr´arias de um e-mail para determinar o que ´e legal.
Outros mecanismos podem ser definidos (o SPF possibilita a cria¸c˜ao de novos
mecanismos para serem utilizados no futuro). Desta forma, os mecanismos podem co-
incidir, n˜ao coincidir ou ent˜ao gerar uma exce¸c˜ao. Caso os mecanismos coincidam, seus
valores de prefixo dever˜ao ser retornados; caso os mecanismos n˜ao coincidam, o processa-
mento dever´a continuar; caso seja lan¸cada uma exce¸c˜ao, o valor da exce¸c˜ao ser´a retornado.
Alguns mecanismos possuem suporte para argumentos opcionais. Esses argumen-
tos s˜ao respons´aveis por definir nomes de dom´ınios, conjuntos de IPs e outras informa¸c˜oes
pertinentes para a valida¸c˜ao de hosts/dom´ınios.
Modificadores
Apenas dois modificadores s˜ao definidos como padr˜ao na esp ecifica¸c˜ao do SPF:
“redirect” e “exp”. Esses modificadores dever˜ao ser implementados nos clientes SPF.
Os modificadores disponibilizam informa¸c˜oes adicionais ou ent˜ao altera¸c˜oes no curso do
processamento do SPF. Os modificadores disponibilizam tamb´em uma maneira f´acil de
estender o registro SPF. Os modificadores s˜ao:
• redirect: se todos os mecanismos falharem e um modificador redirect estiver definido,
ent˜ao o modificador ir´a alterar o dom´ınio para ser processado;
• exp: utilizado para gerar uma mensagem SMTP para o host emissor caso o proces-
samento do SPF resultar em rejei¸c˜ao.
4.3 Limita¸c˜oes da arquitetura
O SPF possui algumas limita¸c˜oes e problemas que n˜ao foram originalmente abor-
dadas pelos autores. Segundo [Cun05], suas principais limita¸c˜oes s˜ao:
1. Servidores que possuem m´ultiplos dom´ınios podem ser utilizados por spammers para
envio de mensagens, pois usu´arios do dom´ınio dominio1.com.br s˜ao capazes de se
passar por um determinado usu´ario do dom´ınio dominio2.com.br que encontram-
se no mesmo servidor f´ısico;
32
2. O forwarding de e-mail pode ser comprometido, pois um agente ´e capaz de repassar
uma mensagem sem alterar o endere¸co em “from:”. Como o SPF valida o conte´udo
da mensagem, o retorno para forwarding ser´a sempre fail, pois as informa¸c˜oes da
consulta n˜ao ir˜ao coincidir com o servidor utilizado para fazer o forward da men-
sagem;
3. Se um servidor DNS for invadido, as informa¸c˜oes poder˜ao ser falsificadas (DNS
poison);
4.4 Sender ID
A framework SIDF (SenderID Framework ) [WML04] foi desenvolvida por um con-
junto de empresas para prover autentica¸c˜ao de dom´ınio em servidores de e-mail. Esta
framework checa cada mensagem recebida pelo servidor, validando se o servidor de
e-mail emissor pode enviar a mensagem originada pelo dom´ınio do emissor da men-
sagem. Esta verifica¸c˜ao ´e feita de forma autom´atica atrav´es do servidor receptor antes
que a mensagem seja entregue ao usu´ario. O ciclo de vida de uma comunica¸c˜ao SMTP
utilizando o SenderID pode ser visto na figura 4.3.
Figura 4.3: Funcionamento do Sender ID [WML04]
Nesta figura o servidor emissor do dom´ınio 1 abriu um canal de comunica¸c˜ao
SMTP com o servidor receptor do dom´ınio 2 e est´a enviando mensagens. Ao receber
uma mensagem, o servidor receptor dever´a requisitar ao SIDF a valida¸c˜ao do dom´ınio do
usu´ario emissor. Em seguida o SIDF far´a uma consulta ao servidor de DNS SPF Records
do dom´ınio 1 verificando a autenticidade do dom´ınio. Em posse dessas informa¸c˜oes o
servidor de e-mail poder´a receber ou rejeitar a mensagem. A framework SIDF ´e dividida
33
em trˆes partes:
1. extrair o endere¸co do remetente do cabe¸calho da mensagem;
2. extrair o dom´ınio do remetente;
3. chamar a fun¸c˜ao check host que dever´a fazer uma consulta ao servidor DNS do
dom´ınio extra´ıdo no passo 2 verificando a autenticidade do usu´ario. Os parˆametros
a serem passados para a fun¸c˜ao check host s˜ao:
(a) endere¸co IP;
(b) dom´ınio do remetente;
(c) endere¸co do remetente;
Como resultado da consulta dever´a ser retornado um dos resultados apresentados
na se¸c˜ao 4.2.1. Este resultado poder´a ser utilizado tanto para negar a mensagem
quanto como parˆametro adicional dos filtros de mensagem do servidor de e-mail.
O cen´ario a seguir apresenta um exemplo de uso do SIDF, sendo que o endere¸co
“From:” do cabe¸calho da mensagem ´e maria@ppgia.pucpr.br e existe apenas um
registro SPF no DNS do dom´ınio emissor.
Registro: “acme.com.br v=spf1 ip4:192.0.2.0/24 -all”
1. addr = [email protected]
2. domain = ppgia.pucpr.br
3. result = check host(“127.0.0.1”, domain, addr)
O resultado do check host dever´a ser fail, pois as informa¸c˜oes coletadas pelo SIDF
n˜ao est˜ao presentes no DNS SPF Record.
4.4.1 Registros Sender ID e o PRA (Purpoted Responsible Address)
O SIDF utiliza o SPF [Won04] para disponibilizar as informa¸c˜oes sobre um de-
terminado dom´ınio. Conforme visto na sess˜ao 4.2.2 esses registros informam quais hosts
podem enviar mensagens utilizando o dom´ınio que armazena os registros. A seguir s˜ao
apresentados alguns exemplos de
34
• exemplo.com.br TXT ‘‘v=spf1 ip4:192.0.2.0/24 -all’’: especifica um con-
junto de IP;
• example.com TXT ‘‘v=spf1 -all’’: este dom´ınio nunca envia e-mail;
• example.com TXT ‘‘spf2.0/pra ip4:192.0.3.0/24 -all’’: diferente con-
figura¸c˜ao de checagem PRA.
Note que o ´ultimo exemplo possui uma vers˜ao 2.0 do SPF. A vers˜ao 2 foi proposta
para suportar o PRA ( Purpoted Responsible Address) [Lyo05]. O PRA foi projetado
para resolver os problemas de forwarding, onde, em alguns casos, uma mensagem pode
trafegar por mais de um MTA, n˜ao sendo poss´ıvel validar o dom´ınio/IP do servidor
emissor correto. O PRA define a entidade mais recente (de acordo com o cabe¸calho) que
enviou a mensagem, utilizando campos adicionais no cabe¸calho do e-mail. O PRA de
uma mensagem ´e determinado pelo algoritmo a seguir [Lyo05]:
1. Selecione o primeiro cabe¸calho Resent-Sender n˜ao vazio da mensagem. Se nenhum
cabe¸calho for encontrado, v´a para o passo 2. Se o cabe¸calho encontrado for precedido
por um cabe¸calho Resent-From n˜ao vazio e um ou mais cabe¸calhos Received ou
Return-Path ocorrerem depois do cabe¸calho Resent-From e antes do cabe¸calho
Resent-Sender, v´a para o passo 2. Do contr´ario, v´a para o passo 5.
2. Selecione o primeiro cabe¸calho Resent-From n˜ao vazio da mensagem. Se o cabe¸calho
Resent-From for encontrado, v´a para o passo 5. Do contr´ario, v´a para o passo 3.
3. Selecione todos os cabe¸calhos Sender n˜ao vazios da mensagem. Se existir exata-
mente um cabe¸calho, v´a para o passo 5. Se existir mais de um cabe¸calho, v´a para
o passo 6. Do contr´ario, v´a para o passo 4.
4. Selecione todos os cabe¸calhos From n˜ao vazios da mensagem. Se existir exatamente
um cabe¸calho, v´a para o passo 5. Do contr´ario, v´a para o passo 6.
5. Os passos anteriores selecionaram um ´unico cabe¸calho da mensagem. Se este
cabe¸calho for mal formado (aparentemente possui m´ultiplas caixas de correio, ou
uma ´unica caixa de correio n˜ao possui um nome de dom´ınio, etc), v´a para o passo
6. Do contr´ario, retorne que a caixa de correio ´e um PRA.
6. A mensagem ´e mal formada, e ´e imposs´ıvel determinar um PRA.
35
4.4.2 ESMTP SUBMITTER
O SIDF prop˜oe ainda o ESMTP SUBMITTER [AK04], que d´a suporte a inclus˜ao
do emissor atual da mensagem no protocolo SMTP. Esta extens˜ao deve obedecer aos
seguintes padr˜oes:
1. nome do servi¸co ESTMP ´e Responsible Submitter ;
2. chave EHLO deve estar associada `a extens˜ao SUBMITTER;
3. chave SUBMITTER n˜ao possui parˆametros;
4. parˆametro opcional dever´a ser inclu´ıdo no comando MAIL que utilizar´a a chave
SUBMITTER para especificar o endere¸co do emissor respons´avel pelo reenvio da men-
sagem.
Um exemplo do uso do ESMTP SUBMITTER pode ser visto a seguir [AK04]:
1 S : 220 company . com . example ESMTP server ready
2 C : EHLO alm amater . edu . e xample
3 S : 250 - company . com . examp le
4 S : 250 - DSN
5 S : 250 - AUTH
6 S : 250 - SUBMI TTER
7 S : 250 SIZE
8 C : MAIL FROM :< ali ce@exa mple .com >
9 S UBMITT ER = bob@al mama ter . edu . exa mple
10 S : 250 < ali ce@exampl e . com > sender ok
11 C : RCPT TO :< bob@c ompan y . com . example >
12 S : 250 < b ob@co mpany . com . example > recip ient ok
13 C : DATA
14 S : 354 okay , send messag e
15 C : Resent -From: bo b@al mamat er . edu . exampl e
16 C : Received By : ...
17 C : ( message body goes here )
18 C : .
19 S : 250 message ac ce pted
20 C : QUIT
21 S : 221 goodbye
36
Utilizando o SUBMITTER, um servidor de e-mail ser´a capaz de recuperar o en-
dere¸co do emissor e fazer a consulta SPF no dom´ınio do emissor atrav´es do protocolo
SMTP.
4.4.3 Limita¸c˜oes
As principais limita¸c˜oes no Sender ID s˜ao: o SIDF autentica os dom´ınios e n˜ao os
usu´arios; valida apenas o ´ultimo salto; spammers s˜ao capazes de registrar seus pr´oprios
dom´ınios, fazendo com que seja necess´ario um esfor¸co investigativo e criar sistema de
reputa¸c˜ao de dom´ınios.
4.5 DomainKeys
O DomainKeys ´e uma tecnologia desenvolvida por um grupo de pesquisas do Yahoo
[DY04] que, assim como o SPF e SIDF tem como objetivo autenticar o dom´ınio e validar
a integridade das mensagens enviadas. Al´em disso, o DomainKeys foi projetado para ser
transparente, 100% compat´ıvel com a infra-estrutura existentes, independente de clientes
e n˜ao requer uma autoridade de certifica¸c˜ao centralizada.
4.5.1 Fundamentos do DomainKeys
O DomainKeys cria um par de chaves p´ublica/privada para cada dom´ınio/sub-
domin´ıo e armazena em locais seguros do servidor. A chave p´ublica ´e armazenada em um
registro do DNS (disponibiliza essas chaves para consultas de outros dom´ınios da rede). A
chave privada ´e armazenada em um diret´orio ou qualquer outra forma de armazenamento
local, acessado pelo sistema de sa´ıda do servidor de e-mail para gerar uma assinatura no
cabe¸calho de mensagens que ser˜ao enviadas pelo sistema utilizando a chave privada. A
Figura 4.4 apresenta o fluxo do DomainKeys.
37
Figura 4.4: Funcionamento do DomainKeys [DY04]
Quando a mensagem for enviada por um servidor com suporte a DomainKeys, o
servidor de destino dever´a submeter a mensagem recebida as seguintes etapas de auten-
tica¸c˜ao:
1. Extrair a assinatura cifrada pela chave privada do emissor do e-mail;
2. Solicitar a chave p´ublica do dom´ınio em quest˜ao;
3. Utilizar a chave p´ublica para verificar se a assinatura foi gerada a partir da chave
privada do servidor emissor. Se a chave p´ublica for capaz de decifrar a assinatura,
significa que o e-mail foi originado pelo dom´ınio descrito no cabe¸calho da mensagem.
Do contr´ario, o emissor ´e falso e a mensagem poder´a ser descartada.
4.5.2 Registros DomainKeys
Para evitar conflito de namespace no DNS, a especifica¸c˜ao do DomainKeys prop˜oe
o uso de um namespace especial: “ domainkey”. Este namespace ser´a reservado para
armazenar as chaves p´ublicas de um dom´ınio no formato: domainkey.dominio1.com.br.
O namespace dever´a ser dividido em um ou mais “selectors”. Os selectors s˜ao n´ıveis
´unicos do namespace definidos por uma string. Um exemplo de selector pode ser visto a
seguir:
“teste. domainkey”
onde teste indica o nome do selector.
Cada dom´ınio dever´a definir a quantidade de chaves p´ublicas em conjunto com seus
respectivos selectors. Por padr˜ao os algoritmos de cifragem utilizados pelo Domainkeys
38
s˜ao o RSA/SHA1, contudo, novos algoritmos podem ser utilizados, tal como o PGP.
Representa¸c˜ao de uma chave p´ublica no DNS
A chave p´ublica no DomainKeys ´e representada da seguinte forma:
“teste. domainkey IN TXT ‘‘k=rsa; p=MEwwDQYJKoZLhvcNAQEB’’”
onde:
• g: granularidade da chave;
• k: tipo da chave;
• n: notas que podem ser de interesse humano (nenhuma interpreta¸c˜ao ´e feita pelos
programas);
• p: chave p´ublica codificada em Base64 se o valor for vazio, significa que a chave foi
revogada;
• t: modo de teste. Indica se esta chave ´e apenas para teste.
Cabe¸calho do e-mail
A assinatura digital gerada pelo DomainKeys para autenticar a mensagem deve
ser armazenada como uma linha do cab e¸calho da mensagem a ser transmitida; o campo
que armazena esta assinatura ´e o “DomainKey-Signature:”. Um exemplo do campo pode
ser visto a seguir:
“DomainKey-Signature: a=rsa-sha1 s=teste; d=dominio1.com.br; c=simple; q=dns;
b=dzdVyOfAKCDLXdOc8GCQ;”, onde:
• a: algoritmo utilizado para gerar a assinatura;
• b: assinatura codificada em Base64;
• c: forma que o cabe¸calho/conte´udo s˜ao apresentados;
• d: nome do dom´ınio que gerou a assinatura;
39
• q: tipo de consulta para requisitar a chave p ´ublica (atualmente somente o m´etodo
dns ´e suportado);
• s: “selector” que ser´a consultado para requisi¸c˜ao da chave p ´ublica.
Resultados de consultas
O DomainKeys disponibiliza um status para os clientes de e-mail que ´e armazenado
no campo “DomainKey-Status”. Os status podem ser:
• good: assinatura v´alida;
• bad: assinatura inv´alida;
• no key: chave inexistente;
• revoked: chave revogada;
• bad format: dados da chave inv´alidos;
• non-participant: n˜ao faz parte do dom´ınio.
A grande maioria dos clientes de e-mail possuem suporte a configura¸c˜ao de regras
de cabe¸calho. Utilizando esta funcionalidade, ´e poss´ıvel que usu´arios apliquem regras
para manipular mensagens de acordo com o status retornado pelo DomainKeys.
4.6 Vantagens e Limita¸c˜oes
As principais vantagens de se utilizar o DomainKeys s˜ao:
• Um par de chaves pode ser criado para cada dom´ınio da internet, tornando poss´ıvel
um sistema de autentica¸c˜ao de servidores de e-mail global;
• Qualquer dom´ınio pode gerar suas chaves e disponibiliz´a-las no servidor DNS (n˜ao
´e necess´ario um reposit´orio de chaves global);
• As informa¸c˜oes que v˜ao no cabe¸calho SMTP n˜ao influenciam o e-mail, isto ´e, se um
determinado servidor n˜ao suportar DomainKeys, a assinatura ser´a ignorada.
As limita¸c˜oes do DomainKeys s˜ao:
• Precisa ser suportado em ambos os lados da conex˜ao para funcionar;
• O desempenho do processo de recebimento de mensagens poder´a cair, pois o Do-
mainKeys dever´a consultar o DNS, recuperar a chave, decifrar a assinatura e depois
receber ou rejeitar a mensagem.
4.7 Conclus˜ao
Neste cap´ıtulo foram apresentados os principais m´etodos de autentica¸c˜ao de
dom´ınios que s˜ao o PGP e SMIME (baseados em cliente), SPF, Sender ID e DomainKeys
(baseados em servidor). A tabela 4.1 apresenta um comparativo entre as abordagens
apresentadas neste cap´ıtulo.
Tabela 4.1: Quadro comparativo modelos de autentica¸c˜ao de remetentes
Implementa¸c˜ao Utiliza Modelo Necessidade de Altera¸c˜oes
no cliente/servidor chave centralizado no protocolo SMTP
S/MIME Cliente Sim Sim N˜ao
PGP Cliente Sim N˜ao N˜ao
SPF Servidor N˜ao N˜ao N˜ao
Sender ID Servidor N˜ao N˜ao Sim
Domain Keys Servidor Sim N˜ao N˜ao
Nesta tabela s˜ao apresentadas as principais diferen¸cas entre os principais m´etodos
de autentica¸c˜ao de remetentes. Os modelos de autentica¸c˜ao baseados em clientes n˜ao ´e
escal´avel e dif´ıcil de manter as chaves. Os modelos de autentica¸c˜ao de remetente baseados
possuem uma forma mais confi´avel de disponibiliza¸c˜ao das chaves. Ambos os modelos n˜ao
tratam o conte´udo da mensagem e seus resp ectivos emissores.
A autentica¸c˜ao de dom´ınios ´e o caminho inicial para a conten¸c˜ao de spams, contudo
est´a longe de ser uma solu¸c˜ao efetiva, pois spammers ainda s˜ao capazes de enviar e-mail
utilizando dom´ınios autenticados porque a autentica¸c˜ao do remetente n˜ao o impede de
enviar e-mails com conte´udo n˜ao solicitado, apenas possibilita seu rastreamento.
No pr´oximo cap´ıtulo ser˜ao abordadas as no¸c˜oes de confian¸ca hier´arquica, confian¸ca
em grupos e redes de relacionamento.
Cap´ıtulo 5
Redes de Confian¸ca
As rela¸c˜oes de confian¸ca s˜ao fundamentais na constru¸c˜ao e manuten¸c˜ao de uma
sociedade. Por rela¸c˜ao de confian¸ca entende-se o quanto uma pessoa deposita confian¸ca
em outras pessoas que conhece, e como age em rela¸c˜ao a desconhecidos. Rela¸c˜oes de
confian¸ca s˜ao modelos dinˆamicos onde os n´ıveis de confian¸ca podem aumentar ou diminuir
de acordo com as atitudes de um indiv´ıduo no meio. As regras para determinar atitudes
positivas e negativas s˜ao definidas pela sociedade (grupos de indiv´ıduos, governo, parentes,
comunidades, etc.) onde o indiv´ıduo encontra-se inserido. Essas regras definem puni¸c˜oes
para todos os indiv´ıduos que n˜ao as cumprem.
As rela¸c˜oes de confian¸ca vˆem sendo empregadas em redes de computadores para
prover uma maior seguran¸ca nesses sistemas. Exemplos de rela¸c˜oes de confian¸ca podem
ser encontrados em redes peer-to-peer, que utilizam algoritmos de reputa¸c˜ao para indicar
indiv´ıduos mais ou menos confi´aveis em uma rede. Para que possam ser analisados algo-
ritmos eficazes e modelos aplic´aveis a sistemas de e-mail faz-se necess´ario um estudo mais
aprimorado dos modelos de confian¸ca utilizados pelos seres humanos.
Os estudos comportamentais realizados em seres humanos para determinar como
funcionam os modelos de confian¸ca, apresentam um indicativo de que a confian¸ca pode
ser medida utilizando v´arias abordagens, dentre elas a bin´aria (sim ou n˜ao) e a escalar
(porcentagem) [Han98].
Utilizando a confian¸ca escalar, ´e poss´ıvel definir que um indiv´ıduo A pode confiar
em B de 0% a 100%. Al´em disso, se A confia em B e B confia em C, isto implica que A
pode confiar em C de acordo com a propriedade de transitividade de A, B e C, ou seja,
Se A → B e B → C ent˜ao A → C [VM02].
A Figura 5.1 mostra que se A confia em B 80% e B confia em C 50%, conseq¨uen-
temente A confia em C 40%. Contudo, existem ainda os fatores externos (clima, humor,
42
Figura 5.1: Confian¸ca entre indiv´ıduos distintos
local, etc) que podem influenciar na confian¸ca final entre os indiv´ıduos. Todos esses fa-
tores s˜ao armazenados na mem´oria de cada pessoa e servir˜ao de base em suas pr´oximas
intera¸c˜oes. A mem´oria de um indiv´ıduo pode ser representada na forma de uma matriz,
chamada de mem´oria de Confian¸ca. Um exemplo de mem´oria de confian¸ca pode ser
visto na tabela 5.1.
Tabela 5.1: Mem´oria de Confian¸ca de A
Indiv´ıduo Confian¸ca Fatores externos Confian¸ca final
B 80% -5% 75%
C 40% +10% 50%
Nesta tabela est´a sendo representada a confian¸ca de um indiv´ıduo A nos indiv´ıduos
B e C. A linha que representa a confian¸ca de A em B mostra que a confian¸ca ´e de
80%. Contudo, fatores externos fizeram com que a confian¸ca de A (naquele momento)
diminu´ısse em 5%, resultando a confian¸ca final de A em B um total de 75%. Da mesma
forma a linha que representa a confian¸ca de A em C mostra que a confian¸ca ´e de 40%.
Contudo, fatores externos fizeram com que a confian¸ca de A (naquele momento) aumen-
tasse em 10%, resultando a confian¸ca final de A em C um total de 50%.
Este cap´ıtulo traz uma vis˜ao sobre as rela¸c˜oes de confian¸ca entre indiv´ıduos e seu
uso em sistemas distribu´ıdos. Este cap´ıtulo est´a estruturado da seguinte forma: a se¸c˜ao
5.1 apresenta uma vis˜ao geral sobre a confian¸ca hier´arquica de acordo com o comporta-
mento humano; a se¸c˜ao 5.2 apresenta os grupos sociais; a se¸c˜ao 5.3 apresenta as redes de
relacionamento e suas principais caracter´ısticas; a se¸c˜ao 5.4 apresenta alguns algoritmos
para gest˜ao de confian¸ca e reputa¸c˜ao encontrados na literatura; p or ´ultimo, a se¸c˜ao 5.5
conclui o cap´ıtulo.
43
5.1 Confian¸ca hier´arquica
A confian¸ca hier´arquica ´e definida como a confian¸ca que um indiv´ıduo possui em
seus pais, parentes e vice-versa. A confian¸ca hier´arquica ´e de extrema importˆancia na
forma¸c˜ao do indiv´ıduo, pois a p ersonalidade de uma pessoa est´a relacionada diretamente
com sua educa¸c˜ao familiar, ou seja, uma pessoa ´e fortemente influenciada a aprender o
que seus pais e parentes ensinam [Car61].
A confian¸ca pode ser representada p or uma ´arvore, onde os n´os representam in-
div´ıduos participantes (pais/parentes) e as arestas representam o grau de parentesco
de cada indiv´ıduo. O grau de parentesco ´e a distˆancia de um n´o em rela¸c˜ao a outro n´o;
quanto menor a distˆancia a ser p ercorrida para chegar ao destino, menor ser´a seu grau de
parentesco. A figura 5.8 apresenta um exemplo de ´arvore de confian¸ca.
Figura 5.2:
´
Arvore de confian¸ca
Analisando a figura, ´e poss´ıvel verificar que qualquer participante da ´arvore ´e
capaz de chegar em um outro participante utilizando caminhamento entre os n´os. Este
caminhamento pode ser representado por um vetor onde os elementos s˜ao n´os a serem
visitados. A figura 5.3 apresenta o caminhamento do n´o E (da figura anterior) at´e o n´o
K.
Figura 5.3: Vetor de confian¸ca
44
Para o n´o E chegar ao n´o K este n´o dever´a visitar seu pai que ´e capaz de chegar a
sub-´arvore do n´o destino. A medida que os n´os v˜ao sendo visitados, o grau de parentesco
aumenta, diminuindo o n´ıvel de confian¸ca, pois, mesmo que ambos os n´os perten¸cam a
mesma “fam´ılia”, n˜ao significa que um indiv´ıduo da sub-´arvore X seja confi´avel para
um indiv´ıduo da sub-´arvore Y. Por este motivo, existe a necessidade de limitar o grau
de parentesco confi´avel, tornando a ´arvore menor, conseq¨uentemente diminuindo o espa¸co
de procura e a quantidade de parentes confi´aveis.
Incluindo valores de confian¸ca nas arestas de liga¸c˜ao da ´arvore, um n´o ser´a capaz
de gerar um percentual de confian¸ca com qualquer n´o que esteja acess´ıvel e que n˜ao
ultrapasse um limite de grau de parentesco pr´e-estabelecido. As arestas que fazem a
liga¸c˜ao de cada n´o s˜ao unidirecionais, ou seja, a confian¸ca de A em B poder´a ser diferente
da confian¸ca de B em A. A figura 5.4 apresenta a confian¸ca entre os membros de uma
´arvore e as arestas que os conectam.
Figura 5.4: Confian¸ca entre n´os de uma ´arvore
Observa-se nesta figura que a confian¸ca do n´o G com o n´o J ´e de 0%. Isto significa
que qualquer n´o abaixo da sub-´arvore J, incluindo J estar´a inacess´ıvel. Os demais
n´os poder˜ao gerar percentuais de confian¸ca utilizando as propriedades de transitividade
descritas em [VM02].
Outra forma de representar a confian¸ca hier´arquica ´e atrav´es de uma matriz in-
div´ıduo vs indiv´ıduo, onde a intersec¸c˜ao dos eixos da matriz indicam o percentual de
45
confian¸ca entre os indiv´ıduos. Desta forma, ´e poss´ıvel definir a confian¸ca entre todos os
n´os da ´arvore anterior. A tabela 5.2 mostra a representa¸c˜ao tabular da ´arvore de confian¸ca
da figura 5.4.
Tabela 5.2: Rela¸c˜oes de confian¸ca
B F G J K
B 100% - 100% 0% 80%
F 50% 100% 50% 0% 40%
G - - 100% 0% 80%
J - - - 100% -
K - - - - 100%
A confian¸ca de um indiv´ıduo nele mesmo ser´a sempre de 100%; as intersec¸c˜oes com
um tra¸co (-) indicam que n˜ao existe uma rela¸c˜ao de confian¸ca entre os n´os.
5.2 Grupos sociais
Grupo social ´e um conjunto de indiv´ıduos onde suas atividades se relacionam
mutuamente de forma sistem´atica para um determinado fim. Ou seja, um grupo deve ser
concebido como um sistema cujas partes se inter-relacionam [Gra76].
Os grupos sociais s˜ao formados por indiv´ıduos que tenham interesses comuns (com-
puta¸c˜ao, futebol, etc.) e est˜ao em constante renova¸c˜ao (grupos dinˆamicos) [Wei82]. Como
por exemplo: grupo de amigos, equipe de trabalho, colegas de turma, time de fute-
bol, entre outros. Quando a forma¸c˜ao desses grupos for realizada de forma volunt´aria e
pr´eviamente planejada, o grupo dever´a ser chamado de “Grupo Organizado” [Wei82].
A confian¸ca em grupos sociais define quanto um grupo confia em um determinado
indiv´ıduo ou em outros grupos. Cada participante do grupo dever´a expressar sua opini˜ao
para gerar um consenso entre todos eles. Este consenso ´e utilizado para aceitar ou rejeitar
novos participantes, excluir participantes ativos
1
, etc.
Integrantes de grupos sociais s˜ao capazes de compartilhar informa¸c˜oes de interesse
comum, fazendo com que essa informa¸c˜ao seja propagada entre os demais integrantes. Os
integrantes tamb´em utilizam a confian¸ca do grupo para iniciar e manter relacionamento
com outros indiv´ıduos.
1
Participantes ativos s˜ao aqueles que est˜ao em constante comunica¸c˜ao com o grupo.
46
Um indiv´ıduo pode possuir um ou mais grupos dependendo de suas necessidades/e-
specialidades. Atrav´es deste indiv´ıduo, integrantes de outros grupos s˜ao capazes de se co-
municar e trocar informa¸c˜oes de interesse comum, ou ent˜ao unificar os grupos formando
um grupo maior e mais forte.
5.2.1 Composi¸c˜ao dos grupos sociais
A composi¸c˜ao dos grupos sociais ´e definida a partir de um conjunto de fatores
que influenciam diretamente na comunica¸c˜ao dos indiv´ıduos. Estudos realizados em seres
humanos por meio de inqu´eritos “sociom´etricos” evidenciaram a existˆencia de la¸cos de
amizade, simpatia e antipatia que s˜ao capazes de refor¸car ou destruir a coes˜ao de um
grupo. Esses la¸cos podem ser definidos da seguinte forma [Gra76, Wei82]:
• A → B: A gosta de trabalhar com B;
• B → A: B gosta de trabalhar com A;
• A ↔ B: A gosta de trabalhar com B e B gosta de trabalhar com A (Estado Ideal);
• ←A B→: A e B se antipatizam;
• A → B, B → C e C → A: A gosta de B, B gosta de C e C gosta de A;
• A ↔ B, A ↔ C e B ↔ C: Todos gostam de todos.
Nessas pesquisas foram manipuladas independentemente a semelhan¸ca e a simpa-
tia de um estranho por outros indiv´ıduos [Gra76, Wei82]. Os indiv´ıduos foram induzidos
a acreditar que determinadas pessoas possu´ıam semelhan¸cas em comum mas que n˜ao
gostavam deles e que outras pessoas n˜ao possu´ıam semelhan¸cas em comum, mas que
gostavam deles. Quando os indiv´ıduos pesquisados classificaram a atra¸c˜ao pelos descon-
hecidos, foi constatado que a semelhan¸ca n˜ao tinha efeito sobre as classifica¸c˜oes. Isto
significa que a semelhan¸ca pode ser uma condi¸c˜ao desej´avel, mas ´e improv´avel que seja
a raz˜ao de atra¸c˜ao. A partir desses estudos gerou-se o conceito de necessidade e troca
[Gra76]:
• A teoria da necessidade diz que somos atra´ıdos por outros indiv´ıduos cuja personal-
idade complementa a nossa, ou seja, o indiv´ıduo submisso ´e atra´ıdo pelo indiv´ıduo
dominante.
• A teoria da troca trata o comportamento de um indiv´ıduo como a mercadoria e o
conhecimento como moeda. A partir da´ı, os indiv´ıduos podem investir seus conhec-
imentos e receber v´arios comportamentos em troca.
47
Tomando como exemplo uma reuni˜ao: as pessoas dispendem seu tempo falando
com um certo n´umero de pessoas diferentes, contudo, elas n˜ao podem falar com todas ao
mesmo tempo. Por isso ´e necess´ario uma sele¸c˜ao. A teoria da troca parte do princ´ıpio de
que a finalidade de um indiv´ıduo ´e maximizar os resultados e ter um dia produtivo. Nessa
teoria s˜ao ponderadas todas as v´arias recompensas contra os custos. Ao final do dia a
alternativa escolhida dever´a ser a que produza o melhor resultado calculado [Gra76].
Os integrantes dos grupos s˜ao separados por cargos e fun¸c˜oes espec´ıficas. Esses
cargos/fun¸c˜oes s˜ao definidas de acordo com os objetivos do grupo, o seu tamanho e as es-
pecialidades de cada indiv´ıduo. Como o objetivo deste estudo ´e definir de forma gen´erica
os grupos sociais, ser˜ao discutidos apenas dois tipos de integrantes: os l´ıderes e os partic-
ipantes.
L´ıderes
O l´ıder ´e uma pessoa no grupo a qual foi atribu´ıda, formal ou informalmente,
uma posi¸c˜ao de autoridade para dirigir, definir e aprovar novas regras para o grupo e
tomar decis˜oes cr´ıticas no grupo, tal como interferir em disputas de interesses entre outros
participantes.
Os l´ıderes podem ser definidos de duas formas: consenso global (por exemplo um
Presidente) ou imposi¸c˜ao (por exemplo um Imperador). Este cargo ´e desejado por todos os
integrantes do grupo caso exista um descontentamento do grupo como um todo, ou de sub-
grupos, novos candidatos poder˜ao reivindicar o cargo (atrav´es de vota¸c˜ao ou imposi¸c˜ao),
havendo assim uma disputa entre o l´ıder atual e um ou mais candidatos [RB56].
Participantes de um grupo
Como o pr´oprio nome diz, participantes de um grupo s˜ao indiv´ıduos que fazem
parte de um grupo. A comunica¸c˜ao entre os diversos participantes, visando o interesse
comum e a confian¸ca que um indiv´ıduo tem com o outro formam os grupos sociais.
Exclus˜ao de integrantes
A exclus˜ao de integrantes define o modo com que um participante de um determi-
nado grupo social deixar´a de fazer parte do mesmo, sendo de extrema importˆancia nos
grupos sociais, pois mant´em a comunica¸c˜ao dos integrantes sempre ativa e tenta diminuir
as discordˆancias e intrigas dentro do grupo. Existem basicamente duas formas de um
indiv´ıduo ser exclu´ıdo de um grup o social:
• volunt´aria: onde o indiv´ıduo deixa de se comunicar com integrantes do grupo du-
48
rante um determinado tempo (participante inativo);
• imposi¸c˜ao: onde o grupo decide expulsar um integrante do grupo. Esta exclus˜ao
ocorre geralmente porque o indiv´ıduo n˜ao se adequou ao grupo, n˜ao corresponde `as
expectativas ou por gerar discordˆancia e descontentamento dos demais integrantes.
A exclus˜ao por imp osi¸c˜ao dever´a ser feita utilizando o consenso do grupo. Quando
um indiv´ıduo desconfiar de outro, ele dever´a convencer a maioria dos membros para que
a pessoa “n˜ao confi´avel” seja exclu´ıda do grupo. O problema neste modelo de exclus˜ao
´e que indiv´ıduos mal-intencionados s˜ao capazes de excluir indiv´ıduos confi´aveis, fazendo
com que os demais participantes vejam ele como n˜ao-confi´avel.
Representa¸c˜ao gr´afica
Os grupos sociais podem ser representados a partir de um grafo (tamb´em chamado
de “
´
Atomo Social” [Wei82]), onde os n´os s˜ao os integrantes e as arestas s˜ao as liga¸c˜oes
entre os indiv´ıduos. A figura 5.5 apresenta um exemplo de um grupo social representado
por um grafo.
Figura 5.5:
´
Atomo Social [Wei82]
Neste figura, todos os integrantes do grupo possuem relacionamento entre si. Isto
´e uma rela¸c˜ao desej´avel, mas n˜ao necess´aria, visto que quanto maior for o grupo menor a
chance de todos os integrantes do grupo se conhecerem. Contudo, utilizando o relaciona-
mento de outros integrantes do grupo ´e poss´ıvel chegar a qualquer outro participante do
grupo (ver se¸c˜ao 5.3).
5.2.2 Rela¸c˜ao entre grupos
Grupos com os mesmos interesses ou com participantes em comum podem se fundir
formando um ´unico grupo maior e mais forte. Quando um determinado grupo come¸ca a se
49
expandir demais surgem descontentamentos que podem ocasionar rebeli˜oes. Para conter
esses problemas os grupos dividem-se novamente s´o que desta vez ser˜ao formados sub-
grupos ao inv´es de grupos independentes, como por exemplo Pa´ıses, Estados, Munic´ıpios,
etc. Esses sub-grupos s˜ao comandados por l´ıderes que devem respeitar a cadeia hier´arquica
(confian¸ca hier´arquica), vista na figura 5.8.
Figura 5.6: Um exemplo de ´arvore hier´arquica
Nesta figura pode ser vista a representa¸c˜ao hier´arquica do pode executivo em uma
democracia, onde o Presidente ´e o posto mais alto, seguido por Governador e Prefeito.
A rela¸c˜ao entre diversos grupos pode ser representada atrav´es de um grafo, onde o rela-
cionamento entre os grupos se d´a atrav´es de indiv´ıduos comuns. A figura 5.7 apresenta a
representa¸c˜ao do relacionamento de grupos sociais.
Nesta figura s˜ao mostrados trˆes grupos onde participantes possuem uma rela¸c˜ao de
confian¸ca. O Grupo 1 est´a interligado com o Grupo 2 atrav´es de um indiv´ıduo comum.
Este indiv´ıduo ser´a o elo entre os dois grupos. O Grupo 3 n˜ao possui liga¸c˜oes com os
demais grupos, contudo, novas conex˜oes s˜ao poss´ıveis, basta existir interesse entre um ou
mais indiv´ıduos de grupos diferentes.
50
Figura 5.7: Relacionamento entre grupos sociais
5.3 Redes de relacionamento
A palavra relacionamento pode ser definida como um padr˜ao de intera¸c˜ao entre
dois indiv´ıduos baseado em percep¸c˜oes rec´ıprocas. J´a as redes de relacionamento s˜ao todos
os relacionamentos “tecidos” por um indiv´ıduo, ou seja, o conv´ıvio de um determinado
indiv´ıduo com pessoas que este conhece ou conheceu [WOB76]. Essa teia pode ser formada
tamb´em por conhecidos de conhecidos e assim por diante; a partir dela ´e poss´ıvel caminhar
pelos n´os conhecidos at´e chegar a um objetivo final.
As redes de relacionamento s˜ao utilizadas pelas pessoas para interagir com outras
pessoas ou ent˜ao chegar at´e um indiv´ıduo qualquer. Por exemplo: Maria conhece Jo˜ao
e n˜ao conhece Antˆonio; Jo˜ao conhece Antˆonio. Para Maria chegar a Antˆonio ela dever´a
utilizar a sua rede de relacionamento que ´e capaz de chegar at´e Jo˜ao. Utilizando Jo˜ao como
ponte, Maria ser´a capaz de conhecer Antˆonio. Assim como Maria chegou at´e Antˆonio, ela
poderia chegar a qualquer pessoa que fizesse parte da sua rede de relacionamento.
Cada indiv´ıduo possui sua pr´opria rede de relacionamento. Essas redes est˜ao in-
terligadas atrav´es de n´os que fazem parte de redes de relacionamento comuns. Os dados
de uma rede de relacionamento s˜ao representados em uma matriz, onde a linhas da po-
dem ser casos, assuntos ou observa¸c˜oes. As colunas s˜ao informa¸c˜oes que descrevem o
relacionamento entre os indiv´ıduos. Como por exemplo:
51
Tabela 5.3: Matriz de atributos
Sexo Idade Interesse
Jo˜ao Masculino 23 Esporte
Maria Feminino 21 Computa¸c˜ao
Antˆonio Masculino 35 Esporte
Todos os dados de uma rede de relacionamento est˜ao focados em cada indiv´ıduo
e em suas rela¸c˜oes com outros indiv´ıduos de sua rede. Por este motivo os indiv´ıduos
n˜ao podem ser observados independentemente. Isto significa que quando um indiv´ıduo
for escolhido para verificar suas preferˆencias/afinidades, todos os outros indiv´ıduos que
fazem parte de sua rede de relacionamento tamb´em dever˜ao ser analisados, fazendo com
que esses m´etodos utilizem o consenso de uma rede ao inv´es de observa¸c˜oes simples.
As redes poder˜ao ser analisadas de uma forma “micro” ou “macro”, isto ´e, como
uma determinada rede est´a ligada a outras redes, ´e poss´ıvel analisar um estado que abrange
uma rede grande/global (macro) ou uma rede pequena/local (micro). A abordagem a ser
escolhida depende do tipo de informa¸c˜ao que queremos coletar. A seguir s˜ao apresentados
os modelos e liga¸c˜oes de redes, conforme descrito em [Han98].
• M´etodo de redes completo: m´etodo que procura informa¸c˜oes em cada uma das
conex˜oes de um indiv´ıduo de uma rede. Esse m´etodo cria um consenso entre todas
as liga¸c˜oes de uma determinada popula¸c˜ao. Dependendo do tamanho da rede ele
se torna computacionalmente invi´avel, pois ´e imposs´ıvel visitar todos os indiv´ıduos
de uma rede em um curto espa¸co de tempo. Como por exemplo: um indiv´ıduo A
pertencente a um grupo de amigos composto por A, B, C, D e E quer saber qual ´e a
cor de olhos predominante em seu grupo de amigos. Para isto, ele dever´a perguntar
a todos os integrantes do grupo e gerar a m´edia de cada uma das cores.
• M´etodo Snowball: inicia com um indiv´ıduo ou um conjunto de indiv´ıduos. A
partir da´ı, cada indiv´ıduo “visitado” informa os participantes que fazem parte da
sua rede. Este processo continua at´e que n˜ao existam mais indiv´ıduos a serem
visitados ou atrav´es de uma condi¸c˜ao de parada. O m´etodo Snowball n˜ao garante
que ser˜ao localizados todos os indiv´ıduos conectados a uma determinada rede. Como
por exemplo: um indiv´ıduo A pertencente a um grupo de amigos composto p or A,
B, C, D e E quer saber quem da fam´ılia de cada grupo at´e a quarta gera¸c˜ao possui
olhos azuis. Todos os integrantes dever˜ao fazer a mesma pergunta recursivamente
diminuindo uma gera¸c˜ao. Cada indiv´ıduo dever´a retornar o resultado da pergunta
para o indiv´ıduo A.
52
• Redes Ego-Cˆentricas (com conex˜oes alternadas): seleciona um conjunto de
n´os iniciais (egos) e identifica todas as conex˜oes de cada n´o selecionado. Em seguida
determina quais n´os est˜ao conectados entre si. Por fim, ele visita cada n´o selecionado
que possuem conex˜oes comuns e caminha entre esses n´os (similar ao Snowball).
Os dados coletados pelo m´etodo de redes Ego-Cˆentricas podem ser definidos como
conjuntos de micro-redes, por isso, propriedades como distˆancia (caminho a ser
percorrido para chegar em um determinado n´o), centralidade (identifica se um n´o
´e um n´o que possui muitas conex˜oes) e tipos de equivalˆencia posicional (posi¸c˜ao de
um determinado n´o ´e equivalente a de outro n´o) n˜ao podem ser obtidos por esta
abordagem. Como por exemplo: um indiv´ıduo A quer determinar um conjunto de
pessoas que tem amigos em comuns a ele em sua escola.
• Redes Ego-Cˆentricas (apenas ego): est´a focada no indiv´ıduo. Coleta in-
forma¸c˜oes nas conex˜oes de indiv´ıduos conectados para cada n´o inicial (ego). Uti-
lizando as redes ego-cˆentricas ´e poss´ıvel ter a vis˜ao da rede “local” e tamb´em da
vizinhan¸ca de cada n´o. Esta abordagem permite que seja poss´ıvel entender como
as redes de relacionamento afetam um n´o individualmente, como tamb´em d´a uma
vis˜ao geral da rede como um todo. Como por exemplo: um indiv´ıduo A quer iden-
tificar cada uma das conex˜oes com la¸cos de amizade como “parentes”, “amigo de
trabalho”, “membro da mesma igreja”, etc. A pode gerar ent˜ao uma vis˜ao geral
de posi¸c˜oes sociais (ao inv´es de redes de indiv´ıduos), no qual os indiv´ıduos est˜ao
inseridos.
5.3.1 Escalas de medidas
As redes de relacionamento permitem que os dados coletados possam ser men-
surados utilizando diferentes n´ıveis (escalas) de medida. Essas escalas s˜ao importantes
pois atrav´es delas ´e poss´ıvel limitar um conjunto de quest˜oes a serem examinadas pelo
“pesquisador”. Al´em disso, ´e poss´ıvel utilizar na an´alise dos dados coletados diferentes
tipos de escala de acordo com as propriedades matem´aticas dos dados (possibilidade de se
utilizar algoritmos de an´alise diferentes). A seguir s˜ao apresentadas as principais escalas
de medida para dados de redes sociais, conforme descrito em [Han98]:
• Medidas bin´arias de rela¸c˜oes: possuem apenas dois n´ıveis de medida (0 ou
1). Como por exemplo: Definir se um determinado indiv´ıduo gosta de um outro
indiv´ıduo qualquer ou n˜ao. A resposta dever´a ser “sim” ou “n˜ao”. Muitas teorias
de grafos foram desenvolvidas utilizando medidas bin´arias;
53
• Medidas de m´ultipla-categoria nominal: possuem v´arios n´ıveis de medida.
Como por exemplo: Descrever a rela¸c˜ao de um determinado indiv´ıduo de acordo
com a seguinte lista: amigo, namorado ou relacionamento de trabalho. A resposta
dever´a ser uma das listadas anteriormente. Este tipo de escala ´e qualitativa; ao
contr´ario das medidas bin´arias, a medida qualitativa permite m´ultiplas escolhas;
• Medidas ordinais: visam medir um determinado indiv´ıduo de acordo com o grupo.
Como por exemplo: Descobrir quantas pessoas gostam e quantas pessoas n˜ao gostam
de um determinado indiv´ıduo. As respostas ter˜ao a forma “0 ou mais gostam” ou
“0 ou mais n˜ao gostam”. Esta abordagem mede os diferentes aspectos quantitativos
de uma rela¸c˜ao;
• Medidas ordinais por rank completo: visam definir um ranking para um con-
junto de indiv´ıduos de acordo com o grupo. Como por exemplo: Pedir para um
determinado indiv´ıduo escrever em uma lista de nomes o n´umero “1” ao lado da
pessoa que mais gosta; o n´umero “2” ao lado da segunda pessoa que mais gosta e
assim por diante. Este tipo de escala dever´a resultar um “rank completo ordenado”.
Tal escala reflete em diferentes graus de intensidade, mas n˜ao necessariamente em
diferen¸cas de igualdade, isto ´e, a diferen¸ca entre a primeira e a segunda escolha n˜ao
´e necessariamente a mesma diferen¸ca entre a segunda e a terceira escolha. Contudo,
cada rela¸c˜ao ´e ´unica (primeiro, segundo, terceiro, etc).
• Medidas escalares: definem uma escala de medida. Como por exemplo: Definir
quanto um indiv´ıduo gosta de outro indiv´ıduo. A resposta dever´a ser de dada de
acordo com a medida de escala convencionada pelos indiv´ıduos.
5.4 Algoritmos de confian¸ca/desconfian¸ca e reputa¸c˜ao
Confian¸ca ´e a perspectiva subjetiva que um indiv´ıduo tem sobre outros a partir
dos hist´oricos de seus encontros, desconfian¸ca ´e a d´uvida sobre a honestidade de um
indiv´ıduo e reputa¸c˜ao ´e a percep¸c˜ao que os indiv´ıduos criam uns dos outros a partir de
suas a¸c˜oes passadas, de acordo com as inten¸c˜oes e normas, onde normas s˜ao heur´ısticas
definidas a partir de pressupostos morais que os indiv´ıduos seguem no decorrer de suas
vidas [MMH02, Ost98].
Os algoritmos de confian¸ca e reputa¸c˜ao s˜ao algoritmos desenvolvidos para tentar
“simular” a confian¸ca de seres humanos em redes de relacionamento. Todos utilizam
m´etodos de propaga¸c˜ao das informa¸c˜oes de integrantes de uma rede centralizada para
54
gerar um consenso global da confian¸ca e reputa¸c˜ao de cada um dos integrantes da rede.
Nesta se¸c˜ao ser˜ao apresentados os algoritmos de confian¸ca e reputa¸c˜ao propostos por
[GKRT04] e [KSGM03] respectivamente.
5.4.1 Propaga¸c˜ao de confian¸ca e desconfian¸ca
O estudo de propaga¸c˜ao de confian¸ca e desconfian¸ca proposto por [GKRT04], cria
uma framework que faz uso das redes de relacionamento para predizer com um certo
grau de precis˜ao a confian¸ca entre dois indiv´ıduos. Segundo os autores, este trabalho foi
o primeiro a incorporar tanto a confian¸ca quanto a desconfian¸ca de indiv´ıduos em um
sistema computacional de propaga¸c˜ao de confian¸ca.
Neste estudo, os autores criaram um universo de “n” indiv´ıduos capazes de ex-
pressar n´ıveis de confian¸ca e desconfian¸ca para qualquer outro indiv´ıduo da rede. Esses
valores de confian¸ca e desconfian¸ca foram divididos em duas matrizes: T (confian¸ca) e D
(desconfian¸ca), onde t
ij
representa a confian¸ca de um usu´ario i em j (esses valores podem
ser 0 ou 1) e d
ij
representa a desconfian¸ca de um usu´ario i em j. Al´em disso, foi proposta
uma matriz B que representa um conjunto de cren¸cas de um indiv´ıduo em outros, onde
b
ij
pode ser tanto a confian¸ca de i em j quanto a combina¸c˜ao das confian¸cas de i em j. A
informa¸c˜ao ´e propagada utilizando m´etodos de propaga¸c˜ao atˆomica, onde em uma ´unica
etapa ´e poss´ıvel indicar que um indiv´ıduo i confia em k. Por exemplo, se i confia em j e j
confia em k, ent˜ao j dever´a informar a i a confian¸ca dele em k.
Propaga¸c˜ao atˆomica
A propaga¸c˜ao atˆomica define o modelo de comunica¸c˜ao de dois indiv´ıduos uti-
lizando propriedades transitivas para definir a confian¸ca em um terceiro indiv´ıduo. Exis-
tem quatro tipo de propaga¸c˜ao atˆomica:
• Propaga¸c˜ao direta - B: se B
ij
= 1 (i confia em j) e B
jk
= 1 (j confia em k), ent˜ao
a propaga¸c˜ao atˆomica deve possibilitar que i confie em k;
• Co-cita¸c˜ao - B
T
B: suponha que i
1
confia em j
1
e em j
2
e que i
2
confia em j
2
.
Utilizando a co-cita¸c˜ao ´e poss´ıvel concluir que i
2
poder´a confiar em j
1
. A seq¨uˆencia
B
T
B pode ser vista como uma etapa de propaga¸c˜ao “voltando - avan¸cando”, onde
i
2
confia em j
2
que ´e capaz de voltar para i
1
para ent˜ao chegar em j
1
. A figura a
seguir apresenta o grafo que representa esta propaga¸c˜ao atrav´es de co-cita¸c˜ao;
55
Figura 5.8: Exemplo de co-cita¸c˜ao
• Confian¸ca transposta - B
T
: se i confia em j ent˜ao j dever´a desenvolver algum
n´ıvel de confian¸ca em i;
• Acoplamento de confian¸ca - BB
T
: a confian¸ca de i em j ´e propagada para k,
porque j e k confiam em pessoas comuns.
Supondo que α = (α
1
, α
2
, α
3
, α
4
) seja o vetor que representa os pesos das quatro
combina¸c˜oes de propaga¸c˜ao, ent˜ao ´e poss´ıvel definir todas as propaga¸c˜oes atˆomicas em
uma ´unica matriz de cren¸ca C
B,α
, com um vetor de peso α. Esta matriz de cren¸ca pode
ser expressa da seguinte forma:
C
B,α
= α
1
B + α
2
B
T
B + α
3
B
T
+ α
4
BB
T
Esta matriz ser´a utilizada na propaga¸c˜ao de cren¸ca e descren¸ca descrita a seguir.
Propaga¸c˜ao de confian¸ca e desconfian¸ca
O objetivo da propaga¸c˜ao de confian¸ca e desconfian¸ca ´e gerar uma matriz F que
possa indicar a confian¸ca/desconfian¸ca entre dois n´os distintos em uma rede. O resultado
final ser´a gerado a partir das seguintes etapas:
1. Gerar a matriz F seguindo as etapas a seguir:
(a) Propaga¸c˜ao de desconfian¸ca: Supondo que C
B,α
seja uma matriz onde a ij-
´esima entrada descreva a cren¸ca de i para j atrav´es da propaga¸c˜ao atˆomica;
se a entrada for 0, ent˜ao n˜ao ´e poss´ıvel concluir como i enxerga j. Supondo
que k seja um inteiro positivo e supondo que P
(k)
seja a matriz onde ij-´esima
entrada representa a propaga¸c˜ao de i para j ap´os a propaga¸c˜ao atˆomica de k,
ser´a poss´ıvel chegar a uma nova matriz de cren¸ca B ap´os k passos. Isto significa
56
que a repeti¸c˜ao de propaga¸c˜ao de confian¸ca pode ser representada a partir de
uma opera¸c˜ao P
(k)
. S˜ao propostos trˆes modelos para definir B e P
(k)
para a
propaga¸c˜ao de confian¸ca e desconfian¸ca, a partir de uma matriz de confian¸ca
T ou desconfian¸ca T:
Apenas confian¸ca: ignora a desconfian¸ca completamente. Neste caso obt´em-
se que B = T e P
(k)
= C
B,α
.
Um-passo de desconfian¸ca: assume-se que quando um usu´ario desconfia de
algu´em, ele dever´a descontar todos os julgamentos feitos por aquela pessoa. Ou
seja, a desconfian¸ca ´e propagada em apenas um passo, enquanto a confian¸ca
pode ser propagada repetidamente. Neste caso obt´em-se que B = T e P
(k)
=
C
B,α
∗ (T − D).
Desconfian¸ca propagada: assume-se que tanto a confian¸ca quanto a descon-
fian¸ca dever˜ao ser propagadas juntas. Neste caso obt´em-se que B = T − D e
P
(k)
= C
B,α
.
(b) Propaga¸c˜ao interativa: Depois de definido o algoritmo de propaga¸c˜ao de de-
sconfian¸ca, ´e poss´ıvel gerar a matriz F que representa as conclus˜oes que qual-
quer indiv´ıduo dever´a ter sobre um outro, utilizando dois algoritmos:
EIG (Eigenvalue Propagation): sendo K o n´umero de itera¸c˜oes, ent˜ao a
matriz final ser´a gerada atrav´es de
F = P
(k)
WLC (Weighted Linear Combination ): supondo que γ seja uma con-
stante e que K seja um valor apropriado escolhido, ent˜ao a matriz final ser´a
gerada atrav´es de
F =
K
k=1
γ
k
∗ P
(k)
2. Coletar os resultados interpretando os valores de F para gerar a confian¸ca e descon-
fian¸ca. Esses resultados dever˜ao informar se um indiv´ıduo pode ou n˜ao confiar em
outro. Este procedimento dever´a utilizar um dos algoritmos a seguir:
(a) Arredondamento Global: tenta alinhar a taxa dos valores de confian¸ca e de-
sconfian¸ca em F para uma entrada qualquer. Considere o vetor F
i
, onde i
dever´a confiar em j se e somente se F
ij
estiver acima da fra¸c˜ao de uma entrada
x do vetor F
i
. Como por exemplo:
57
Sendo F
i
=
1
2
2
3
4
sendo a i-´esima coluna da matriz F =
3 1 3
7 2 5
... 8 2 2 ...
5 3 0
1 4 4
o ponto inicial requisitado x igual a 3 e F
ij
sendo o segundo elemento de F
i
, ´e
poss´ıvel concluir que F
ij
est´a acima da fra¸c˜ao x, conseq¨uentemente i confia em
j.
(b) Arredondamento Local: similar ao arredondamento local. Contudo, o ponto
inicial x deve ser escolhido atrav´es de julgamentos de pontos confi´aveis vs
desconfi´aveis feitos por i.
(c) Arredondamento da Maioria: utiliza um conjunto de indiv´ıduos para gerar a
confian¸ca final a partir do arredondamento local. Ou seja, ele utiliza a m´edia de
todas as suas confian¸cas geradas a partir do arredondamento local para gerar
a confian¸ca final de um indiv´ıduo.
5.4.2 EigenTrust: algoritmo de gerenciamento de reputa¸c˜ao em redes peer-to-peer
O EigenTrust [KSGM03] ´e um algoritmo de gera¸c˜ao de reputa¸c˜ao de n´os desen-
volvido para diminuir o n´umero de downloads de arquivos n˜ao autˆenticos em redes P2P
(Peer-To-Peer). O EigenTrust define um m´etodo distribu´ıdo e seguro para computar val-
ores de confian¸ca global baseados no poder de intera¸c˜ao. Os valores de reputa¸c˜ao global
s˜ao calculados atrav´es de valores de confian¸ca local que cada n´o da rede define para outros
n´os. Este algoritmo define alguns passos que devem ser seguidos para seu funcionamento.
O primeiro passo do Eigentrust ´e normalizar os valores locais de confian¸ca em
uma forma simples de ser interpretada probabilisticamente, do contr´ario, n´os maliciosos
poder˜ao atribuir arbitrariamente valores de confian¸ca alto para outros n´os maliciosos e
valores baixos para n´os bons. Esta normaliza¸c˜ao dever´a disponibilizar um valor ´unico de
confian¸ca de i para j. A f´ormula de normaliza¸c˜ao ´e:
c
ij
=
max(s
ij
, 0)
j
max(s
ij
, 0)
O segundo passo ´e agregar todos os valores de confian¸ca local normalizados de
58
cada n´o da rede P2P. Esta agrega¸c˜ao ser´a realizada por um n´o n
i
que deseja criar uma
confian¸ca global em um n´o n
j
. O n
i
far´a requisi¸c˜oes de confian¸ca a outros n´os perguntando
qual a confian¸ca deles em n
j
. O n´o n
i
dever´a utilizar a seguinte f´ormula:
t
ik
=
j
c
ij
c
jk
onde t
ik
representa a confian¸ca que o n´o n
i
deposita no n´o n
k
baseado nas perguntas feitas
a um grupo de confian¸ca. Outra forma de se escrever esta rela¸c˜ao ´e atrav´es de nota¸c˜ao
de matriz. Se C define a matriz |c
ij
| e
−→
T
i
´e o vetor que cont´em os valores de t
ik
. Ent˜ao:
−→
t
i
= C
T
−→
c
i
Mas esta vis˜ao ainda n˜ao considera todos os relacionamentos de outros n´os da rede.
Para n
i
criar uma vis˜ao geral da rede, ´e proposta uma f´ormula que faz com que n
i
seja
capaz de perguntar para os amigos de seus amigos sobre a confian¸ca que eles tˆem em um
determinado n´o:
−→
t
i
= (C
T
)
n
−→
c
i
onde n indica a quantidade de amigos de amigos a serem pesquisados. Ao final de n
intera¸c˜oes o n´o n
i
dever´a possuir uma vis˜ao completa sobre a rede e sobre o vetor
−→
t . A
distribui¸c˜ao estacion´aria da cadeia de Markov definida pela matriz C de confian¸ca local
normalizada ´e a confian¸ca global de um n´o na rede. Esta confian¸ca global ´e definida a
partir do vetor
−→
t .
O terceiro passo ´e definir como o vetor
−→
t ser´a calculado:
EigenTrust B´asico
O EigenTrust B´asico ignora a natureza distribu´ıda das redes P2P assumindo que
existe um servidor central que conhece todos os valores c
ij
e executa toda a computa¸c˜ao.
Utilizando este algoritmo deseja-se computar apenas
−→
t = (C
T
)
n
−→
e , para n=grande, onde
−→
e ´e um vetor m representando uma probabilidade de distribui¸c˜ao uniforme sobre todos
59
os n´os e
i
= 1/m. O algoritmo pode ser visto a seguir:
−→
t
(0)
=
−→
e ;
repeat
−→
t
(k+1)
= C
T
−→
t
(k)
;
δ =|
−→
t
(k+1)
−
−→
t
(k)
|;
until δ < ε;
Existem trˆes melhorias a serem realizadas neste algoritmo visando uma maior
confiabilidade de cada n´o.
• n´os pr´e-confi´aveis: alguns n´os da rede devem ser naturalmente confi´aveis, tais
como n´os iniciais de uma rede P2P;
• n´os inativos: se um n´o n
i
n˜ao executa mais downloads ou se este n´o atribui valores
zero a todos os outros n´os, ele dever´a ser descartado;
• maliciosos coletivos: grupos de n´os que disponibilizam informa¸c˜oes n˜ao confi´aveis,
fazendo com que se torne dif´ıcil confiar em outros n´os da rede. Estes grupos devem
ser identificados e ignorados.
EigenTrust distribu´ıdo
Para prover as melhorias apontadas anteriormente, os autores propuseram o Eigen-
Trust distribu´ıdo, onde cada n´o da rede coopera para computar e armazenar o vetor de
confian¸ca global. Cada n´o pode computar sua pr´opria confian¸ca global a partir da seguinte
f´ormula:
−→
t
(k+1)
= (1 − α)(c
1i
t
(k)
1
+ ... + c
ni
t
(k)
n
) + αp
i
onde p
i
= 1/|P | se i pertence a P (conjunto de n´os pr´e-confi´aveis); p
i
= 0 do contr´ario.
O algoritmo a seguir apresenta o EigenTrust distribu´ıdo.
foreach peer i do
Query all peers j end A
i
fort
(0)
j
= p
j
;
repeat
Compute
−→
t
(k+1)
= (1 − α)(c
1i
t
(k)
1
+ ... + c
ni
t
(k)
n
) + αp
i
Send c
ij
t
(k+1)
i
to all peers j ∈ B
i
;
Compute δ =| t
(k+1)
i
− t
(k)
i
|;
60
W ait f or all peersj ∈ A
i
to return c
ij
t
(k+1)
i
;
until δ < ε;
end
Neste algoritmo cada n´o n
i
computa e reporta seu pr´oprio valor de confian¸ca t
i
.
N´os maliciosos podem facilmente reportar valores de confian¸ca falsos, manipulando o
sistema.
EigenTrust seguro
Para resolver os problemas de usu´arios maliciosos, os autores prop˜oem utilizar mais
de um n´o para computar os valores de confian¸ca. Esses n´os s˜ao chamados de gerenciadores
de escore. Cada n´o da rede deve possuir um n´umero M de gerenciadores de escore.
A posi¸c˜ao desses gerenciadores ´e oculta utilizando uma tabela hash distribu´ıda DHT
(Distributed Hash Table). Por fim, o seguinte algoritmo foi proposto:
foreach peer i do
Submit local tr ust values
−→
c
i
to all score managers at positions
h
m
(pos
i
), m = 1...M − 1;
Collect local trust values
−→
c
d
and
sets of acquaintances B
d
i
of daughter peers d ∈ D
i
;
Submit daughter d‘s local trust values c
dj
to
score managers h
m
(pos
d
), m = 1...M − 1, ∀ j ∈ B
i
d
;
Collect acquaintances A
d
i
of daughter peers;
foreach daugter peer d ∈ D
i
do
Query all peers j ∈ A
i
d
for c
jd
p
j
;
repeat
Compute t
(k+1)
d
= (1 − α)(c
1d
t
(k)
i
+ c
2d
t
(k)
2
+ ... + c
nd
t
(k)
n
) + αp
d
;
Send c
dj
t
(k+1)
d
to all peers j ∈ B
i
d
;
W ait for all peers j ∈ A
i
d
to return c
jd
t
(k+1)
j
;
until | t
(k+1)
d
− t
(k)
d
|< ε;
end
end
Neste algoritmo s˜ao definidos gerenciadores de escore que s˜ao respons´aveis por
disponibilizar informa¸c˜oes dos n´os que eles gerenciam. Todos os n´os que n˜ao forem geren-
ciadores de escore (tamb´em chamados de n´os daughter) dever˜ao definir um ou mais geren-
ciadores de escore padr˜ao, que ser˜ao respons´aveis por disponibilizar as informa¸c˜oes deste
n´o para a rede. Cada gerenciador de escore dever´a armazenar informa¸c˜oes sobre todos
os n´os que fazem uso dele e armazenar informa¸c˜oes sobre os pontos que baixam arquivos
dos n´os daughter.
Utilizando esta abordagem, garante-se que apenas n´os gerenciadores de escore
poder˜ao propagar a confian¸ca pela rede, fazendo com que n´os maliciosos n˜ao sejam capazes
de votar.
5.5 Conclus˜ao
Neste cap´ıtulo foram abordadas a confian¸ca hier´arquica (fundamental para o in-
div´ıduo), os grupos sociais (base de todas as sociedades) e redes de relacionamento (rela-
cionamento tecido no decorrer da vida de um indiv´ıduo). Foi apresentado ainda o algo-
ritmo de propaga¸c˜ao de confian¸ca e desconfian¸ca [GKRT04] e o algoritmo do EigenTrust
[KSGM03] que tem como objetivo gerar um sistema de reputa¸c˜ao para n´os (peers) em
redes P2P.
O modelo de confian¸ca dos seres humanos pode ser muito ´util em aplica¸c˜oes de
redes, visto que o ambiente, tanto humano quanto computacional possuem caracter´ısticas
parecidas. No pr´oximo cap´ıtulo ser´a apresentada a proposta do trabalho, que procura
utilizar alguns m´etodos apontados neste cap´ıtulo para gerar um sistema de confian¸ca
distribu´ıda em sistemas de e-mail.
Cap´ıtulo 6
Um sistema de confian¸ca entre servidores de e-
mail
A principal deficiˆencia no que tange os problemas apresentados no cap´ıtulo 3,
reside na falta de um mecanismo robusto de autentica¸c˜ao e reputa¸c˜ao de dom´ınios de
servidores de e-mail. Spammers e fraudadores utilizam t´ecnicas de envio de e-mail em
massa para propagar v´ırus e mensagens indesej´aveis atrav´es da rede, tentando enganar
usu´arios, persuadindo-os a fornecer informa¸c˜oes sens´ıveis (senha de banco, n´umero de
cart˜ao de cr´edito, etc) que possam ser utilizadas em benef´ıcio do pr´oprio fraudador.
T´ecnicas de detec¸c˜ao de spam, detec¸c˜ao de v´ırus, black lists, white lists , entre
outras, est˜ao sendo empregadas na conten¸c˜ao de e-mails maliciosos, contudo elas s˜ao
estritamente locais, o que dificulta a propaga¸c˜ao de informa¸c˜oes de spammers pela rede.
Outra maneira de se conseguir informa¸c˜oes sobre spammers s˜ao as RBLs, listas globais
que armazenam informa¸c˜oes (tais como dom´ınio e IP) sobre servidores maliciosos. Essas
listas s˜ao centralizadas em um ´unico ponto, possibilitando ataques do tipo DoS e DDoS.
Al´em disso, essas listas devem ser constantemente atualizadas, tornando-as dif´ıceis de
serem mantidas.
T´ecnicas de autentica¸c˜ao de servidores de e-mail e remetente est˜ao sendo estu-
dadas para limitar a propaga¸c˜ao de mensagens enviadas por fraudadores (diminuindo sua
atua¸c˜ao na rede), partindo do princ´ıpio que os spammers fazem uso de programas que
geram remetentes de forma aleat´oria. Essas abordagens continuam falhas, pois mesmo
que um dom´ınio tenha sido autenticado, nada impede que seus usu´arios continuem en-
viando/propagando informa¸c˜oes maliciosas pela rede.
Este cap´ıtulo apresenta a proposta do trabalho e est´a dividido da seguinte forma:
a se¸c˜ao 6.1 apresenta uma vis˜ao geral sobre a proposta do trabalho; a se¸c˜ao 6.2 apresenta
uma vis˜ao da arquitetura do sistema; a se¸c˜ao 6.3 apresenta o modelo de gerˆencia de con-
fian¸ca; a se¸c˜ao 6.4 apresenta o modelo de armazenamento do sistema; a se¸c˜ao 6.5 apresenta
63
o modelo de propaga¸c˜ao de confian¸ca entre servidores de e-mail; a se¸c˜ao 6.6 apresenta os
benef´ıcios e limita¸c˜oes da proposta; a se¸c˜ao 6.7 apresenta os trabalhos correlatos a esta
proposta; por fim, a se¸c˜ao 6.8 conclui o cap´ıtulo.
6.1 Proposta
A proposta deste trabalho ´e definir uma arquitetura que permita criar e gerenciar
listas de servidores confi´aveis e n˜ao confi´aveis de forma dinˆamica e descentralizada, uti-
lizando t´ecnicas consolidadas de classifica¸c˜ao de e-mail e autentica¸c˜ao de servidores, em
conjunto com t´ecnicas de redes de confian¸ca abordadas no cap´ıtulo 5 para propaga¸c˜ao e
gerˆencia de confian¸ca entre os servidores de e-mail.
A gerˆencia de confian¸ca deve ser utilizada para diminuir gradativamente a quanti-
dade de mensagens a serem recebidas de servidores que propagam informa¸c˜oes maliciosas,
ou seja, quanto menor a confian¸ca de um servidor receptor em um servidor emissor, menor
ser´a a quantidade de mensagens que o emissor poder´a enviar ao receptor no decorrer de
um determinado per´ıodo de tempo.
A confian¸ca de um servidor deve ser gerada a partir de c´alculos de confian¸ca e da
comunica¸c˜ao de um MTA com os integrantes de seu grupo de confian¸ca
1
. Esta confian¸ca
ser´a verificada antes que uma mensagem seja recebida pelo MTA e ser´a recalculada e
propagada aos participantes do grupo do servidor receptor antes que a mensagem seja
aceita. A partir das redes de relacionamento os servidores s˜ao capazes de trocar in-
forma¸c˜oes com outros servidores da rede, formando este modelo escal´avel, pois, qualquer
servidor que fa¸ca parte de uma rede de relacionamento ser´a indiretamente influenciado
por outros integrantes desta rede. A figura 6.1 apresenta o modelo de recebimento de
mensagens.
Quando o servidor A enviar uma mensagem ao servidor B, B utilizar´a a confian¸ca
que ele possui em A, gerada a partir de informa¸c˜oes locais (vide se¸c˜ao 6.3.1) e do seu
grupo de confian¸ca para aceitar ou rejeitar a mensagem.
A confian¸ca de cada servidor da rede deve ser propagada a outros servidores atrav´es
das redes de relacionamento. A figura 6.2 apresenta o modelo de propaga¸c˜ao de confian¸ca.
Nesta figura os quadrados representam os servidores de e-mail, os c´ırculos repre-
sentam os grupos de confian¸ca de cada servidor e as setas representam a propaga¸c˜ao de
confian¸ca. Neste exemplo, B envia a confian¸ca dele em outros servidores para C e E, que
1
Conjunto de servidores considerados confi´aveis pelo servidor.
64
Figura 6.1: Modelo de recebimento de mensagens
Figura 6.2: Modelo de propaga¸c˜ao de confian¸ca
enviam a confian¸ca deles para o seu grupo de confian¸ca e assim por diante. Todos os servi-
dores que fizerem parte da rede de relacionamento de B ser˜ao indiretamente influenciados
pela informa¸c˜ao propagada por ele.
Esta arquitetura dever´a disponibilizar um sistema de confian¸ca que ser´a capaz de
gerar a confian¸ca dos servidores nos receptores de e-mail, que ser˜ao capazes de aumentar
ou diminuir esta confian¸ca de acordo com as a¸c˜oes de cada integrante da rede de rela-
cionamento. A partir desta confian¸ca, os servidores de e-mail poder˜ao limitar/aceitar
uma quantidade de mensagens a serem recebidas, visando a diminui¸c˜ao do tr´afego de
mensagens indesejadas (que degradam os servi¸cos de e-mail) pela rede.
65
6.2 Arquitetura do sistema
A arquitetura do sistema utiliza conceitos de redes de confian¸ca, descritos no
cap´ıtulo 5 em conjunto com ferramentas anti-spam, ferramentas anti-v´ırus e um mod-
elo de autentica¸c˜ao de servidores de e-mail para disponibilizar um sistema de confian¸ca
entre MTAs. Nesta arquitetura s˜ao definidos um conjunto de algoritmos para c´alculo, ar-
mazenamento e propaga¸c˜ao de confian¸ca de servidores de e-mail. O sistema de confian¸ca
funcionar´a de duas formas:
• dever´a aprender “imitando” (atrav´es de compartilhamento de confian¸ca) e seguindo
regras de acordo com um conjunto de servidores que fazem parte do seu grupo de
confian¸ca.
• dever´a aprender atrav´es de tentativa e erro, ou seja, todas as informa¸c˜oes prejudiciais
aos servi¸cos de e-mail (spam, v´ırus, etc.) ser˜ao classificadas e manipuladas e servir˜ao
de base na perda ou ganho de confian¸ca num emissor.
Para o funcionamento correto do modelo de confian¸ca, faz-se necess´aria a inclus˜ao
de alguns m´odulos nos MTAs. A figura 6.3 ilustra a arquitetura proposta.
Nesta figura est˜ao representados os componentes que dever˜ao ser implementa-
dos/integrados nos MTAs que desejam prover tal modelo de confian¸ca e o fluxo da ar-
quitetura proposta. Os componentes da proposta s˜ao:
• Servidor SMTP: respons´avel pelo recebimento das mensagens; implementa o pro-
tocolo SMTP.
• Autenticar emissor: implementa um m´etodo de autentica¸c˜ao de dom´ınio (ver
cap´ıtulo 4).
• Anti-spam: filtro anti-spam respons´avel pela classifica¸c˜ao das mensagens rece-
bidas. O resultado deste filtro ser´a utilizado pelo sistema de confian¸ca.
• Anti-v´ırus: filtro anti-v´ırus de servidor que analisa se uma mensagem cont´em um
v´ırus em seu corpo. O resultado deste filtro ser´a utilizado pelo sistema de confian¸ca.
• Sistema de confian¸ca: analisa a confian¸ca de um servidor de acordo com as a¸c˜oes
deste servidor localmente e na rede (ver se¸c˜ao 6.3).
O fluxo do sistema dever´a ser iniciado quando um emissor qualquer estabelecer uma
comunica¸c˜ao SMTP com um servidor que implementa o sistema de confian¸ca. As etapas
66
Figura 6.3: Arquitetura proposta
que ser˜ao executadas dentro do sistema de confian¸ca ser˜ao detalhadas no decorrer deste
cap´ıtulo. Quando a comunica¸c˜ao SMTP for estabelecida, o servidor de e-mail receptor
dever´a executar os seguintes passos para cada mensagem recebida:
1. Autenticar servidor. Se o servidor for corretamente autenticado, ir para o pr´oximo
passo, do contr´ario, n˜ao receber a mensagem;
2. Verificar se o servidor emissor pode enviar mensagem, consultando o sistema de
confian¸ca (dever´a retornar sim ou n˜ao). Caso a resposta seja positiva o sistema
recebe a mensagem, do contr´ario a conex˜ao ´e encerrada;
3. Submeter e-mail recebido a diversos filtros, tais como anti-spam e anti-v´ırus. Esses
filtros dever˜ao retornar se o e-mail ´e leg´ıtimo ou malicioso;
4. Enviar resultado da consulta anterior ao sistema de confian¸ca que atualiza a base
de confian¸ca;
5. Retornar ao passo 1 at´e que a conex˜ao seja encerrada.
A arquitetura foi dividida em trˆes m´odulos: gerˆencia, armazenamento e propaga¸c˜ao
de confian¸ca. A seguir ser˜ao apresentados cada um desses m´odulos.
67
6.3 Gerˆencia de confian¸ca
Os c´alculos de confian¸ca dos diversos servidores de e-mail em conjunto com regras
de aceita¸c˜ao ou nega¸c˜ao de e-mail formam o que ser´a chamado de gerˆencia de confian¸ca.
O objetivo deste m´odulo ´e definir um modelo justo de gera¸c˜ao e manuten¸c˜ao de confian¸ca
em servidores de e-mail e criar uma forma de diminuir gradativamente a quantidade de
mensagens a serem recebidas de servidores que propagam informa¸c˜oes maliciosas, ou seja,
quanto menor a confian¸ca de um servidor receptor em um servidor emissor, menor ser´a a
quantidade de mensagens que o emissor poder´a enviar ao receptor no decorrer de um dado
per´ıodo de tempo. Esta funcionalidade necessita de um modelo de medida de confian¸ca
que seja capaz de expressar o quanto um servidor confia em outro. Durante o estudo
foi constatado que as medidas que mais se adequam `a proposta (dentre as pesquisadas,
conforme apresentado na se¸c˜ao 5.3.1) s˜ao:
• bin´aria: um servidor confia ou n˜ao confia em outro servidor;
• escalar: define uma medida de escala para indicar a confian¸ca de um servidor em
outro.
Foi optado pela medida escalar pois a confian¸ca de cada servidor emissor poder´a
ser tratada de 0 a 100%, possibilitando o c´alculo da quantidade m´axima de mensagens
que cada servidor emissor poder´a enviar para um servidor receptor durante determinado
per´ıodo. A f´ormula a seguir define a quantidade m´axima de mensagens que o receptor
poder´a receber de um determinado emissor (QMS ):
QMS = QM ∗ CS
onde, QM (Quandidade de Mensagens) ´e uma vari´avel definida no sistema de confian¸ca
que indica a quantidade m´axima de mensagens que um servidor pode receber de um
emissor com 100% de confian¸ca e CS (Confian¸ca do Servidor) ´e a confian¸ca que o receptor
possui no emissor.
O QMS (Quantidade de Mensagens Servidor) ´e o n´umero de mensagens que o
servidor poder´a receber de um emissor durante o dia. A medida que as mensagens v˜ao
sendo recebidas, um CMS (Contador de Mensagens), definido no servidor para cada
emissor ser´a acrescido e o QMS ser´a recalculado. Quando o CMS for igual ao QMS a
conex˜ao ser´a interrompida e o servidor emissor n˜ao poder´a mais enviar mensagens naquele
68
dia. Todos os dias o CMS dever´a ser reiniciado para que o servidor emissor possa receber
mensagens do receptor novamente. Como p or exemplo:
Um servidor receptor A possui a confian¸ca em B igual a 30% e o QM de A ´e igual
a 500. Depois do c´alculo de QMS, o n´umero m´aximo de mensagens di´arias que o servidor
A poder´a receber de B ´e 150 mensagens.
Este modelo define uma forma justa de recebimento de mensagens, onde servi-
dores mais confi´aveis poder˜ao enviar mais mensagens que servidores menos confi´aveis.
Definido o modo com que a confian¸ca dever´a implicar no envio/recebimento de men-
sagens, o pr´oximo passo ´e definir os c´alculos de confian¸ca. Neste trabalho a medida de
confian¸ca foi dividida em trˆes medidas: local, global e final.
• Confian¸ca local: confian¸ca gerada a partir de informa¸c˜oes coletadas a partir de
comunica¸c˜oes com um determinado servidor da rede;
• Confian¸ca global : confian¸ca gerada a partir de um conjunto de servidores
confi´aveis;
• Confian¸ca final: m´edia entre a confian¸ca local e final.
6.3.1 Confian¸ca local
A confian¸ca local define o modo com que o servidor receptor aumenta ou diminui
sua confian¸ca “individual” em um determinado emissor utilizando o hist´orico de men-
sagens recebidas deste. O n´umero de mensagens a serem recebidas (QR) que influenciar˜ao
no aumento ou na diminui¸c˜ao da confian¸ca ser´a calculado a partir da seguinte f´ormula:
QR =
CS ∗ MC se a mensagem for maliciosa
(1 − CS) ∗ MC caso contr´ario
onde CS (Confian¸ca do Servidor) ´e a confian¸ca que o receptor possui no emissor e MC
(Mensagens de Confian¸ca) ´e uma vari´avel definida no sistema de confian¸ca que influenciar´a
no resultado de QR da seguinte forma:
• quanto maior a confian¸ca em um servidor, menor a quantidade necess´aria de men-
sagens leg´ıtimas para aumentar a confian¸ca e maior a quantidade necess´aria de
mensagens maliciosas para diminuir a confian¸ca;
69
• quanto menor a confian¸ca em um servidor, maior a quantidade necess´aria de men-
sagens leg´ıtimas para aumentar a confian¸ca e menor a quantidade necess´aria de
mensagens maliciosas para diminuir a confian¸ca;
O QR ser´a recalculado toda vez que o servidor receptor receber uma mensagem
e comparado com o CMLS (Contador de mensagens leg´ıtimas no servidor ) no caso de
mensagem leg´ıtima ou com o CMMS (Contador de mensagens maliciosas no servidor)
no caso de mensagem maliciosa. O CMLS ´e um contador definido no servidor para cada
emissor, que armazena o n´umero de mensagens leg´ıtimas recebidas e ´e utilizado para
aumentar a confian¸ca local (CLS ) no servidor. O CMMS ´e um contador definido no
servidor para cada emissor, que armazena o n´umero de mensagens maliciosas recebidas
e ´e utilizado para diminuir a confian¸ca local no servidor. Se a mensagem for leg´ıtima, o
servidor dever´a incrementar o CMLS em 1; quando o CMLS for igual a QR, a confian¸ca
local ser´a incrementada em 1%
2
e o contador CMLS ser´a reiniciado. Da mesma forma, se
a mensagem for maliciosa, o servidor dever´a incrementar o CMMS em 1; quando CMMS
for igual a QR, a confian¸ca local ser´a decrementada em 1% e o contador CMMS ser´a
reiniciado. O algoritmo a seguir apresenta o c´alculo da confian¸ca local de um servidor:
if M ensagem idonea then
if QR = CM LS then
if CLS < 100% then
CLS = CLS + 1%
endif
CM LS = 0
else
CM LS = CM LS + 1
endif
else
if QR = CM MS then
if CLS > 0% then
CLS = CLS − 1%
endif
CM M S = 0
else
CM M S = CM MS + 1
endif
2
O valor de 1% foi escolhido de forma emp´ırica. Trabalhos futuros dever˜ao ser realizados para encontrar
o melhor valor.
70
endif
A CLS indica a confian¸ca local de um servidor A em outro servidor B e ser´a
utilizada no c´alculo da confian¸ca final do servidor A. Como por exemplo, um servidor A
possui a vari´avel MC igual a 30 e confia 70% em um servidor B. Supondo que o CMMS
de B no servidor A seja 20 e o CMLS seja 7, ent˜ao:
QR para mensagem maliciosa
QR = 0.7 ∗ 30 = 21
QR para mensagem leg´ıtima
QR = (1 − 0.7) ∗ 30 = 0 .3 ∗ 30 = 9
Isto significa que ser´a necess´aria mais 1 mensagem maliciosa para diminuir a con-
fian¸ca, pois neste caso QR ´e igual a 21 e CMMS ´e igual a 20 e mais 2 mensagens leg´ıtimas
para aumentar a confian¸ca, pois neste caso QR ´e igual a 9 e CMLS ´e igual a 7.
6.3.2 Confian¸ca global
A confian¸ca global define a confian¸ca de um servidor emissor em um determinado
grupo de servidores confi´aveis (ver se¸c˜ao 6.5). A confian¸ca global ´e a m´edia de todas as
confian¸cas locais de cada servidor e dever´a ser propagada pela rede atrav´es do modelo de
propaga¸c˜ao de confian¸ca. A f´ormula para o c´alculo de confian¸ca do servidor A em B ´e
apresentada a seguir:
CGS
AB
=
k
i=0
CLS
iB
k
onde k ´e a quantidade de servidores pertencentes ao grupo de confian¸ca de A e CLS
iB
´e
a confian¸ca de cada servidor do grupo de A (incluindo a dele) em B.
71
A CGS
AB
indica a confian¸ca do grupo de A em B e ser´a utilizado no c´alculo da
confian¸ca final do servidor A.
6.3.3 C´alculo da confian¸ca final
A CS (Confian¸ca Final) ´e a confian¸ca de um servidor A em um servidor B. Esta
confian¸ca foi proposta para definir um modelo justo de c´alculo de confian¸ca que considera
a confian¸ca de um grupo de servidores e a confian¸ca do servidor em si. Isto significa que
se um servidor receptor n˜ao conhecer um emissor, ele poder´a gerar uma confian¸ca inicial
influenciado pela confian¸ca de seu grup o de servidores. Esta confian¸ca ser´a calculada a
partir da seguinte f´ormula:
CS =
CLS + CGS
2
onde CLS (Confian¸ca Local do Servidor ) ´e a confian¸ca local de A em B e CGS (Confian¸ca
do Grupo no Servidor ) ´e a confian¸ca do grupo de A em B.
A confian¸ca local e a confian¸ca em grupo foram definidas visando a propaga¸c˜ao da
confian¸ca de um determinado emissor atrav´es da rede sem que esta confian¸ca seja decisiva
no recebimento de mensagens, visto que o grupo de confian¸ca ´e capaz de mentir sobre a
credibilidade de um emissor na rede.
Caso um servidor receptor n˜ao possua uma confian¸ca definida em um servidor
emissor que est´a tentando se comunicar, ser´a necess´aria a defini¸c˜ao de uma confian¸ca
local CLS inicial. Para este trabalho foi definido que a CLS inicial ser´a de 80% (ser˜ao
realizados trabalhos futuros para a defini¸c˜ao da melhor CLS inicial). Isto faz com que a
confian¸ca inicial CS de um servidor para um desconhecido seja de 40%, pois ainda n˜ao
foi calculada a global do emissor. Ent˜ao:
CS =
80 + 0
2
= 40
tornando o crit´erio de recebimento na primeira comunica¸c˜ao mais rigoroso; quanto menor
a confian¸ca, menor ser´a o QR para diminuir a confian¸ca.
72
6.4 Armazenamento de confian¸ca
O m´odulo de armazenamento ´e respons´avel por armazenar, retornar e remover
informa¸c˜oes sobre servidores emissores no sistema de confian¸ca. Est´e m´odulo ser´a a
mem´oria de confian¸ca de cada servidor e deve armazenar as seguintes informa¸c˜oes:
• dom´ınio: dom´ınio do servidor emissor;
• nome: nome do servidor emissor;
• ip: endere¸co IP do servidor emissor (dever´a suportar m´ultiplos IPs por servidor);
• CLS : confian¸ca local, entre 0 e 100%;
• CGS : confian¸ca global, entre 0 e 100%;
• CFS : contador de fichas que o servidor possui (utilizada na prioriza¸c˜ao de consulta,
vide se¸c˜ao 6.5.1);
• CMLS : contador de mensagens leg´ıtimas recebidas pelo servidor. Dever´a ser reini-
ciado toda vez que atingir a quantidade de QR;
• CMMS : contador de mensagens maliciosas recebidas pelo servidor. Dever´a ser
reiniciado toda vez que atingir a quantidade de QR;
• TTL (Time To Live): tempo de vida desta informa¸c˜ao.
O TTL disponibiliza um modelo de “esquecimento” de acordo com o tempo que um
servidor fica sem se comunicar com o emissor. Quando um servidor ´e armazenado, o sis-
tema de confian¸ca atribui um TTL indicando a quantidade de dias que aquela informa¸c˜ao
ser´a v´alida. A cada dia que se passa o TTL ´e decrementado em uma unidade. A cada
comunica¸c˜ao o TTL dever´a ser reiniciado. Quando o TTL chegar a zero, as informa¸c˜oes
de confian¸ca deste servidor n˜ao ser˜ao mais v´alidas e ser˜ao armazenadas como hist´orico
para futuras comunica¸c˜oes. O hist´orico de cada servidor ser´a utilizado para recalcular
a confian¸ca inicial dos servidores que deixaram de se comunicar durante muito tempo
(definido pelo TTL) com o servidor receptor. Caso um servidor emissor sem confian¸ca
em um receptor possua um hist´orico de comunica¸c˜ao, a confian¸ca CLS inicial dever´a ser
calculada utilizando a seguinte f´ormula:
73
CLS =
80 + h
2
onde CLS ´e a m´edia entre o hist´orico (h) do servidor e um grau de confian¸ca inicial (80%).
Esta f´ormula permite que um servidor com maus antecedentes recupere sua con-
fian¸ca na rede, e que bons servidores continuem com um confian¸ca inicial boa. A figura
6.4 apresenta os quatro cen´arios de armazenamento.
Figura 6.4: Modelo de armazenamento
No primeiro cen´ario o servidor de e-mail A inicia uma comunica¸c˜ao SMTP com o
servidor B. Ent˜ao B verifica no sistema de armazenamento se ele possui confian¸ca em A.
O sistema de armazenamento responde negativamente, ent˜ao, B armazena uma confian¸ca
inicial em A.
No segundo cen´ario, o servidor de e-mail A inicia uma comunica¸c˜ao SMTP com
o servidor B. Ent˜ao B verifica no sistema de armazenamento se ele possui confian¸ca em
A. O sistema de armazenamento responde positivamente, ent˜ao, B recupera a confian¸ca
inicial em A.
No terceiro cen´ario, A termina de enviar uma mensagem para B. Ent˜ao B recalcula
a confian¸ca dele em A e atualiza o sistema de armazenamento.
Por ´ultimo, no quarto cen´ario, B possui um contador de tempo que verifica o TTL
de cada servidor, decrementa o TTL e se este atingir zero, gera um hist´orico do servidor
74
A e grava no sistema de armazenamento.
6.5 Propaga¸c˜ao de confian¸ca
A propaga¸c˜ao de confian¸ca ´e fundamental para o funcionamento da proposta, visto
que o objetivo deste sistema consiste nos servidores de e-mail serem capazes de gerar listas
de servidores confi´aveis e n˜ao confi´aveis de forma dinˆamica e descentralizada atrav´es de
um grupo de servidores confi´aveis entre si.
Os grupos de confian¸ca s˜ao grupos definidos pelo administrador de servi¸cos de
e-mail que indicam quais servidores dever˜ao ser consultados para o c´alculo da confian¸ca
global. Foi optado pelo m´etodo de escolha manual dos grupos de confian¸ca pois os m´etodos
de c´alculo de reputa¸c˜ao dos n´os s˜ao dif´ıceis de serem implementados e definidos, sendo
necess´ario um estudo mais detalhado sobre o assunto (n˜ao faz parte do escopo deste tra-
balho). No decorrer do estudo foram encontradas trˆes formas de propaga¸c˜ao de confian¸ca.
Essas formas podem ser classificadas como:
• Propaga¸c˜ao s´ıncrona: toda vez que houver uma altera¸c˜ao de confian¸ca, o servidor
dever´a requisitar um novo consenso da confian¸ca global. Os servidores requisitados
far˜ao o mesmo pedido ao seu grupo de confian¸ca e assim por diante. Este m´etodo
´e lento, visto que antes da confian¸ca ser gerada, todos os participantes de uma rede
de relacionamento dever˜ao ser consultados;
• Propaga¸c˜ao ass´ıncrona: um servidor A pergunta ao seu grupo sobre a confian¸ca
de um servidor B. O resultado desta consulta ser´a a confian¸ca global de A em B.
Este m´etodo ´e mais r´apido do que o s´ıncrono, contudo as pesquisas ser˜ao restritas
aos servidores que A conhece ou que est˜ao tentando iniciar uma comunica¸c˜ao com
A
.
• Propaga¸c˜ao h´ıbrida: um servidor A notifica, de forma s´ıncrona, os demais inte-
grantes de seu grupo de confian¸ca informando que um emissor B perdeu ou ganhou
a confian¸ca de A. Os servidores utilizam essas notifica¸c˜oes para perguntar ao seu
grupo de confian¸ca, de forma ass´ıncrona, sobre a confian¸ca do grupo em B afim
de se gerar a confian¸ca global de B. Este m´etodo propaga a informa¸c˜ao de uma
maneira r´apida e permite com que os servidores que mais se comunicam na rede
sejam propagados mais rapidamente.
Optou-se pelo uso do m´etodo de comunica¸c˜ao h´ıbrida, por ser capaz de alcan¸car
um grande n´umero de servidores pela rede, com um desempenho razo´avel. A seguir ser˜ao
75
apresentados os m´etodos de notifica¸c˜ao (s´ıncrono) e de propaga¸c˜ao global (ass´ıncrono).
6.5.1 Notifica¸c˜oes de ajuste de confian¸ca
Esta abordagem utiliza o conceito de “fichas” para notificar o ajuste de confian¸ca
de um determinado servidor. As fichas indicam a altera¸c˜ao da confian¸ca de um receptor
em um emissor e ser´a utilizada como base de prioriza¸c˜ao de consultas do sistema de
propaga¸c˜ao de confian¸ca global, ou seja, quanto maior o n´umero de fichas um determinado
servidor possuir em outro, maior ser´a a prioridade de consulta para defini¸c˜ao da sua
confian¸ca global. A figura 6.5 apresenta o modelo de notifica¸c˜ao de ajuste de confian¸ca.
Figura 6.5: Modelo de comunica¸c˜ao s´ıncrono
Nesta figura, o servidor A envia uma ficha para todos os servidores de seu grupo de
confian¸ca (B, C, D, E e F) indicando que ocorreu uma altera¸c˜ao de confian¸ca no servidor
X. Os servidores aceitam a ficha, gravam em seu sistema de armazenamento e aguardam
novas notifica¸c˜oes. O algoritmo a seguir define o modelo de envio e recebimento de fichas.
Notifica ajuste
foreach n´o
i
pertencente ao grupo de confian¸ca do
envia ficha (dom´ınio, ip) alterado para n´o
i
end
Recebe ajuste
while verdadeiro do
recebe mensagem (dom´ınio, ip) de n´o
j
if n´o
j
faz parte do grup o de confian¸ca then
76
armazena (dom´ınio, ip, nova ficha)
notifica sistema de propaga¸c˜ao de confian¸ca global
endif
end
O primeiro algoritmo notifica os demais servidores do grup o de relacionamento,
que houve uma altera¸c˜ao de confian¸ca em um servidor emissor. O segundo algoritmo
verifica se o servidor que est´a notificando faz parte do grupo de confian¸ca. Caso fa¸ca
parte, recebe a mensagem e notifica o sistema de propaga¸c˜ao global, do contr´ario, ignora
notifica¸c˜ao.
6.5.2 Propaga¸c˜ao da confian¸ca global
A propaga¸c˜ao de confian¸ca global faz uso das redes de relacionamento para propa-
gar a confian¸ca de um determinado servidor para o maior n´umero de servidores e-mail
confi´aveis, ou seja, um servidor A dever´a propagar a sua mem´oria de confian¸ca para o seu
grupo de confian¸ca; cada integrante deste grupo propagar´a a sua mem´oria de confian¸ca
e assim por diante. Desta forma, todos os servidores que fizerem parte da rede de rela-
cionamento de A dever˜ao receber informa¸c˜oes propagadas por A. A figura 6.6 apresenta
o modelo de propaga¸c˜ao de confian¸ca global.
Figura 6.6: Modelo de propaga¸c˜ao ass´ıncrono
Nesta figura o servidor A faz uma requisi¸c˜ao de confian¸ca para todos os servidores
de seu grupo de confian¸ca. Os servidores B, C, D e F retornam a confian¸ca ao servidor
A; o servidor E n˜ao possui informa¸c˜oes sobre o servidor requisitado, ent˜ao, o servidor
A envia uma ficha ao servidor E, para que E seja capaz de gerar sua pr´opria confian¸ca
global no servidor pesquisado por A. Ap´os receber todas as respostas o servidor A dever´a
77
calcular a confian¸ca global (CGS). A seguir ´e apresentado o algoritmo de propaga¸c˜ao
global.
Requisita confian¸ca
while verdadeiro do
if existe servidor n˜ao pesquisado na mem´oria de confian¸ca then
j = seleciona o servidor com maior numero de fichas
if CLS
j
igual a NULO then
CLS
j
= 80
endif
CGS = CLS
j
k = 1
foreach n´o pertencente ao grupo de confian¸ca = i do
C = requisita confian¸ca de j para n´o
i
if C igual a NULO then
envia ficha e endere¸co do servidor alterado para n´o
i
else
CGS
=
CGS
+
C
k = k + 1
endif
end
CGS =
CGS
k
armazena CGS
else
aguarda recebimento de ficha
endif
end
Retorna confian¸ca
while verdadeiro do
server = escuta entrada (bloqueante)
recupera j
if servidor possui confian¸ca em j then
return CLS
j
else
return NULO
78
endif
end
O primeiro algoritmo fara uma verifica¸c˜ao da existˆencia de um servidor na base
de confian¸ca que a confian¸ca global ainda esteja com a confian¸ca global NULA (ainda
n˜ao foi gerada) ou todos os servdores que tenham uma notifica¸c˜ao de ajuste pendente.
Se n˜ao existirem servidores pendentes, este algoritmo ficar´a aguardando at´e que existe
uma notifica¸c˜ao de ajuste de confian¸ca. Do contr´ario, ele dever´a serlecionar o servidor
que tenha um n´umero maior de notifica¸c˜oes pendentes e dever´a requisitar ao seu grupo de
confian¸ca a confian¸ca que cada um possui naquele servidor pendente. Caso um membro
consultado n˜ao possua a confian¸ca naquele servidor, ser´a retornada ao servidor requi-
sitor uma notifica¸c˜ao informando que ele n˜ao possui uma confian¸ca local formada, do
contr´ario, a confian¸ca dever´a ser retornada e somada ao CGS. Ao final do recebimento de
todas as respostas `a requisi¸c˜ao, o servidor dever´a calcular o CGS e gravar no sistema de
armazenamento.
O segundo algoritmo dever´a receber as requisi¸c˜oes, verificar se o servidor requisi-
tado encontra-se na mem´oria de confian¸ca e retornar a CLS (se estiver cadastrado) ou
ent˜ao retornar NULO. Por fim, dever´a aguarda por novas requisi¸c˜oes.
6.6 Benef´ıcios e limita¸c˜oes
A arquitetura apresentada torna poss´ıvel a diminui¸c˜ao gradativa do tr´afego de
mensagens de servidores de e-mail que s˜ao utilizados por spammers como ferramentas de
transporte de mensagens maliciosas. A arquitetura traz outros benef´ıcios para a imple-
menta¸c˜ao deste sistema em servi¸cos de e-mail:
• cria um modelo capaz de diminuir a quantidade de mensagens a serem recebidas de
um determinador servidor, de acordo com um consenso de um determinado grupo
de servidores;
• este modelo diminui a quantidade de mensagens n˜ao solicitadas armazenadas no
servidor, visto que ele diminui a quantidade de mensagens que um poss´ıvel servidor
spammer possa enviar;
• a mem´oria de confian¸ca permite com que administradores de servi¸cos de e-mail criem
blacklists e disponibilizem informa¸c˜oes de poss´ıveis spammers em RBLs;
79
• f´acil integra¸c˜ao com diversos tipos de filtros para e-mail. N˜ao existe necessidade de
altera¸c˜ao do protocolo de comunica¸c˜ao entre servidores;
• facilmente adapt´avel a outros tipos de algoritmos de Redes de relacionamento e
P2P;
• n˜ao necessita altera¸c˜ao no protocolo SMTP;
• compat´ıvel com o modelo atual de transporte de e-mail;
As principais restri¸c˜oes e deficiˆencias desta proposta s˜ao:
• troca de informa¸c˜ao entre servidores pode ocasionar perda de desempenho na co-
munica¸c˜ao dos servidores de e-mail;
• servidores confi´aveis podem ser considerados n˜ao confi´aveis a partir da propaga¸c˜ao
de confian¸ca global;
• servidores s˜ao mais suscept´ıveis a ataques de nega¸c˜ao de servi¸co (visto que eles
aceitam informa¸c˜oes de v´arios servidores da rede).
6.7 Trabalhos correlatos
Nesta se¸c˜ao ser˜ao apresentados o MailRank e o Leveraging Social Network to Fight
Spam, dois trabalhos que utilizam redes de relacionamento para criar white lists e black
lists de servidores de e-mail.
6.7.1 MailRank
O MailRank [CDN05] ´e um sistema colaborativo para cria¸c˜ao de white lists globais.
Os dados da lista s˜ao coletados atrav´es de redes de relacionamento e agrupados em uma
´unica rede global baseada nas atividades dos usu´arios do MailRank. Cada mensagem
enviada a outro servidor ´e transformada em um voto de confian¸ca.
Representando a rede social de e-mail como um grafo, os autores criaram um
algoritmo de itera¸c˜ao global que computa cada valor de reputa¸c˜ao para cada endere¸co de
e-mail. Este modelo assume que cada indiv´ıduo de uma rede social n˜ao ´e um spammer, e
a pontua¸c˜ao deste pode ser usada para identificar endere¸cos de spammers.
Arquitetura do sistema
80
O MailRank ´e composto por dois m´odulos principais: proxy MailRank (implemen-
tado nos clientes de e-mail) e servidor MailRank (m´aquina espec´ıfica da rede).
• Proxy MailRank:
Quando o proxy recebe um e-mail de sa´ıda, ele extrai os votos do usu´ario, utilizando
alguns dados de entradas dispon´ıveis (tal como analisando a caixa de mensagens
enviadas), envia os votos coletados para o servidor MailRank e repassa a mensagem
para o servidor de e-mail local. Quando um e-mail ´e recebido, o proxy consulta o
servidor MailRank verificando o ranque do endere¸co do emissor, recebe a pontua¸c˜ao
j´a computada e atualiza a pontua¸c˜ao recebida no assunto da mensagem.
O proxy utiliza os votos que s˜ao baseados nos campos “To” do cabe¸calho (“To:”,
“Cc:”, “BCc:”, etc.). Nenhuma a¸c˜ao adicional por parte do usu´ario para a cria¸c˜ao
dos votos ´e necess´aria, desde que o proxy consiga extrair automaticamente os votos.
Para isto, o usu´ario do MailRank precisa alterar seu cliente de envio de e-mail para
apontar para o MailRank ao inv´es do servidor de e-mail local.
• Servidor MailRank:
O servidor coleta os dados de entrada de todos os usu´arios do MailRank utilizando
o algoritmo MailRank. O principal objetivo do algoritmo MailRank ´e atribuir uma
classifica¸c˜ao para cada endere¸co de e-mail armazenado no sistema e usar esta clas-
sifica¸c˜ao para decidir qual endere¸co de e-mail ´e de um spammer ou n˜ao. As etapas
deste algoritmo s˜ao:
1. Determinar um conjunto de endere¸cos de e-mail que possuam uma alta rep-
uta¸c˜ao na rede social;
2. Executar o algoritmo no grafo da rede de e-mail, utilizando o conjunto deter-
minado anteriormente para computar a pontua¸c˜ao final de cada endere¸co de
e-mail.
Existem trˆes formas de se determinar o conjunto de endere¸cos de e-mail:
1. Manual: garante que nenhum spammer far´a parte do conjunto;
2. Autom´atica: Seleciona os endere¸cos de e-mail que possuem um ranque alto,
tal que que a soma dos ranques de cada n´o seja igual a 2 do total de ranque
do sistema;
3. Semi-autom´atica: Faz uma pr´e-sele¸c˜ao utilizando a abordagem autom´atica
e disponibiliza essa sele¸c˜ao para que seja refinada manualmente.
81
A partir deste conjunto ´e gerado um vetor de de pontua¸c˜ao final. Este vetor ir´a
classificar o endere¸co emissor a partir do proxy de entrada da seguinte forma:
– n˜ao spammer: se a pontua¸c˜ao final do endere¸co emissor for maior que o ponto
inicial T;
– spammer: se a pontua¸c˜ao final do endere¸co emissor for menor que o ponto
inicial T;
– n˜ao identificado: se o endere¸co de e-mail ainda n˜ao foi identificado pelo
sistema.
6.7.2 Leveraging Social Networks to Fight Spam
O Leveraging Social Networks to Fight Spam [BR05] ´e uma ferramenta antispam
que explora as propriedades das redes sociais para distinguir mensagens de e-mail n˜ao
solicitadas (spam) de mensagens associadas `as pessoas que um usu´ario conhece. O fun-
cionamento desta ferramenta foi dividido em trˆes etapas apresentadas a seguir:
A primeira etapa ´e criar uma rede de relacionamento de um ´unico usu´ario. Essa
rede ´e montada baseada nas informa¸c˜oes dispon´ıveis em mensagens de sua caixa de correio:
emissores (a partir do campo From) e receptores (a partir dos campos To, Cc, BCc, etc).
A partir das informa¸c˜oes obtidas, s˜ao definidos n´os que representam todos os endere¸cos
coletados. Em seguida s˜ao adicionadas conex˜oes entre os pares de endere¸cos que aparecem
na mesma mensagem (indiv´ıduos que se comunicaram atrav´es do outro). Os n´os que
representam o pr´oprio usu´ario dever˜ao ser removidos.
A segunda etapa consiste em utilizar a rede social (grafo) montada para definir
white lists de usu´arios, utilizando uma propriedade das redes sociais: Tendˆencia de aglom-
era¸c˜ao. Por exemplo, se Alice conhece Bob e Eve, Bob possui grandes chances de tamb´em
conhecer Eve.
A terceira etapa consiste em utilizar f´ormulas de classifica¸c˜ao definidas em [BR05],
nos grupos aglomerados, que analisam se esses grupos de mensagens s˜ao spams ou n˜ao
spams a partir de seus coeficiente de aglomeramento. Todos os componentes que tenham
o coeficiente de aglomeramento maior que uma taxa m´axima C
max
fazem parte do grupo
social do usu´ario. Todos os n´os desses componentes dever˜ao ser inseridos em uma white
list. Comp onentes que possuam um coeficiente de aglomeramento menor que uma taxa
C
min
ser˜ao considerados spams e ser˜ao inseridos em uma black list. Os componentes que
estiverem entre a taxa C
min
e C
max
n˜ao s˜ao pass´ıveis de classifica¸c˜ao, por isso dever˜ao ser
definidos como componentes n˜ao classificados.
6.8 Conclus˜ao
Neste cap´ıtulo foi apresentada a proposta do trabalho e os trabalhos correlatos que
utilizam t´ecnicas de redes de relacionamento para classificar poss´ıveis spammers e gerar
listas de e-mails maliciosos, visando conter a quantidade de spams que trafegam pela rede.
A proposta deste trabalho foi dividida em trˆes m´odulos:
• Gerˆencia de confian¸ca: forma como a confian¸ca ´e tratada pelo sistema de confian¸ca;
• Comunica¸c˜ao entre servidores: modelo de propaga¸c˜ao de confian¸ca pela rede;
• Sistema de armazenamento: modelo de armazenamento das informa¸c˜oes sobre con-
fian¸ca.
A proposta deste trabalho utiliza uma abordagem diferente no uso de redes de
relacionamento das que foram apresentadas como trabalhos correlatos.
• O primeiro trabalho utiliza as redes de relacionamento para classificar se uma de-
terminada mensagem ´e um spam ou n˜ao. Este trabalho utiliza um sistema de votos
que permite classificar e propagar spammers e spams pela rede.
• O segundo trabalho utiliza as redes de relacionamento para verificar se um deter-
minado usu´ario apresentado no campo From ´e um spammer.
• A proposta deste trabalho utiliza as redes de relacionamento para classificar servi-
dores que s˜ao utilizados como emissores de spam, diminuindo gradativamente a
quantidade de mensagens que esses servidores maliciosos s˜ao capazes de enviar para
um determinado servidor. Esta proposta apresenta ainda algoritmos para propagar
esta confian¸ca para outros servidores da rede.
Al´em disso, s˜ao apontados os principais benef´ıcios e limita¸c˜oes da proposta. No
pr´oximo cap´ıtulo ser˜ao discutidos os detalhes de implementa¸c˜ao, os testes efetuados e as
an´alises dos resultados obtidos.
Cap´ıtulo 7
Implementa¸c˜ao e resultados
O prot´otipo da proposta apresentada no cap´ıtulo anterior foi implementado para a
plataforma Linux, usando o Postfix como servidor de e-mail, o SpamAssassin como filtro
anti-spam e o Clamav como filtro anti-v´ırus. Foi implementado um programa, denominado
TrustMail, que realiza a gerˆencia de confian¸ca, armazena as informa¸c˜oes e propaga a
confian¸ca pela rede a partir do grupo de confian¸ca. As pr´oximas se¸c˜oes descrevem a
implementa¸c˜ao do TrustMail, o sistema de comunica¸c˜ao entre o servidor de e-mail e os
demais componentes da proposta e uma avalia¸c˜ao sobre o funcionamento do sistema.
7.1 TrustMail
O TrustMail ´e o sistema de confian¸ca apresentado na proposta. O TrustMail
implementa os modelos de gerˆencia, armazenamento e propaga¸c˜ao de confian¸ca. Foi foi
implementado na linguagem C e utiliza o SQLite (biblioteca que cont´em fun¸c˜oes SQL para
armazenamento de dados) para armazenar as informa¸c˜oes sobre a confian¸ca dos servidores
de e-mail. A comunica¸c˜ao do TrustMail com as outras ferramentas para recebimento e
classifica¸c˜ao de e-mail ´e feita atrav´es de filas de mensagens do Linux (explicado a seguir).
As filas de mensagens podem ser descritas como listas internas no espa¸co de endere¸camento
do Kernel para a troca de mensagens entre processos [Rib05]. Optou-se por este m´etodo
de IPC (Interprocess Communication) para facilitar a integra¸c˜ao do TrustMail com as
demais ferramentas.
O MTA escolhido foi o Postfix 2.2, p ela facilidade de integra¸c˜ao com outras fer-
ramentas e pelo seu c´odigo ser simples e leg´ıvel. O sistema de autentica¸c˜ao de servidor
escolhido foi o SPF, por ser f´acil de implementar (existe uma biblioteca de desenvolvi-
mento “libspf2” dispon´ıvel para download no site do autor) e por ser f´acil de integrar
com o Postfix. Tanto a comunica¸c˜ao do MTA com o SPF, quanto a comunica¸c˜ao com
84
o TrustMail s˜ao feitas atrav´es do policyd. O policyd ´e uma implementa¸c˜ao SPF de-
senvolvida pela mesma equipe do libspf2 que utiliza esta biblioteca para verificar a aut-
enticidade dos servidores de e-mail. O c´odigo do policyd foi modificado para suportar
a comunica¸c˜ao com o TrustMail. Este programa far´a a autentica¸c˜ao completa de um
servidor, tornando desnecess´aria a comunica¸c˜ao direta do TrustMail com o Postfix. O
filtro anti-spam escolhido foi o SpamAssassin 2.63. Este filtro possui v´arios crit´erios de
classifica¸c˜ao de mensagens, como por exemplo, an´alise de cabe¸calho, an´alise de texto,
black lists, sistema de pontua¸c˜ao de mensagens de acordo com caracter´ısticas recup eradas
atrav´es de an´alise bayesiana, entre outras. O anti-v´ırus utilizado foi o Clamav 0.70. Este
anti-v´ırus foi desenvolvido em C e possui uma extensa lista de assinaturas de v´ırus e est˜ao
em constante atualiza¸c˜ao (tanto o Clamav quanto o SpamAssassin ro dam como daemons,
facilitando a integra¸c˜ao com outros programas). A comunica¸c˜ao do Postfix com os fil-
tros de mensagens ´e feita atrav´es do script Clamav-Filter . Este script foi alterado para
suportar a notifica¸c˜ao de mensagens maliciosas/leg´ıtimas para o TrustMail. O prot´otipo
da implementa¸c˜ao atual est´a ilustrado na figura 7.1
Figura 7.1: Prot´otipo implementado
Nesta figura ´e poss´ıvel observar que o TrustMail independe do servidor, do sistema
de autentica¸c˜ao e dos filtros de mensagens. Ou seja, este modelo pode ser facilmente
integrado com outras ferramentas. A seguir ser´a detalhado o fluxo de comunica¸c˜ao entre
85
os processos no recebimento de e-mails.
7.1.1 Fluxo do programa
O processo de recebimento dever´a seguir as seguintes etapas:
1. O Postfix dever´a fazer uma chamada ao policyd toda vez que receber um comando
RCPT TO e dever´a aguardar o comando de resp osta (que ser´a recebido do policyd).
Os parˆametros passados ao policyd s˜ao: endere¸co do emissor, ip do emissor e dom´ınio
informado no comando HELO/EHLO.
2. O policyd recebe os parˆametros de entrada recebidos do Postfix e faz uma con-
sulta, utilizando a biblioteca libspf2, ao servidor DNS do dom´ınio do emissor,
autenticando assim, a procedˆencia do servidor. O retorno desta consulta dever´a ser:
• Pass, Soft Fail, Neutral, Unknown ou None: O processo continua;
• Error: Retorna ao Postfix a mensagem “450 Falha tempor´aria”;
• Fail: Retorna um erro e a conex˜ao deve ser finalizada pelo Postfix.
3. Se o processo prosseguir, o policyd chamar´a o TrustMail (atrav´es de Filas de Men-
sagens) e requisitar´a se a conex˜ao pode continuar. O TrustMail calcula a quanti-
dade de mensagens que o servidor pode receber em um per´ıodo de tempo (no caso
do prot´otipo, o per´ıodo estabelecido foi de um dia) e retorna verdadeiro se o servi-
dor puder receber, ou falso, caso contr´ario. O policyd notifica o postfix sobre
a resposta recebida. Por fim, o processo de recebimento de mensagem do Postfix
continua.
4. Quando uma mensagem for recebida, o Postfix chamar´a o script Clamav-Filter.
Os parˆametros passados ao Clamav-Filter s˜ao: o endere¸co ip, o host de origem e
o dom´ınio da mensagem.
5. Em seguida, o Clamav-Filter recuperar´a a mensagem de um diret´orio, chamar´a o
Clamav e o SpamAssassin e aguardar´a o retorno.
6. Depois, o Clamav-Filter chamar´a o TrustMailNotify que notificar´a ao TrustMail
(utilizando filas de mensagens) que uma mensagem maliciosa ou leg´ıtima foi rece-
bida.
7. Por fim, o servidor calcular´a a nova confian¸ca e armazenar´a as novas informa¸c˜oes
no Trust Mail.db.
86
8. A comunica¸c˜ao pela rede ´e feita pelo processo TrustMail que escuta na porta
60002 as notifica¸c˜oes de fichas e na porta 60001 a requisi¸c˜ao de confian¸ca. Quando
a confian¸ca de um servidor ´e alterada no servidor, ele propaga uma ficha para todos
os integrantes do seu grupo de confian¸ca. Uma thread que roda a cada 60 segundos
verifica se existem fichas pendentes no servidor para requisitar a confian¸ca. Caso
existam fichas pendentes, o servidor faz uma requisi¸c˜ao para todos os servidores de
seu grupo de confian¸ca para gerar a confian¸ca global do servidor em quest˜ao.
Para facilitar a cria¸c˜ao do grupo de confian¸ca, foi desenvolvido o TrustMailAdmin,
que insere, exclui e lista servidores do grupo de relacionamento.
Al´em do TrustMailAdmin, existe um processo batch (TrustMailTTL) que ´e exe-
cutado pelo cron.d. Este processo ´e respons´avel por limpar os contadores tempor´arios e
diminuir o TTL dos servidores.
Quando a confian¸ca do servidor ´e alterada, um processo de log registra o dom´ınio,
CGS, CLS, CMMS e CMLS. Este log ser´a utilizado para a avalia¸c˜ao do prot´otip o.
7.2 Avalia¸c˜ao do prot´otipo
O equipamento utilizado para a avalia¸c˜ao do prot´otipo nos testes foi um Pentium
4 2.8, com 1.5 GB de mem´oria e 120 GB de disco r´ıgido serial ATA e um Pentium 3 Dual
800 com 1024GB de mem´oria e 80 GB de disco r´ıgido. O sistema operacional de ambas
as m´aquinas ´e o Linux Fedora Core 4 com kernel 2.6.3. Para a avalia¸c˜ao dos servi¸cos de
e-mail foi definida a utiliza¸c˜ao de m´aquinas virtuais. A m´aquina virtual escolhida foi o
UML (User-Mode Linux) compilada com o kernel2.6.9. A escolha do UML foi devido a
facilidade de implementa¸c˜ao, suporte a todas as funcionalidades de uma m´aquina real e
por ser suportada pelo kernel oficial do Linux.
As pr´oximas se¸c˜oes discutem os aspectos relacionados a massa de teste, funciona-
mento e escalabilidade, desempenho e a an´alise dos resultados obtidos.
7.2.1 Massa de teste
Como a proposta da avalia¸c˜ao n˜ao ´e testar a efic´acia dos filtros de mensagens e
sim caracter´ısticas do TrustMail, foram definidos dois e-mails para testes. Um e-mail
ser´a classificado como spam pelo filtro anti-spam e o outro e-mail ser´a classificado como
leg´ıtimo.
Mensagem maliciosa
87
O SpamAssassin classifica a mensagem GTUBE como sendo um spam. A men-
sagem maliciosa a ser enviada para o MTA ´e apresentada a seguir:
1 Subject : Test spam mail ( GTUBE )
2 Message-ID: < GTUBE1 .10101 01 @ex am ple . net >
3 Date: Wed , 23 Jul 2 003 2 3:30:00 + 0200
4 From: Sender < sender@examp le . net >
5 To: Re cipien t < recipie nt@e xamp le . net >
6 P receden ce : junk
7 MIME- Version : 1.0
8 Content -Type: text / plain ; charset =us - ascii
9 Content - Transfer -Encoding : 7 bit
10
11 This is the GTUBE , the
12 Gene ric
13 Test for
14 Unsol icite d
15 Bulk
16 Email
17
18 If your spam filter supports it , the GTUBE p ro vi des a test by which you
19 can verify that the filter is i nstall ed corre ctly and is d et ecting
20 incom in g
21 spam . You can send yours el f a test mail cont aining the fo llowin g string
22 of
23 c haracte rs ( in upper case and with no white spaces and line breaks ):
24
25 XJS * C4JD BQADN1 . NSBN3 *2 IDNEN * GTUBE - STANDARD - ANTI - UBE - TEST - EMAIL *C .34 X
26
27 You should send this test mail from an account outside of your netw ork .
Mensagem leg´ıtima
A mensagem leg´ıtima a ser utilizada nos teste ser´a a mensagem apresentada a
seguir. Esta mensagem foi submetida aos servi¸cos anti-v´ırus e anti-spam e foi considerada
confi´avel.
1 From: Leon ard Bispo de Oliveira < bisp o@ppg ia . pucpr .br >
2 To: s ende r@example . net
3 Subject : Mensa ge m =? iso -8859 -1? q ?Id= F4nea ?=
4 Date: Thu , 28 Jun 20 01 19 :33:35 -0 300
5 User - Agent : KMail /1.7.2
6 X - KMail - Crypt oForma t : 15
7 MIME- Version : 1.0
88
8 Content -Type: text / plain ;
9 charset =" iso -8859 -1 "
10 Content - Transfer -Encoding : quoted - print able
11 Content - Di sp os it io n : inline
12 X - KMail - R ecipien ts : sen der@ exam ple . net
13 Status : R
14 X - Status : N
15 X - KMail - Encr ypti onSt ate :
16 X - KMail - SignatureStat e :
17 X - KMail - MDN - Sent :
18
19 Modelo de mensa ge m que n=E3o dever = E1 ser cla ssificada como um =20
20 SPAM
21
22 Esta mensag em servir = E1 como massa de testes para o Tru st Mail .
23
24 Abra = E7o ,
25
26 Servi do r de teste
7.2.2 An´alise do funcionamento
Os testes foram realizados utilizadas seis m´aquinas virtuais. Em cada m´aquina
virtual foi instalado todos os programas necess´arios para suportar as funcionalidades da
proposta. O grupo de confian¸ca de cada TrustMail pode ser visto na figura 7.2.
Figura 7.2: Grupo de confian¸ca
Os valores das vari´aveis do TrustMail foram definidos da seguinte forma:
• QM: 1000 (foi definido um valor alto para permitir a comunica¸c˜ao de um servidor
at´e o final dos testes);
89
• MC: 10;
• TTL: 1;
• Confian¸ca default inicial: 80%.
Os testes foram realizados atrav´es de um programa que envia automaticamente
mensagens para os servidores de e-mail. Este programa foi configurado para enviar men-
sagens do dom´ınio teste.com.br. Metade dos servidores recebeu mensagens maliciosas
e a outra metade recebeu mensagens leg´ıtimas. De tempos em tempos o programa mod-
ificou o envio das mensagens leg´ıtimas/maliciosas. Os servidores que estavam recebendo
mensagens leg´ıtimas passaram a receber mensagens maliciosas e vice-versa. Todas as men-
sagens recebidas foram tratadas por cada um dos servidores e armazenadas para an´alise.
Ao final dos testes, cada servidor recebeu cerca de duzentas mensagens.
Para facilitar a an´alise, os resultados obtidos foram plotados em gr´aficos. A an´alise
foi feita a partir dos gr´aficos com valores mais expressivos do funcionamento do TrustMail.
Destes, cinco est˜ao interpretados detalhadamente nesta se¸c˜ao. O ´ultimo gr´afico corre-
sponde a uma vis˜ao geral de todos os servidores. A seguir s˜ao apresentados os gr´aficos
que representam os resultados obtidos.
Figura 7.3: Acompanhamento do Grau de Confian¸ca do Servidor 1
Esta figura demonstra que, partindo de um grau de confian¸ca total (CS) de 71% e,
estando o grau de confian¸ca global dos servidores (CGS) em 66%, foram necess´arias sete
mensagens maliciosas para diminuir 1% do grau de confian¸ca local do servidor (CLS) e
conseq¨uentemente o grau de confian¸ca total (CS). O valor de sete mensagens maliciosas
foi obtido pela f´ormula:
90
QR = 0.7 ∗ 10 = 7
Enquanto seriam necess´arias trˆes mensagens leg´ıtimas para aumentar em 1% o
grau de confian¸ca total (CS), conforme demonstrado na f´ormula abaixo:
QR = (1 − 0.7) ∗ 10 = 0 .3 ∗ 10 = 3
A linha do gr´afico que parte do valor de confian¸ca de 70% para 74%, demonstra o
aumento de 4% no grau de confian¸ca total (CS), devido ao recalculo do grau de confian¸ca
global dos servidores (CGS) que passou de 66% para 74%. O recalculo dos servidores ´e
realizado a cada 60 segundos.
Figura 7.4: Acompanhamento do Grau de Confian¸ca do Servidor 3
Esta figura destaca a varia¸c˜ao das condi¸c˜oes de aumento da quantidade de men-
sagens leg´ıtimas e aumento da quantidade de mensagens maliciosas. O ponto no gr´afico,
cujo valor de confian¸ca total (CS) ´e de 65% sofre uma queda para o valor de 58% quando o
servidor recebe o total de seis mensagens maliciosas. O grau de confian¸ca total (CS) volta
a aumentar, conforme demonstrado na curva do gr´afico, quando se estabiliza a quantidade
de mensagens maliciosas e aumenta a quantidade de mensagens leg´ıtimas. A cada cinco
mensagens leg´ıtimas ´e aumentado 1% do grau de confian¸ca total (CS), que passou de 57%
para 58%
91
Figura 7.5: Acompanhamento do Grau de Confian¸ca do Servidor 4
Esta figura demonstra a diminui¸c˜ao do grau de confian¸ca total (CS) de 79% para
67% devido `a queda do valor de confian¸ca global dos servidores (CGS), que passou de
75% para 51%. Esta diminui¸c˜ao ocorreu mesmo estando est´aveis os valores de confian¸ca
local do servidor (CLS) e tendo aumentado a quantidade de mensagens leg´ıtimas.
Logo em seguida, ´e demonstrado o aumento do grau de confian¸ca total (CS) de
67% para 78%, tamb´em justificado exclusivamente pelo aumento do valor de confian¸ca
global dos servidores (CGS).
Figura 7.6: Acompanhamento do Grau de Confian¸ca do Servidor 5
92
Esta figura apresenta uma situa¸c˜ao comum do funcionamento do TrustMail. Basi-
camente, iniciando a an´alise onde o grau de confian¸ca total (CS) ´e de 79%, este sofre uma
queda devido ao recalculo do valor de confian¸ca global dos servidores (CGS) que passou
de 77% para 65%. A curva do gr´afico sofre pequenas altera¸c˜oes. Essas altera¸c˜oes s˜ao
decorrentes da f´ormula QR onde, estando o valor de 73% de confian¸ca total (CS), foram
necess´arias trˆes mensagens para aumentar 1% deste valor. Estas pequenas varia¸c˜oes
ocorrem at´e 76%, quando sofre uma eleva¸c˜ao, que corresponde ao aumento do valor de
confian¸ca total (CS) para 81%, tamb´em devido ao recalculo do valor de confian¸ca global
dos servidores (CGS).
Figura 7.7: Acompanhamento do Grau de Confian¸ca do Servidor 6
Esta figura apresenta uma deficiˆencia no funcionamento do TrustMail. Partindo
do ponto, cujo grau de confian¸ca total (CS) ´e de 80%, foram necess´arias oito mensagens
maliciosas para diminuir em 1% o grau de confian¸ca total (CS) e somente duas mensagens
leg´ıtimas para aumentar este mesmo grau. Esta diferen¸ca de valores ´e justificada pela
f´ormula QR:
Quantidade necess´aria de mensagens leg´ıtimas
QR = (1 − 0.8) ∗ 10 = 0 .2 ∗ 10 = 2
Quantidade necess´aria de mensagens maliciosas
QR = 0.8 ∗ 10 = 8
93
Desta forma, um dom´ınio poderia ter sua confian¸ca diminu´ıda ao enviar oito men-
sagens maliciosas e sua confian¸ca aumentada posteriormente enviando apenas duas men-
sagens.
Este ´ultimo gr´afico apresenta uma vis˜ao geral de todos os servidores funcionando
nas mesmas condi¸c˜oes de quantidades de mensagens e propaga¸c˜ao de confian¸ca entre os
seus respectivos grupos de relacionamento. O gr´afico demonstra o comportamento dos
servidores no recebimento das vinte e cinco primeiras mensagens.
Figura 7.8: Acompanhamento de Grau de Confian¸ca de Servidores
7.2.3 An´alise do desempenho
O desemp enho foi medido analisando o temp o de resposta do TrustMail para o
servidor de e-mail, o tempo m´edio gasto para a propaga¸c˜ao de confian¸ca e o tempo m´edio
gasto na comunica¸c˜ao de servidores pertencentes a um grupo comum.
Desempenho local
A avalia¸c˜ao do tempo de resposta do TrustMail foi feita utilizando uma ´unica
m´aquina virtual (para n˜ao sobrecarregar o processamento da m´aquina). Neste teste foram
enviadas, quinze vezes, vinte e cinco mensagens maliciosas e vinte e cinco mensagens
leg´ıtimas para o servidor de e-mail da m´aquina virtual com o TrustMail e vinte e cinco
mensagens maliciosas e vinte e cinco mensagens leg´ıtimas para o mesmo servidor de e-mail
da m´aquina virtual sem o TrustMail. Em ambos os caso, o MTA foi integrado com o
94
SPF, SpamAssassin e Clamav. Todas as mensagens foram enviadas utilizando um ´unico
canal de comunica¸c˜ao SMTP. Os resultados do teste s˜ao apresentados na tabela 7.1.
Tabela 7.1: Tempo de reposta do TrustMail para o servidor de e-mail
Servidor sem TrustMail Servidor com TrustMail Custo (%)
1
o
envio 40s 45s 12,5%
2
o
envio 38s 45s 18,5%
3
o
envio 42s 47s 12,0%
4
o
envio 41s 48s 17,0%
5
o
envio 39s 53s 36,0%
6
o
envio 42s 52s 23,0%
7
o
envio 42s 59s 40,5%
8
o
envio 41s 58s 41,5%
9
o
envio 39s 62s 59,0%
10
o
envio 37s 65s 75,5%
11
o
envio 42s 65s 54,5%
12
o
envio 41s 69s 68,0%
13
o
envio 42s 66s 57,0%
14
o
envio 39s 70s 79,5%
15
o
envio 40s 73s 82,5%
Analisando os resultados, nota-se que os valores de tempo no recebimento de men-
sagens por um servidor de e-mail sem TrustMail ´e constante. J´a o temp o no recebimento
de mensagens por um servidor de e-mail com TrustMail cresce a cada comunica¸c˜ao. Este
aumento de tempo ´e causado pelas consultas SQL na base de dados de confian¸ca. Quanto
maior a base de dados, maior ser´a o tempo de procura.
Desempenho na comunica¸c˜ao entre servidores
Para a avalia¸c˜ao do desempenho remoto, foram realizados trˆes testes. O primeiro
teste com quatro m´aquinas, o segundo teste com doze m´aquinas e o terceiro teste com
vinte m´aquinas virtuais. Essas m´aquinas foram divididas em duas m´aquinas reais. Neste
teste, todas as m´aquinas fazem parte de um grupo de confian¸ca comum. Optou-se por
um grupo de confian¸ca comum para avaliar o pior dos casos, onde, todas as m´aquinas
dever˜ao se comunicar entre si. A base de confian¸ca para o teste de comunica¸c˜ao foi gerada
a partir dos testes anteriores. A partir desta base de confian¸ca, as m´aquinas trocaram
95
informa¸c˜oes e geraram um percentual de confian¸ca comum (visto que todas as m´aquinas
possuem a mesma base de confian¸ca). Os resultados deste teste ´e apresentado na tabela
7.2.
Tabela 7.2: Tempo m´edio de comunica¸c˜ao entre os servidores do grupo de confian¸ca
Tempo m´edio de comunica¸c˜ao
Quatro M´aquinas 3s
Doze M´aquinas 7s
Vinte M´aquinas 13s
Os resultados apresentam um aumento no tempo de comunica¸c˜ao a medida que o
n´umero de servidores do grupo aumenta. Esta an´alise de tempo de comunica¸c˜ao n˜ao gera
resultados confi´aveis, pois as m´aquinas virtuais encontram-se no mesmo espa¸co f´ısico e a
comunica¸c˜ao entre elas ´e feita diretamente pela mem´oria. Para serem gerados resultados
7.4 Conclus˜ao
Este cap´ıtulo descreveu o prot´otipo do TrustMail e as altera¸c˜oes no processo de
recebimento de e-mail conforme proposta no cap´ıtulo 6. A implementa¸c˜ao demonstrou
como as redes de relacionamento podem ser modelos interessantes a serem utilizados na
confian¸ca de servi¸cos da internet.
97
Conclus˜ao
Este trabalho descreveu a proposta de um modelo de confian¸ca em servidores de e-
mail. A base da proposta foi gerar a confian¸ca de cada servidor que se comunica com outro
servidor e utilizar esta confian¸ca para aumentar ou diminuir gradualmente a quantidade
de mensagens que ser˜ao recebidas de um servidor emissor. A confian¸ca ´e propagada
pela rede para tentar atingir o maior n´umero de servidores confi´aveis atrav´es do modelo
de redes de relacionamento, tornando as listas de servidores confi´aveis e n˜ao confi´aveis
descentralizadas.
O prot´otipo implementado, apresentou resultados interessantes, contudo deve ser
melhorado. Os c´alculos de confian¸ca apresentaram problemas no c´alculo de quantidade
de mensagens, pois um servidor com um grau de confian¸ca alto precisa de mais mensagens
maliciosas para perder a confian¸ca do que para ganhar. Com isso, ele ´e capaz de enviar
uma quantidade X de mensagens maliciosas e perder um porcento a confian¸ca e enviar a
mesma quantidade de mensagens leg´ıtimas e aumentar em dois porcento a confian¸ca.
As principais contribui¸c˜oes deste trabalho foram:
• Estudo de modelos de servi¸cos de autentica¸c˜ao de e-mail: neste estudo foram lev-
antados os principais mecanismos de autentica¸c˜ao de remetente e suas principais
fragilidades;
• Estudo de modelos de confian¸ca baseado em seres humanos que podem e vˆem sendo
utilizados em sistemas computacionais, para tentar resolver problemas relacionados
a autenticidade e confian¸ca em sistemas distribu´ıdos;
• Definir um modelo de confian¸ca baseado em redes de relacionamento na tentativa
de minimizar a quantidade de spam a serem enviados por poss´ıveis servidores spam-
mers;
• Implementar o modelo de confian¸ca definido para validar a proposta;
Outros aspectos deste trabalho que podem ser explorados em trabalhos futuros
correspondem `a reputa¸c˜ao dos membros de um grupo de confian¸ca e os melhores valores
para as constantes do modelo de confian¸ca. Uma alternativa, ´e implementar algoritmos de
reputa¸c˜ao presentes em redes de relacionamento para gerar grupos de confian¸ca de forma
autom´atica. Al´em disso, podem ser realizados testes mais detalhados com o TrustMail,
alterando os valores constantes do sistema para chegar a valores mais expressivos.
99
Referˆencias Bibliogr´aficas
[Abd04] Abdul-Kareem Abdullah. Protecting your good name: identity theft and its
prevention. In InfoSecCD ’04: Proceedings of the 1st annual conference on
Information security curriculum development, pages 102–106, New York, NY,
USA, 2004. ACM Press.
[AK04] E. Allman and H. Katz. Sender id: Authenticating e-mail. Technical rep ort,
Microsoft, 2004.
[BR05] P. Oscar Boykin and Vwani P. Roychowdhury. Leveraging social networks to
fight spam. IEEE Computer, 38(4):61–68, 2005.
[Car61] Fernando Henrique Cardoso. Homem e sociedade : leituras b´asicas de soci-
ologia geral. Sao Paulo: Nacional, 1961.
[CDN05] Paul Alexandru Chirita, J¨org Diederich, and Wolfgang Nejdl. Mailrank: Using
ranking for spam detection. ACM International CIKM Conference , 2005.
[CL98] Lorrie Faith Cranor and Brian A. LaMacchia. Spam! Commun. ACM,
41(8):74–83, 1998.
[Coh90] Fred Cohen. How does a virus spread through a system. ASP Press, 1990.
[Cri96] M. Crispin. RFC 2060: Internet Message Access Proto col — Version 4rev1.
IETF RFC 2060, December 1996.
[Cro82] D. Crocker. RFC 822: Standard for the format of arpa internet text messages,
August 1982.
[Cun05] B. D. Cunningham. Message level protocol. Technical report, MessageLevel,
May 2005.
[DY04] Mark Delany and Yahoo. Domain-based email authentication using public-
keys: Advertised in the DNS (DomainKeys). Internet Draft, 2004.
100
[FB96a] N. Freed and N. Borenstein. RFC 2045: Multipurpose internet mail extensions
(mime) part one: Format of internet message bodies, November 1996.
[FB96b] N. Freed and N. Borenstein. RFC 2046: Multipurpose internet mail extensions
(mime) part two: Media types, November 1996.
[FB96c] N. Freed and N. Borenstein. RFC 2049: Multipurpose internet mail extensions
(mime) part five: Conformance criteria and examples, November 1996.
[FKP96] N. Freed, J. Klensin, and J. Postel. RFC 2048: Multipurpose internet mail
extensions (mime) part four: Registration precedures, November 1996.
[Fro04] Michael Fromberger. Bayesian classification of unsollicited e-mail.
http://thayer.dartmouth.edu/ sting/sw/bayes-spam.pdf, 2004.
[GHR05] Joshua Goodman, David Heckerman, and Robert Rounthwaite. Guerra anti-
spam. Scientific American, May 2005.
[GKRT04] R. Guha, Ravi Kumar, Prabhakar Raghaven, and Andrew Tomkins. Propaga-
tion of trust and distrust. In Proceedings of WWW 04, pages 403–412. ACM,
ACM, May 2004.
[Gra76] J. Grahagan. Comportamento interpessoal e de grupo. Rio de Janeiro: Zahar,
1976.
[Hal98] R. J. Hall. How to avoid unwanted email. Communications of the ACM,
41(3):88–95, 1998.
[Han98] Robert A. Hanneman. Introduction to social network methods, 1998.
[HKS01] Brian Hatch, George Kurtz, and Saumil Shah. Hacking Linux Exposed.
McGraw-Hill Professional, 2001.
[IDC04] IDC. The true cost of spam and the value of antispam solutions. IDC Report,
2004.
[JS04] Jaeyeon Jung and Emil Sit. An Empirical Study of Spam Traffic and the Use
of DNS Black Lists. In Internet Measurement Conference, Taormina, Italy,
October 2004.
[Kle01a] J. Klensin. RFC 2821: Simple mail transfer protocol, April 2001.
[Kle01b] J. Klensin. Simple mail transfer protocol. IETF RFC 2821, April 2001.
101
[Kop04] Gene J. Koprowski. Beware of ‘spoofing’ scams. United Press International,
2004.
[KSGM03] Sepandar D. Kamvar, Mario T. Schlosser, and Hector Garcia-Molina. The
eigentrust algorithm for reputation management in p2p networks. In WWW
’03: Proceedings of the 12th international conference on World Wide Web,
pages 640–651, New York, NY, USA, 2003. ACM Press.
[Lin99] G. Lindberg. Anti-spam recommendations for SMTP MTAs. IETF RFC 2505,
February 1999.
[Lyo05] J. Lyon. Purpoted responsible address in e-mail messages, 2005.
[MMH02] L. Mui, M. Mohtashemi, and A. Halberstadt. A computational model of trust
and reputation. In Proceedings of the 35th Hawaii International Conference
on System Sciences, 2002.
[Moo96] K. Moore. RFC 2047: Multipurpose internet mail extensions (mime) part
three: Message header extensions for non-ascii text, November 1996.
[MR96] J. Myers and M. Rose. RFC 1939: Post Office Protocol — Version 3. IETF
RFC 1939 (also STD0053), May 1996.
[Ost98] E. Ostrom. A behavioral approach to the rational choice theory of collective
action. In he American Political Science Review 92, pages 1–22, 1998.
[Pos82] J. Postel. IETF RFC 821: Simple mail transfer protocol, August 1982.
[Ram04] B. Ramsdell. RFC 2633: S/mime version 3.1 message specification, April
2004.
[RB56] Russell and Bertrand.
´
Etica e pol´ıtica na sociedade humana. Rio de Janeiro:
Zahar, 1956.
[Rib05] U Ribeiro. Sistemas Distribu´ıdos - Desenvolvendo Aplica¸c˜oes de alta perfor-
mance no Linux. Axcel Books, 2005.
[Sch94] B Schneier. Applied cryptography : protocols, algorithms, and source code in
C. New York, Wiley, 1994.
[SDHH98] M. Sahami, S. Dumais, D. Heckerman, and E. Horvitz. A bayesian approach
to filtering junk E-mail. In Learning for Text Categorization: Papers from the
102
1998 Workshop, Madison, Wisconsin, 1998. AAAI Technical Report WS-98-
05.
[SHF90] Eugene H. Spafford, Kathleen A. Heaphy, and David J. Ferbrache. A computer
virus primer. ACM Press, pages 316–355, 1990.
[Str03] Prashanth Strinthan. An overview of spam handling techniques. Technical
report, George Mason University, 2003.
[VM02] Wesley Vaz and Geovane Cayres Magalh˜aes. Um modelo para deriva¸c˜ao de
relacionamentos espaciais em equivalentes semˆanticos relacionais. IV Simp´osio
Brasileiro de GeoInform´atica - Caxamb´u, MG, 2002.
[Wei82] P. Weil. Rela¸c˜oes humanas na familia e no trabalho. ed. Petropolis: Vozes,
1982.
[WML04] Wong, Microsoft, and Lentczner. The SenderID record: Format interpretation.
http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-02.txt, 2004.
[WOB76] D. R. Woods, S. D. Omerod, and M. D. Black. Como tecer uma rede de
relacionamentos e se valer dela. S˜ao Paulo :Nacional, 1976.
[Won04] M. Wong. Sender Policy Framework (SPF): A conven-
tion to describe hosts authorized to send SMTP traffic.
http://db.org/drafts/internet/mengwong/spf/00/, 2004.
[ZGT02] Cliff Changchun Zou, Weibo Gong, and Don Towsley. Code Red worm prop-
agation modeling and analysis. In 9th ACM conference on Computer and
Communications Security, pages 138–147, 2002.
[Zim95] P. R. Zimmermann. The Official PGP User’s Guide. The MIT Press, 1995.
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo