Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA
PAULA SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA
CURSO SUPERIOR DE TECNOLOGIA EM REDES DE COMPUTADORES
PAULO EDUARDO DE MORAES BINI
RODRIGO ALEXANDRE DA SILVA
TECNOLOGIAS DE CONTROLE DE SPAM
LINS/SP
2º SEMESTRE/2012
CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA
PAULA SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA
CURSO SUPERIOR DE TECNOLOGIA EM REDES DE COMPUTADORES
PAULO EDUARDO DE MORAES BINI
RODRIGO ALEXANDRE DA SILVA
TECNOLOGIAS DE CONTROLE DE SPAM
Trabalho de Conclusão de Curso apresentado à Faculdade de Tecnologia de Lins para obtenção do Título de Tecnólogo em Redes de Computadores. Orientador: Prof. Me. Júlio Fernando Lieira.
LINS/SP
2º SEMESTRE/2012
PAULO EDUARDO DE MORAES BINI
RODRIGO ALEXANDRE DA SILVA
TECNOLOGIAS DE CONTROLE DE SPAM
Trabalho de Conclusão de Curso apresentado à
Faculdade de Tecnologia de Lins, como parte dos
requisitos necessários para a obtenção do título de
Tecnólogo em Redes de Computadores sob
orientação do Prof. Me. Júlio Fernando Lieira.
Data de aprovação:___/___/___
___________________________________
Orientador Prof. Me. Júlio Fernando Lieira
___________________________________
___________________________________
Este trabalho é dedicado aos que mais
desejaram a minha chegada até aqui, por isso
faço uma homenagem póstuma aos meus amados
e queridos pais Marineide de Moraes Bini (sete
anos) e José Eduardo Bini (três meses) que
presenciou o início desta jornada, me deu todo o
apoio, mas infelizmente já não pôde estar ao meu
lado nesta linha de chegada.
Paulo Eduardo de Moraes Bini
A meus pais, Rodolfo e Roseli que tanto me
apoiaram e me incentivaram de forma
incondicional. Meus irmãos Rodolfo Filho e
Rafaela, e todas as aquelas pessoas que de
alguma forma contribuíram para finalização desse
trabalho.
Rodrigo Alexandre da Silva
AGRADECIMENTOS
Agradeço primeiramente a Deus, por permitir que eu chegasse até aqui, em
meio a todas as dificuldades que encontrei neste trabalho e nestes anos de
faculdade só mesmo a fé foi capaz de me dar o sustento que eu tanto precisei.
Agradeço ao meu grande amigo Rodrigo que juntamente a mim encarou este
trabalho com dedicação e seriedade, realmente ele não mediu esforços para que
atingíssemos nosso objetivo de realizar este trabalho.
Agradeço a minha querida esposa Loiriane, pelo amor e carinho que sempre
me dedicou, esteve o tempo todo do meu lado e foi fator crucial para me fazer ver
flores pelo longo caminho que trilhei, a ela tenho minha especial gratidão.
Agradeço ao Professor Júlio, que tanto fico honrado por ter conhecido,
convivido e ter sido orientado, em mim ficarão sempre guardados seus exemplos de
determinação e comprometimento, assim como seus ensinamentos, a ele tenho meu
profundo respeito e admiração.
Agradeço também aos demais professores, colegas e colaboradores, cujo
quais passei a viver inúmeros dias mais próximo deles do que de minha própria casa
e família, todos definitivamente fizeram e fazem parte da minha vida.
Paulo Eduardo de Moraes Bini
AGRADECIMENTOS
Em primeiro lugar agradeço a DEUS, por me conceder sabedoria e forças
para concluir esse trabalho depois de dias e dias de estudos, agradeço também por
ter me mantido firme nesses três anos de Faculdade.
Agradeço também ao meu amigo e parceiro de monografia Paulo, por todos
os dias dedicados exclusivamente a esse trabalho, deixando de lado muitas vezes
seus interesses pessoais.
Agradeço em especial toda a minha família, por entenderem todos os dias
dedicados exclusivamente à finalização desse trabalho.
Deixo aqui registrado os meus sinceros agradecimentos ao Professor Me.
Júlio, pela orientação, ajuda e o tempo dedicado a esse trabalho, que foram de
estrema importância para alcançarmos nossos objetivos. Não posso deixar de
agradecer também a todos os professores, em especial a Prof.ª Adriana, Prof.ª
Luciana e ao Prof. Alexandre Ponce.
Aos meus amigos, e colegas de trabalho por suportarem todos aqueles dias
de reclamação e stress.
Rodrigo Alexandre da Silva
RESUMO
No contexto globalizado atual, a comunicação é indispensável e representa um dos mais comuns atos cotidianos da humanidade. No mundo virtual não é diferente e um dos principais meios de comunicação é o correio eletrônico, cuja utilização tem sido ameaçada devido ao mau uso da tecnologia através do envio de mensagens não solicitadas - spam, estas são originadas de diversas formas e para os mais diversos objetivos e trazem enormes prejuízos aos usuários, desempenho de servidores de redes e corporações. Este trabalho tem por objetivo um estudo de técnicas para reduzir o alto índice de spam e os seus transtornos fazendo o bloqueio de mensagens não solicitadas dentro dos servidores de e-mail, tornando as ações eficientes e discretas à ótica do usuário final. Para tanto, testes foram feitos em um ambiente de rede virtual composto por dois servidores de e-mail, visando demonstrar as transações de envio e recebimento de mensagens entre eles. Um deles conteve os softwares Postfix, Clamav e Spamassassin, já o outro conteve somente o Postfix e estes foram configurados com técnicas de combate ao spam. Tais técnicas foram testadas também em um servidor real de frente para a Internet e em produção. Ao final foram geradas estatísticas sobre oito dias de atividade do servidor real que tornaram possível demonstrar as ferramentas e técnicas anti-spam. As ferramentas e técnicas testadas comprovadamente foram vitais para segurança dos servidores de e-mail. Palavras-chave: Spam. E-mail. Servidores MTA.
ABSTRACT
On the actual globalized context. The communication is indispensable and represents one of the most common acts of humanity. In the virtual world is no different and one of most means of communication is the electronic mail that has been threatened because of the misuse of technology by unsolicited messages. They are originated in different ways and for different purposes that brings huge losses to users, network servers performance and corporations. This work aims to reduce the high rate of spam and its disorders by blocking unsolicited messages inside the e-mail servers, making efficient and discrete actions of the end user perspective. For those purposes were implanted in a virtual network two email servers aiming to demonstrate transaction sending and receiving messages between them. In your essence into each server were contained Postfix, Clamav, SpamAssasin and other softwares which were set up with spam combat techniques. The techniques were also tested on a real server facing the Internet and in production, at the end statistics were generated on respect of 8 days of real server activity who made it possible to demonstrate the tools and techniques to fight spam. The tools and techniques tested proved to be vital to the email servers are viable. Keywords: Spam. E-mail. MTA Servers.
LISTA DE ILUSTRAÇÕES
Figura 1.1 – A rede de computadores Arpanet.......................................................... 20
Figura 1.2 – O Modelo de Referência TCP/IP. .......................................................... 20
Figura 1.3 – Parte do espaço de nomes do DNS mostrando a divisão em zonas..... 24
Figura 1.4 – Exemplo de comunicação SMPT .......................................................... 25
Figura 1.5 – As camadas de rede, de transporte e de aplicação. ............................. 27
Figura 1.6 – Encapsulamento de TPDUs, pacotes e quadros. .................................. 28
Figura 1.7 – Um protocolo usando confirmação positiva com retransmissão. .......... 31
Figura 1.8 – O cabeçalho IPv4 (Internet Protocol). ................................................... 32
Figura 1.9 – Formatos de endereços IP. ................................................................... 33
Figura 1.10 – Posicionamento e operação de uma caixa NAT.................................. 34
Figura 1.11 – Um fluxo de pacotes indo do transmissor até o receptor. ................... 36
Figura 1.12 – O encapsulamento de um datagrama IP em um frame. ...................... 37
Figura 2.1 – Serviços do Agente de Usuário ............................................................. 40
Figura 2.2 – Envio e recebimento de e-mail .............................................................. 42
Figura 2.3 – Formato de uma mensagem eletrônica ................................................. 43
Figura 2.4 – Alcance do Protocolo SMTP ................................................................. 44
Figura 2.5 – POP e IMAP .......................................................................................... 44
Figura 2.6 – Funcionamento do Protocolo POP ........................................................ 46
Figura 2.7 – Sistema de Webmail ............................................................................. 47
Figura 3.1 – Exemplo de e-mail do tipo Corrente ...................................................... 51
Figura 3.2 – E-mail fraudulento usando o nome do Banco do Brasil ......................... 52
Figura 3.3 – Trecho do e-mail com o golpe da Nigéria .............................................. 53
Figura 3.4 – Envio de e-mail spam através de open relay ........................................ 57
Figura 4.1 – Ambiente Virtual .................................................................................... 62
Figura 4.2 – Configurações do servidor Thor no Outlook .......................................... 63
Figura 4.3 – Configurações do servidor Rodrigo no Outlook ..................................... 64
Figura 4.4 – Log gerado com o envio de e-mail de Rodrigo para Thor ..................... 64
Figura 4.5 – Log gerado com o recebimento do e-mail do Rodrigo para Thor .......... 65
Figura 4.6 – E-mail disponível na caixa de entrada do usuário ................................. 65
Figura 4.7 – Transação SMTP. ................................................................................. 67
Figura 4.8 – Diretório do Postfix. ............................................................................... 69
Figura 4.9 – Log de e-mail com rejeição. .................................................................. 70
Figura 4.10 – Log de e-mail rejeitado ........................................................................ 70
Figura 4.11 – Log de e-mail rejeitado - FQDN ........................................................... 71
Figura 4.12 – Log de e-mail rejeitado – Domínio inexistente..................................... 71
Figura 4.13 – Arquivo main.cf – RBLs ....................................................................... 72
Figura 4.14 – Arquivo de configuração com regras de lista de acesso. .................... 73
Figura 4.15 – Conteúdo do arquivo cliente_access. .................................................. 73
Figura 4.16 – Log gerado com rejeição do e-mail / Lista de Acesso. ........................ 73
Figura 4.17 – Mensagem enviada ao remetente ....................................................... 74
Figura 4.18 – Conteúdo do arquivo que analisa o cabeçalho da mensagem ............ 74
Figura 4.19 – Mensagem de erro ao Administrador .................................................. 75
Figura 4.20 – Trecho do arquivo cabeçalho_da_mensagem .................................... 76
Figura 4.21 – Bloqueio por cabeçalho ....................................................................... 77
Figura 4.22 – Bloqueios ............................................................................................ 77
Figura 4.23 – Log de e-mail rejeitado por conter vírus. ............................................. 79
Figura 4.24 – Sintaxe de uma regra no Spamassassin ............................................. 81
Figura 4.25 – Exemplo de regra de corpo. ................................................................ 81
Figura 4.26 – Exemplo de regra de cabeçalho. ......................................................... 81
Figura 4.27 – Exemplo de regra de URI. ................................................................... 81
Figura 4.28 – Exemplo de regra de rawbody............................................................. 82
Figura 4.29 – Exemplo de regra de meta. ................................................................. 82
Figura 4.30 – Exemplo de uma mensagem definida como spam. ............................. 82
Figura 4.31 – Mensagens consideradas Spams. ...................................................... 83
LISTA DE QUADROS
Quadro 1.1 – Uma comparação entre POP3 e IMAP. ............................................... 27
Quadro 1.2 – As primitivas para um serviço de transporte simples. .......................... 28
Quadro 1.3 – O formato dos campos em um datagrama UDP. ................................. 30
Quadro 1.4 – Formato de um segmento TCP com um cabeçalho TCP. ................... 31
Quadro 1.5 – Os principais tipos de mensagens ICMP. ............................................ 36
Quadro 4.1 – Restrições ........................................................................................... 68
Quadro 4.2 – Tipos de Bloqueio ................................................................................ 76
Quadro 4.3 – Estatística Geral de Bloqueios............................................................. 84
Quadro 4.4 – Bloqueios pelo Postfix ......................................................................... 84
LISTA DE ABREVIATURAS E SIGLAS
ACK – Acknowledgement
AFF – Advanced Fee Fraud
ASCII – American Standard Code for Information Interchange
CERT – Centro de Estudos, Respostas e Tratamento de Incidentes de Segurança no
Brasil
CGI – Comitê Gestor de Internet no Brasil
DNS – Domain Name System
ESMTP – Extended Simple Mail Transfer Protocol
EUA – Estados Unidos da América
FQDN – Fully Qualified Domain Name
FTP – File Transfer Protocol
GPL – General Public License
GUI – Graphical User Interface
HTTP – HyperText Transfer Protocol
ICMP – Internet Control Message Protocol
IMAP – Internet Message Access Protocol
IP – Internet Protocol
IPv4 – Internet Protocol Version 4
IPv6 – Internet Protocol Version 6
ISP – Internet Service Provider
LAN – Local Area Network
MAC – Media Access Control
MAPS – Mail Abuse Prevention System
MTA – Mail Transfer Agent
MUA – Mail User Agent
NAT – Network Addres Translation
ORDB – Open Relay Database
OSI – Open Systems Interconnection
PAR – Positive Acknowledgement with Retransmition
PID – Process Identifier
POP – Post Office Protocol
RBL – Real Time Blackhole List
RFC – Request for Comments
SMTP – Simple Mail Transfer Protocol
SPF – Sender Policy Framework
TCP/IP – Transport Protocol / Internet Protocol
TCP – Transport Protocol
TPDU – Transport Protocol Data Unit
UCE – Unsolicited Comercial E-mail
UDP – User Datagram Protocol
URL – Uniform Resource Locator
WAN – Wide Area Network
SUMÁRIO
INTRODUÇÃO ..................................................................................... 17
1 ARQUITETURA TCP/IP .................................................................... 19
1.1 ORIGEM E HISTÓRICO ...................................................................................... 19
1.2 ARQUITETURA TCP/IP ...................................................................................... 19
1.3 CAMADA DE APLICAÇÃO .................................................................................. 21
1.4 CAMADA DE TRANSPORTE .............................................................................. 27
1.5 CAMADA IP ......................................................................................................... 31
1.6 CAMADA DE INTERFACE DE REDE ................................................................. 37
2 CORREIO ELETRÔNICO .................................................................. 39
2.1 HISTÓRICO ........................................................................................................ 39
2.2 ARQUITETURA ................................................................................................... 40
2.3 FUNCIONALIDADES DO CORREIO ELETRÔNICO ........................................... 41
2.4 ELEMENTOS DO CORREIO ELETRÔNICO ....................................................... 42
2.4.2 Mail Transfer Agent – (MTA) ............................................................................ 43
2.4.3 Mail User Agent – (MUA) .................................................................................. 44
2.4.4 Protocolos de Correio Eletrônico ...................................................................... 45
2.4.4.1 SMTP ............................................................................................................ 45
2.4.4.2 POP ............................................................................................................... 45
2.4.4.3 IMAP .............................................................................................................. 46
2.5 WEBMAIL ............................................................................................................ 47
3 SPAM ................................................................................................ 49
3.1 HISTÓRICO ......................................................................................................... 49
3.2 TIPOS DE SPAM ................................................................................................. 50
3.2.1 Boatos .............................................................................................................. 50
3.2.2 Correntes .......................................................................................................... 51
3.2.3 Lendas Urbanas ............................................................................................... 52
3.2.4 Propaganda ...................................................................................................... 52
3.2.5 Fraudes ............................................................................................................ 52
3.2.6 Golpes .............................................................................................................. 53
3.2.7 Códigos maliciosos (Malware) .......................................................................... 53
3.2.8 Vírus ................................................................................................................. 54
3.2.9 Worms .............................................................................................................. 54
3.2.10 Trojans (Cavalo de Tróia) ............................................................................... 54
3.2.11 Pornografia ..................................................................................................... 54
3.2.12 Ameaças e brincadeiras ................................................................................. 54
3.2.13 Spam via Instant Messengers (Spim) ............................................................. 55
3.3 SPAMMERS ........................................................................................................ 55
3.3.1 Ferramentas ..................................................................................................... 55
3.3.2 Tipos de spammers .......................................................................................... 56
3.4 COMBATE AO SPAM .......................................................................................... 56
3.4.1 Listas Negras de open relays ........................................................................... 58
3.4.1 Filtro anti-spam ................................................................................................. 58
3.4.2 Spamassassin .................................................................................................. 60
3.4.3 Bogofilter .......................................................................................................... 60
3.5 POLÍTICAS ANTI-SPAM ...................................................................................... 60
4 TECNOLOGIAS ANTI-SPAM ............................................................ 62
4.1 CONFIGURAÇÕES DO AMBIENTE .................................................................... 62
4.2 POSTFIX ............................................................................................................. 66
4.2.1 Configuração de bloqueio de Spam do Postfix ................................................. 66
4.2.3 Restrições de Clientes...................................................................................... 69
4.2.4 Restrições de Hostname/DNS/IP ..................................................................... 70
4.2.5 Restrições de entrega forçada de e-mail .......................................................... 71
4.2.6 Bloqueio usando RBLs ..................................................................................... 72
4.2.7 Bloqueio a partir de Listas de Acesso .............................................................. 72
4.2.8 Bloqueio a partir do Conteúdo .......................................................................... 75
4.2.9 Restrições por Classes ..................................................................................... 77
4.3 CLAMAV .............................................................................................................. 78
4.4 SPAMASSASSIN ................................................................................................ 79
4.5 ANÁLISE DOS RESULTADOS ............................................................................ 83
CONCLUSÃO ....................................................................................... 86
17
INTRODUÇÃO
De acordo com Ibope (2012), o número de pessoas que utilizam a Internet
cresce cada vez mais a cada ano. No Brasil este número em 2012 já chega a 83,4
milhões de usuários. Outra pesquisa divulgada em Cgi (2010) aponta que em 2010,
97% das empresas de diversos setores no Brasil utilizavam computadores. Ainda
em Cgi (2010), o serviço de correio eletrônico é uma das aplicações mais utilizadas
pelos internautas e também se tornou uma ferramenta muito importante para os
negócios das empresas com utilização de 98% nas empresas que possuem acesso
à Internet.
Junto com todos os benefícios que a Internet proporciona para usuários e
empresas, também surgem os problemas advindos do mau uso da tecnologia por
determinadas pessoas, como é o caso das mensagens de correio eletrônico
indesejadas, também conhecidas por spam, recebidas diariamente por praticamente
todos os usuários da Internet. Segundo Teixeira (2004), o spam se tornou uma
ameaça ao serviço básico da Internet: o e-mail. Esse tipo de e-mail é considerado
um abuso e refere-se ao envio de mensagens não solicitadas.
De acordo com o Cert (2012) mais de quinhentos mil spams já foram
denunciados, isso até maio de 2012, que corresponde aproximadamente 10% dos e-
mails spams reportados ao Centro de Estudos, Respostas e Tratamento de
Incidentes de Segurança no Brasil (CERT) do ano de 2011.
O envio e recebimento de spam tem um grande impacto negativo na
produtividade dos funcionários das empresas, os quais gastam muito tempo para se
livrarem de tais mensagens, além de degradar o desempenho de servidores e redes.
A partir disso, identificou-se a importância do uso das tecnologias de controle
de spam. Segundo Teixeira (2004, p. 116): “à medida que se torna mais caótica a
situação criada pelo grande volume de spam na rede, cresce a necessidade de
adoção de medidas para combater o problema”.
Existem diversas maneiras e ferramentas para se combater o spam. A maioria
delas procura por características nas mensagens de correio eletrônico que possam
identificá-las como spam.
Frente a esses dados, a perspectiva desse trabalho volta-se para soluções de
combate aos e-mails não solicitados, o spam, e nos possíveis problemas de
18
segurança que podem causar.
Dessa forma, esse trabalho tem por finalidade mostrar as tecnologias de
controle de spam e testá-las a fim de descobrir qual a melhor opção, dando
subsídios ao administrador de rede para escolher o software com o melhor
desempenho e eficiência no combate ao spam. Tais tecnologias foram testadas em
uma rede virtual e as principais técnicas foram implementadas em um servidor de
correio eletrônico de um domínio real. Uma análise dos registros de mensagens
recebidas, enviadas e descartadas deste servidor de correio, mostrou a eficiência de
cada técnica implementada.
A seguir uma breve descrição da estrutura do trabalho.
O primeiro capítulo descreve a arquitetura Transmission Control Protocol /
Internet Protocol (TCP/IP), bem como suas camadas: aplicação, transporte, redes e
interface de redes. Os principais protocolos também são destacados, sobretudo os
protocolos relacionados ao correio eletrônico.
O segundo capítulo apresentara o correio eletrônico, sua definição, aplicação
e evolução. O protocolo Simple Mail Transfer Protocol (SMTP), utilizado para
transferir e-mails, terá uma maior ênfase. Conceitos de cliente e servidor serão
exemplificados ao longo do texto.
Já no terceiro capítulo são apresentados os tipos de mensagens não
solicitadas, ou spam, definidos de acordo com suas características. É feita uma
classificação dos tipos de spammers, finalizando o capítulo com uma discussão
teórica das formas de combate ao spam.
No quarto capítulo as ferramentas de combate ao spam ganharam mais
detalhes, bem como suas técnicas. As aplicações serão instaladas, comparadas e
testadas, a fim de documentar e demonstrar seu funcionamento e seus respectivos
resultados no combate ao spam. Após a avaliação destes testes serão apresentadas
às conclusões finais do trabalho.
19
1 ARQUITETURA TCP/IP
É fundamental para que se possa entender o spam e o funcionamento do
serviço de e-mail, compreender previamente o funcionamento das tecnologias de
redes de computadores, tanto genéricas quanto as empregadas como parte do
mecanismo de e-mail. Para tal este capítulo se destina a explicar o funcionamento
básico de uma rede de computadores, apresentando a origem da Internet, a
arquitetura Transport Protocol / Internet Protocol (TCP/IP), as camadas de aplicação
e transporte, e os detalhes da camada IP.
1.1 ORIGEM E HISTÓRICO
Segundo Morimoto (2008), como quase tudo na informática, as redes
passaram por um longo processo de evolução antes de chegarem aos padrões
utilizados atualmente. No entanto, faz-se necessário o conhecimento a respeito da
origem das redes de computadores e da Internet.
Afirma ainda Morimoto (2008) que de 1969 a 1972 foi criada a Arpanet,
embrião da Internet que conhecemos hoje. A rede entrou no ar em 1969,
inicialmente com apenas 4 nós.
A rede Arpanet foi desenvolvida com finalidades de teste na comunicação
remota entre computadores de diferentes arquiteturas, tendo em vista futuramente
prover a segurança que seria necessária para a consistência de dados em um
ambiente de guerra, ocasião em que um computador juntamente a todas suas
informações poderia ser destruído ou receptado por forças inimigas. A figura 1.1
ilustra a rede Arpanet.
1.2 ARQUITETURA TCP/IP
Com o constante crescimento da rede e da quantidade de equipamentos que
a integravam, muito tráfego começou a ser gerado e a perda e colisão de pacotes
começou a ser um problema grave, era então necessária a criação de um modelo
para protocolos que fosse menos vulnerável a falhas de comunicação, foi então
criada a arquitetura TCP/IP.
20
Figura 1.1 – A rede de computadores Arpanet. Fonte: Computer History
Tanenbaum (2003) diz que é razoável dizer que a função da camada inter-
redes do TCP/IP é muito parecida com a da camada de rede do Open Systems
Interconnection (OSI). A figura 1.2 mostra a correspondência entre elas.
Figura 1.2 – O Modelo de Referência TCP/IP. Fonte: TANENBAUM, 2003, p 48.
A figura 1.2 mostra que o modelo TCP/IP é dividido em camadas, assim como
no modelo OSI, cada camada possui uma função específica que realiza seu trabalho
e se comunica com a próxima camada para dar sequência à empreita que está
sendo realizada. As camadas existentes são: Aplicação, Transporte, Internet e
Interface de Rede.
A camada de Aplicação é responsável por executar protocolos utilizados por
21
aplicativos que façam interface com o usuário.
No nível mais alto, os usuários invocam aplicativos que acessam serviços
disponíveis por uma Internet TCP/IP. O programa aplicativo passa dados no formato
exigido para remessa pela camada de transporte. (COMER, 2006).
Alguns protocolos suportados pela camada de aplicação são os protocolos
HyperText Transfer Protocol (HTTP), Domain Name System (DNS), Simple Mail
Transfer Protocol (SMTP), Post Office Protocol (POP) e Internet Message Access
Protocol (IMAP) – os quais serão detalhados nas próximas seções.
A camada de Transporte pode regular o fluxo de informações. Ela também
pode oferecer transporte confiável, garantindo que os dados cheguem sem erro e
em sequência. (COMER, 2006).
A camada de Internet trata das comunicações de uma máquina para outra.
Ela aceita uma requisição para enviar um pacote da camada de transporte junto com
uma identificação da máquina à qual o pacote deve ser enviado. (COMER, 2006).
A camada de Interface de Rede é responsável por aceitar datagramas IP e
transmiti-los por uma rede específica. Isso é possível através do uso de software e
hardware, que atua de acordo com as características dos meios físicos por meio de
uma interface de rede. Uma interface de rede pode consistir em um driver de
dispositivo ou um subsistema complexo que usa seu próprio protocolo de enlace de
dados. (COMER, 2006).
Para maior entendimento a respeito da arquitetura TCP/IP e seu
funcionamento, é preciso dar maior ênfase nas camadas mais complexas e seus
serviços mais habitualmente utilizados. Para isso, o próximo seguimento se dá a
explicar de forma mais específica o funcionamento das camadas de Aplicação e
Transporte, bem como os protocolos suportados e o funcionamento desses
protocolos.
1.3 CAMADA DE APLICAÇÃO
Como visto na seção anterior, a camada de Aplicação se incube de conversar
com a camada de Transporte, enviando para ela as solicitações geradas pelos
aplicativos. Cada aplicativo que faz uso de uma conexão TCP/IP, faz isto através do
uso de um protocolo específico, característico daquela aplicação. Estes protocolos
associam as informações geradas e recebidas para que um cliente analogamente
22
“converse na mesma língua” que o servidor daquele recurso em específico.
A camada de aplicação trabalha com diversos protocolos, será visto o
detalhamento da atividade de alguns dos protocolos mais comuns da camada de
aplicação.
A camada de aplicação tem por função ainda, prover a interface de um
aplicativo com o usuário e de posse das informações solicitadas/inseridas pelo
usuário neste aplicativo, realizar o trabalho, sendo assim, de longe a camada de
mais alto nível dentre as outras camadas e mais compreensível pelo usuário, por ser
“visível” a ele.
1.3.1 Protocolo HTTP
O protocolo usado para a comunicação entre um navegador e um servidor
Web ou entre máquinas intermediárias e servidores Web é conhecido como HTTP.
(COMER, 2006).
Basicamente o protocolo HTTP trabalha voltado para a navegação, os
aplicativos mais comuns que fazem uso do protocolo HTTP são os web browsers,
como o Internet Explorer, Mozilla Firefox e Google Chrome.
Este protocolo envia e recebe informações a partir de solicitações
denominadas requisições. Cada requisição informa ao servidor Web o que deseja,
então o servidor identifica e disponibiliza a informação solicitada.
A requisição consiste em uma única linha de texto que começa com a
palavra-chave GET e é seguida por um URL e um número de versão HTTP, uma
requisição ao site www.fateclins.edu.br ficaria desta forma: GET
http://www.fateclins.edu.br/HTTP/1.1 (COMER, 2006)
1.3.2 Protocolo FTP
Os protocolos de transferência de arquivo padrão existiam para a Arpanet
antes de o TCP/IP se tornar operacional. Essas primeiras versões do software de
transferência de arquivos evoluíram para um padrão atual conhecido como File
Transfer Protocol (FTP). (COMER, 2006)
De uma forma geral, a finalidade do protocolo FTP é a transferência de
arquivo de uma máquina A para uma máquina B, através de uma conexão TCP/IP.
23
Dentre as várias formas para se realizar uma transferência por FTP, a mais simples
é por web browsers, especificando na Uniform Resource Locator (URL) o recurso
pretendido, neste caso o FTP. Assim ficaria um exemplo de URL para acessar um
servidor FTP do domínio fateclins.edu.br dentro de um web browser:
ftp://fateclins.edu.br.
O servidor mantém um processo aguardando conexões de clientes, a medida
que eles se conectam, processos de transferência de dados são criados
dinamicamente. (COMER, 2006)
1.3.3 Protocolo DNS
No começo da Internet havia poucos servidores disponíveis e era até
aceitável a ideia de memorizar ou manter uma lista de endereços IP dos servidores
costumeiramente utilizados para acessá-los, mas com o crescimento constante da
rede, começou a ficar impraticável para o usuário guardar os endereços IP de todos
os servidores. Era preciso tornar o acesso aos servidores mais intuitivo e prático, e
isto foi feito por meio da criação de um protocolo para prover a conversão de nomes
para endereços IP, disponibilizada por um servidor, o servidor DNS.
Quando o endereço http://www.fateclins.edu.br é acessado, um servidor DNS
converte o “apelido” no endereço IP do servidor, para tanto o servidor DNS mantém
uma tabela atualizada que cruza o apelido com o endereço IP de cada servidor
cadastrado. (MORIMOTO, 2008)
Seria inviável o uso da Internet se não houvesse o serviço DNS, e muito
provavelmente ela não teria se tornado tão popular em tão pouco tempo. Apesar de
parecer simples à primeira vista, o serviço DNS tem sua complexidade,
especialmente pela hierarquia empregada nas atribuições dos servidores DNS. Essa
hierarquia é dividia por seções chamadas zonas, a figura 1.3 ilustra o conceito.
Segundo Morimoto (2008), os servidores DNS compõe uma cadeia
hierárquica, de forma que no primeiro nível estão os root servers, em seguida os
servidores DNS de domínios primários como .com, .net, etc. Na sequência domínios
de cada país como .edu.br ou .com.br. depois vem os domínios como
fateclins.edu.br. Estes são mantidos por instituições como o registro.br, responsável
por todos domínios pertencentes ao .br.
Para resolver um nome em um endereço IP uma consulta move um fluxo que
24
percorre toda a cadeia da hierarquia até finalmente chegar ao servidor DNS que
possui o endereço IP correspondente ao domínio consultado, o servidor DNS
consulta os root servers, que apontam para o servidor DNS primário, que aponta
para o servidor do domínio do país, que aponta para servidor do domínio consultado,
finalizando a consulta e obtendo o endereço IP. (MORIMOTO, 2008)
Figura 1.3 – Parte do espaço de nomes do DNS mostrando a divisão em zonas. Fonte: TANENBAUM, 2003, p 444.
Este tipo de consulta é denominada como consulta não recursiva, segundo
Nemeth, Snyder e Hein (2007) os servidores raiz e de domínio de primeiro nível são
todos não recursivos, pois recebem muitas consultas por segundos. Ainda Nemeth,
Snyder e Hein (2007) os servidores não recursivos tem a função de buscar uma
resposta, caso essa resposta não tiver armazenada em cache, ele retornará o
endereço de outro servidor que conhece o domínio solicitado. Já a consulta
recursiva busca o endereço do domínio solicitado em todos os servidores de
domínio até receber uma resposta verdadeira ou um erro.
1.3.4 Protocolo SMTP
Finalmente, agora é possível abordar de forma mais objetiva e clara o
funcionamento dos protocolos envolvidos no serviço de e-mail, o protocolo SMTP é
um dos mais importantes protocolos do serviço de e-mail, que têm por finalidade a
transferência de mensagens de e-mail entre um cliente e um servidor remoto.
O SMTP é estabelecido por uma conexão TCP na porta 25, e realiza suas
transações utilizando código American Standard Code for Information Interchange
(ASCII), as transações compõe uma conversa entre o servidor que está enviando
uma mensagem (cliente) e o servidor que está recebendo esta mensagem
25
(servidor), primeiramente o servidor envia sua identificação e avisa que está pronto
para receber mensagens, depois o cliente avisa que possui uma mensagem para
transmitir para determinado usuário, se este usuário existir no servidor, a mensagem
é aceita e transferida. Abaixo há um exemplo da situação apresentada:
(TANENBAUM, 2003).
Figura 1.4 – Exemplo de comunicação SMPT Fonte: TANENBAUM, 2003, p 457.
1.3.5 Protocolo POP
A troca de mensagens de e-mail como visto no item anterior pode se dar
através do uso do protocolo SMTP, porém, se essa fosse a única forma de se obter
uma mensagem isso seria um problema grave, pois para receber uma mensagem
seria preciso manter o e-mail aberto o tempo todo, caso contrário, sempre que o
26
computador que atuaria como servidor estivesse desligado ou fora da rede,
recusaria a transferência de um cliente remoto. Essa foi a motivação para a criação
de um protocolo que pudesse descarregar mensagens de um servidor crítico,
responsável pela conta de e-mail, que fosse capaz de acumular as mensagens e
transferi-las para uma outra máquina no momento em que se ela conectasse ao
servidor de e-mail, e é justamente essa a função do protocolo POP.
Para que a ação citada acima pudesse ser feita de maneira segura, o
protocolo POP incorpora rotinas de autenticação, transação e atualização, utilizando
código ASCII.
Para um usuário descarregar uma mensagem armazenada em um servidor
através do protocolo POP, o cliente precisa estabelecer uma conexão TCP na porta
110 do servidor, depois é realizada a autorização através do envio de usuário e
senha pelo cliente, se autorizado são realizadas as transações que consistem no
descarregamento de cópias das mensagens do servidor no cliente, por fim é feita a
atualização que realiza a exclusão no servidor das mensagens que já foram
descarregadas pelo cliente. (TANENBAUM, 2003)
As mensagens podem ou não ser excluídas no servidor após a transferência
das mesmas via POP, no entanto existem configurações para manter as mensagens
na caixa de entrada mesmo após serem descarregadas.
1.3.6 Protocolo IMAP
O protocolo IMAP é uma alternativa ao protocolo POP na visualização de
mensagens de e-mail. O IMAP não efetua o descarregamento das mensagens no
servidor, mas sim a exibição das caixas de correio, como as caixas de entrada, itens
enviados, lixeira, spam entre outras. Dessa forma, é possível manter as mensagens
no servidor e visualizá-las igualmente de qualquer computador a qualquer momento,
o que é ideal para quem precisa abrir o e-mail em mais de um computador.
O IMAP possibilita a criação de caixas adicionais, separando as mensagens
da forma que lhe for mais conveniente, possivelmente possuindo uma caixa para
SPAM, outra para Itens lidos, outra para backup e assim por diante, possibilita ainda
o carregamento de partes de mensagens, o que é útil ao utilizar um fraco link de
Internet como Internet via mobile.(TANENBAUM, 2003)
O estilo geral do protocolo IMAP é semelhante ao do POP3, como mostra o
27
quadro 1.1, exceto pelo fato de existirem dezenas de comandos. O servidor IMAP
escuta na porta 143. (TANENBAUM, 2003)
Quadro 1.1 – Uma comparação entre POP3 e IMAP.
Fonte: TANENBAUM, 2003, p 461.
1.4 CAMADA DE TRANSPORTE
Sua função é promover uma transferência de dados confiável e econômica
entre a máquina de origem e a máquina de destino, independente das redes físicas
em uso no momento. (TANENBAUM, 2003)
A camada de transporte atua na comunicação entre as camadas de aplicação
e de rede e seu relacionamento (lógico) existente está ilustrado na figura 1.5.
A camada de transporte permite aos programas aplicativos estabelecer, usar
e encerrar uma conexão, o que é suficiente para muitas aplicações (TANENBAUM,
2003).
Figura 1.5 – As camadas de rede, de transporte e de aplicação. Fonte: TANENBAUM, 2003, p 369.
28
Para ter uma ideia de como deve ser um serviço de transporte, o quadro 1.2
mostra as cinco primitivas.
Quadro 1.2 – As primitivas para um serviço de transporte simples.
Fonte: TANENBAUM, 2003, p 371.
Os serviços de transporte do cliente e do servidor se comunicam através das
primitivas apresentadas, assim negociando o estabelecimento de uma conexão,
realizada a conexão, os pacotes advindos de outras camadas são encapsulados
dentro de pacotes de transporte (TPDU) ilustrado na figura 1.6, que por sua vez é
encapsulado pelo pacote de rede, que depois é encapsulado pelo quadro do frame
ethernet, que ao fazer o processo inverso e chegar a camada de transporte remota
são extraídos e se dá a sucessão deles as camadas originalmente respectivas a
eles. (TANENBAUM, 2003)
Figura 1.6 – Encapsulamento de TPDUs, pacotes e quadros. Fonte: TANENBAUM, 2003, p 371.
Este é o funcionamento básico de um protocolo de transporte, que age se
comunicando com a camada de aplicação e com a camada de rede, se for um
servidor, abrindo um listen para um processo remoto no intuito de aguardar uma
conexão, e se for um cliente, abrindo um connect para tentar estabelecer uma
conexão com um servidor remoto. No entanto, para um processo se conectar a um
servidor remoto é necessário que tanto o cliente quanto o servidor identifiquem qual
dos vários processos está atingindo uma conexão remota, só o número de PID dos
processos não seria o bastante, já que os processos são criados dinamicamente e
29
um processo cliente jamais saberia o PID do processo de listen de um recurso
pretendido em um servidor. Por esse motivo, foi criado o conceito de portas, que
visa permitir diversas conexões entre um cliente através de vários processos
distintos e vários servidores utilizando um só endereço IP no cliente e um só
endereço IP no servidor. (TANENBAUM, 2003)
Existem 65536 portas TCP e mais 65536 portas UDP, cada porta pode ser
usada por um programa ou serviço diferente, utilizando um único endereço IP.
(MORIMOTO, 2008)
No entanto há grandes diferenças entre o protocolo TCP e o UDP, ambos
serão descritos no próximo seguimento, que é dado unicamente para este fim.
1.4.1 Protocolo UDP
O protocolo UDP é um protocolo de entrega de datagramas sem conexão, o
que quer dizer que não é preciso haver um contato para estabelecer uma conexão
confiável entre o cliente e o servidor para depois transferir uma informação,
simplesmente a informação é enviada diretamente do cliente ao servidor, sem se
preocupar em checar se a mensagem realmente chegou ao destino e, se for o caso
retransmiti-la e reordená-la, assim se ganha muito tempo no envio de um pacote. No
entanto isso só é possível devido a cada datagrama ser bastante pequeno e único,
sem correlação aos enviados anteriormente ou posteriormente ao seu envio. O
quadro 1.3 mostra como é simples a composição de um datagrama UDP. (COMER,
2006).
Contudo, para se utilizar uma conexão não confiável é preciso ter em mente
que ou um ou outro pacote enviado pode nunca chegar ao seu destino, então esse
tipo de conexão é indicado para enviar mensagens de um pacote só, como é o caso
do DNS, que em um só pacote envia uma requisição, e em um só pacote o servidor
DNS devolve o IP do domínio descrito na solicitação.
O transporte via UDP também é indicado para transmissão de dados ao vivo,
quando se tem maior necessidade de atualização constante do que de checar se um
dado chegou ou se está fora de ordem, a fim de evitar ao máximo os atrasos de uma
conexão em tempo real. (MORIMOTO, 2008)
30
Quadro 1.3 – O formato dos campos em um datagrama UDP.
0 16 31
PORTA DE ORIGEM UDP PORTA DE DESTINO UDP
TAMANHO DA MENSAGEM UDP CHECKSUM UDP
DADOS
... Fonte: Modificado pelos autores, 2012.
1.4.2 Protocolo TCP
Segundo Tanenbaum (2003) o protocolo UDP possui algumas limitações, no
que se refere à entrega confiável e em sequência, o que é fundamental nas
aplicações da Internet, sendo assim necessário a criação de outro protocolo, o TCP.
Comer (2006) afirma que as redes de computadores no nível mais baixo,
entregam os pacotes não confiáveis. Quando algo de errado acontece com os
pacotes, falha, sobrecarga, hardware, o sistema de comutação de pacotes altera as
rotas dinamicamente, fazendo com que os pacotes sigam aos seus destinos,
podendo chegar com atraso e fora de ordem ou entregas duplicadas. Já no nível
mais alto, a quantidade de dados que é transmitida de um computador para o outro
e muito grande, o uso de um programa de remessa não confiável pode ser
extremamente frustrante, isso exige grande empenho na detecção e recuperação
dos erros.
O protocolo TCP garante um fluxo confiável de pacotes até mesmo dentro de
um ambiente de rede hostil, garantindo a sequência de ordenação dos pacotes e a
retransmissão de pacotes perdidos. Comer (2006) diz que os protocolos de uma
forma geral usam a mesma técnica, chamada de confirmação positiva com
retransmissão ou Positive Acknowledgement with Retransmition (PAR). Essa técnica
necessita que o destinatário envie uma confirmação (ACK) quando se comunica com
a origem. Existe também um timer que controla a chegada do pacote, e se por acaso
esse timer expirar o pacote será retransmitido. A figura 1.7 ilustra o conceito.
31
Figura 1.7 – Um protocolo usando confirmação positiva com retransmissão. Fonte: Modificado pelos autores, 2012.
O quadro 1.4 mostra o formato do segmento TCP
Quadro 1.4 – Formato de um segmento TCP com um cabeçalho TCP.
Fonte: Modificado pelos autores, 2012.
1.5 CAMADA IP
O protocolo que define o mecanismo de entrega não confiável, sem conexão,
é denominado IP. (COMER, 2006).
Ainda em Comer (2006), o protocolo IP tem a função de definir a unidade
básica para transferência de dados na rede TCP/IP, ele determina o formato dos
dados que passam pela Internet. Outra função é de traçar rotas para o pacote a ser
enviado, o IP possui um conjunto de regras, nas quais determinam como hosts e
roteadores irão processar os pacotes, bem como e quando as mensagens de erro
deveram ser geradas, e até mesmo o descarte dos pacotes. Comer (2006, p 47) diz,
“IP é uma parte tão fundamental do projeto que a Internet às vezes é chamada de
tecnologia baseada em IP”.
32
O IP cumpre um papel fundamental dentro da Internet, através da unidade de
identificação de hosts, encaminhamento de mensagens e de controle de pacotes.
Assim como todos os outros protocolos, o IP possui uma unidade de transferência
de pacotes, o datagrama IP, a figura 1.8 ilustra o cabeçalho de um datagrama IP.
Figura 1.8 – O cabeçalho IPv4 (Internet Protocol). Fonte: TANENBAUM, 2003, p 334.
1.5.1 Endereçamento IP
Segundo Tanenbaum (2003) todos os hosts e roteadores na Internet possuem
um único número IP, que é sua identificação na rede. O endereço IP é formado por
32 bits é são utilizados nos campos Source address e Destination address dos
pacotes IP. É importante destacar que o endereço IP não se refere a um host, mas
sim a interface de rede.
Qualquer computador para estar conectado diretamente à Internet deve
possuir no mínimo um endereço IP válido atribuído para si. Este endereço é um
número que visa identificar sua interface de rede e distinguir, por exemplo, se um
pacote deverá ser entregue a você ou não.
Os endereços IP foram divididos em classes para melhor arranjá-los, a figura
1.9 ilustra essas classes.
33
Figura 1.9 – Formatos de endereços IP. Fonte: TANENBAUM, 2003, p 337.
Em geral, os endereços de rede, que são números de 32 bits, são escritos em notação decimal com pontos. Nesse formato, cada um dos 4 bytes é escrito em notação decimal, de 0 a 255. Por exemplo, o endereço hexadecimal de 32 bits C0290614 é escrito como 192.41.6.20. O endereço IP mais baixo é 0.0.0.0 e o mais alto é 255.255.255.255. (TANENBAUM, 2003, p 337)
Como é possível observar na figura 1.9, as classes de endereços IP possuem
uma proporção diferente de bits referentes a identificação da rede e de bits
referentes a identificação do host, dessa forma, dando subsídios ao administrador de
rede para optar por uma classe de endereços IP que seja condizente ao número de
redes e de hosts que possui o ambiente que administra. Dentro de um nível de
segurança desejável, deve-se interpretar que para cada um dos departamentos ou
setores que constituem uma rede, terá uma rede específica, favorecendo o
desempenho da rede através da redução do tráfego de pacotes, grande parte das
vezes desnecessárias, que ocorre quando se tem um número muito grande de hosts
dentro de uma mesma rede.
Outra forma de expressar a proporção de bits referentes a redes para bits
referentes a hosts em uma classe de endereços IP, é através do mascaramento, que
pode dividir o espaço antes destinado apenas a identificação de hosts, para
identificar sub-redes e um número menor de hosts, assim aumentando a proporção
de bits referentes a identificação de rede e diminuindo o número de bits referentes a
identificação de hosts, o que na prática aumenta o número de sub-redes dentro de
uma mesma classe de endereços IP.
Há uma grande quantidade de endereços IP válidos, usados para identificar
34
hosts membros da Internet, mas a quantidade disponível está longe de ser o
bastante para que cada dispositivo que se conecte à Internet possua um endereço
IP permanente, a quantidade de dispositivos aumenta a cada dia, e já a quantidade
de endereços, limitados, permanece a mesma desde o início da criação do padrão
de endereçamento IPv4.
Para fazer toda uma LAN ter acesso a Internet através de um único endereço
IP, é preciso que hajam duas redes, uma interna (LAN) e uma externa (WAN).
Os dispositivos integrantes da LAN devem possuir endereços IPs inválidos
dentro da classe de IP mais propícia ao ambiente de rede.
Nesse modelo um roteador é o único membro integrante das duas redes,
possuindo um endereço IP válido e também um endereço IP inválido, e é ele quem
repassa os pacotes destinados a Internet de uma LAN para uma WAN e vice-versa,
fazendo com que as duas redes analogamente “conversem entre si” por intermédio
dele. Este conceito é chamado de NAT (Network Address Translation), e será mais
bem explicado a seguir através de um exemplo voltado para empresas com vários
computadores e um só endereço IP válido.
Tanenbaum (2003) explica que o NAT tem função de atribuir um único
endereço IP a cada empresa para se ter o acesso a Internet, e na rede interna da
empresa são usados endereços IP exclusivos, e quando algum pacote precisa sair
para Internet o NAT faz a conversão de endereços, IP inválido para IP valido.
A operação da NAT é mostrada na figura 1.10.
Figura 1.10 – Posicionamento e operação de uma caixa NAT. Fonte: TANENBAUM, 2003, p 344.
O NAT é uma correção em curto prazo para um erro de projeto do IPv4, que
possui endereços de 32 bits apenas, possuindo poucas possibilidades de
35
combinação tendo em vista ser um protocolo de nível mundial, a solução definitiva
para este problema veio com a atualização do mesmo protocolo, o IPv6 (protocolo IP
versão 6), que possui 128 bits, ampliando muito a gama de endereços IP.
Segundo Tanenbaum (2003) o problema de se acabar os endereços IP não é
apenas teórico, mas sim real. A grande aposta vem sendo a implantação do IPv6,
que possui endereços de 128 bits, com isso aumentando o número de combinações
possíveis, mas esse processo de mudança e lento e pode levar alguns anos para
migração total. O IPv6 não é compatível com o IPv4, mas é compatível com os
protocolos auxiliares da Internet.
1.5.2 Roteamento IP
A principal função da camada de rede é rotear pacotes da máquina de origem
para a máquina de destino. Na maioria das sub-redes, os pacotes necessitarão de
vários hops para cumprir o trajeto. (TANENBAUM, 2003)
Um hop é um salto que um pacote faz entre um roteador intermediário para
transferir determinado pacote de um roteador A até um roteador C através de um
roteador B, já que na maioria das vezes, os roteadores inicial e final da transação
não estão diretamente conectados, mas indiretamente conectados através de outros
roteadores.
Para se ter uma melhor ideia de roteamento, a figura 1.11 ilustra um
roteamento de pacotes de um roteador A até um roteador E, efetuando um hop por
um roteador C.
Na figura 1.11, o motivo pelo qual o pacote fez um hop no roteador C e não
nos roteadores B e D, é porque existem diversos algoritmos de roteamento, que
seguem condições lógicas para tomar a decisão da rota a ser seguida ao enviar um
pacote.
O algoritmo de roteamento é responsável por decidir qual a linha de saída
pela qual o pacote de entrada devera ser transmitido, se caso a sub-rede utilizar
datagramas, a decisão devera ser tomada a cada pacote de dados recebidos. No
caso de utilizar circuitos virtuais a decisão só será tomada uma única vez, quando
um novo circuito virtual for estabelecido, em seguida os pacotes seguirão para seu
destino, é o que afirma Tanenbaum (2003).
36
Figura 1.11 – Um fluxo de pacotes indo do transmissor até o receptor. Fonte: TANENBAUM, 2003, p 344.
1.5.3 Protocolo ICMP
Segundo Tanenbaum (2003) toda a Internet é monitorada por roteadores, o
ICMP é um dos protocolos utilizados para monitorar a Internet, existem dezenas de
mensagens ICMP. As mensagens mais importantes estão listadas no quadro 1.5.
Cada tipo de mensagem ICMP é encapsulado em um pacote IP.
Quadro 1.5 Os principais tipos de mensagens ICMP.
Fonte: TANENBAUM, 2003, p 346.
Tanenbaum (2003) define cada uma delas, DESTINATION UNREACHABLE é
usada quando não se consegue localizar o destino. PARAMETER PROBLEM é
utilizada quando algum valor inválido é detectado no cabeçalho. SOURCE QUENCH
indica que os pacotes que estão sendo enviados são demais, esse tipo de
mensagem não é mais utilizado. REDIRECT informa ao host que foi roteado um
pacote de forma incorreta. ECHO e ECHO REPLY são utilizadas para verificar se o
destino está ativo e acessível. TIMESTAMP REQUEST e TIMESTAMP REPLY este
recurso mede o desempenho da rede.
37
1.6 CAMADA DE INTERFACE DE REDE
A camada de interface de rede exerce as funções de transmissão através da
rede física, fazendo conversão de pacotes em binários e adequando a propagação
dos dados de acordo com o meio físico empregado, no caso de uma rede ethernet,
através do encapsulamento do datagrama IP dentro de um frame Ethernet (quadro),
cada frame é uma unidade de transporte para uma rede física, posteriormente o
frame é transmitido pela interface através de impulsos elétricos.
Para Comer (2006) o datagrama IPv4 aloca 16 bits em seu tamanho total,
limitando em 65535 octetos. Para que o transporte da Internet seja eficiente, é
preciso que cada datagrama IP trafegue em um frame físico ou seja, mapeado para
um pacote real. O encapsulamento é feito quando o datagrama é transportado em
um frame de rede. O hardware não reconhece o formato do datagrama, nem
entende o endereço de destino IP. Assim, como mostra a figura 1.12, quando uma
máquina envia um datagrama IP para outra, o datagrama inteiro trafega na parte de
dados do frame de rede.
Figura 1.12 O encapsulamento de um datagrama IP em um frame. Fonte: Elaborado pelos autores, 2012.
Tanenbaum (2003) contribui dizendo que mesmo que todas as máquinas
conectadas a Internet tenham um ou mais endereços IP, não é possível transferir um
pacote à outra máquina, pois o hardware da camada de enlace de dados não
reconhece esses tipos de endereços.
É preciso então, cruzar as informações de endereço físico (MAC) com
endereço IP.
As tecnologias de rede apresentadas, protocolos e conceitos caracterizam o
conhecimento necessário para o perfeito entendimento dos conteúdos que serão
apresentados nos capítulos seguintes, dispondo uma abordagem mais direta e
38
sucinta, bem como a apresentação de padrões e conceitos com um ponto de vista e
abordagem de alto nível.
39
2 CORREIO ELETRÔNICO
O entendimento teórico do correio eletrônico é fundamental para o
prosseguimento dos estudos das tecnologias de combate a mensagens não
solicitadas ou spam. Este capítulo aborda os principais elementos do eletronic-mail
ou, traduzido, correio eletrônico, bem como seu histórico e origem.
2.1 HISTÓRICO
Segundo Tanenbaum (2003) o correio eletrônico existe há mais de três
décadas. Antes de 1990 era utilizado para fins acadêmicos, já nos anos 90 ele se
tornou muito popular, tendo um crescimento muito rápido, seu uso chegando a ser
imensamente maior do que o número de cartas de papel enviadas através do correio
convencional.
Apesar de ser informal, o e-mail como é chamado também, é usado para
comunicação formal e oficial da maioria das empresas que possuem acesso à
Internet é o que diz Cgi (2010). Segundo Tanenbaum (2003) as primeiras
mensagens eram como um arquivo de texto, na qual a primeira linha tinha que
conter o endereço de destinatário. Forouzan (2008, p. 547) diz: “No início da era da
Internet, as mensagens enviadas pelo correio eletrônico eram curtas e consistiam
apenas de texto; elas permitiam que as pessoas trocassem memorandos
rapidamente [...]”.
Com o passar do tempo as limitações do correio eletrônico ficaram mais
evidentes. Tanenbaum (2003) lista algumas dessas restrições:
Enviar mensagens para um determinado grupo de pessoas;
Não se tinha certeza da entrega ou não das mensagens;
Criar regras de encaminhamento de mensagens;
Não era possível criar mensagens contendo textos, desenhos, fax e voz.
Na medida em que os usuários ganharam mais experiência, foram surgindo
novos softwares de correio eletrônicos, bem mais elaborados, de acordo com as
propostas dos usuários. Tanenbaum (2003) complementa dizendo que até mesmo
funcionários da mesma empresa ou de empresas distintas podem trabalhar em
projetos de grande complexidade, mesmo que estejam em continentes diferentes do
40
planeta, utilizando o correio eletrônico para comunicação.
2.2 ARQUITETURA
Tanenbaum (2003) afirma que o sistema de correio eletrônico está dividido
em dois subsistemas: agentes do usuário que é responsável pelo envio e leitura, e
agente de transferência de mensagens que transmite as mensagens da origem até o
destino. Os agentes do usuário são programas locais divididos em dois tipos:
dirigidos por comando que são: mail, pine e elm, e baseados em GUI. Forouzan
(2008) diz que os componentes do GUI permitem interagir com software utilizando o
mouse e o teclado, alguns dos agentes baseados em GUI são: Eudora, Outlook e
Netscape. Já o agente de transferência de mensagens é composto por processos
que executam em segundo plano.
Para Forouzan (2008) agente de usuário são softwares que tem a função de
ler, responder e encaminhar mensagens ou e-mail, conseguindo até manipular a
caixa de correio. A figura 2.1 mostra os serviços de um agente de usuário.
Figura 2.1 - Serviços do Agente de Usuário Fonte: Forouzan, 2008, p. 551
O sistema de correio eletrônico basicamente possui cinco funções:
Composição de mensagens: O agente do usuário ajuda o usuário a
compor sua mensagem e na maioria das vezes o próprio sistema de correio
eletrônico possui um editor de texto, mas não obrigatoriamente precisa ser usado,
pode-se usar qualquer editor para escrever uma mensagem ou e-mail;
Leitura de mensagens: O agente do usuário verifica a caixa de
mensagens, trazendo em forma de um resumo todas as mensagens recebidas;
Resposta de mensagens: Feita a leitura da mensagem, o agente de
usuário ajuda o leitor a responder, dando a opção de responder ao remetente ou aos
41
destinatários preservando a mensagem original;
Encaminhamento de mensagens: O leitor também possui a opção de
encaminhar as mensagens a terceiros com ou sem os comentários extras;
Manipulação da caixa de correio: O agente de usuário cria duas
caixas, a de entrada que mantém todas as mensagens recebidas e saída que
mantém as mensagens enviadas, normalmente as caixas de correio eletrônico
possuem opções de personalizar.
2.3 FUNCIONALIDADES DO CORREIO ELETRÔNICO
De acordo com Teixeira (2004) os e-mails são mensagens eletrônicas que
utilizam a rede de computadores como transporte. O correio eletrônico possui muitas
funcionalidades desde anexar documentos eletrônicos, arquivos de som, vídeo,
imagem e fotos até enviar mensagens para um grande número de destinatários.
2.3.1 Envio e recebimento de Mensagens
A identificação de um usuário de e-mail segundo (Teixeira, 2004) é feita da
seguinte forma: nome@dominio. O “nome” é a identificação do usuário podendo ou
não ser o seu nome, apelido ou abreviatura do nome. Já o “domínio” é o nome da
rede, mais conhecido como o domínio da rede. Exemplos: yahoo.com.br,
google.com ou Hotmail.com, @ tem a função de juntar o “nome” e “domínio”, lido
também como at.
Existem também outras maneiras de se endereçar uma mensagem, é o que
afirma Tanenbaum (2003). X.400 é uma forma bem radical de endereçamento
composta por pares atributo = valor separados por barras; por exemplo:
/C=BR/ST=SAOPAULO/L=LINS/PA=269 JOSE TELLES/CN=RODRIGO SILVA/. O
exemplo acima mostra país, estado, cidade, endereço e nome do destinatário para o
qual será enviada a mensagem.
Outro recurso do correio eletrônico são as listas de debate, permitem que o
usuário crie uma lista debate, como no exemplo faculdade, ao enviar uma
mensagem para lista faculdade todos os seus membros que pertencem a essa lista
recebem a mensagem individualmente.
Teixeira (2004) exemplifica a forma de envio e recebimento de uma
42
mensagem eletrônica ou e-mail, após o usuário ter escrito e enviado sua mensagem
através do software de correio eletrônico, a mesma irá do computador atual para o
servidor de e-mail daquele domínio, o servidor atual encaminha a mensagem para o
servidor responsável, a mensagem fica disponível na caixa de entrada do
destinatário, então, é feita a entrega final ao destinatário. Este envio ou recebimento
só é possível utilizando protocolos de e-mail. A figura 2.2 ilustra o envio e
recebimento de e-mail.
Figura 2.2 - Envio e recebimento de e-mail Fonte: Teixeira, 2004, p. 83
2.4 ELEMENTOS DO CORREIO ELETRÔNICO
2.4.1 Mensagem Eletrônica
Um dos principais elementos do correio eletrônico é a mensagem eletrônica
ou e-mail, composta por um envelope e uma mensagem, o envelope contém o
endereço do remetente e do destinatário e outras informações, a mensagem é
subdividida em cabeçalho que define o remetente, destinatário e assunto, e
mensagem que contém as informações que serão lidas pelo destinatário, é o que
afirma Forouzan (2008). A imagem 2.3 mostra o formato da mensagem eletrônica.
43
Figura 2.3 - Formato de uma mensagem eletrônica Fonte: Forouzan, 2008, p. 553
2.4.2 Mail Transfer Agent – (MTA)
De acordo com Teixeira (2004) MTA é um programa responsável por enviar e
receber mensagens eletrônicas. Quando uma mensagem é enviada, o MTA analisa
os dados e encaminha ao usuário, quando o usuário não é do mesmo domínio, o
MTA encaminha a outro MTA para que esse possa fazer a entrega final. O SMTP é
o protocolo mais usado na Internet para que o MTA desempenhe suas funções.
Forouzan (2008, p. 561) confirma: “Para enviar correspondência, um sistema deve
ter o cliente MTA e, para receber correspondência, ele deve ter um servidor MTA. O
protocolo formal que define o cliente e o servidor MTA na Internet é chamado
SMTP”. A figura 2.4 demonstra o alcance do protocolo SMTP.
Sendmail, o Qmail e o Postfix são alguns dos mais usados programas de
MTA, todos estão gratuitamente disponíveis para download, já o Microsoft
Exchange, que é pago, é o MTA usado pela Microsoft. Segundo Teixeira (2004) a
melhor escolha do MTA deve levar em consideração a dimensão e configuração da
rede, mas os principais pontos a serem analisados são a segurança, facilidade de
configuração e o desempenho, enfim velocidade no processamento das mensagens.
44
Figura 2.4 - Alcance do Protocolo SMTP Fonte: Forouzan, 2008, p. 561
2.4.3 Mail User Agent – (MUA)
Mais conhecido como MUA, segundo Teixeira (2004) é o programa
responsável pela interface do usuário e sua caixa postal, onde se encontra
armazenado todas as suas mensagens. Teixeira (2004, p. 86) diz: “MUA não recebe
e-mails”, ele se diferencia pela interatividade com o usuário, por gerenciar e
armazenar as suas mensagens ou e-mails. É possível também recuperar as
mensagens eletrônicas do servidor e guardá-las no computador do usuário, ou
mantê-las no servidor, apresentando na própria interface do MUA. Os protocolos
responsáveis pelo MUA são o Post Office Protocol (POP) e o Interactive Mail Access
Protocol (IMAP). Atualmente existem diversos programas utilizados como MUA,
Eudora, o Pine, Netscape Mail e o Microsoft Outlook são os mais conhecidos.
A imagem 2.5 explica a função do MUA segundo Forouzan (2008), o autor
explica que o protocolo SMTP está presente na fase em que o remetente envia sua
mensagem, passando do servidor de correio remetente, Internet e chegando até o
servidor de correio destinatário. O receptor, então, utiliza um MUA que, através dos
protocolos POP ou IMAP, recupera suas mensagens do servidor. Os protocolos
POP e IMAP serão detalhados nas próximas seções.
Figura 2.5 - POP e IMAP Fonte: Forouzan, 2008, p. 569
45
2.4.4 Protocolos de Correio Eletrônico
2.4.4.1 SMTP
O protocolo SMTP segundo Teixeira (2004) é responsável por enviar
mensagens eletrônicas entre MTAs, é usado também na comunicação dos
servidores, tanto no envio quanto no recebimento das mensagens. Importante
salientar que todos os computadores conectados a Internet podem enviar uma
mensagem eletrônica usando SMTP a outro computador, desde que ambos estejam
na mesma rede. Já os clientes de e-mail enviam mensagem através do SMTP e
recebem pelos protocolos POP ou IMAP. O SMTP possui uma extensão o Extended
Simple Mail Transfer Protocol (ESMTP) sua principal característica é autenticação
que permite identificar o cliente de e-mail durante o acesso à sua caixa postal no
servidor.
2.4.4.2 POP
Segundo Teixeira (2004), POP é um protocolo responsável por permitir que o
programa MUA que está sendo executado no computador do usuário, possa acessar
sua caixa postal e ler suas mensagens. A principal característica do POP é a
recuperação das mensagens do servidor, guardando ou não uma cópia das
mensagens no servidor. Complementando a ideia da autora acima, Forouzan (2008)
diz que POP possui dois modos, o de exclusão, quando a correspondência é
excluída do servidor após sua visualização, geralmente isso acontece quando o
usuário está trabalhando em seu próprio computador. Já o modo de manutenção, a
correspondência é mantida salva no servidor, após a visualização, esse modo é
utilizado quando o usuário não está em seu computador principal.
A grande vantagem de se usar o POP é não sobrecarregar o espaço do disco
do servidor, pois, na maioria dos casos, as mensagens são removidas do servidor e
armazenadas no computador do usuário, mas também possui uma desvantagem, se
o usuário quiser acessar sua caixa postal em outro computador, poderá ocorrer
inconsistência na caixa postal do usuário, gravando mensagens em locais distintos.
46
2.4.4.3 IMAP
Ao contrário do POP, o IMAP segundo Teixeira (2004) consiste em acessar a
caixa postal do usuário e gerenciar todas as mensagens, sem precisar gravá-las em
seu computador. Dessa forma as mensagens são exibidas através da interface do
computador do usuário, porém continuam armazenadas no servidor.
O IMAP possui uma vantagem acima do POP, que possibilita ao usuário
acessar suas mensagens em computadores distintos, pois todas as mensagens
estão disponíveis no servidor, mas ele também tem uma desvantagem, o consumo
do espaço em disco.
Forouzan (2008) contribui dizendo que o protocolo IMAP é semelhante ao POP,
porém mais complexo. O IMAP possui algumas funções extras:
O usuário analisa o cabeçalho da mensagem antes do download;
O usuário pode realizar buscas específicas no conteúdo antes do download;
O usuário consegue fazer baixa parcial das mensagens, isso é importante se
o usuário tiver banda de Internet limitada;
O usuário consegue gerenciar todas as suas mensagens, excluir, criar,
renomear caixas de correio direto do servidor;
A imagem 2.6 mostra o funcionamento do POP.
Figura 2.6 - Funcionamento do Protocolo POP Fonte: Teixeira, 2004, p. 91
47
2.5 WEBMAIL
Outra opção de correio eletrônico muito utilizado é o webmail, que permite o
acesso através da web. Teixeira (2004) explica que a maioria das soluções de
webmail mantém um canal seguro apenas no login do usuário, onde contém a sua
senha, retornando a conexão web normal. A caixa de entrada do usuário fica
disponível em um servidor de e-mail que pode ser acessado a qualquer hora ou
lugar, necessitando apenas de um navegador como o Internet Explorer e acesso a
Internet. Por encontrar-se em um ambiente web o protocolo de comunicação é o
HTTP, mas Forouzan (2008, p. 571) diz: “A transferência da mensagem do servidor
de correio remetente ao servidor de receptor ainda é por meio de SMTP.”
Ainda em Teixeira (2004), a maior vantagem do webmail é a mobilidade, além
disso, tem uma interface bem mais amigável e intuitiva, facilitando o uso do correio
eletrônico. Alguns exemplos de webmails são: Hotmail e Yahoo.
Em um sistema de Webmail como o mostrado na figura 2.7, as mensagens
ficam armazenadas no servidor de e-mail, caso o usuário (Ana Joana) queira ler ou
enviar uma mensagem, terá que ser feita à comunicação através do browser ao
servidor Web, geralmente instalado na mesma máquina do servidor de e-mail. Todo
processamento de envio e recebimento é feito pelo MTA, via protocolo SMTP.
Figura 2.7 - Sistema de Webmail Fonte: Teixeira, 2004, p. 89
Os assuntos aqui abordados serão muito úteis para o entendimento pleno das
48
mensagens não solicitadas (SPAM), para tanto a assunto terá continuidade no
próximo capítulo, com maior ênfase ao SPAM.
49
3 SPAM
O termo Spam é o nome dado às mensagens não solicitadas. Ela já foi
considerada ameaça ao uso de e-mail e à segurança da rede, tendo destaque até na
imprensa. Este capítulo aborda o histórico, evolução, funcionamento de um modo
geral e as principais técnicas de combate ao spam.
3.1 HISTÓRICO
Segundo Teixeira (2004) o termo spam foi relacionado com as mensagens
não solicitadas, em virtude de algumas cenas na série de filmes de comédia do
Monty Phyton, onde vikings (piratas) pedem várias e várias vezes o spam, que é
uma marca de presunto enlatado nos EUA. Por isso que as mensagens não
solicitadas ficaram conhecidas como SPAM, pois se recebe várias vezes, causando
muita perturbação e chateação.
Em 05 de Março de 1994, segundo Cert (2012) deu-se origem ao spam,
quando dois advogados Canter e Siegel publicaram uma mensagem sobre aquisição
de green cards para imigrantes nos EUA através de uma rede de artigos e/ou fóruns
chamada de USENET. Teixeira (2004) afirma que esse fato desencadeou ira da
comunidade USENET, ficando conhecido como o primeiro grande caso de violação
da Netiqueta, que é um conjunto de normas e conduta para os usuários da Internet,
tais normas podem ser encontradas na Request for Comments (RFC) 1855. É
possível encontrar outras histórias da origem do spam, uma bem conhecida afirma
que a primeira mensagem spam surgiu em 03 de Maio de 1978, quando um
profissional de marketing da empresa DEC, divulgou os novos modelos de
computador DEC-20.
Spam é considerado um abuso, muitas pessoas dizem para que sejam
consideradas spam, é preciso se ter vários envios de mensagens não solicitadas ou
indesejadas, mas tudo isso não importa, pois todas as mensagens enviadas sem a
permissão ou prévio aviso ao destinatário, se caracteriza como spam é o que afirma
Teixeira (2004). Apesar do número de spams reportados ao CERT ter tido uma
queda, ainda é considerável. Só em 2012 Cert (2012) já acumula mais de meio
milhão de spams reportados.
50
3.2 TIPOS DE SPAM
Como citado acima o spam ou mensagem indesejada é caracterizado pelo
envio de mensagens sem a permissão ou prévio aviso ao destinatário. Os primeiros
tipos de spam encontrados na Internet foram as correntes, com promessas de
dinheiro, sorte e saúde. Os boatos que contam histórias com muita criatividade
também apareceram com grande força é o que conta Teixeira (2004).
Teixeira (2004) cita o exemplo da Coca-Cola do Brasil, quando em Julho de
2003 publicou uma nota sobre o e-mail falso que circulava na rede, questionando
uma composição utilizada no guaraná Kaut. E com o passar do tempo os
desenvolvedores descobriram muitas outras artimanhas, como multiplicar seus vírus
e códigos maliciosos através do e-mail, e tudo o que se tem que fazer é ter um
assunto convincente ou atraente.
Como apresentado anteriormente, 83,4 milhões de usuários utilizaram a
Internet no segundo trimestre de 2012. Esse número justifica a afirmação de Teixeira
(2004), que a chegada do comércio eletrônico divulgou a Internet ainda mais,
tornando-se uma grande ferramenta de marketing e com todas essas informações
na rede o spam atingiu seu ápice, espalhando e-mails vendendo mala direta,
cadastros e também surgiram as fraudes e os golpes, tendo o e-mail como meio de
propagação (IBOPE, 2012).
A última geração de spams segundo Teixeira (2004) já atingiu os mais
recentes aplicativos disponíveis na Internet, por exemplo: blogs, programas de
mensagens instantâneas e as famosas redes sociais.
O texto abaixo define de forma breve os principais tipos de mensagens não
solicitadas ou spam.
3.2.1 Boatos
Segundo Teixeira (2004) os boatos são textos que contém histórias
alarmantes e falsas, apelando ao destinatário pela divulgação a todos de sua lista de
contatos. Antispam.br (2012) classifica os boatos em dois tipos, difamatórios que
denigrem produtos e empresas, com promessas de brindes ou comentando sobre
uma determinada substância prejudicial a saúde e filantrópicos que apela o lado
sentimental do destinatário, usam catástrofes naturais ou problemas de saúde para
51
arrecadar dinheiro que nunca chega as verdadeiras vítimas.
Um clássico exemplo de boato foi um e-mail que circulou em Abril de 2003
envolvendo a Nestlé, a mensagem dizia que todas as pessoas que encaminhassem
para 15 ou mais contatos copiando um terceiro e-mail, supostamente de um
funcionário da Nestlé ganhariam um cesta de produtos Nestlé. Em nota a empresa
disse que a mensagem era falsa e o endereço de e-mail não era de nenhum
funcionário da Nestlé, exemplo citado pela autora Teixeira (2004).
3.2.2 Correntes
As correntes são mensagens que circulam várias e várias vezes pelas caixas
de e-mail, criando um loop quase sem fim, elas prometem riqueza e sorte aos que
as encaminham e azar para aqueles que interrompem a corrente. Antispam (2012)
contribui dizendo que as correntes estão diminuindo, mas não desapareceram, a
engenharia social contribui muita para convencer os destinatários a encaminhar tais
mensagens. A imagem 3.1 mostra um exemplo de corrente, onde é divulgado que o
portal de periódicos do CAPES será desativado por falta de acesso.
Figura 3.1 - Exemplo de e-mail do tipo Corrente Fonte: Corrente, 2012
52
3.2.3 Lendas Urbanas
As lendas urbanas são conhecidas por contar histórias com um tom de
verdade, sejam elas tristes, alegres, assustadoras ou maravilhosas é o que explica
Antispam.br (2012). Teixeira (2004) diz que ao menos uma fonte de referência é
usada nas mensagens de lendas urbanas, como “... o amigo do meu amigo...” dando
credibilidade à lenda contada.
3.2.4 Propaganda
De acordo com Teixeira (2004) os Unsolicited Comercial E-mail (UCE) ou e-
mails comerciais não solicitados, ou seja, spam que faz propaganda é uma prática
muito comum e vem aumentando cada vez mais nas caixas postais dos usuários e,
por mais interessante que seja todos esses produtos e/ou preços contidos nos e-
mails, o conceito de spam é claro, afirma que todas as mensagens recebidas não
solicitadas são consideradas como spam.
3.2.5 Fraudes
Figura 3.2 - E-mail fraudulento usando o nome do Banco do Brasil Fonte: Fraude, 2012
As fraudes segundo Teixeira (2004) são mensagens falsas de empresas
idôneas com intuito de convencer o destinatário a instalar programas que contém
53
códigos maliciosos, Antispam (2012) contribui afirmando que na maioria das vezes
os golpistas utilizam de engenharia social para induzir o leitor a acessar páginas de
web fraudadas ou falsificadas para que todos os dados bancários e pessoais sejam
roubados. A imagem 3.2 mostra um típico exemplo de e-mail fraudulento, onde os
golpistas simulam um suposto e-mail do Banco do Brasil solicitando os dados de
seus clientes.
3.2.6 Golpes
Em Antispam (2012) explica que os golpes antigamente eram praticados
através de cartas e ligações telefônicas, e hoje utiliza o e-mail como meio de
propagação. Um grande exemplo é o golpe da Nigéria que se tornou muito famoso,
pois em suas mensagens pediam um adiantamento de dinheiro para uma
determinada história mirabolante. Teixeira (2004) classifica esses golpes como
advanced fee fraud (AFF) ou fraude de antecipação de pagamentos. Basicamente o
spam em titulado como golpe constitui em convencer os usuários de e-mail a
depositarem uma determinada quantia de dinheiro em suas contas. A imagem 3.3
mostra um trecho de um e-mail com o golpe da Nigéria.
Figura 3.3 - Trecho do e-mail com o golpe da Nigéria Fonte: Golpe da Nigéria, 2012
3.2.7 Códigos maliciosos (Malware)
Segundo Antispam (2012) códigos maliciosos ou malware são programas que
54
na maioria das vezes estão anexados ao spam, eles são capazes de causar grandes
danos ao computador.
3.2.8 Vírus
Teixeira (2004) define vírus como um programa que se multiplica através do
e-mail, infectando as máquinas pelas quais passou, causando danos pequenos ou
irreparáveis. Os vírus ficam de forma transparente no sistema aguardando o
momento de entrar em ação.
3.2.9 Worms
Muito parecido com o vírus, worms é capaz de se multiplicar, gerando cópias
de si mesmo ou de suas partes, para se multiplicar ele utiliza recursos de rede, como
e-mail e páginas de web. Ele também vem anexado junto ao spam é o que explica
Teixeira (2004).
3.2.10 Trojans (Cavalo de Tróia)
Segundo Teixeira (2004) os Trojans são programas que tem objetivo de obter
controle do sistema, usando o e-mail, vulnerabilidades do sistema ou vírus como
meio de propagação. Diferente dos worms, o trojan não se reproduz e nem infecta
outros programas.
3.2.11 Pornografia
Antispam.br (2012) diz que os e-mails contendo pornografia é uma dos tipos
mais comuns de spam, Teixeira (2004) complementa dizendo que há vários relatos
de pessoas constrangidas por receberam mensagens contendo pornografia ou até
mesmo pedofilia.
3.2.12 Ameaças e brincadeiras
Existem spams com o objetivo de fazer ameaças e brincadeiras de mau
55
gosto, mensagens essas que incluem ameaças de ex (namorados, namoradas,
esposas e esposos) ou até mesmo mensagens falsificadas. Por serem enviadas em
grande quantidade é considerado spam, é o que afirma Teixeira (2004).
3.2.13 Spam via Instant Messengers (Spim)
Um novo tipo de spam vem ganhando espaço na Internet é o caso do spim,
ele se refere ao envio de spam através de aplicativos de troca de mensagens
instantâneas, como o Windows Messenger, Skype e outros. As famosas redes
sócias se tornaram o mais recente meio de proliferação de spam, propagandas,
marketing são enviadas para milhares de pessoas de uma só vez, é o que contribui
Teixeira (2004).
3.3 SPAMMERS
Segundo Teixeira (2004) spammers são os responsáveis pelo envio de
mensagens não solicitadas ou spam. Eles utilizam ferramentas e técnicas para
convencer o destinatário a abrir o e-mail contendo spam, isso serve para confirmar
que o e-mail é legítimo, incluindo o mesmo na base definitiva dos spammers. São
muitos os recursos do spammers, desde os mais técnicos, que tem a função de
camuflar as origens do spam, garantindo o anonimato dos spammers, já os outros
utilizam de engenharia social para induzir o usuário a propagar spams. Teixeira
(2004) cita alguns dos artifícios utilizados para convencer o usuário: o one-time e-
mails ou e-mails enviados uma única vez, são mensagens comuns de se receber
apelando ao usuário, “para sair desta lista, basta responder ao e-mail digitando
Remove”, “Se este assunto não lhe interessa, apenas delete este e-mail”, surgiu até
uma mensagem dizendo que “De acordo com a lei xxxx, este e-mail não pode ser
considerado spam...”, mas nenhuma lei ou decreto regulamenta o spam, muitas
outras frases ou palavras são utilizadas no subject (assunto) do e-mail para atrair os
destinatários.
3.3.1 Ferramentas
Todos os spammers têm suas ferramentas de trabalho, seja ela para enviar
56
de forma automática os e-mails ou até “anonimizadores”, que tem função de
camuflar a origem dos spams. A maior fonte de ferramentas dos spammers e dos
hackers segundo Teixeira (2004) é a Internet, onde inúmeras ferramentas podem ser
encontradas. Outra ferramenta muito utilizada são as famosas malas diretas, que
contém milhares de endereços de e-mail, elas são vendidas pela Internet ou por
vendedores ambulantes, Teixeira (2004) diz: “Um tipo de comércio que se nota estar
crescendo é o “mercado negro” de contas de e-mail, domínios e contratação de
provedores para o envio de spam”.
3.3.2 Tipos de spammers
Segundo Teixeira (2004) com base na utilização e no dia a dia no e-mail, foi
possível identificar alguns tipos de spammers: os convictos acreditam que os
incomodados que se mudem ou apaguem as mensagens não solicitadas, os
spammers institucionais são constituídos de funcionários que tem mania de mandar,
por exemplo: convite para chá, café, textos de auto-ajuda, receitas, piadas e etc.
Teixeira (2004, p. 73) diz: “Com relação ao trabalho, a Netiqueta e o bom senso são
fundamentais.”, os spammers acidentais são os usuários de e-mails que por algum
engano mandam para uma lista de discussão arquivos grandes ou determinados
conteúdos não solicitados. Os spammers desinformados geralmente são os novos
usuários da Internet ou e-mail e, acreditam em todas as correntes, boates, lendas e
outros. Já os spammers informantes são os usuários que repassam todos os tipos
de informação que recebem, sem sequer saber do que se trata.
3.4 COMBATE AO SPAM
Teixeira (2004, p. 92) diz: “À medida que o e-mail se tornou ferramenta
indispensável... na vida pessoal e profissional dos cidadãos, o servidor de e-mail
ganhou cada vez mais destaque, sendo um dos componentes vitais da rede.”. Mas
todo esse avanço teve um preço, as invasões e ataques aos servidores de e-mail
aumentaram tudo a fim de obter controle dos servidores para envio de spam de
forma secreta ou violar as informações sigilosas armazenadas nas caixas postais
dos usuários. Esses ataques aproveitam vulnerabilidades do servidor, explorando as
configurações inadequadas dos sistemas ou aplicativos.
57
Segundo Teixeira (2004) a configuração do servidor de e-mail é muito
importante, pois existem alguns servidores com relay aberto ou open relay. No início
da Internet o servidores por padrão eram open relay, ou seja, encaminhavam
qualquer mensagem seja ela de seus usuários ou não, para os respectivos
destinatários. Ainda em Teixeira (2004) os spammers utilizam essa falha para enviar
seus spams de forma anônima camuflando sua verdadeira origem. Viu-se então a
necessidade de restringir o uso do relay dos servidores para redes autorizadas e
conhecidas pelo servidor. A imagem 3.4 ilustra um envio de e-mail spam através de
servidor open relay que modifica sua identidade.
Figura 3.4 - Envio de e-mail spam através de open relay Fonte: Teixeira, 2004, p. 94
Teixeira (2004) explica que se o usuário quiser descobrir a origem do e-mail,
acabará encontrando o servidor open relay que foi usado apenas como “ponte” para
o envio, pois o campo remetente poderá ser modificado pelos spammers.
58
3.4.1 Listas Negras de open relays
O uso de Realtime Blackhole Lists (RBLs) ou Listas Negras também é
considerado como um combate ao envio de spam, Teixeira (2004) diz que o
aumento dos servidores de e-mail mal configurados deram origem as listas negras
de open relays, que são mantidas por organizações anti-spam. Esses sites são
responsáveis por testar e validar um servidor como open relay, com isso o servidor é
incluído em uma lista negra de servidores de e-mail. O responsável pelo servidor é
contatado e orientado a solucionar o problema para que seu servidor seja retirado
das RBLs
Ainda em Teixeira (2004) as RBLs são utilizadas para configurar os
servidores de e-mail a fim de bloquear todas as mensagens recebidas de um
determinado servidor, que está incluído em alguma lista negra. Com isso o servidor
bloqueado terá sérios problemas, pois todos os seus usuários não conseguirão
enviar mensagens para os servidores que utilizam RBLs nas suas configurações.
Teixeira (2004) alerta que ao configurar listas negras no servidor de e-mail é
recomendado retornar uma mensagem padrão aos servidores bloqueados, explicado
que sua rede ou usuário foi listado como spammer.
Na Internet existem algumas dessas listas, por exemplo, a Mail Abuse
Prevention System (MAPS) e a Open Relay Database (ORDB).
Teixeira (2012) afirma que as listras negras não são suficientes para acabar
com o spam, por isso o ideal é usar as RBLs juntamente com outras técnicas anti-
spam.
3.4.1 Filtro anti-spam
Outra técnica muito usada para o combate ao spam são os filtros anti-spam é
o que afirma Teixeira (2004). Os filtros tem a função de separar os e-mails válidos
dos spams, por meio de regras predefinidas. Teixeira (2004) diz que antigamente os
filtros eram utilizados para organizar em pastas os e-mails de um determinado
destinatário. Um exemplo de filtro contra o spam é criar uma regra que remove todas
as mensagens com a palavra “pornografia” no subject.
Teixeira (2004) explica que alguns filtros já são configurados diretamente nos
MTAs e MUAs, o principal objetivo de um filtro anti-spam é a identificação correta
59
das mensagens, não gerando um grande número de falso negativo, spams que
foram classificados como e-mail legítimo ou falso positivo, e-mails legítimos
considerados como spam. Existem dois tipos de filtros, os que procuram estilos
iguais nas mensagens consideradas como spam (filtros de conteúdo) e no bloqueio
de mensagens com a origem conhecida com spammer (filtros de bloqueio).
Os filtros de conteúdo comparam as características de um e-mail considerado
como spam ou regras predefinidas, a fim de detectar um spam. Segundo Teixeira
(2004, p. 105) “São considerados filtros de conteúdo todos aqueles baseados em
padrões, independente de origem...”, dentro de filtros de conteúdo estão filtros
baseados em regras, que usam arquivos de configuração responsáveis por
armazenarem regras predefinidas e à medida que alguma regra é satisfeita uma
pontuação é somada no e-mail, caso essa pontuação ultrapasse um valor máximo, a
mensagem é filtrada como spam. Filtros estáticos buscam padrões (assinaturas) nas
mensagens verificadas, os filtros bayesianos são exemplos de filtros estáticos, eles
utilizam classificação de textos. A grande vantagem é que esse filtro aprende com os
spams recebidos. Outro também é o filtro baseado em desafio e resposta, é quando
o destinatário recebe uma mensagem de um servidor desconhecido que não consta
na whitelist, lista de servidores conhecidos e confiáveis, o servidor do destinatário
responde o e-mail solicitando resposta e confirmando sua mensagem. Teixeira
(2004) cita o exemplo utilizado pela uol que responde o e-mail desconhecido com
um link que apresenta ao remetente uma sequência de letras a ser preenchida,
confirmando então o envio da mensagem. Já os Filtros colaborativos são atualizados
pelas próprias vitimas de spam, que contribuem deixando as características comuns
entre os spams é que afirma Teixeira (2004).
Segundo Teixeira (2004) os filtros de bloqueio utilizam sites da Internet que
mantêm RBLs, redes, servidores com relay ou proxy abertos para bloquear e recusar
e-mails oriundos desses remetentes. A redução dos spams na caixa do usuário é a
maior vantagem das listas de bloqueios, porém existem algumas desvantagens,
atualização diária dos sites que mantém essas listas, dependência de listas
mantidas por terceiros e o radicalismo de algumas listas, como a blackhole.us, que
filtra todos os IPs de um determinado país, tais como Brasil, Coréia e a Índia, por
serem países mal vistos.
60
3.4.2 Spamassassin
Teixeira (2004) explica que o spamassasim é um filtro de anti-spam para
servidores de e-mail, baseia-se em análises de conteúdo e nas listas negras
disponíveis na Internet. Ele contém uma base de regras que são utilizadas para
checar os cabeçalhos e corpo da mensagem, o reconhecimento é feito através de
uma marca ou tag, possibilitando ao MUA dar o tratamento necessário conforme as
regras definidas pelo administrador ou política anti-spam da empresa. Outra
vantagem do spamassasim é conseguir fornecer dados e características ao filtro
colaborativo (Vipul´s Razor), na medida em que ele recebe novos spams. A partir da
versão 2.50 foi incluído um filtro bayesiano, possibilitando que o filtro aprenda com
mensagens recebidas, seja elas spams ou não. O spamassasim vem sendo muito
utilizado e aprimorado e sua base de dados em inglês apresenta ótimos resultados
na filtragem dos spams, outras regras podem ser acrescentadas com outros idiomas.
3.4.3 Bogofilter
O Bogofilter é outra ferramenta baseada no filtro estatístico, segundo Teixeira
(2004) ele é um filtro bayesiano e analisa o cabeçalho e o corpo da mensagem
comparando-os com palavras chaves para classificá-las da forma correta. A
capacidade de aprender do bogofilter é muito valorizada, porém o tempo de
aprendizagem pode ser enxergado como uma desvantagem, outras vantagens são
apontadas por administradores: bom desempenho em redes de grande porte,
manutenção e configuração fácil e estabilidade do sistema em pouco tempo.
3.5 POLÍTICAS ANTI-SPAM
Segundo Teixeira (2004) a política de segurança é composta por regras que
define o que pode ser feito e o que é proibido fazer com os recursos de Informática,
bem como as consequências e punições em caso de transgressão de alguma regra.
A política mostra como os funcionários devem lidar com os recursos da empresa e
os dados usados diariamente, a utilização do e-mail também deve constar na política
da empresa e de forma bem clara. Com uma boa política anti-spam e a
conscientização e educação do usuário, os números de mensagens não solicitadas
61
diminuirá de forma gradativa. Outra forma de se combater é reclamar ao responsável
pela rede, ou seja, enviar uma mensagem sobre o spam recebido anteriormente e
pedir providências quanto aos envios constantes de spam.
Neste capítulo foi abordado o conceito de spam, que por fim deram base para
prosseguir com os estudos de forma prática. O próximo capítulo irá mostrar os testes
práticos e as estatísticas dos resultados obtidos, bem como a conclusão sobre as
tecnologias de controle de spam utilizadas.
62
4 TECNOLOGIAS ANTI-SPAM
Para um maior entendimento sobre o spam, este capítulo mostra de forma
prática e exemplificada as técnicas mais usadas pelos administradores de redes no
combate ao spam. Segundo Oliveira (2011), o spam causa vários problemas às
empresas e provedores. Maior tráfego de e-mails é um deles, forçando o aumento
dos links de conexão e gerando o repasse dos custos aos consumidores finais.
4.1 CONFIGURAÇÕES DO AMBIENTE
Para a demonstração das técnicas anti-spam foi utilizado um ambiente virtual.
A figura 4.1 mostra a topologia dos servidores de e-mail no ambiente criado no
programa Virtualbox. Foram utilizadas máquinas virtuais em virtude da não
existência de domínios reais e proprietários para testes.
Figura 4.1 - Ambiente Virtual Fonte: Elaborado pelos autores, 2012
63
No primeiro servidor, denominado Thor, foi instalado o servidor de e-mail
Postfix com as configurações padrões, alterando apenas o domínio e IP. O antivírus
Clamav também foi utilizado e integrado ao Postfix, de modo que, ao receber um e-
mail, o Postfix o redireciona ao Clamav que verificará se o e-mail possui vírus. O
Spamassassin foi instalado como a ferramenta anti-spam, que filtra as mensagens
através de regras predefinidas, cada regra possui uma espécie de pontuação, e por
padrão o Spamassassin possui uma pontuação máxima tolerável, caso essa
pontuação ultrapasse a máxima, a mensagem é classificada como spam. Essas
aplicações foram utilizadas no servidor Thor para uma melhor eficácia ao combate
ao spam. Já no segundo servidor chamado Rodrigo, foi configurado apenas o
Postifix com as mesmas configurações do servidor Thor, mudando apenas o
domínio e IP. A máquina cliente (sistema hospedeiro) foi configurada para acesso
aos servidores de e-mail utilizando os protocolos SMTP e POP3 instalados em
ambos servidores, Thor e Rodrigo. Segundo Teixeira (2004) o protocolo POP é
utilizado pelos programas de MUAs para baixar as mensagens recebidas, podendo
ou não mantê-las no servidor. O Outlook versão 2010 foi o programa MUA escolhido
para receber as configurações do POP. A figura 4.2 mostra as configurações do
servidor Thor no Outlook e a figura 4.3 as configurações do servidor Rodrigo.
Figura 4.2 - Configurações do servidor Thor no Outlook Fonte: Elaborado pelos autores, 2012
64
Figura 4.3 - Configurações do servidor Rodrigo no Outlook Fonte: Elaborado pelos autores, 2012
A figura 4.4 mostra o log do servidor Rodrigo após o envio de mensagem
teste para o usuário [email protected], o servidor Rodrigo conecta à maquina
física que possui o IP 10.50.50.3 para enviar a mensagem ao destinatário final, o
status do e-mail passa a ser sent, ou seja, enviado.
Figura 4.4 - Log gerado com o envio de e-mail de Rodrigo para Thor Fonte: Elaborado pelos autores, 2012
Já na figura 4.5 mostra o log do servidor Thor que recebeu a mensagem.
Como o servidor Thor possui configurado o Postfix integrado ao Clamav e
Spamassassin ele gerou um log mais extenso. Ele mostra a transmissão da
mensagem via SMTP do servidor Rodrigo para o Thor, após o término da conexão a
65
mensagem é enviada para análise do Clamav e Spamassassin. Caso encontre algo
ele classifica a mensagem coma vírus ou spam. Caso contrário, entrega
normalmente a mensagem ao destinatário final ([email protected]). A
mensagem gerada através do servidor de e-mail pode ser interpretada da seguinte
forma: | mês | dia | hora | nome do servidor | software utilizado | [número do
processo] | ações geradas |.
Figura 4.5 - Log gerado com o recebimento do e-mail do Rodrigo para Thor Fonte: Elaborado pelos autores, 2012
Figura 4.6 - E-mail disponível na caixa de entrada do usuário Fonte: Elaborado pelos autores, 2012.
66
4.2 POSTFIX
Segundo Oliveira (2011) o Postfix foi criado para suprir e substituir outro
servidor de e-mail, o SendMail, que por sua vez possui problemas de mal
funcionamento e segurança, fora sua complexidade na configuração das regras mais
básicas de envio de e-mail necessitando de ajustes para funcionar. O projeto da
criação do Postfix teve como mentor Wietse Venema, conforme solicitação da IBM.
Sua distribuição é totalmente gratuita, porém algumas particularidades (legais) que
resguardam a própria IBM. Oliveira (p. 5, 2011) afirma que “O Postfix é um MTA
modular, pode-se integrá-lo a várias outras ferramentas (Greylisting, Spamassassin,
SPF, e etc...)”.
O servidor de e-mail Postfix já possui internamente diversos parâmetros de
filtros anti-spam, e ainda consegue fazer integração com diversas ferramentas de
combate ao spam é o que afirma Oliveira (2011). O autor cita ainda os gatemail’s
que são equipamentos especializados em combater o spam, mas que se torna inútil
quando utilizamos as técnicas anti-spam do Postfix.
Dent (2003) afirma que a grande vantagem de se usar o Postifix no combate
ao spam é a economia de recursos, pois se usa bem menos recurso da máquina do
que quando se utiliza outro programa. O autor divide em quatro categorias diferentes
de detecção de spam: Client Detection Rules, que são regras aplicadas sobre a
identificação de quem está enviando o e-mail; Syntaxe Checking Parameters, são
regras que verificam os padrões dos protocolos contidos nas mensagens recebidas,
pois na maioria das vezes os servidores de spammers estão mal configurados e não
respeitam nenhum tipo de protocolo; Content Checks, são regras que buscam
palavras ou expressões no cabeçalho e no corpo do e-mail contidas em uma
mensagem não solicitada; Restrictions Classes, as quais permitem criar novas
regras a partir de combinações das anteriores. As técnicas anti-spam compatíveis
com o Postfix serão mostradas nos tópicos a seguir, de uma forma exemplificada.
4.2.1 Configuração de bloqueio de Spam do Postfix
Segundo Dent (2003), com base nas informações do cliente (pessoa que está
enviando a mensagem) é possível bloquear as mensagens utilizando as seguintes
diretivas:
67
smtpd_client_restrictions;
smtpd_helo_restrictions;
smtpd_sender_restrictions;
smtpd_recipient_restrictions;
smtpd_data_restrictions.
A figura 4.7 mostra os passos de uma transação SMTP, bem como as
diretivas correspondentes a cada processo.
Figura 4.7 - Transação SMTP. Fonte: Dent, 2003
Oliveira (2011) explica que a diretiva smtpd_client_restrictions é
responsável por verificar o IP/Hostname do MTA conectado ao SMTP, podendo
solicitar a negação ou aceitação da mensagem. A smtpd_sender_restrictions é
uma diretiva aplicada no Mail From, ou seja, nas informações enviadas pelo
remetente. Smtpd_recipient_restrictions é uma restrição aplicada no RCPT TO,
que se refere na hora em que o cliente informa ao servidor quem é o destinatário da
mensagem. Essa é a ultima verificação feita pelo Postfix antes de receber os dados
da mensagem. Dent (2003) complementa dizendo que ao passar por todas essas
diretivas o remetente da mensagem envia um comando DATA, seguido dos dados
que contém o cabeçalho e o corpo da mensagem, podendo então aplicar as
restrições baseadas no conteúdo da mensagem.
Segundo Dent (2003) nem todas as diretivas tem que ser usada, por padrão o
postfix utiliza as seguintes diretivas:
smtpd_client_restrictions =
68
smtpd_helo_restrictions =
smtpd_sender_restrictions =
smtpd_recipient_restrictions =
permit_mynetworks, reject_unauth_destination
Com a diretiva permit_mynetworks todos que estiverem dentro da rede interna
estão permitidos a enviar e-mails pelo Postfix e a reject_unauth_destination rejeita
todas as mensagens de qualquer outro cliente, a menos que ele esteja entregando
um e-mail a um usuário válido do servidor. O Quadro 4.1 mostra algumas restrições
que podem ser utilizadas nas diretivas mostradas acima.
Quadro 4.1 - Restrições Restrições Informações enviadas pelo Cliente
check_client_access
maptype:mapname
Client IP address or hostname reject_rbl_client
reject_rhsbl_client
reject_unknown_client
check_helo_access
maptype:mapname
HELO hostname permit_naked_ip_address
reject_invalid_hostname
reject_non_fqdn_hostname
reject_unknown_hostname
check_sender_access
maptype:mapname
MAIL FROM address reject_non_fqdn_sender
reject_rhsbl_sender
reject_unknown_sender_domain
check_recipient_access
maptype:mapname
RCPT TO address
permit_auth_destination
permit_mx_backup
reject_non_fqdn_recipient
reject_unauth_destination
reject_unknown_recipient_domain
reject_unauth_pipelining DATA command
Fonte: Modificado pelos autores, 2012.
4.2.2 Funcionamento das Restrições
Dent (2003) afirma que as restrições são avaliadas na ordem em que
aparecem na diretiva. Cada restrição, depois de avaliada, retorna uma das três
69
ações a ser tomada pelo Postfix: OK, REJECT ou DUNNO. Caso ele retorne um
REJECT, a mensagem será rejeitada; se retornar OK, a verificação é interrompida e
vai para próxima até concluir todas ou alguma retornar um REJECT. Para que a
mensagem seja aceita ela tem que ser aceita em todas as diretivas, caso alguma
restrição não retorne nem OK e nem REJECT, ela é avaliada com DUNNO que
segundo Oliveira (2011) é uma regra que não bate com nenhum padrão.
4.2.3 Restrições de Clientes
Esses parâmetros são inseridos no principal arquivo do Postfix, o
/usr/local/etc/Postfix/main.cf, responsável pelas configurações. A figura 4.8 mostra o
diretório do Postfix seguido do comando ls que mostra todos os arquivos dentro
desse diretório.
Figura 4.8 - Diretório do Postfix. Fonte: Elaborado pelos autores, 2012
Dent (2003) mostra algumas das restrições que verificam as informações de
clientes:
permit_auth_destination: recebe o e-mail se o endereço destino é o
hostname ou domínio local do Postfix ou algum domínio que o Postfix foi autorizado
a fazer relay. Os domínios autorizados estão nas diretivas my_destination,
inet_interfaces, virtual_alias_maps, ou virtual_mailbox_maps, e os relays são
listados em relay_domains. Se caso ele não valide a restrição, ela retornará DUNNO
e o Postfix continua verificando as outras restrições.
permit_mynetworks: permite o acesso dos IPs listados na diretiva
mynetworks, que na maioria das vezes lista os endereços IP da rede interna.
reject_unauth_destination: rejeita os e-mails que não estão na lista de
domínios do próprio servidor Postfix ou para um domínio que o Postfix esteja
autorizado a fazer relay, então se o destino final não for um usuário do nosso
domínio ele retornará um REJECT e a mensagem será rejeitada. A figura 4.9 mostra
70
a rejeição no e-mail, por não encontrar o usuário de destino.
Figura 4.9 - Log de e-mail com rejeição. Fonte: Elaborado pelos autores, 2012
4.2.4 Restrições de Hostname/DNS/IP
Segundo Oliveira (2011), as restrições conferem os padrões dos protocolos
de correio eletrônico, visto que os spammers usam conexões amadoras, não
possuem um domínio registrado, bem como um servidor de DNS bem configurado.
As restrições abaixo validam ou negam o recebimento do e-mail por um servidor
remoto, destacando-se as validações de hostname, DNS (pesquisa direta e reversa),
domínio, Fully Qualified Domain Name (FQDN - Nome de Domínio Totalmente
Qualificado), o autor destaca que esses parâmetros possuem alto grau de eficiência
no combate ao spam.
reject_invalid_hostname: rejeita a mensagem que não possui um hostname
válido ou quando não for enviado o hostname. A figura 4.10 mostra o log de e-mail,
com a mensagem de que o e- mail foi rejeitado por não possuir um hostname válido.
Figura 4.10 – Log de e-mail rejeitado Fonte: Elaborado pelos autores, 2012
reject_unknown_hostname: rejeita a mensagem que não possui entrada
DNS, A ou MX. Todo servidor legítimo possui um registro DNS.
reject_non_fqdn_hostname: rejeita a mensagem que não apresente um
hostname totalmente qualificado (FQDN). A figura 4.11 exemplifica a rejeição por
FQDN.
Nov 8 00:15:55 platao postfix/smtpd[60365]: warning:
216.145.159.254: hostname dsl.i.254.ktis.net verification
failed: hostname nor servname provided, or not known
71
Figura 4.11 – Log de e-mail rejeitado - FQDN Fonte: Elaborado pelos autores, 2012
reject_unknown_recipient_domain: rejeita a mensagem do servidor de
destino que não possui entrada DNS, A ou MX. Todo servidor legítimo possui um
registro DNS.
reject_non_fqdn_recipient: rejeita a mensagem que não apresente um
hostname totalmente qualificado (FQDN).
reject_unauth_destination: permite somente o relay dos servidores
declarados no parâmetro mynetworks, as demais ele rejeita.
reject_non_fqdn_sender: rejeita a mensagem dos domínios desconhecidos
e inválidos. A figura 4.12 mostra log com esse exemplo, não existe o domínio
@ourocardecielo.com.br.
Figura 4.12 – Log de e-mail rejeitado – Domínio inexistente Fonte: Elaborado pelos autores, 2012
reject_unknown_client: rejeita as mensagens de domínios que não
possuem registro reverso.
reject_unknown_sender_domain: não permite o envio de mensagem cujo o
domínio não tem entrada de MX ou A.
4.2.5 Restrições de entrega forçada de e-mail
reject_unauth_pipelining: bloqueia a entrega de mensagens forçadas. Essa
técnica é bastante usada pelos spammers que mandam uma quantidade alta de
Nov 8 01:03:02 platao postfix/smtpd[61264]: NOQUEUE:
reject: RCPT from unknown[189.62.230.161]: 504 5.5.2
<particul-7d148f>: Helo command rejected: need fully-
qualified hostname; from=<[email protected]>
to=<[email protected]> proto=SMTP helo=<particul-
7d148f>
Nov 8 00:50:19 platao postfix/smtpd[61163]: NOQUEUE:
reject: RCPT from epoch.as.wakwak.ne.jp[61.205.238.222]: 450
4.1.8 <[email protected]>: Sender address
rejected: Domain not found;
from=<[email protected]> to=<[email protected]>
proto=ESMTP helo=<post.epoch-net.ne.jp>
72
comandos SMTP de uma só vez, a fim de furar a segurança, isso previne que os
spammers enviem spam em massa.
4.2.6 Bloqueio usando RBLs
Como já foi explicado anteriormente nesse trabalho, existem diversas listas
que contém endereços com servidores open relay, que por sua vez podem ser
usados por sparmmers para o envio de spam em massa. Existem alguns parâmetros
que checam em servidores externos quanto ao remetente do e-mail.
reject_rbl_client: essa regra pesquisa nos servidores de RBLs o domínio/IP
do remetente da mensagem, caso ele se encontre na lista sua mensagem e
rejeitada. Já a reject_rbl_replay também rejeita a mensagem, entretanto alerta o
remetente da mensagem. A figura 4.13 mostra alguns dos servidores de listas
negras configurados no arquivo main.cf, sua sintaxe é a regra reject_rbl_client
espaço e o endereço do servidor RBL.
Figura 4.13 – Arquivo main.cf – RBLs Fonte: Elaborado pelos autores, 2012
4.2.7 Bloqueio a partir de Listas de Acesso
As listas de acesso segundo Dent (2003) possuem uma ação de aceitar ou
rejeitar as mensagens de acordo com a pessoa que está enviando a mensagem,
essa regra é muito parecida com o conceito de whitelists e blacklists. O arquivo de
lista de acesso contém uma informação do cliente (IP ou domínio) e a ação a ser
executada (aceitar ou rejeitar). A figura 4.14 mostra o arquivo de configuração onde
está às diretivas necessárias para bloquear as mensagens de um determinado
reject_rbl_client cbl.abuseat.org,
reject_rbl_client charter.net,
reject_rbl_client h2.pop.rcts.pt,
reject_rbl_client pielgrzym.zamosc.mm.pl,
reject_rbl_client conpoint.com,
reject_rbl_client netidea.com,
reject_rbl_client bl.spamcop.net,
73
domínio.
Figura 4.14 - Arquivo de configuração com regras de lista de acesso. Fonte: Elaborado pelos autores, 2012
O arquivo cliente_access possui a seguinte regra, todas as mensagens
enviadas do IP com início 10.50 ou domínio teste.com.br será rejeitada, conforme
figura 4.15
Figura 4.15 – Conteúdo do arquivo cliente_access. Fonte: Elaborado pelos autores, 2012
Então a mensagem Teste enviada do servidor Rodrigo 10.50.50.2 será
rejeitada pelo servidor Thor, com isso o log de e-mail mostra que a mensagem
realmente foi rejeitada, porém o remetente recebeu uma mensagem dizendo que
sua mensagem foi rejeitada. A figura 4.16 mostra o log e a figura 4.17 mostra o e-
mail enviado ao remetente da mensagem.
Figura 4.16 - Log gerado com rejeição do e-mail / Lista de Acesso. Fonte: Elaborado pelos autores, 2012
10.50 REJECT SEU EMAIL FOI CONSIDERADO UM SPAM
teste.com.br REJECT SEU EMAIL FOI CONSIDERADO UM SPAM
74
Figura 4.17 - Mensagem enviada ao remetente Fonte: Elaborado pelos autores, 2012
Dent (2003) explica que é possível ter algumas ações sobre as regras: OK
que analisa e libera para próxima regra; REJECT que rejeita a mensagem e não
libera para próximas fases e possui também a opção de configurar um texto padrão
a ser enviado ao remetente. DUNNO interrompe a análise e passa para próxima
regra, FILTER redireciona a mensagem para um filtro, HOLD coloca a mensagem
em fila de mensagens capturadas, DISCARD manda uma mensagem de sucesso ao
remetente e descarta a mensagem, 4xx message text rejeita a mensagem e manda
uma mensagem ao remetente correspondente ao código no intervalo 4xx e 5xx
message tex rejeita a mensagem e retorna a origem com uma resposta
correspondente ao intervalo 5xx. A figura 4.18 mostra as ações a serem tomadas,
OK ou REJECT, no caso do exemplo abaixo, e como as mensagens são inseridas
para aparecerem no log de e-mail, ação -> mensagem (SEU E-MAIL FOI
CONSIDERADO SPAM).
Figura 4.18 – Conteúdo do arquivo que analisa o cabeçalho da mensagem Fonte: Elaborado pelos autores, 2012
/^from:.*cliente_B.com.br/ OK
/^from:.*fornecedor_A.com.br/ OK
/^from:.*fornecedor_B.com.br/ OK
/^Subject.*Vairga*/ REJECT SEU E-MAIL FOI CONSIDERADO SPAM - BAM 012
/^Subject.*vendors*/ REJECT SEU E-MAIL FOI CONSIDERADO SPAM - BAM 011
75
A figura 4.19 mostra o log do e-mail, onde o teste do servidor Rodrigo para o
servidor Thor foi rejeitado em virtude da regra de Listas de Acesso e para que
ficasse mais visível ao administrador de rede foi inserida uma mensagem no log.
Figura 4.19 - Mensagem de erro ao Administrador Fonte: Elaborado pelos autores, 2012
4.2.8 Bloqueio a partir do Conteúdo
Postfix fornece algumas diretivas para análise de conteúdo, header_checks
para verificação do cabeçalho da mensagem, mime_header_checks verifica as
informações de MINE, nestd_header_checks analisa mensagens anexadas e
body_checks que verifica o corpo da mensagem, é o que afirma Dent (2003). Cada
diretiva dessa usa um arquivo para consultar suas regras, mas por padrão
mime_header_checks e nested_header_checks utilizam o mesmo arquivo.
Dent (2003) explica que no arquivo de configuração do Postfix main.cf atribui-
se ao arquivo contendo as regras a expressão utilizada, por exemplo:
header_checks = regexp:/usr/local/etc/postfix/cabeçalho_da_mensagem, o arquivo
cabecalho_da_mensagem contém todas as regras usadas no parâmetro
header_checks. Dentro do arquivo utiliza-se a seguinte sintaxe para regras: a
expressão a ser procurada está dentro das / / em seguida vem à ação a ser tomada,
/Ganhe dinheiro facil/ REJECT. Segundo Dent (2003) existem as seguintes ações:
REJECT message: retorna uma mensagem ao usuário (message) e registra
no log;
WARN message: registra no log, mas não rejeita a mensagem;
IGNORE ignora a regra atual e transfere a verificação para próxima regra;
HOLD message: deixa a mensagem um uma fila de espera para futuras
inspeções;
DISCARD message: reponde ao remetente que sua mensagem foi entregue
com sucesso, e a descarta em seguida;
FILTER transport:nexthop: encaminha a mensagem a outro programa de
76
filtragem.
Para demonstrar as regras acima, foi configurado no servidor Thor os
seguintes parâmetros: o primeiro passo foi a criação de cinco arquivos,
anexo_da_mensagem, helo_proibido, cabeçalho_da_mensagem, conexão e
corpo_da_mensagem contendo cada um deles regras de combate ao spam.
Segundo Oliveira (2011) é essencial à identificação das regras, pois será mais fácil
visualizar qual a regra que bloqueou uma determinada mensagem, a figura 4.20
mostra um trecho do arquivo cabeçalho_da_mensagem.
Figura 4.20 – Trecho do arquivo cabeçalho_da_mensagem Fonte: Elaborado pelos autores, 2012
O arquivo contém as regras entre / /, ação (REJECT) e mensagem de
identificação, um padrão de mensagem foi criado, SEU E-MAIL FOI CONSIDERADO
SPAM – BAM 006, a palavra BAM do exemplo é a abreviação de Bloqueio por
Assunto da Mensagem, o quadro 4.2 mostra as abreviações e seus significados.
Quadro 4.2 – Tipos de Bloqueio
Tipo de Bloqueio Abreviação
Bloqueio por Assunto da Mensagem BAM
Bloqueio de E-mail Enviados por Programa de Envio em Massa BEEPEM
Bloqueios por Remetente ou Domínio BRD
IP Não Permitido INP
Tipo de Conexão Não Permitida TCNP
Texto no Corpo do E-mail Não Permitido TCENP Fonte: Elaborado pelos autores, 2012
Uma mensagem foi enviada do servidor Rodrigo para o servidor Thor com o
subject HELLO Good day and Compliments, essa mensagem é um tipo boato e por
conter a palavra HELLO ela foi rejeitada. A regra determina que todos os subjects
contendo essa palavra serão rejeitados. A figura 4.21 mostra o log de e-mail com a
rejeição da mensagem.
/^Subject.*via.*gra/ REJECT SEU E-MAIL FOI CONSIDERADO SPAM - BAM 003
/^Subject.*vi.*gr.*/ REJECT SEU E-MAIL FOI CONSIDERADO SPAM - BAM 002
/^Subject.*jaculation*/ REJECT SEU E-MAIL FOI CONSIDERADO SPAM - BAM 001
# ========== Bloqueio de E-mail Enviados por Programa de Envio em Massa = BEEPEM
/^X-Mailer: .*Avalanche/ REJECT SEU E-MAIL FOI CONSIDERADO SPAM - BEEPEM 007
/^X-Mailer: .*Caretop 2604/ REJECT SEU E-MAIL FOI CONSIDERADO SPAM - BEEPEM 006
77
Figura 4.21 – Bloqueio por cabeçalho Fonte: Elaborado pelos autores, 2012
A figura 4.22 mostra os bloqueios por meio das regras de BRD e TCENP, foi
incluído o IP do servidor Rodrigo no arquivo de domínios proibidos. Já o outro
bloqueio se deu pela regra TCENP 001, que determina o bloqueio das mensagens
contendo a palavra dinheiro no corpo da mensagem.
Figura 4.22 – Bloqueios Fonte: Elaborado pelos autores, 2012
4.2.9 Restrições por Classes
Segundo Dent (2003) as restrições por classes são úteis quando se tem
usuários da rede que não querem receber nenhum tipo de spam, mesmo correndo o
risco de perder alguns e-mails legítimos e outros que não se importam em receber
spams. Para isso tem que se criar duas classes, por exemplo: a spamlover, que vai
receber todas as mensagens e a spamhater, que vai utilizar todos os recursos de
combate ao spam. No arquivo main.cf configurar as diretivas:
smtpd_restriction_classes = spamlover, spamhater
Definir as restrições em cada classe:
spamhater =
reject_invalid_hostname
reject_non_fqdn_hostname
Nov 17 19:22:12 thor postfix/smtpd[3679]: connect from rodrigo[10.50.50.2]
Nov 17 19:22:12 thor postfix/smtpd[3679]: 4A5DB39F25: client=rodrigo[10.50.50.2]
Nov 17 19:22:12 thor postfix/cleanup[3682]: 4A5DB39F25: reject: header Subject: HELLO Good
day and Compliments from rodrigo[10.50.50.2]; from=<[email protected]>
to=<[email protected]> proto=ESMTP helo=<rodrigo.teste.com.br>: 5.7.1 SEU E-MAIL FOI
CONSIDERADO SPAM - BAM 013
Nov 17 19:22:12 thor postfix/smtpd[3679]: disconnect from rodrigo[10.50.50.2]
Nov 18 12:17:07 thor postfix/cleanup[5945]: A874739FA3: reject: header From: "Admin"
<[email protected]> from rodrigo[10.50.50.2]; from=<[email protected]>
to=<[email protected]> proto=ESMTP helo=<rodrigo.teste.com.br>: 5.7.1 SEU E-MAIL FOI
CONSIDERADO SPAM - BRD 010
Nov 18 12:48:14 thor postfix/cleanup[6797]: A58D539F1A: reject: body Com isso vc. vai
ganhar muito dinheiro... from rodrigo[10.50.50.2]; from=<[email protected]>
to=<[email protected]> proto=ESMTP helo=<rodrigo.teste.com.br>: 5.7.1 SEU E-MAIL FOI
CONSIDERADO SPAM - TCENP 001
78
reject_unknown_sender_domain
reject_rbl_client xxx.com
spamlover = permit
Criar um arquivo contendo os usuários e suas preferências, chamado de
user_list:
#
# Lista de Acesso Por usuário – define a
# classe de spam para cada usuário
#
[email protected] spamhater
[email protected] spamlover
Configurar a diretiva no Postfix para verificar o arquivo de Lista de Acesso:
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
check_recipient_access
hash:/usr/local/etc/postfix/user_list
Feito isso, todos os e-mails recebidos pelo João serão bem vasculhados,
enquanto os da Maria não.
4.3 CLAMAV
Segundo Loriato e Loriato (2008) o antivírus Clam Antivírus, ou ClamAv como
é mais conhecido, é o principal antivírus livre do mercado, ele foi criado em meados
de janeiro de 2002, licenciado pela GPL e mantido até hoje pela comunidade aberta.
Desde sua criação vem sendo utilizado em várias máquinas que rodam Linux/Unix e
cumprindo com o propósito inicial, que é oferecer segurança às máquinas que o
utilizam. Neste trabalho ele foi utilizado com a finalidade de ajudar o Postifix no
combate ao spam, pois muitos dos e-mails considerados spam trazem consigo um
vírus.
Para fazer com que o ClamAv varresse os e-mails recebidos pelo o usuário,
foi necessário a implementação de um script, que é facilmente encontrado na
Internet, o qual faz com que o Postfix redirecione para o Clamav todo e-mail
recebido. O script utilizado no ambiente de teste, o qual foi inicialmente desenvolvido
79
por Deives Michellis, foi encontrado em http://granito2.cirp.usp.br/Tutorial.Postifix.C
IRP.pdf , páginas 24, 25 e 26 com acesso em 06/11/2012.
A figura 4.23 mostra o log registrado pelo servidor Thor, onde a mensagem
enviada foi detectada como vírus e removida posteriormente. Quando é detectado
um vírus, o servidor envia um e-mail para o postmaster, que é o administrador
daquele serviço, dizendo que alguns dos seus usuários receberam um vírus, o e-
mail ainda conta com o detalhe de quem enviou e para quem.
Figura 4.23 - Log de e-mail rejeitado por conter vírus. Fonte: Elaborado pelos autores, 2012.
Isso mostra que o um antivírus configurado no servidor de e-mail é muito
importante, pois ele filtra inúmeras mensagens contendo vírus.
4.4 SPAMASSASSIN
Como visto, o próprio Postfix permite uma filtragem de spam bastante
seletiva, no entanto muitas vezes temos também outros parâmetros a observar para
identificar um spam, é aí onde entra o Spamassassin.
O core do Spamassassin é uma série de módulos Perl, que fazem avaliações
específicas e considera todas as avaliações de uma forma abrangente. Geralmente
o Spamassassin é rodado como daemon, ou seja, um programa que executa em
segundo plano no sistema operacional e analisa todas as mensagens que o servidor
recebe, é o que afirma Schwartz (2004).
Segundo Schwartz (2004) basicamente o Spamassassin trabalha com o
conceito de score, ou seja, ele faz uma pontuação sobre a mensagem que analisa, o
administrador delimita a pontuação máxima que uma mensagem possa ter para que
esta não seja considerada spam e siga o fluxo de entrega normalmente. Caso essa
pontuação seja excedida, esta mensagem será tratada como um spam e sofrerá as
alterações programadas pelo administrador.
Schwartz (2004) afirma ainda que os elementos predeterminantes do score
analisam o cabeçalho e o corpo da mensagem avaliando se seguem a formatação
padrão, se possuem frases comumente encontradas em um spam, se existem
80
referências a essa mensagem com uma consulta online a bancos de dados, se o
endereço IP da origem está em uma lista negra disponibilizada por organizações
anti-spam e se o usuário que enviou a mensagem tem permissão de envio no
domínio no qual diz pertencer. O Spamassassin pode ainda aprender com as
mensagens que o usuário sinaliza como spam ou não-spam e dar maior prioridade
de recebimento a mensagens advindas de servidores com alto poder computacional.
Uma possibilidade adicional é o uso de White lists e Black lists, isto é, listas
brancas e listas negras localmente no servidor a fim de se desconsiderar resultados
de testes de spam para domínios cadastrados. Para isso é necessário apenas
adicionar os domínios desejados a bloquear ou liberar no arquivo de configuração
principal do Spamassassin.
Quando o Spamassassin define como spam uma mensagem que não é de
fato um spam, esse conceito é dado como falso positivo, quando ocorre o contrário,
ou seja, quando o Spamassassin não define como spam uma mensagem que é de
fato um spam, este conceito é dado como falso negativo, esses tipos de ocorrências
são toleráveis desde que com baixa incidência e é algo que muito tem a ver com a
configuração executada pelo administrador, as principais configurações estão
ligadas a personalização de score de testes, criação de suas próprias regras e forma
de entrega da mensagem ao usuário final.
Segundo Schwartz (2004), por padrão o Spamassassin envia as mensagens
spam que detecta aos usuários finais alterando o subject da mensagem para
“*****SPAM*****”, possibilitando uma fácil filtragem pelo MUA. Essa mensagem pode
ser personalizada, ou ainda, remover estes e-mails no servidor sem entrega-los ao
usuário final.
Por padrão o Spamassassin vem configurado para a língua inglesa, no
entanto para a utilização na língua portuguesa algumas regras possivelmente
precisarão ser criadas, surge aí uma das necessidades de criar novas regras para o
Spamassassin.
Para uma nova regra é preciso usar a sintaxe semelhante ao seguinte
exemplo 4.24, na descritiva campo deve estar o campo da mensagem que a regra
irá analisar, na descritiva MY_NOME_REGRA deve estar o nome da regra precedido
de MY - o que indica que é uma regra escrita pelo administrador, na descritiva
parâmetro deve estar aquilo pelo que a regra está buscando, a descritiva score é
uma palavra reservada e na sua linha na descritiva peso deve estar o valor em
81
decimal do peso para cálculo de score, a descritiva describe é uma palavra
reservada e sua linha possui o nome da regra e explica qual é a sua função.
Schwartz (2004)
Figura 4.24 – Sintaxe de uma regra no Spamassassin Fonte: Elaborado pelos autores, 2012.
Para análise do corpo de uma mensagem, são utilizadas as Body Rules, por
exemplo, uma regra com campo body e parâmetro viagra, para buscar a palavra
viagra no corpo da mensagem como a figura 4.25
Figura 4.25 – Exemplo de regra de corpo. Fonte: Elaborado pelos autores, 2012.
Para análise de cabeçalho, são utilizadas as Header Rules, por exemplo, uma
regra com o campo header e parâmetro subject = oferta, como na figura 4.26
Figura 4.26 – Exemplo de regra de cabeçalho. Fonte: Elaborado pelos autores, 2012.
Para análise de links contidos em seções HTML do e-mail, são utilizadas as
URI Rules, como na figura 4.27
Figura 4.27 – Exemplo de regra de URI. Fonte: Elaborado pelos autores, 2012.
Para análise de itens a ser executada antes que o SpamAssassin processe o
e-mail e retire algumas formatações importantes tais como tags HTML e finais de
linha, são utilizadas as Rawbody Rules, como na figura 4.28 que procura pela
campo MY_NOME_REGRA parâmetro
score MY_NOME_REGRA peso
describe MY_NOME_REGRA Regra para demonstração de sintaxe
body MY_VIAGRA /viagra/
score MY_VIAGRA 0.1
header MY_OFERTA Subject =~ /\boferta\b/i
score MY_OFERTA 0.1
uri MY_VIAGRA_LINK /www.exemplo.com\/OrderViagra\//
score MY_VIAGRA_LINK 0.1
82
assinatura de um software de propagação de spam.
Figura 4.28 – Exemplo de regra de rawbody. Fonte: Elaborado pelos autores, 2012
Para análises mais complexas, compostas por mais de uma regra, são
utilizadas as Meta Rules, como na figura 4.29 que considera a ocorrência da palavra
sexo associada à ocorrência da origem fateclins.edu.br, admitindo a possibilidade de
estar relacionado a gênero masculino ou feminino em um formulário por exemplo, a
regra calcula essas ocorrências e desconsidera a definição de spam, um detalhe
com relação a sintaxe é o uso do duplo underline junto com o nome da regra parcial.
Figura 4.29 – Exemplo de regra de meta. Fonte: Elaborado pelos autores, 2012
Após a mensagem passar pelas regras e essas serem satisfeitas ou não, ao
final é dado o score total da mensagem, como no exemplo da figura 4.30, onde
mostra que a mensagem analisada possuía um score de valor 9, quando o requerido
para ser spam é a partir de 5.
Figura 4.30 – Exemplo de uma mensagem definida como spam. Fonte: Elaborado pelos autores, 2012
A figura 4.31 mostra o log de um servidor legítimo com algumas mensagens
consideradas spam. As mensagens geradas a partir do Spamassassin podem ser
interpretadas da seguinte forma: | mês | dia | hora | nome do servidor | software
utilizado (Spamassassin) | [número do processo] | resultado gerado | regras
rawbody MY_SPAMMER /\<\-\-! created with spamware 1\.0 \-\-\>/
score MY_SPAMMER 0.1
header __MY_FATEC From =~ /fateclins\.edu/\.br/i
body __MY_SEXO /sexo/
meta MY_FATEC_SEXO (__MY_FATEC && __MY_SEXO)
score MY_SPAMMER -1.0
Nov.5 02:21:09 thor spamd[53912]: spamd: result: Y 9 -
BR_COPYRIGHT,BR_SPAMMER_URI,HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_M
ULTI,MIME_QP_LONG_LINE,MPART_ALT_DIFF,RP_MATCHES_RCVD,SUBJECT_NEEDS_ENCO
DING,URIBL_DBL_SPAMscantime=6.1,size=32801,user=clamav,uid=063,required_
score=5.0,rhost=localhost,raddr=127.0.0.1,rport=37290,mid=<5E.F6.00753.D
35EF269@mta02>,bayes=0.022088,autolearn=no
83
utilizadas para análise da mensagem | tempo utilizado | tamanho da mensagem
| usuário | identificador do usuário | pontuação máxima desejada | host | porta |
identificador@domínio |.
Figura 4.31 – Mensagens consideradas Spams. Fonte: Elaborado pelos autores, 2012
4.5 ANÁLISE DOS RESULTADOS
Nas seções anteriores foram mostradas algumas regras testadas dos
servidores virtuais THOR e RODRIGO. Cabe salientar que nem todas as regras
puderam ser testadas no ambiente de simulação, pois os servidores não são
domínios registrados. Entretanto, após o entendimento das regras e testes no
ambiente simulado, várias regras foram aplicadas em um servidor de e-mail de uma
Instituição (aqui não identificada) e foi analisado o log do servidor de e-mail para
comprovar a efetividade de cada regra no combate ao spam.
Para se obter algumas conclusões sobre o combate ao spam, e qual a melhor
regra ou melhor ferramenta a se utilizar nesse combate, foi extraído o log de e-mail
do servidor real apelidado aqui de servidor XXX. O log de e-mail é um arquivo texto
contendo informações de todas as mensagens de e-mail processadas
(recebidas/enviadas) pelo servidor de correio eletrônico, bem como as mensagens
emitidas pelo antivírus Clamav e pelo anti-spam Spamassassin que também são
utilizados pelo servidor XXX. Os registros analisados são referentes a oito dias, de
01 à 08/11/2012. Eles foram divididos em oito arquivos, cada arquivo contendo as
Nov 8 20:29:27 platao spamd[854]: spamd: result: Y 23 -
BAYES_99,BR_ADJUST_2,BR_CLIQUE_AQUI,BR_SPAMMER_URI,HTML_IMAGE_ONLY_1
6,HTML_MESSAGE,HTML_SHORT_LINK_IMG_2,MIME_HEADER_CTYPE_ONLY,MIME_HTM
L_ONLY,RCVD_IN_BRBL_LASTEXT,RCVD_IN_PSBL,RP_MATCHES_RCVD,SUBJECT_NEE
DS_ENCODING,SUBJ_ALL_CAPS,SUBJ_ILLEGAL_CHARS,T_KHOP_FOREIGN_CLICK,T_
RP_MATCHES_RCVD,T_URIBL_BLACK_OVERLAP,URIBL_BLACK,URIBL_DBL_SPAM,URI
BL_WS_SURBL
scantime=8.0,size=2097,user=clamav,uid=106,required_score=5.0,rhost=
localhost,raddr=127.0.0.1,rport=22535,mid=<20121108222542.93FF213D17
[email protected]>,bayes=1.000000,autolearn=spam
Nov 8 20:33:58 platao spamd[854]: spamd: result: Y 8 -
BAYES_99,BR_CLIQUE_AQUI,HTML_IMAGE_ONLY_08,HTML_IMAGE_RATIO_02,HTML_
MESSAGE,RCVD_IN_BRBL_LASTEXT,T_KHOP_FOREIGN_CLICK
scantime=6.6,size=2409,user=clamav,uid=106,required_score=5.0,rhost=
localhost,raddr=127.0.0.1,rport=10986,mid=<6d3d89a23c5ea765828b57de5
[email protected]>,bayes=1.000000,autolearn=no
84
mensagens de um dia. O quadro 4.3 mostra o histórico dos e-mails.
Quadro 4.3 – Estatística Geral de Bloqueios
Servidor XXX
8 d
ias
de
an
ális
e Técnica/Ferramenta de detecção de
Spam Nº de Mensagens
Recebidas Mensagens em %
Spam/Spamassassin 4734 1,1%
Vírus/Clamav 7 0,0016%
Rejeitadas/Postfix 421222 95,4%
Bouced/Postfix 20 0,005%
Deferred/Postfix 346 0,1%
Total de mensagens bloqueadas 426329 96,5%
Total de mensagens não bloqueadas 15353 3,5%
Total de Mensagens recebidas 441682 100% Fonte: Elaborado pelos autores, 2012
O quadro 4.3 mostra que apenas 1,1% das mensagens são bloqueadas a
partir da análise do Spamassassin, o tópico 4.4 deste capítulo explica algumas
dessas regras, e as figuras 4.30 e 4.31 exemplificam as mensagens geradas em log
após a detecção. Já o antivírus Clamav, bloqueou 0,0016% das mensagens por
conterem vírus, o tópico 4.3 explica um pouco mais sobre análise feita pelo Clamav.
O quadro 4.4 mostra os principais bloqueios feitos pelo Postfix, todas as restrições e
regras são explicadas e exemplificadas nos tópicos 4.2.3 ao 4.2.8.
Quadro 4.4 - Bloqueios pelo Postfix
Postfix
Bloqueios Nº de
Mensagens Recebidas
Mensagens em %
Restrições de Clientes 215088 56,0%
Restrições de Hostname/DNS/IP 109132 28,4%
Hostname ausente/Helo 35951 9,4%
Domínio não encontrado 23597 6,1%
Fonte: Elaborado pelos autores, 2012
85
A técnica de bouced, também foi citada no quadro 4.3, são aquelas
mensagens bloqueadas por algum motivo, caixa do destinatário cheia, servidor de e-
mail indisponível ou etc. Deferred é outro tipo de restrição, mas que na realidade são
mensagens que ficam em uma fila de espera, e aguardam algum tipo deliberação
para serem entregues.
Pode-se observar claramente a ferramenta mais importante de todo esse
cenário de combate ao spam ou mensagem não solicitada, o Postfix foi a ferramenta
que mais bloqueou as mensagens, com aproximadamente 98,9% das 426329
mensagens bloqueadas, nem por isso as outras ferramentas são desnecessárias em
um servidor de e-mail real. Cada uma delas tem sua utilidade, pois se uma
determinada mensagem “y”, que realmente é um spam, não for detectada pelo
Postfix e nem pelo Clamav, muito provavelmente o Spamassassin vai detectar essa
mensagem. Também a de se destacar a importância de um software de antivírus
associado ao sistema de correio eletrônico, pois mesmo com a baixa incidência
detectada, caso apenas um destes vírus chegue à caixa postal de um usuário da
empresa e, posteriormente, à sua estação de trabalho, além de infectar esta estação
o vírus pode se propagar pela rede ou pode se auto-enviar para a lista de contatos
do usuário trazendo grandes prejuízos para a empresa.
Aqui foram mostradas as ferramentas e recursos mais utilizados no combate
ao spam, Entretanto, existem outras que merecem estudos.
86
CONCLUSÃO
O correio eletrônico atualmente é uma das aplicações mais utilizadas pelos
internautas, tornando-se uma ferramenta muito importante para usuários finais,
empresas e seus negócios, tendo uma utilização de 98% nas empresas que
possuem acesso à Internet. O mau uso do correio eletrônico trouxe uma “praga” ao
serviço básico de comunicação pela Internet: o spam. Tornando-se um transtorno na
vida dos usuários, mesmo assim, fica longe de ser o principal problema causado
pelo Spam.
O trabalho mostra que o principal problema do spam é a utilização dos
recursos de informática, como tempo de utilização de CPUs, tráfego de rede e
armazenamento físico dos dados, todos esses recursos estão escassos, ainda mais
nos dias de hoje, que o poder computacional é muito maior e demanda mais
equipamentos, tanto de hardware quanto de software.
Com os resultados mostrados no trabalho foi possível alcançar o objetivo
proposto, porém as conclusões foram adversas às imaginadas no início da pesquisa,
onde o Spamassassin ganhava toda credibilidade na luta contra o spam, mas quem
se mostrou imprescindível foi o conjunto de diretivas de combate ao spam
disponibilizadas pelo próprio MTA Postfix. É importante lembrar que as outras
ferramentas aqui exploradas como Spamassassin e Clamav não são desprezíveis,
pois as mensagens liberadas pelo Postfix serão analisadas e, se necessário,
bloqueadas por outras ferramentas. Outro ponto que deve ser observado é a
conduta dos usuários de e-mail, que na maioria das vezes contribuem muito para
propagação do Spam, segundo Teixeira (2004) alguns “mandamentos” devem ser
seguidos para não contribuir com o Spam, ou ainda pior, não se tornar uma
spammer, não respondendo e-mails desconhecidos, contendo vírus, correntes,
boatos, lendas e etc. O administrador de rede é o principal responsável pela
configuração do servidor de e-mail, e uma configuração bem feita resulta em um
servidor bem mais seguro e protegido.
É bom destacar que nenhuma ferramenta anti-spam é totalmente segura, e
que sempre haverá spams nas caixas de entrada dos usuários. O melhor a se fazer
é manter as regras atualizadas e bem configuradas no servidor para se ter uma
proteção mais eficaz. Este trabalho mostrou a integração de três das principais
87
ferramentas de combate ao spam: regras do MTA Postfix, anti-vírus Clamav e anti-
spam Spamassassin. Porém, existem outras técnicas.
Dessa forma, trabalhos futuros poderão ser desenvolvidos utilizando esse
trabalho como base, na implementação de outras técnicas e também outras
ferramentas em servidores reais distintos, demonstrando as mais diversas maneiras
de se combater o spam, bem como a eficiência de cada uma delas.
88
REFERÊNCIAS BIBLIOGRÁFICAS
ANTISPAM.BR. Tipos de Spam. 2012. Disponível em: < http://www.antispam.br/historia/ > Acesso em: 20 nov. 2012. CERT Centro de estudos, respostas e tratamento de incidentes de segurança no Brasil. Estatísticas: Total de spams reportados ao CERT.br por ano. 2012. Disponível em: <http://www.antispam.br/estatisticas/> Acesso em: 20 nov. 2012. CERT Centro de Estudos, Respostas e tratamento de Incidentes de Segurança no Brasil. História: Origem e Curiosidades. Disponível em: < http://www.antispam.br/historia/ > Acesso em: 20 nov. 2012. CGI Comitê Gestor da Internet no Brasil. Pesquisa sobre o uso das tecnologias de informação e comunicação no Brasil. 2010. Disponível em: <http://www.cetic.br> Acesso em: 04 mar. 2012. COMER, D. E. Interligação de redes com TCP/IP, Volume 1 – Princípios, protocolos e arquitetura. 5. ed. Rio de Janeiro: Elsevier Editora, 2006. CORRENTE. Lenda: Capes vai desativar portal. 2012. Disponível em: < http://www.quatrocantos.com/LENDAS/163_portal_capes.htm > Acesso em: 14 out. 2012. DENT, K. D. Postfix: The Definitive Guide. Sebastopol-United States of America: Editora O’Reilly., 2003. FOROUZAN B. A. Comunicação de dados e redes de computadores. 3. ed. Porto Alegre: Bookman, 2008. FRAUDE. Falsa mensagem do Banco do Brasil instala Trojan-Spy.Win32.Banker. 2012. Disponível em: < http://www.quatrocantos.com/lendas/224_banco_do_brasil.htm > Acesso em: 14 out. 2012. GOLPE DA NOGÉRIA. O golpe dos nigerianos. 2012. Disponível em: < http://www.quatrocantos.com/lendas/58_419_scam_nigeria.htm > Acesso em: 14 out. 2012. IBOPE. Número de brasileiros com acesso à Internet chega a 83,4 milhões de pessoas. 2012. Disponível em: http://www.ibope.com/pt-br/noticias/Paginas/Numero-de-brasileiros-com. aspx > Acesso em: 20 nov. 2012. INTERNET. Computer history museum. 2006. Disponível em: <http://www.computerhistory.org/Internet_history/Internet_history_70s.html> Acessado em 16 de abr. 2012. LORIATO, L. A; LORIATO, L. A. Protótipo de anti-vírus estático com verificação on-access em ambiente windows utilizando a engine do Clamav. 2011. TCC
89
(Graduação em Engenharia de Sistemas e Computação) – Instituto Militar de Engenharia, Rio de Janeiro. MORIMOTO, C. E. Redes, Guia Prático. Porto Alegre: Sul Editores, 2008. NEMETH, E.; SNYDER, G.; HEIN, T. R. Manual Completo do Linux, Guia do Administrador. 2. ed. São Paulo: Prentice Hall (Pearson), 2007. OLIVEIRA, W. M. Postfix, Servidor de e-mail livre - Guia Prático. Rio de Janeiro: Editora Ciência Moderna Ltda., 2011. SCHWARTZ, A. Spamassassin. Sebastopol-United States of America: Editora O’Reilly., 2004. TANENBAUM, A. S. Redes de computadores. 4. ed. Rio de Janeiro: Elsevier Editora, 2003. TEIXEIRA, R. C. Combatendo o Spam: aprenda como evitar e bloquear e-mails não-solicitados. São Paulo: Novatec, 2004.