Embed Size (px)
Citation preview
FURB – UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE PÓS-GRADUAÇÃO EM TÉCNOLOGIAS PARA O
DESENVOLVIMENTO DE APLICAÇÕES WEB
PROTÓTIPO DE UMA FERRAMENTA PARA ANÁLISE
DO LOG DE EVENTOS DE UM FIREWALL
MARCIANO DOVAL DALLMANN
BLUMENAU
2005
MARCIANO DOVAL DALLMANN
PROTÓTIPO DE UMA FERRAMENTA PARA ANÁLISE
DO LOG DE EVENTOS DE UM FIREWALL
Esta monografia de conclusão de curso apresentada ao Programa de Pós-Graduação em Tecnologias para o desenvolvimento de aplicações Web do Centro Ciências Exatas e Naturais da Furb – Universidade Regional de Blumenau, como requisito parcial para a obtenção do grau de Especialista em Informática.
Prof. MsC. Francisco Adell Péricas – Orientador
BLUMENAU
2005
MARCIANO DOVAL DALLMANN
PROTÓTIPO DE UMA FERRAMENTA PARA ANÁLISE DO LOG DE EVENTOS DE UM
FIREWALL
Monografia aprovada com conceito “____”, para a obtenção do certificado de “Especialista”, no
Curso de Pós-Graduação em Nível de Especialização em Tecnologias para o Desenvolvimento de
Aplicações WEB, promovido pela Universidade Regional de Blumenau – FURB.
Orientação:
_________________________________________________ Prof. Francisco Adell Péricas, MsC - Orientador, FURB
Comissão Avaliladora:
_________________________________________________ Membro: Prof. Janes Fidelis Tomelim, MeE, FURB
_________________________________________________ Membro: Prof. Paulo Fernando da Silva, MsC, FURB
Blumenau,
Abril de 2005
Dedico este trabalho ao meu filho, Caio de Mattos Dallmann, e minha esposa Josiane que me deu este lindo presente, despertando em mim as forças necessárias a alcançar mais este objetivo.
AGRADECIMENTOS
Agradeço profundamente, a DEUS por ter me dado esta laboriosa experiência carnal, aos
meus pais o consentimento em seu seio familiar e profícua orientação para vida, a minha esposa
Josiane de Mattos Dallmann, pela nobre compreensão da minha freqüente ausência em virtude dos
meus estudos.
Agradeço especialmente ao excelso professor Francisco Adell Péricas, pela honra de tê-lo
como orientador, por ter me permitido granjear conhecimentos, indispensáveis para o sucesso de
mais esta etapa na minha vida.
Agradeço ao companheirismo dos meus amigos e companheiros de curso Cássio Grossklags
e Davi Floriani Coelho.
Agradeço também ao amigo Julio Westarb Junior, que me despertou o interesse no mundo
do código livre, e pela contribuição com sua experiência em administração de redes e firewall.
E para findar, agradeço a todos professores e amigos que ajudaram a alcançar com sucesso
os meus objetivos.
Código livre - Milhões de mentes abertas não podem estar enganadas!
Comunidade Código Livre
RESUMO
Esta monografia de conclusão de curso apresenta um estudo sobre um firewall, e considerações
sobre segurança em redes. Apresenta também a especificação e implementação de um protótipo de
uma ferramenta para análise do arquivo de Log de eventos do firewall IpTables. Este protótipo se
propõe a facilitar a apresentação das informações contidas neste arquivo de Log para o
Administrador da rede.
Palavras Chaves: Log, internet; firewall, segurança.
ABSTRACT
This monograph presents a study about a firewall, and considerations about network security. It also
presents the specification and implementation of a prototype of a software that analyze the IpTables
firewall event Log file. This prototype propose to facilitate the presentation of the information
contained in this Log file for the network Administrator.
Key-words: Log, internet; firewall, security.
LISTA DE ILUSTRAÇÕES
Lista de Figuras Figura 1 - Total de incidentes reportados ao NBSO por ano (1999 à 2004) ..................................26 Figura 2 - Diagrama de Casos de Uso ............................................................................................65 Figura 3 - Diagrama de Classes do Sistema ...................................................................................67 Figura 4 - Diagrama de seqüência a, b, c........................................................................................69 Figura 5 - Diagrama de Seqüência d, e, f........................................................................................70 Figura 6 - Diagrama de seqüência g, h ...........................................................................................71 Figura 7 - Diagrama de Atividades.................................................................................................71 Figura 8 - Página Web principal do protótipo ................................................................................76 Figura 9 - Tela de configuração de exibição...................................................................................76 Figura 10 - Tela de manutenção da tabela TableMonitorar .............................................................77 Figura 11 - Tela de manutenção da tabela TablePorta .....................................................................77 Figura 12 - Tela de Estatísticas.........................................................................................................78 Lista de Tabelas Tabela 1 - Incidentes reportados ao NBSO – Julho a Setembro de 2004 ....................................... 27 Tabela 2 - Exemplos comuns de portas bem conhecidas................................................................ 44 Tabela 3 - Descrição do formato dos campos de Log do Netfilter/IpTables................................... 59 Tabela 4 - Exemplo de codigo do firewall (monitorar portas conhecidas)......................................74 Tabela 5 - Trecho de código do módulo LeitorLog......................................................................... 75
LISTA DE SIGLAS E ABREVIATURAS
CRC - Cyclic Redundancy Check
DoS – Denial of Service
DDoS – Distributed Denial of Service
FTP – File Transfer Protocol
HTTP - HiperText Transfer Protocol
IANA - Internet Assigned Numbers Authority
ICMP – Internet Control Message Protocol
IP – Internet Protocol
IPX – Internetwork Packet Exchange
LAN – Local Area Network
NAT – Network Address Translation
NBSO – NIC BR Security Office
OSI – Open System Interconection
PCAP – Packet Capture Library
P2P – Peer to Peer
SNMP – Simple Network Management Protocol
TCP – Transmission Control Protocol
UDP – User Datagram Protocol
SUMÁRIO
1 INTRODUÇÃO................................................................................................................13
1.1 PROBLEMA DE PESQUISA ...........................................................................................18
1.2 QUESTÃO DE PESQUISA...............................................................................................19
1.3 OBJETIVOS ......................................................................................................................19
1.3.1 Geral...............................................................................................................................19
1.3.2 Específicos .....................................................................................................................20
1.4 PRESSUPOSTOS ..............................................................................................................20
1.5 JUSTIFICATIVA PARA ESTUDO DO TEMA...............................................................20
1.6 ESTRUTURA DO TRABALHO.......................................................................................21
2 SEGURANÇA EM REDES.............................................................................................22
2.1 ESTATÍSTICAS DE INCIDENTES RELACIONADOS AO USO DA INTERNET......23
2.2 ALGUMAS AMEAÇAS CONHECIDAS ........................................................................27
2.3 POLÍTICA DE SEGURANÇA..........................................................................................32
3 FIREWALL......................................................................................................................39
3.1 FILTRAGEM DE PACOTES............................................................................................47
3.2 IPTABLES.........................................................................................................................50
3.3 LOG ...................................................................................................................................58
3.4 TRABALHOS CORRELATOS ........................................................................................61
3.4.1 IPTABLES LOG ANALIZER.......................................................................................61
3.4.2 FWLOGVIEW ...............................................................................................................62
3.4.3 IPTLOG .........................................................................................................................63
4 DESENVOLVIMENTO DO PROTÓTIPO ..................................................................64
4.1 ESPECIFICAÇÃO DO PROTÓTIPO ...............................................................................64
4.1.1 Diagrama de Casos de Uso ............................................................................................64
4.1.2 Diagrama de Classes ......................................................................................................66
4.1.3 Diagrama de Seqüência..................................................................................................68
4.1.4 Diagrama de atividades ..................................................................................................71
4.2 IMPLEMENTAÇÃO DO PROTÓTIPO ...........................................................................72
4.2.1 Configuração do Firewall...............................................................................................73
4.2.2 Módulo LeitorLOG........................................................................................................74
4.2.3 Página Web do Sistema Análise de Log ........................................................................75
4.3 RESULTADOS E DISCUSSÕES .....................................................................................79
5 CONCLUSÕES ................................................................................................................81
5.1 EXTENSÕES.....................................................................................................................82
REFERÊNCIAS...............................................................................................................................83
13
1 INTRODUÇÃO
Com a popularização da internet e o surgimento de várias aplicações voltadas a ela,
aumentou também a disseminação de vírus de computadores e também surgiram outros
problemas como a má utilização pelos funcionários causando prejuízos a empresas, acessos
indevidos a redes e roubo de informações. Em função disso, surgiu a necessidade de criar
mecanismos de segurança para minimizar estes riscos e tornar a internet um meio mais
confiável.
Segundo Soares (1995), para permitir o intercâmbio de dados entre computadores de
fabricantes distintos, tornou-se necessário difundir uma arquitetura de rede única para garantir
que nenhum fabricante levasse vantagem em relação aos outros: a arquitetura teria que ser
aberta e pública. Foi com esse objetivo que a International Organization for Standardization
(ISO) definiu o modelo denominado Reference Model for Open Sistems Intercommunication
(OSI) que propõe uma estrutura com sete níveis como referência para a arquitetura dos
protocolos de redes de computadores.
A coexistência de redes heterogêneas (locais, metropolitanas e de longa distância)
fez com que se tornasse necessário definir uma arquitetura voltada para interconexão dessas
redes. Uma arquitetura importante no contexto de interconexão de redes heterogêneas é a
arquitetura internet, que se baseia na família dos protocolos Transmission Control Protocol /
Internet Protocol (TCP/IP)
Segundo Costa (2004), com o advento da internet e sua ampla difusão nas empresas,
os funcionários passaram a ter contato ilimitado com o mundo externo. Surgiu a figura do
Cyberslacking: sujeito que utiliza intensamente a internet no ambiente de trabalho para fins
14
pessoais. Este "sujeito" corresponde a 90% dos funcionários das empresas, segundo pesquisa
da Vault.com. E mais, 15% ultrapassam as 2 horas diárias.
Este comportamento leva a conseqüências graves, como a queda no rendimento
profissional, o aumento de consumo da banda de internet, a contaminação dos computadores
por vírus, o aumento da vulnerabilidade e a responsabilidade legal da empresa sobre os atos
do funcionário. Enfim, perda de dinheiro e ganho de preocupações.
Segundo Anchieschi (2000), definitivamente há falta de segurança na internet e
vários fatores contribuem para isso, como por exemplo:
a) falta de educação: é simplesmente o aspecto mais importante em relação à
segurança, mencionando aqui a educação que raramente se extende aos
bastidores dos especialistas em segurança;
b) anonimato: a rede é democrática e dispõe de vários serviços para proteger a
privacidade dos usuários;
c) disseminação da tecnologia: hoje um cracker de nível médio tem a sua
disposição as mesmas ferramentas utilizadas pela maioria das organizações
governamentais e empresas especializadas em segurança. Além disso, as
máquinas que os crackers usam são ferramentas extremamente poderosas,
contribuindo para uma rápida e eficiente operação.
A internet precisa ser segura, não somente por razões de segurança nacional, mas
também de segurança pessoal. A cada dia, mais instituições financeiras e comerciais estão
presentes na internet. Muitos usuários usam a internet para pagar suas contas, fazer declaração
de imposto de renda, fazer compras, etc. Qualquer pessoa pode estar exposta a um ataque.
15
Segundo Mendes (2000), neste vasto mundo de comunicação global, numerosas
conexões por internet e desenvolvimento acelerado de software, segurança de computadores é
um assunto que está cada dia tornando-se mais importante. Inteligência artificial, crackers e
hackers estão se tornando comuns neste contexto. Portanto segurança passa a ser o
requerimento básico porque a comunicação por meio da internet é pela própria natureza
insegura.
Neste contexto, é necessário criar uma política de segurança para os sistemas e para
os usuários, a qual eles devem seguir. O propósito é proteger os dados e as informações de
pessoas externas e talvez dos próprios usuários. Nesta etapa deve-se decidir quem terá acesso
ao sistema, que tipo de acesso e para que. Quem será o responsável pela instalação de
software nos computadores e quem irá autorizá-la, pelo backup e pela manutenção periódica
dos computadores. Também deverá haver o comprometimento por escrito das empresas que
fornecem suporte técnico em relação ao sigilo das informações a que têm acesso.
Basicamente, as medidas de segurança são simples de ser executadas, o difícil é definí-las.
Segundo Péricas (2003), a segurança em relação às informações acessíveis pelas
Local Area Netwoks (LANs) de empresas ou organizações é uma grande preocupação para os
administradores de redes. A forma mais comum de se evitar o acesso a LANs por pessoas não
autorizadas é através do seu isolamento utilizando-se os firewalls.
Para isolar as LANs de uma empresa ou organização através de um firewall é
necessário que, independentemente da forma com que elas estejam interconectadas, todo
tráfego de entrada e de saída da empresa ou organização seja feito exclusivamente através
dele.
Segundo Jang (2003), qualquer comando ou arquivo de configuração que é
configurado para bloquear a entrada de dados em uma LAN é um firewall. A principal
16
ferramenta de firewall de Linux é o IpTables. Diversos comandos IpTables podem ser
conectados em cadeia, onde cada um desses comandos pode ser usado para bloquear ou
permitir dados associados a protocolos específicos.
Dentre as várias funcionalidades essenciais de um firewall, as seguintes são funções
muito importantes (LAUREANO, 2002):
a) proteção contra ataques Denial-Of-Service (DoS), ou negação de serviços,
análises e farejadores (sniffers) – Um firewall funciona como um ponto único
que monitora o tráfego de entrada e de saída. É possível para este firewall limitar
qualquer tipo de tráfego que se desejar;
b) filtragem de IP e de portas – A capacidade de permitir ou rejeitar uma conexão
baseada no endereço IP e/ou no endereço de porta. Este tipo de filtragem é
provavelmente a função mais bem entendida de um firewall. De uma forma geral,
este tipo de filtragem é geralmente feito por filtros de pacotes. A filtragem de
pacotes pode se tornar bastante complexa, pois deve-se sempre considerar que o
tráfego pode ser filtrado de acordo com a origem ou o destino do pacote. Por
exemplo, um filtro de pacotes pode bloquear o tráfego que chega à rede vindo de
um determinado endereço IP e para uma determinada porta;
c) registros complementares – Um dos benefícios mais importantes (mas
ignorado) de um firewall é que ele permite examinar todos os detalhes dos
pacotes de rede que passam por ele. Pode-se descobrir se está para sofrer (ou já
sofreu) um ataque, bastando verificar se no registro existem varreduras de portas
e vários tipos de conexão ao sistema.
17
Segundo Zwicky (2001), a filtragem de pacotes é um mecanismo de segurança de
rede que funciona controlando os dados que podem fluir de e para uma rede.
O dispositivo básico que interconecta redes é chamado roteador. Uma das
características de um roteador de filtragem é que ele deve ser capaz de registrar no Log de
eventos os pacotes aceitos e descartados. As regras refletem a política de segurança,
permitindo saber quando alguém tenta violar esta política. O modo mais simples de conhecer
essas tentativas de violação é através de análise de um Log desse tipo.
Também seria interessante ter a possibilidade de registrar no Log pacotes
selecionados que foram aceitos. Registrar no Log todos os pacotes aceitos significa colocar no
Log uma quantidade muito grande de dados em operação normal, mas pode valer a pena fazê-
lo ocasionalmente para fins de depuração e para lidar com ataques em andamento. Embora
provavelmente se esteja fazendo algum registro de Log no destino do pacote, esse registro de
Log não funciona se o host de destino estiver comprometido, e também não mostrará pacotes
que passem através do filtro de pacotes mas que não tenham um destino válido. Esses pacotes
são interessantes, porque podem ser testes de sondagem realizados por um atacante. Sem as
informações do roteador, não se terá o quadro completo do que o atacante está fazendo.
As informações específicas registradas no Log também são importantes, e os
roteadores de filtragem de pacotes têm recursos amplamente variáveis.
Registro em Log é qualquer procedimento pelo qual um sistema operacional ou
aplicativo registra eventos à medida que eles acontecem e preserva esses registros para
posterior análise (Anônimo, 2000).
18
Em um contexto de segurança, registro em Log serve a um propósito diferente:
preservar um registro contra as ações nocivas de um invasor. Os registros de Log fornecem a
única evidência real de que um crime ocorreu.
De acordo com o exposto acima, esta monografia de conclusão de curso visa criar
uma ferramenta de auxílio na análise dos registros de Log de firewall, principalmente os
registros de Log do firewall IpTables do Linux, com o objetivo de fornecer ao administrador
de rede informações e estatísticas de uma maneira mais adequada e rápida sobre a sua
segurança, identificando serviços rodando ou tentando rodar no servidor e na rede local. Desta
forma, reduz-se os riscos de prejuízos maiores que poderiam ser evitados com a apresentação
das informações de maneira mais rápida e apropriada, prejuízos que podem ser desde a perda
de produtividade dos funcionários utilizando alguns softwares de rede proibidos pela política
de segurança e até alguns programas nocivos rodando na rede.
1.1 PROBLEMA DE PESQUISA
Há alguns softwares de avaliação de Log de firewall, tanto comerciais quanto
gratuitos, porém, dentre os estudados, estes apenas apresentam as linhas de Log numa
interface gráfica ou simplesmente num terminal colorido, não possuindo uma análise muito
maior do que são estes pacotes, cabendo ao administrador realizar toda esta tarefa.
O software proposto visa apresentar ao administrador as informações pré-analizadas
numa interface gráfica considerada mais adequada, disponibilizadas em áreas separadas,
divididas por alguns critérios. Diferente das demais ferramentas, o software já identifica para
o administrador alguns tipos de ataques e alguns programas não permitidos rodando na rede,
monitora portas estranhas mostrando ao administrador a existência de algum programa não
19
identificado ou mesmo vírus existente no host originador dos pacotes, e mostra os pacotes
oriundos das portas conhecidas.
O software proposto também mostra-se muito flexível quanto à inclusão de novos
ítens a serem monitorados e exibidos na tela.
1.2 QUESTÃO DE PESQUISA
As questões de pesquisa que norteiam este estudo são:
a) Os administradores sabem o que está trafegando em sua rede?
b) O acesso a estas informações é rápido e eficiente?
c) Estas informações são apresentadas de maneira adequada?
1.3 OBJETIVOS
A seguir enunciam-se os objetivos geral e específicos de pesquisa.
1.3.1 Geral
Criação de uma ferramenta de análise dos registros de Log de firewall,
principalmente dos registros de Log do firewall IpTables do Linux, para apresentar de uma
forma gráfica e intuitiva um resumo do que acontece no firewall, com estatísticas, tentativas
de acessos a determinadas portas/serviços, identificando tentativas de invasão, e até quais
usuários da rede interna tentam usar programas não autorizados na empresa como por
exemplo: ICQ, MSN Messenger, Kazaa, Emule, etc.
20
1.3.2 Específicos
Os objetivos específicos do trabalho são:
a) extrair as informações do arquivo de Log do firewall;
b) classificar as informações extraídas do Log do firewall;
c) criar uma interface gráfica que facilite o entendimento e visualização das
informações do Log do firewall.
1.4 PRESSUPOSTOS
Com o aumento do uso da internet, os administradores de rede precisam saber o que
está trafegando na sua rede, pois o uso intensivo da internet nas empresas pode ter como
efeito colateral o seu uso para fins particulares dos funcionários causando perda de
produtividade. Também é outra preocupação o acesso a informações sigilosas da empresa, e
demais ataques prejudiciais, como também programas não autorizados tentando rodar na sua
rede.
Estas informações necessárias aos administradores de rede se encontram nos
arquivos de Log, principalmente no Log de eventos do firewall, sendo sua visualização difícil,
e mais difícil ainda sua interpretação de uma maneira eficiente.
1.5 JUSTIFICATIVA PARA ESTUDO DO TEMA
O estudo do firewall IpTables, a criação de regras de Log adequadas e a referida
análise do tráfego registrado nos arquivos de Log, para identificação de possíveis tentativas de
ataque, através da análise do acesso a portas estranhas e da identificação de alguns possíveis
softwares não autorizados rodando na rede, constituem um fator relevante por se tratar de um
21
dos aspectos mais importantes na definição e na implantação e cumprimento de políticas de
segurança de empresas conectadas à internet.
1.6 ESTRUTURA DO TRABALHO
A estrutura deste trabalho está dividido em 5 capítulos.
O capítulo 1 introduz o contexto geral do trabalho e está dividido em problema de
pesquisa, questão de pesquisa, objetivos, pressupostos, justificativa para estudo do tema e
estrutura do trabalho.
O capítulo 2 abrange o tema segurança em redes e está dividido em estatísticas de
incidentes relacionados ao uso da internet, algumas ameaças conhecidas e política de
segurança.
O capítulo 3 abrange o tema firewall e está dividido em filtragem de pacotes,
IpTables, Log e trabalhos correlatos.
O capítulo 4 abrange a especificação do protótipo e está dividido em diagrama de
casos de uso, diagrama de classes, diagrama de sequência e diagrama de atividades. E também
abrange a implementação, apresentando os resultados obtidos com o protótipo desenvolvido.
O capítulo 5 descreve as conclusões obtidas no desenvolvimento desta monografia e
apresenta sugestões para extensões e trabalhos futuros.
Para finalizar, apresenta-se as referências bibliográficas utilizadas durante o
desenvolvimento desta monografia.
22
2 SEGURANÇA EM REDES
Segundo Borelli (2003), o termo segurança traz à memória todos os tipos de itens e
assuntos que se referem à proteção dos dados e à prevenção de acessos indesejáveis. Além
disso, não existe uma única definição para o termo segurança de rede. O que é importante são
os itens e os recursos que uma organização julga importante manter protegidos, para que suas
operações tenham sucesso. Cada rede, empresa e organização precisa ser considerada caso a
caso. Só depois que todos os casos tiverem sido coletados de acordo com a importância desses
itens e/ou serviços é que uma política de segurança pode ser desenvolvida e implementada. As
políticas de segurança não aparecem de uma forma genérica. Uma vez determinadas as
necessidades, uma organização pode começar a construir políticas de segurança modeladas de
acordo com as implementações existentes, mas as políticas precisarão ser melhoradas e
modificadas para se adequarem às especificidades da organização.
Segundo Mendes (2000), segurança em redes de computadores é um assunto bastante
complexo, uma verdadeira arte para proteger uma rede contra ataques maliciosos. Não existe
um sistema completamente seguro, sempre há falhas de segurança, mas o que pode-se fazer é
diminuir estas falhas ao mínimo e implementar medidas preventivas junto com uma política
de informação adequada. Uma importante estratégia é adotar a filosofia de que nunca deve-se
executar no servidor o que não se sabe o que é, pois muitos servidores trazem inúmeros
serviços habilitados por padrão.
Segundo Albuquerque (2001), o acesso à internet traz vantagens indiscutíveis, mas
traz preocupações quanto à segurança das máquinas na rede da organização. Essas
preocupações têm fundamento. Ao longo dos últimos anos, foram noticiados inúmeros casos
de redes invadidas.
23
2.1 ESTATÍSTICAS DE INCIDENTES RELACIONADOS AO USO DA INTERNET
Segundo Websense (2002), o mau uso da internet no ambiente de trabalho custa às
empresas brasileiras mais de três bilhões de reais por ano em termos de produtividade, de
acordo com a companhia de software de gerenciamento de acesso à internet por funcionários,
a Websense Inc., líder mundial em soluções para Gerenciamento de Acesso à internet para
Funcionários (EIM - Enterprise Internet Management),
Graças ao contínuo crescimento do número de usuários com acesso à internet a partir
do trabalho e aos avanços, em termos de atrativos e interatividade, os funcionários têm gasto
cada vez mais tempo navegando na Web com conteúdo de interesse pessoal.
Segundo uma pesquisa da Websense/Harris Interactive, os funcionários admitem
gastar 1,5 hora por semana com visitas a sites de conteúdo não relacionado ao trabalho. Para
se ter uma idéia de quanto a navegação improdutiva afeta os negócios no Brasil, basta
multiplicar a estimativa de tempo gasto por semana com visitas a sites de diversidades, pela
média salarial local, fornecida pelo IBGE - Instituto Brasileiro de Geografia e Estatística.
Em contraste com a informação dos funcionários, os gerentes de Recursos Humanos
reportaram que são gastas cerca de 8,3 horas por semana com acesso a sites que não têm
relação com a atividade de trabalho, o que representa mais tempo do que uma jornada diária e
contribui para agravar a crise mundial.
"O mau uso da internet é um assunto crítico para as corporações, pois, ao mesmo
tempo em que a Web consagrou-se como uma ferramenta de produtividade, em alguns casos,
sua má utilização vem eliminando os benefícios do acesso à internet", afirmou Fernando
Fontão, engenheiro de Sistema Websense para a América Latina (Websense, 2002).
24
"Neste momento de crise, o que as companhias mais precisam é alavancar a
produção. No entanto, em vez de concentrar esforços em maximizar orçamentos cada vez
mais limitados e aumentar os fluxos produtivos, muitos funcionários estão comercializando
ações, fazendo compras, jogando ou ouvindo rádio, tudo pela internet".
Com a tendência mundial de diminuição da carga horária de trabalho semanal, que
visa minorar os efeitos da crise do desemprego, os desperdícios com a navegação improdutiva
(cyberslacking) podem prejudicar ainda mais os resultados de negócio, obrigando as empresas
a tomar sérias iniciativas para tentar conter estes gastos. Ou seja, a queda de produtividade
pode levar os empregadores a medidas drásticas para coibir a navegação pessoal e até a tirar
completamente o acesso do trabalhador à Web.
Segundo IDG (2004a), a troca de arquivos via sistema Peer-to-Peer (P2P) no
ambiente de trabalho é uma das preocupações que as empresas têm enfrentado atualmente,
sobretudo pela redução de produtividade e pelo tempo que a atividade consome dos
funcionários.
De acordo com um estudo da companhia Blue Coat, cerca de 38,6% dos usuários de
P2P realizam esse tipo de atividade durante o trabalho. Desse total, 69,7% afirmaram passar
mais de 16 minutos por dia trocando arquivos, enquanto 15,9% disseram gastar mais de uma
hora.
Em relação ao tipo de aplicações, 41,9% dos usuários de P2P afirmaram utilizar
programas como Kazaa, Morpheus, BearShare, LimeWire e Xolo, além de Gnutella e
FastTrack.
25
Entre os outros efeitos negativos que a troca de arquivos causa às empresas, a Blue
Coat destacou o alto consumo de banda. Em alguns casos, a troca P2P pode consumir até 30%
da capacidade da rede.
O problema ainda está no fato de que, em alguns países, um único usuário que
compartilha arquivos ilegalmente pode provocar processos contra a empresa. O uso do
sistema também favorece a invasão por vírus, além de aumentar as constantes reclamações
sobre o congestionamento da rede.
De acordo com a pesquisa, a tendência é que o porcentual de internautas que utilizam
o P2P aumente e os desafios das empresas, por sua vez, serão encontrar a melhor política para
controlar o acesso à web.
De acordo com IDG (2004b), mais de quatro entre dez americanos usam ferramentas
de comunicação instantânea, sendo que cerca de 11 milhões de pessoas adotam a solução no
ambiente de trabalho.
A maioria desses usuários, entretanto, tem dúvidas sobre a capacidade desses
comunicadores de ampliar a produtividade e estimular a colaboração entre os funcionários nas
empresas, revelou um estudo divulgado pela consultoria Pew Internet & American.
De acordo com o levantamento, 68% daqueles que utilizam instant messengers no
trabalho disseram que essa é uma experiência mista - que em parte contribui e em parte
atrapalha na produtividade. Cerca de 11% dos entrevistados disseram que não conseguem
viver sem eles.
Por outro lado, 10% das pessoas pesquisadas disseram que não se importariam se os
comunicadores fossem banidos do ambiente corporativo. Quando questionados se essas
26
soluções ajudam a melhorar o trabalho em equipe, 40% destacaram que sim, e 50% afirmaram
que elas proporcionam economia de tempo.
No Brasil, o NBSO (NIC BR Security Office), grupo de resposta a incidentes para a
internet brasileira, mantido pelo Comitê Gestor da internet no Brasil, é responsável por
receber, analisar e responder a incidentes de segurança em computadores, envolvendo redes
conectadas à internet brasileira (NBSO, 2003b). Este grupo mantém estatísticas de incidentes
reportados a ela, conforme Figura 1 e Tabela 1:
Figura 1 - Total de incidentes reportados ao NBSO por ano (1999 à 2004)
Fonte: NBSO (2003b)
27
Tabela 1 - Incidentes reportados ao NBSO – Julho a Setembro de 2004 .
Totais Mensais e Trimestral Classificados por Tipo de Ataque
Fonte: NBSO ( 2003b)
2.2 ALGUMAS AMEAÇAS CONHECIDAS
Segundo Anchieschi (2000), a internet nasceu em 1969. Após sua conclusão e
estabilização, pesquisadores confrontaram-se com um fato: a internet não é segura e pode
facilmente ser fraudada. Atualmente escritores, para amenizar esse fato, ressaltam que a
tecnologia de segurança empregada naquela época era muito primitiva. Há um pequeno
engano, pois hoje a tecnologia de segurança de rede é mais complexa e a internet continua
sendo fraudada. Qualquer pessoa pode estar exposta a um ataque. Existem diversos tipos, e
varia muito o grau de comprometimento da rede.
Segundo Borelli (2003), as ameaças a uma rede podem ser bastante óbvias ou podem
vir disfarçadas como atividades ou ações insuspeitas. As organizações possuem dados que são
em geral de uso privado da empresa e não para o consumo do público. Em alguns ambientes,
alguns dados podem estar disponíveis para acesso público, enquanto outros não. Nessas
situações, há a necessidade de se criar verdadeiras barreiras para impedir o acesso não
autorizado do lado público para o privado. A segurança em uma rede envolve segurança física
Mês Totaljul 6773 4636 68 18 0 2 0 7 0 49 0 1791 26 270 3ago 5910 3221 54 26 0 5 0 22 0 71 1 2194 37 371 6set 5167 2997 58 56 1 4 0 13 0 52 1 1704 32 341 6
aw (%) scan (%) fraude (%)worm (%) af (%) dos (%) invasão
Legenda: af: Ataque ao usuário final dos: Denial of Service aw: ataque a servidor Web scan: varredura de portas worm: tipo de vírus
28
e segurança de software. Os aspectos físicos incluem o controle do acesso físico ao
equipamento.
Existem tipos diferentes de pessoas que podem ameaçar uma rede. O termo hacker é
freqüentemente usado para descrever os indivíduos que tentam ganhar ou efetivamente
chegam a obter acesso não autorizado a uma rede ou sistemas em geral.
Segundo Starlin (2000), existem vários tipos de hackers:
a) CARDERS, que fazem compras com cartão de crédito alheio ou gerado, ou
seja, os CARDERS têm uma grande facilidade de fazer compras na internet;
b) HACKERS, que invadem em benefício próprio. Eles pegam tudo o que podem
e não destroem nada;
c) CRACKERS, como hackers, mas que gostam de ver a destruição: invadem e
destroem. São os ladrões da internet, roubam dinheiro, informações, apagam
sistemas, e normalmente deixam sua marca registrada;
d) PHREAKINGS, são os piratas da telefonia, que fazem tudo o que é relativo aos
telefones, convencionais ou celulares.
Segundo Borelli (2003), outra ameaça em potencial à rede de uma empresa são os
ex-funcionários, demitidos sob condições desfavoráveis. Um outro motivo de preocupação
envolvido neste contexto é que, de acordo com alguns peritos em segurança, a maior causa de
furto de dados e vandalismo eletrônico são os próprios funcionários.
Para obter acesso a uma rede, o invasor geralmente começa realizando, com um
scanner, uma varredura de portas (port scan) a fim de descobrir quais portas estão abertas.
29
Segundo Anchieschi (2000), um scanner é um programa que automaticamente
detecta as fraquezas e falhas de segurança em um host local ou remoto. A função de um
verdadeiro scanner é analisar, por meio de um ataque, as portas e serviços (Telnet ou File
Transfer Protocol (FTP), por exemplo) do protocolo TCP/IP, gravando as informações
importantes do alvo.
Spoofing de IP, segundo os autores Anchieschi (2000), Bernstein (1997) e Starlin
(2000), envolve o fornecimento de informações falsas sobre uma pessoa ou sobre a identidade
de um host para obter acesso não autorizado a hosts e/ou aos seus sistemas. O spoofing
interfere na forma como um cliente e um servidor estabelecem uma conexão. O spoofing de
IP consiste na troca do IP original por um outro, podendo assim se passar por outro host, ou
seja, esse tipo de ataque consiste na simulação de pacotes IP em que o objetivo é dar
autenticidade nas relações que envolvem trocas de informações.
Segundo Borelli (2003), o principal objetivo de um Ataque de Negação de Serviço
(DoS - Denial-of-Service) é o de inundar um serviço de rede com tantos pacotes não
desejados que os sistemas afetados fiquem indisponíveis para uso. Se um ataque DoS atingir o
servidor público da Web de uma empresa, os usuários ficam impossibilitados de acessar o site
da Web, que, então, gera um leque completo de outros problemas. A forma mais comum de
um ataque DoS é o ataque SYN. O nome se baseia no pacote usado quando é estabelecida
uma conexão do TCP (Transmission Control Protocol). Quem estiver atacando envia muitos
pacotes SYN quase ao mesmo tempo ao sistema, que passa a gastar todo o seu tempo tentando
satisfazer todas as solicitações de conexão TCP que pensa estarem ocorrendo. Pode-se usar
um firewall apropriadamente configurado para ajudar a deter este ataque, ou para avisar o
administrador de que um ataque DoS está em progresso.
30
Segundo RNP (2000), os ataques Distributed Denial of Service (DDoS), nada mais
são do que o resultado de se conjugar os dois conceitos: negação de serviço e intrusão
distribuída. Os ataques DDoS podem ser definidos como ataques DoS diferentes partindo de
várias origens, disparados simultânea e coordenadamente sobre um ou mais alvos. De uma
maneira simples, é um ataque DoS em larga escala.
Os primeiros ataques DDoS documentados surgiram em agosto de 1999, no entanto
esta categoria se firmou como a mais nova ameaça na internet na semana de 7 a 11 de
fevereiro de 2000, quando vândalos cibernéticos deixaram inoperantes por algumas horas
sites como o Yahoo, EBay, Amazon e CNN. Uma semana depois teve-se notícia de ataques
DDoS contra sites brasileiros, tais como UOL, Globo e IG, causando com isto uma certa
apreensão generalizada.
As principais ferramentas de DDoS são: Trin00, TFN, STACHELDRAHT e TFN2K.
O Trin00 é uma ferramenta distribuída usada para lançar ataques DoS coordenados,
especificamente, ataques do tipo UDP FLOOD.
O TFN (Tribe Flood Network) é uma ferramenta distribuída usada para lançar
ataques DoS coordenados a uma ou mais máquinas vítimas, a partir de várias máquinas
comprometidas. Além de serem capazes de gerar ataques do tipo UDP FLOOD como o
Trin00, uma rede TFN pode gerar ataques do tipo SYN FLOOD, ICMP FLOOD e
SMURF/FRAGGLE.
Baseado no código do TFN, o STACHELDRAHT é outra das ferramenta
distribuídas usadas para lançar ataques DoS coordenados a uma ou mais máquinas vítimas, a
partir de várias máquinas comprometidas. Como sua predecessora TFN, ela também é capaz
de gerar ataques DoS do tipo UDP FLOOD, TCP FLOOD, ICMP FLOOD e
SMURF/FRAGGLE. Funcionalmente, o STACHELDRAHT combina basicamente
31
características das ferramentas Trin00 e TFN, mas adiciona alguns aspectos, tais como:
criptografia da comunicação entre o atacante e a máquina coordenadora e atualização
automática dos agentes.
A ferramenta TRIBLE FLOOD NETWORK 2000, mais conhecida como TFN2K, é
mais uma ferramenta de ataque DoS distribuída. O TFN2K é considerado uma versão
sofisticada do seu predecessor TFN. Ambas as ferramentas foram escritas pelo mesmo autor,
Mixter.
A seguir são mencionadas algumas características da ferramenta:
a) da mesma forma que ocorre no TFN, as vítimas podem ser atingidas por ataques
do tipo UDP FLOOD, TCP FLOOD, ICMP FLOOD e SMURF/FRAGGLE. O
programa pode ser instruído para alternar aleatoriamente entre estes quatro tipos
de ataque;
b) o controle remoto da máquina controladora é realizado através de comandos via
pacotes Transmission Control Protocol (TCP), User Datagram Protocol (UDP),
Internet Control Message Protocol (ICMP) ou os três de modo aleatório. Estes
pacotes são criptografados, e, deste modo, a filtragem de pacotes ou qualquer
outro mecanismo passivo, torna-se impraticável e ineficiente;
c) diferentemente do TFN, esta ferramenta é completamente "silenciosa", isto é, não
existe confirmação (ACK) da recepção dos comandos, a comunicação de controle
é unidirecional. Ao invés disso, o cliente envia 20 vezes cada comando confiando
em que, ao menos uma vez, o comando chegue com sucesso.
d) A máquina controladora pode utilizar um endereço IP forjado.
32
2.3 POLÍTICA DE SEGURANÇA
Segundo Zwicky (2001), a política de segurança é como a política externa de uma
nação. Ela pode ser discutida em documentos de graus variados de legibilidade, mas seu
propósito principal é estabelecer uma direção, uma teoria do que se está tentando alcançar.
Segundo Bernstein (1997), política de segurança com boas informações são o
fundamento para um programa de segurança de informação eficaz. Em termos gerais, as
políticas são diretivas de gerenciamento que estabelecem as metas comerciais da organização,
fornecem uma estrutura de implementação para alcançar os objetivos dessas metas e atribuem
responsabilidades e domínios ao processo. Mais especificamente, as políticas de segurança
são projetadas para gerenciar o risco em que a empresa incorre ao buscar esses objetivos
comerciais. O termo risco nesse contexto se refere às informações, representando um risco
tanto comercial quanto de segurança.
Os procedimentos incorporam os objetivos de segurança para sistemas ou aplicações
específicas e definem como os sistemas deverão ser operados sob determinadas circunstâncias
para que os objetivos sejam alcançados. Os procedimentos de resposta a incidentes, por
exemplo, especificam o que usuários, administradores de sistema e gerentes devem fazer se
alguém descobrir algum indício de algum incidente relacionado à segurança. Os
procedimentos de segurança das informações quase sempre derivam de políticas da empresa.
A política de que a contabilidade dos sistemas deve ser feita continuamente pode impor um
procedimento que exija que os administradores verifiquem diariamente se há espaço em disco
suficiente para o armazenamento de todos os dados contábeis.
Segundo Borelli (2003) e Comer (2001), não existe uma única política de segurança
para todas as redes e sistemas de informações. Entretanto, existem alguns assuntos comuns
33
que são de grande interesse para a maioria das organizações e empresas que administram as
informações. A seguir estão alguns itens que é preciso ter em mente quando da definições de
uma política de segurança:
a) autorização: o ato de implementar uma política de segurança implica que
alguém está no controle. É necessário planejar níveis de segurança e modificá-
los à medida que for necessário. Em alguns ambientes, pode não ser uma boa
idéia ter apenas um pessoa autorizada para definir e mudar as políticas de
segurança. O que aconteceria se o individuo não pudesse exercer sua função,
deixando de desenvolver os seus deveres? Ou, pior do que isso, se o indivíduo
morresse ou fosse o próprio elemento criminoso de quem a política de
segurança estaria se protegendo? A maioria das políticas de segurança envolve
diversos indivíduos com diferentes níveis de autorização, para que nenhuma
pessoa tenha as chaves do reino inteiro;
b) responsabilidade: a maioria das políticas de segurança inclui a capacidade de se
fazer uma auditoria nos eventos e nas atividades. Quando se faz uma auditoria,
há a necessidade de se ter um indivíduo ou um grupo de indivíduos
responsáveis pelas informações que estão sendo investigadas. Por exemplo, se
ocorre uma atividade suspeita, quem deve ser contatado, em qual espaço de
tempo, e assim por diante;
c) disponibilidade dos dados: os usuários precisam saber que terão acesso às
informações quando precisarem. Para as organizações que trabalham na relação
básica de 24 horas por dia, sete dias por semana, isso pode ser um assunto
especialmente desafiador;
34
d) integridade dos dados: os usuários precisam estar confiantes de que as
informações que solicitaram são as mesmas que estão armazenadas na rede. É
preciso haver alguns esquemas de medição para garantir que os dados não
foram modificados durante a transmissão entre sistemas que se comunicam. Os
bits de paridade, somas de verificação e Verificações de Redundância Cíclica
(CRC-Cyclic Redundancy Checks) são úteis para fornecer mecanismos para
que os dados cheguem ilesos, ou para avisar o sistema de que os pacotes foram
danificados. Entretanto, tais métodos não garantem que os dados que estão
chegando ao destinatário realmente foram enviados pelo transmissor
verdadeiro. Não se pode confiar nesses mecanismos para esse tipo de
integridade dos dados, pois um indivíduo não autorizado pode capturar a
transmissão, modificar o conteúdo e o bit de paridade, a soma de verificação
e/ou valores CRC e colocar os pacotes modificados de volta no meio de
transmissão. Para o receptor não suspeito, os dados parecem sem problemas,
pois o bit de paridade, a soma de verificação ou a CRC coincidem com o valor
calculado. Além disso, o uso do endereço de hardware e/ou endereço IP do
remetente para verificar sua identidade não é confiável. É muito fácil imitar
esses endereços, de forma que os pacotes enviados pelo hacker contenham os
endereços do remetente atual. Uma vez mais, o destinatário não estará ciente de
que alguma coisa está errada porque os endereços do remetente, os bits de
paridade, a soma de verificação e a CRC parecem estar corretos;
e) confiabilidade dos dados: os usuários que solicitam informações apenas para
eles próprios, ou para um grupo de usuários autorizados, devem estar
confiantes de que as informações são inacessíveis para os indivíduos não
autorizados;
35
f) privacidade: em alguns sistemas, é importante que a idéia do usuário
permaneça anônima. Em alguns ambientes, as informações pessoais devem ser
apropriadamente protegidas e tratadas com respeito, assim as informações
particulares de um indivíduo são mantidas em sigilo.
Segundo NBSO (2003a), uma política de segurança é um instrumento importante
para proteger uma organização contra ameaças à segurança da informação que a ela pertence
ou que está sob sua responsabilidade. Uma ameaça à segurança é compreendida neste
contexto como a quebra de uma ou mais de suas propriedades fundamentais
(confidencialidade, integridade e disponibilidade).
A política de segurança não define procedimentos específicos de manipulação e
proteção da informação, mas atribui direitos e responsabilidades às pessoas (usuários,
administradores de redes e sistemas, funcionários, gerentes, etc.) que lidam com essa
informação. Desta forma, elas sabem quais as expectativas que podem ter e quais são as suas
atribuições em relação à segurança dos recursos computacionais com os quais trabalham.
Além disso, a política de segurança também estipula as penalidades às quais estão sujeitos
aqueles que a descumprem.
Antes que a política de segurança seja escrita, é necessário definir a informação a ser
protegida. Usualmente, isso é feito através de uma análise de riscos que identifica:
a) recursos protegidos pela política;
b) ameaças às quais estes recursos estão sujeitos;
c) vulnerabilidades que podem viabilizar a concretização destas ameaças,
analisando-as individualmente.
36
Uma política de segurança deve cobrir os seguintes aspectos:
a) aspectos preliminares:
- abrangência e escopo de atuação da política;
- definições fundamentais;
- normas e regulamentos aos quais a política está subordinada;
- quem tem autoridade para sancionar, implementar e fiscalizar o cumprimento
da política;
- meios de distribuição da política;
- como e com que freqüência a política é revisada.
b) política de senhas:
- requisitos para formação de senhas;
- período de validade das senhas;
- normas para proteção de senhas;
- reuso de senhas;
- senhas padrão.
c) direitos e responsabilidades dos usuários:
- utilização de contas de acesso;
- utilização de softwares e informações, incluindo questões de instalação,
licenciamento e copyright;
- proteção e uso de informações (sensíveis ou não), como senhas, dados de
configuração de sistemas e dados confidenciais da organização;
- uso aceitável de recursos como email, notícias e páginas Web;
- direito à privacidade e condições nas quais esse direito pode ser violado pelo
provedor dos recursos (a organização);
37
- uso de antivírus.
d) direitos e responsabilidades do provedor dos recursos:
- backups;
- diretrizes para configuração e instalação de sistemas e equipamentos de rede;
- autoridade para conceder e revogar autorizações de acesso, conectar e
desconectar sistemas e equipamentos de rede, alocar e registrar endereços e
nomes de sistemas e equipamentos;
- monitoramento de sistemas e equipamentos de rede;
- normas de segurança física.
e) ações previstas em caso de violação da política:
- diretrizes para tratamento e resposta de incidentes de segurança;
- penalidades cabíveis.
Cada organização possui um ambiente distinto e os seus próprios requisitos de
segurança e deve, portanto, desenvolver uma política de segurança que se molde a essas
peculiaridades.
Alguns fatores importantes para o sucesso de uma política de segurança são:
a) apoio por parte da administração superior;
b) a política deve ser ampla, cobrindo todos os aspectos que envolvem a segurança
dos recursos computacionais e da informação sob responsabilidade da
organização;
c) a política deve ser periodicamente atualizada de forma a refletir as mudanças na
organização;
38
d) deve haver um indivíduo ou grupo responsável por verificar se a política está
sendo respeitada;
e) todos os usuários da organização devem tomar conhecimento da política e
manifestar a sua concordância em submeter-se a ela antes de obter acesso aos
recursos computacionais;
f) a política deve estar disponível em um local de fácil acesso aos usuários, tal
como a intranet da organização.
Dentre os itens acima, o apoio por parte da administração superior é essencial. Se a
política de segurança não for encampada pela administração, ela rapidamente será deixada de
lado pelos demais setores da organização. Além disso, é importante que os seus membros
dêem o exemplo no que diz respeito à observância da política de segurança.
Os seguintes fatores influem negativamente na aceitação de uma política de
segurança e podem levá-la ao fracasso:
a) a política não deve ser demasiadamente detalhada ou restritiva;
b) o excesso de detalhes na política pode causar confusão ou dificuldades na sua
implementação;
c) não devem ser abertas exceções para indivíduos ou grupos;
d) a política não deve estar atrelada a softwares e/ou hardwares específicos.
39
3 FIREWALL
Um firewall é basicamente, um dispositivo que impede que forasteiros acessem uma
rede. Esse dispositivo é em geral um roteador, um computador que executa um filtro de
pacotes independente (standalone), um software proxy ou um firewall-in-a-box (um
dispositivo proprietário de hardware que desempenha as funções de filtro e proxy)
(Anônimo, 2000).
À medida que as solicitações de conexão são recebidas, o firewall as avalia. Somente
as solicitações de conexão de hosts autorizados são passadas; as demais solicitações de
conexão são descartadas.
Mas isso é muito restrito para uma definição. Hoje os firewalls realizam todos os
tipos de tarefas, incluindo:
a) filtragem e análise de pacotes – os firewalls podem analisar os pacotes recém
chegados de múltiplos protocolos. Baseado nessa análise, os firewalls podem
realizar avaliações condicionais (“se esse tipo de pacote for encontrado faça
isto”);
b) bloqueio de protocolo ou conteúdo – os firewalls permitem a verificação do
conteúdo. Pode se explorar essa capacidade para bloquear Java, JavaScript,
VBScript, ActiveX e cookies no firewall, e até criar regras para bloquear
assinaturas de ataques particulares;
c) autenticação e criptografia de usuário, conexão e sessão – muitos firewalls
utilizam vários algoritmos e esquemas para verificar a identidade dos usuários,
verificar a integridade da sessão e proteger os dados em trânsito contra sniffing
(farejar pacotes).
40
Segundo Albuquerque (2001), a configuração de um firewall deve ser criteriosa. Se
houver um erro que facilite a invasão do firewall, as outras máquinas na rede passam a correr
perigo. A configuração de um firewall não é simples, por isso é aconselhável dividí-la em
etapas. É importante garantir que cada etapa de configuração esteja absolutamente correta.
Além disso é importante garantir a manutenção da configuração do firewall e a análise
periódica dos arquivos com registros gerados pelo firewall.
Os firewalls normalmente adotam a seguinte política: o que não é explicitamente
permitido, é proibido. Antes de configurar um firewall, é necessário, portanto, definir o que é
permitido e o que é proibido. Os serviços são liberados caso a caso, após uma análise em que
são considerados os riscos e os benefícios associados a cada serviço.
Apenas instalar um firewall não garante, entretanto a segurança das máquinas na
rede. É importante lembrar que o firewall apenas controla o tráfego entre redes. O firewall não
evita invasões que partam de máquinas na rede em que se encontra a máquina invadida.
Estatísticas mostram que os responsáveis por invasões são muitas vezes funcionários da
empresa em que se encontra a máquina invadida. Isso demonstra a importância de uma
política global de segurança, em que o firewall é apenas um componente na sua
implementação.
Segundo Bernstein (1997), o firewall representa uma eficiente estratégia para
implementar a política de acesso à internet em uma organização. Os firewalls podem oferecer
proteção contra ataques a protocolos ou aplicações individuais, proteção contra ataques de
spoofing e têm relativa flexibilidade de configuração, ou seja, oferecem várias restrições para
diferentes tipos de tráfego. Os firewalls implementam controles de acesso baseados nos
conteúdos dos pacotes de uma conexão. A melhor maneira de entender como age um firewall
41
é imaginá-lo como sendo um guarda, ou sentinela, da rede, que inspeciona a documentação
para os pacotes que chegam e depois decide se dará passagem ou não.
Uma das maiores vantagens do firewall é que ele oferece um único ponto de controle
para a segurança em uma rede. Muitas pessoas preferem conceber o firewall como um ponto
regulador, pelo qual todo tráfego deve passar antes de entrar na rede da corporação ou sair
dela. Portanto, os firewalls tendem a ser os principais alvos para ataques externos, e por isso é
essencial garantir a segurança da máquina de firewall.
Os firewalls também oferecem um único ponto de administração de segurança. Em
vez de dispor restrições de segurança da rede em hosts individuais, os administradores de
segurança podem concentrar seus esforços em uma área. Os firewalls também são um ótimo
ponto para auditoria e monitoração.
Segundo Borelli (2003), as tecnologias de criptografia ajudam a garantir
transmissões seguras de informações privadas sobre uma rede pública. Mas isso não fornece
nenhuma maneira de evitar que tráfego indesejável atinja uma rede. Em teoria, o tráfego que
viaja da internet para a rede privada de uma empresa deveria ser apenas o tráfego da rede
privada, e não todo o tráfego que está na internet. Além disso, um hacker poderia encontrar o
número IP do endereço de um sistema na rede privada da empresa e enviar uma seqüência
constante de pacotes para o sistema. Dependendo do conteúdo e da natureza dos pacotes
indesejáveis, o resultado poderia inutilizar o sistema e fazê-lo parar de funcionar. Se o
endereço que o indivíduo não autorizado descobrir é o de um servidor, causar uma parada
total em um servidor pode implicar em outros problemas dentro da empresa. Para tornar o
problema ainda maior, se o hacker for capaz de enviar código executável ou comandos para o
servidor, ou fazer que este execute alguns processos, os resultados podem ser desastrosos.
Assim, além de fazer com que as informações nos pacotes de dados sejam confiáveis, é
42
preciso proteger o sistema contra qualquer tráfego inútil e potencialmente danoso ao seu
funcionamento. Para impedir tráfego indesejável, os firewalls precisam ser instalados e
configurados.
O conceito de um firewall de rede e de sistema é deixar apenas o tráfego permitido
entrar no sistema vindo de fora da rede. O termo firewall, como usado na terminologia das
redes, lembra o firewall físico (parede contra incêndios) usado nos edifícios. A idéia de
instalar uma parede contra incêndios durante a construção de um prédio é evitar que um
incêndio vindo da fonte do fogo se propague para além da parede corta fogo. Em complexos
de apartamentos, por exemplo, se cada unidade for separada por uma dessas paredes, um
incêndio em um apartamento não conseguiria se espalhar tão facilmente. Observa-se que, para
as paredes contra incêndio serem eficazes, é necessário construir uma em cada fronteira com o
mundo externo. O mesmo se aplica às redes. Onde quer que haja uma rede que tenha uma
interface para uma rede pública, é necessário haver um firewall pronto e configurado de
acordo com a política de segurança da organização. Se uma fronteira for deixada sem
proteção, a rede inteira estará desprotegida.
Para ser efetivo, um firewall de rede deve satisfazer certos padrões mínimos e
fornecer esquemas básicos de prevenção. A idéia de ter firewalls é criar um cinto de
segurança em torno da rede para impedir o acesso não autorizado e a interferência com as
atividades da rede privada. Uma das primeiras tarefas importantes de um firewall é que ele
próprio deve ser confiável. Se o firewall puder ser comprometido, então é como se não
houvesse firewall instalado. Existem vários produtos de firewall no mercado, e, em geral, suas
maiores diferenças funcionais (e em preço) incluem: as camadas OSI que são protegidas, a
granularidade da prevenção e da permissão de acesso, e qualquer ponto fraco conhecido,
como o grau de facilidade com que se consegue desviar do firewall. A maioria dos peritos em
segurança concorda que uma maneira de proteger os firewalls é usar sistemas dedicados a
43
eles. Em outras palavras, não execute o software do firewall no mesmo sistema do servidor
da Web da empresa, no servidor da base de dados, ou em qualquer outro aplicativo ou serviço.
Uma das razões para esse tipo de abordagem diz respeito aos números das portas IP.
Todo serviço que está sendo executado em um ambiente baseado em IP tem, pelo
menos, um número de porta atribuído ao serviço, assim outro serviço não usa o mesmo
número de porta. Por exemplo, os servidores da Web usam a porta 80 para as conexões
HiperText Transfer Protocol (HTTP) não protegidas, e a porta 443 para as conexões
protegidas com os navegadores. Se um fabricante decidir escrever seu software de jogos para
a porta 80, quando alguém for usar o navegador para acessar uma site da Web, pode acabar
acessando o sistema de jogos, e não site pretendido. Para controlar quais serviços usam quais
portas, as portas usadas pelos aplicativos podem ser registradas com a Autoridade de
Atribuição de Números de Internet (IANA-Internet Assigned Numbers Authority). Mesmo
assim, nem todos os números possíveis de portas podem ser registrados. Os números de portas
são divididos em três grupos:
a) Portas Bem Conhecidas: são números de portas atribuídos pela IANA, e, na
maioria dos sistemas, podem ser usados apenas por processos ou serviços que
operam em um nível privilegiado no sistema operacional. A variação dos
números das portas bem conhecidas é de 0 a 1023. Alguns exemplos comuns de
portas bem conhecidas são mostradas na Tabela 2;
b) Portas Registradas: são registradas com a IANA e podem ser usadas pela maioria
de aplicativos e usuários. A variação das portas registradas é de 1024 a 4951;
c) Portas Dinâmicas e/ou Privadas: podem ser usadas por qualquer aplicativo e
qualquer pessoa. Seus principais usuários são os clientes que estão acessando um
44
serviço, pois o número da porta usado no lado cliente não é relevante quando não
executado um serviço.
Tabela 2 - Exemplos comuns de portas bem conhecidas
Fonte: Borelli (2003)
O conhecimento sobre os números de portas e os serviços que usam uma
determinada porta é muito importante quando se trata de firewalls. Pode-se configurar o
firewall para ter portas abertas para os serviços usados na rede privada que permitem
conexões vindas de fora. Por exemplo, se o único serviço acessível para os usuários da
internet é o site da empresa, apenas a porta 80 precisa estar aberta no firewall. Se o servidor
da Web também suporta conexões HTTP protegidos, a porta 443 também precisaria estar
aberta. Caso contrário, a porta 443 não precisa estar aberta. Onde ocorrem as maiores
incidências de ameaças e acessos não autorizados são nas portas abertas não utilizadas.
Alguns fabricantes de software deixam muitas portas abertas, supondo que o sistema esteja
executando serviços relacionados.
Portas abertas não utilizadas no sistema podem ser desastrosas para rede: o
administrador pode se perguntar se o servidor FTP não está funcionado na rede, que mal
Número de Portas Objetivos20 Controle FTP21 Dados FTP23 Telnet25 SMTP69 TFTP80 HTTP110 POP3119 NNTP123 NTP137 Serviço de nome NETBIOS161 SNMP162 SNMPTRAP443 HTTPS
45
haveria em deixar as portas de FTP abertas, já que não há como responder às solicitações de
FTP? Mas um indivíduo inescrupuloso pode usar uma porta aberta não utilizada para enviar
toda espécie de material que não tem relação alguma com FTP. Pode-se enxergar um firewall
que tem portas abertas não utilizadas como uma casa que está com todas as portas e janelas
trancadas, exceto uma pequena janela de ventilação perto do telhado. Pode dar um pouco de
trabalho para chegar até a janela destrancada e entrar por ela, mas, se ela existe, alguém vai
tentar.
É fundamental que os administradores vigiem as portas abertas nos firewall e
mantenham abertas apenas aquelas estritamente necessárias. Indivíduos não autorizados farão
varreduras de portas em tudo quanto é tipo de sistemas na tentativa de encontrar portas
abertas. É bom lembrar que é relativamente fácil detectar certos tipos de varreduras de portas
que estão em andamento. Alguns produtos de software de firewall incluem o recurso de
reconhecer alguns tipos de varreduras de portas.
Além de se certificar de que o firewall, em si, é confiável, existem outros critérios
que devem ser satisfeitos:
a) todo o tráfego vindo da internet, ou de alguma outra rede que não é mantida pela
organização, deve passar pelos firewalls. Além dos indivíduos que tentam obter
acesso não autorizado às informações na rede privada da empresa, vírus, worms,
cavalos de tróia e outras coisas também podem entrar em uma rede;
b) todo o tráfego indo da rede para alguma outra rede ou para a internet deve passar
pelos firewalls. Essa característica é importante para que a organização possa
determinar quais as localizações e os serviços na internet que são apropriados e
necessários para conduzir os negócios;
46
c) qualquer tráfego não autorizado vindo da rede privada, ou dela saindo, deve ser
rejeitado pelo firewall. A maioria dos firewalls apresentam algum nível de
controle ou auditoria do tráfego não autorizado, assim os administradores podem
determinar as fontes das tentativas e outras informações relacionadas. Se o
firewall realiza as funções de controle e auditoria, deve-se assegurar de verificar
se as portas especificas escolhidas para serem monitoradas estão incluídas. Por
exemplo, um truque comum para entrar em um firewall é usar a porta 53 como
endereço de fonte. A porta 53 é usada pelo DNS, e alguns firewalls permitem sua
passagem direta porque a porta da fonte aparece como se fosse o resultado de um
questionamento de DNS iniciando de uma rede privada. A porta 161, usada pelo
Protocolo Simples de Gerenciamento de Rede (SNMP- Simple Network
Management Protocol), é uma porta comum que o indivíduo não-autorizado
verifica para ver se está aberta. Se estiver aberta, uma quantidade grande de
informações sobre o sistema e o ambiente pode ser recuperada da base de dados
do SNMP. Ademais, alguns softwares de administração de computadores
pessoais utilizam o SNMP (por exemplo, o software de gerenciamento remoto
JetDirect da HP usa o SNMP).
Uma observação final sobre firewalls e modems de cabo, DSL, ou qualquer outro
item sempre presente no acesso residencial à internet: sempre deve-se utilizar um firewall no
dispositivo que o conecta à internet e/ou execute um firewall em todos os PCs, Macs, Linux
/Unix, ou outras que dão acesso à internet. Quem já estiver executando um firewall
personalizado, provavelmente já está ciente do tipo de atividade não autorizada que pode
surgir contra os seus sistemas. Se, por outro lado, não houver um firewall personalizado
funcionando, é necessário instalar um o mais cedo possível, antes que mais informações sobre
o sistema sejam descobertas, ou que algum acesso não autorizado ao sistema tenha sucesso.
47
Segundo Péricas (2003), a configuração mais completa de um firewall tem dois
componentes: dois routers que filtram pacotes e um gateway de aplicação.
Cada filtro de pacotes é um router padrão equipado com algumas funções
complementares que permitem a inspeção de cada pacote de entrada ou de saída. Em geral, os
filtros de pacotes são baseados em tabelas configuradas pelo administrador do sistema. Essas
tabelas listam as origens e os destinos aceitáveis, as origens ou os destinos bloqueados e as
regras-padrão que orientam o que deve ser feito com os pacotes recebidos de outros
equipamentos ou destinados a elas.
O gateway de aplicação, ao invés de apenas examinar o endereçamento dos pacotes,
opera na camada de aplicação. O gateway toma a decisão de transmitir ou descartar cada
mensagem baseada em regras sobre informações contidas no protocolo da camada de
aplicação, tais como os campos de cabeçalho, tamanho da mensagem ou até mesmo o seu
conteúdo.
3.1 FILTRAGEM DE PACOTES
Segundo Borelli (2003), um dos principais mecanismos de um firewall é a filtragem
de pacotes. Os pacotes que não tem permissão para entrar na rede privada da internet são
rejeitados no firewall e retirados do fluxo de pacotes. Similarmente, os pacotes que não tem
permissão para sair da rede privada são bloqueados no firewall, e o tráfego que atinge a
internet é filtrado ao passar pelo firewall. O principal processo através do qual a filtragem de
pacotes funciona é que o firewall examina as informações no cabeçalho dos pacotes. Os
firewalls podem examinar os endereços IP de fonte e destino, e, caso os números ou as redes
estiverem nas listas permitidas, os pacotes podem passar pelo firewall. A filtragem de pacotes
de endereços IP opera na camada de rede, ou camada 3, do modelo de referência OSI. Esse
48
tipo de filtragem, por si só, não caracteriza um firewall. Outro tipo de filtragem que o firewall
pode realizar é a filtragem de protocolos da camada de aplicação.
Segundo Russell (2001), um filtro de pacotes é um sofware que analisa o cabeçalho
(header) dos pacotes enquanto eles passam e decide o destino do pacote como um todo. Ele
pode decidir entre descartar (DROP) o pacote (descartando-o como se nunca o tivesse
recebido), aceitar (ACCEPT) o pacote (deixar o pacote seguir seu caminho), além de outras
opções mais avançadas.
No Linux, filtragem de pacotes está implementada diretamente no KERNEL (como
um módulo ou diretamente compilado) e há várias coisas interessantes que podem ser feitas
com os pacotes, mas o princípio geral é analisar o cabeçalho dos pacotes e decidir o que fazer
com o pacote.
Segundo Bernstein (1997), talvez a maneira mais fácil (e de custo mais baixo) de
implementar um firewall seja no roteador que conecta a rede privada à internet. Como de
qualquer forma é preciso ter um roteador na conexão, faz sentido usar a capacidade de
filtragem de pacote para implementar sua segurança.
O princípio básico por trás dos filtros de pacotes é simples. Com base na tecnologia
“store-and-forward” (armazenamento e encaminhamento) dos roteadores, um roteador ou
host receberá um pacote em uma interface, comparará as informações em seu cabeçalho com
um conjunto de filtros e então decidirá se deixa o pacote passar ou se o “rejeita” (enviando
uma mensagem ICMP de volta ao ponto de origem indicando que o pacote foi abandonado).
Apesar de os parâmetros específicos nos quais um filtro de pacotes baseia suas decisões
variarem de um produto para outro, a maioria dos filtros de pacote leva em consideração os
seguintes critérios:
49
a) a direção do tráfego (da interface para a rede interna ou da rede para interface);
b) a interface na qual o tráfego foi recebido ou para a qual ela se destina;
c) o tipo de protocolo (por exemplo, IP, ICMP, TCP, UDP, IPX);
d) os endereços IP de origem e destino;
e) a porta TCP ou UDP de origem e de destino;
f) a informação sobre o “estado” do TCP.
Ainda Segundo Russell (2001), a importância de filtrar pacotes se resume no
seguinte:
a) controle: quando uma máquina é utilizada para conectar uma rede interna a
outra rede (a internet, por exemplo) há a oportunidade de permitir certo tipo de
tráfego, e rejeitar outro. Por exemplo, o cabeçalho do pacote contém o
endereço de destino do pacote, logo pode-se evitar que os pacotes saiam em
direção a um endereço;
b) segurança: quando uma máquina é a única coisa entre a internet e a rede
interna, é bom saber que é possível restringir o tráfego vindo do mundo
externo. Por exemplo, pode-se permitir que qualquer tipo de pacote saia da rede
interna, mas pode-se bloquear o famoso ataque “Ping of Death” (Ping da
Morte) vindo de malfeitores do mundo externo. Como outro exemplo, permitir
que qualquer um da rede externa conecte-se via TELNET no seu servidor pode
ser desastroso, mesmo que todas as contas da máquina tenham senhas. Talvez o
objetivo é (como a maioria das pessoas) ser apenas um observador, e não um
50
servidor. Simplesmente não se deixa ninguém conectar, dizendo ao filtro de
pacotes para rejeitar pacotes requisitando a criação de novas conexões;
c) vigilância: às vezes uma máquina mal configurada na rede local pode decidir
enviar pacotes descontroladamente para o mundo externo. É interessante dizer
ao filtro de pacotes para informar se algo anormal ocorrer, talvez seja possível
fazer algo para resolver o problema.
3.2 IPTABLES
Segundo Russell (2001), os KERNELS Linux possuem filtros de pacotes desde a
série 1.1. A primeira geração, baseada no IPFW do BSD, foi portada por Alan Cox no final de
1994. Essa implementação foi melhorada por Jos Vos e outros para o Linux 2.0; a ferramenta
userspace IPFWADM controlava as regras de filtragem do KERNEL. Em meados de 1998,
para o Linux 2.2, introduziu-se a ferramenta userspace “IPCHAINS”. Finalmente, a
ferramenta da quarta geração, o IpTables, e mais um árduo trabalho de reedição do KERNEL
ocorreu em meados de 1999 para o Linux 2.4.
É necessário um KERNEL que possua a infra-estrutura Netfilter implementada:
Netfilter é um framework dentro do KERNEL Linux com o qual outros módulos ou
programas (como o módulo do IpTables) podem conectar-se. Isso significa que se precisa do
KERNEL 2.3.15 ou posteriores, e responder `Y (SIM)' para CONFIG_NETFILTER na sua
configuração do KERNEL.
A ferramenta IpTables conversa com o KERNEL e fala quais são os pacotes a serem
filtrados e insere e apaga regras da tabela de filtragem de pacotes do KERNEL. A ferramenta
IpTables é uma substituição para IPFWADM e IPCHAINS.
51
Segundo Silva (2004), no KERNEL do Linux 2.4, foi introduzido o firewall IpTables
(também chamado de Netfilter) que substitui o IPCHAINS dos KERNELs da série 2.2. Este
novo firewall tem como vantagem ser estável (assim como o IPCHAINS e IPFWADM),
confiável, permitir flexibilidade na programação de regras pelo administrador do sistema,
mais opções disponíveis ao administrador para controle de tráfego, controle independente do
tráfego da rede local, entre redes e interfaces devido a nova organização das etapas de
roteamento de pacotes.
O IpTables é um firewall em nível de pacotes e funciona baseado no endereço/porta
de origem/destino do pacote, prioridade, etc. Ele funciona através da comparação de regras
para saber se um pacote tem ou não permissão para passar. Em firewalls mais restritivos, o
pacote é bloqueado e registrado para que o administrador do sistema tenha conhecimento
sobre o que está acontecendo em seu sistema.
Ele também pode ser usado para modificar e monitorar o tráfego da rede, fazer
Network Address Translation (NAT): masquerading, NAT de origem, NAT de destino,
redirecionamento de pacotes, marcação de pacotes, modificar a prioridade de pacotes que
chegam/saem do sistema, contar bytes, dividir tráfego entre máquinas, criar proteções contra
SPOOFING, SYN FLOOD, DoS, etc. O tráfego vindo de máquinas desconhecidas da rede
pode também ser bloqueado/registrado através do uso de regras simples. As possibilidades
oferecidas pelos recursos de filtragem IpTables como todas as ferramentas UNIX maduras
dependem da imaginação do administrador, pois ele garante uma grande flexibilidade na
manipulação das regras de acesso ao sistema, precisando apenas conhecer quais interfaces o
sistema possui, o que deseja bloquear, o que tem acesso garantido, quais serviços devem estar
acessíveis para cada rede, e iniciar a construção do firewall.
52
O IpTables ainda tem a vantagem de ser modularizável, funções podem ser
adicionadas ao firewall ampliando as possibilidades oferecidas. O IpTables é um firewall que
tem possibilidades de gerenciar tanto a segurança em máquinas isoladas como roteamento em
grandes organizações, onde a passagem de tráfego entre redes deve ser minuciosamente
controlada.
Um firewall IpTables não funciona de forma automática (instalar e esperar que ele
faça as coisas sem nenhuma interação do administrador), é necessário pelo menos
conhecimentos básicos de rede TCP/IP, roteamento e endereços de portas para criar as regras
que farão a segurança do sistema. A segurança do sistema depende do controle das regras que
serão criadas pelo administrador, portanto as falhas humanas são garantia de mais de 95% de
sucesso nas invasões.
Enfim, o IpTables é um firewall que é funcional tanto para pessoas que desejam uma
segurança básica em seu sistema, quanto administradores de grandes redes que querem ter um
controle minucioso sobre o tráfego que passa entre suas interfaces de rede (controlando tudo o
que pode passar de uma rede a outra), controlar o uso de tráfego, monitorar a rede, etc.
Segundo Jang (2003), Laureano (2002) e Silva (2004), as regras do firewall são
como comandos passados ao IpTables para que ele realize uma determinada ação (como
bloquear ou deixar passar um pacote) de acordo com o endereço/porta de origem/destino,
interface de origem/destino, etc. As regras são armazenadas dentro dos chains e processadas
na ordem que são inseridas. As regras são armazenadas no kernel, o que significa que quando
o computador for reiniciado tudo o que fez será perdido. Por este motivo elas deverão ser
gravadas em um arquivo para serem carregadas a cada inicialização.
A sintaxe básica do IpTables é definida por: “Iptables [–t <tabela>] <comando>”.
Onde <comando> pode ser composto por <chain>, <regras>, <extensões> e <ação>.
53
As tabelas são os locais usados para armazenar os chains e conjunto de regras com
uma determinada característica em comum. As tabelas podem ser referenciadas com a opção
“-t tabela” e existem 3 tabelas disponíveis no IpTables:
a) filter - esta é a tabela padrão, contém 3 chains padrões: INPUT, consultado para
dados que chegam a máquina, OUTPUT, consultado para dados que saem da
máquina, FORWARD, consultado para dados que são redirecionados para outra
interface de rede ou outra máquina;
b) nat - usada para dados que gera outra conexão (masquerading, source nat,
destination nat, port forwarding, transparent proxy são alguns exemplos). Possui
3 chains padrões: PREROUTING, consultado quando os pacotes precisam ser
modificados logo que chegam; OUTPUT, consultado quando os pacotes gerados
localmente precisam ser modificados antes de serem roteados; POSTROUTING,
consultado quando os pacotes precisam ser modificados após o tratamento de
roteamento;
c) mangle - Utilizada para alterações especiais de pacotes (como modificar o tipo
de serviço (TOS)). Possui 5 chains padrões: INPUT, consultado quando os
pacotes precisam ser modificados antes de serem enviados para o chain INPUT
da tabela filter; FORWARD, consultado quando os pacotes precisam ser
modificados antes de serem enviados para o chain FORWARD da tabela filter;
PREROUTING, consultado quando os pacotes precisam ser modificados antes
de ser enviados para o chain PREROUTING da tabela nat; POSTROUTING,
consultado quando os pacotes precisam ser modificados antes de serem enviados
para o chain POSTROUTING da tabela nat; OUTPUT, consultado quando os
54
pacotes precisam ser modificados antes de serem enviados para o chain
OUTPUT da tabela nat.
Os chains são locais onde as regras do firewall definidas pelo usuário são
armazenadas para operação do firewall. Existem dois tipos de chains: os embutidos (como os
chains INPUT, OUTPUT e FORWARD) e os criados pelo usuário. Os nomes dos chains
embutidos devem ser especificados sempre em maiúsculas.
Os comandos dos chains são definidos por:
a) -A <chain> <regra> [<extensão>] -j <ação>: anexa uma regra ao final de uma
cadeia;
b) -D <chain> número ou <regra>[<extensão>]: apaga o número de regra de uma
chain especificada ou exatamente a regra especificada;
c) -F <chain>: flui ou apaga todas as regras de uma cadeia especificada;
d) -I <chain> número <regra> : insere uma regra como o número de regra
especificado, na cadeia anotada;
e) -L <chain> : lista as regras atuais na cadeia especificada;
f) -N <chain> : insere uma nova cadeia não padrão;
g) -X <chain>: apaga uma cadeia definida por usuário;
h) -C <chain>: verifica o datagrama descrito pela regra especificada contra a cadeia
especificada. Este comando retorna uma mensagem descrevendo como a cadeia
processou o datagrama. Isto é muito útil para testar a configuracão do firewall, e
para uma análise posterior;
55
i) -Z <chain>: restaura os contadores de datagramas e de bytes em todas as regras
das cadeias especificadas para zero, ou para todas as cadeias se nenhuma for
especificada;
j) -P <chain> política : define a política padrão para uma cadeia dentro de uma
política especificada. As políticas válidas são: ACCEPT, DROP, QUEUE e
RETURN.
As seguintes regras podem ser usadas:
a) -p[!] protocol : define o protocolo ao qual a regra se aplica. O parâmetro protocol
pode ser qualquer valor numérico do arquivo /etc/protocol ou uma das palavras
chave: TCP, UDP, ICMP;
b) -s [!] address[/mask] : define a origem do pacote ao qual a regra se aplica. O
parâmetro address pode ser um nome de host, um nome de rede ou um endereço
IP com uma máscara de rede opcional;
c) -d [!] address[/mask] : define o destino do pacote ao qual a regra se aplica. O
endereço e a porta são definidos usando-se as mesmas regras utilizadas para
definir esses valores para a origem do pacote;
d) -i [!] interface_name : define o nome da interface por onde o datagrama foi
recebido. Um nome de interface parcial pode ser usado encerrando-o com um
sinal de “+” (por exemplo, eth+ corresponderia a todas as interfaces Ethernet
iniciadas com eth);
e) -o [!] interface_name : define o nome da interface por onde o datagrama será
transmitido;
56
f) [!] -f : Indica que a regra somente se refere ao segundo fragmento e aos
subseqüentes de pacotes fragmentados.
Observação: o símbolo “!” é usado na regras como uma negação da expressão.
A ação a ser tomada sempre é especificada usando-se o parâmetro “-j <ação>”, que
define um alvo para o pacote. Os alvos possíveis são ACCEPT, DROP, QUEUE ou
RETURN. É possível especificar uma chain do usuário. Também é possível especificar uma
extensão.
O firewall IpTables é extensível através de uma biblioteca de módulo compartilhados
opcional. Para fazer uso das extensões é preciso especificar o seu nome usando o parâmetro
“–m <argumento>” para que o IpTables carregue este módulo.
Em alguns casos é usado o parâmetro “–p” para determinar o protocolo (em certos
casos não é necessário o parâmetro “–m” pois ele é carregado automaticamente, por exemplo
quando se usa TCP, UDP ou ICMP):
a) extensão TCP: usada com –m tcp –p tcp :
--sport [!] [port[:port]] : especifica a porta que a origem do datagrama usa.
Portas podem ser especificadas com um conjunto especificando-se o seu limite
superior e inferior separados por dois pontos (:). Por exemplo, 20:25 descreve
todas as portas numeradas de 20 até 25 inclusive. Também é possível usar o
caracter “!” para inverter a expressão;
--dport [!] [port[:port]] : especifica a porta que o destino do datagrama usa;
--tcp-flags [!] mask comp : especifica que esta regra somente será validada
quando os flags do datagrama TCP coincidirem com o especificado em mask e
comp. Mask é uma lista separada por vírgulas dos flags que devem ser
57
examinados quando for feito o teste. Comp é uma lista separada por vírgulas dos
flags que devem ser configurados. Os flags válidos são: SYN, ACK, FIN, RST,
URG, PSH, ALL ou NONE;
--syn : especifica que a regra deve encontrar somente datagramas com o bit SYN
ligado e os bits ACK e FIN desligados. Datagramas com essas opções são usados
para requisitar início de conexão TCP.
b) extensão UDP: usada com –m udp –p udp :
--sport[!][port[:port]] : este parâmetro tem funcionamento idêntico ao da
extensão TCP;
--dport[!][port[:port]] : este parâmetro tem funcionamento idêntico ao da
extensão TCP.
c) extensão ICMP: usada com –m icmp –p icmp:
--icmp-type [!] typername : especifica o tipo de mensagem ICMP que a regra
deve satisfazer. O tipo pode ser determinado por um número ou nome. Alguns
nomes válidos são: echo-request, echo-reply, source-quench, time-exceeded,
destionation-unreachable, network-unreachable, host-unreanchable, protocol-
unreachable e port-unreachable.
d) extensão MAC: usada com –m mac :
--mac-source [!] address : especifica o endereço Ethernet do host que transmitiu
o datagrama que esta regra deve encontrar.
Demais informações sobre sintaxe do IpTables podem ser obtidas em Jang (2003),
Laureano (2002) e Silva (2004).
58
3.3 LOG
Registro em Log é qualquer procedimento pelo qual um sistema operacional ou
aplicativo registra eventos à medida que eles acontecem e preserva esses registros para
posterior análise. Em casos de invasão, o propósito do Log é preservar um registro contra as
ações nocivas do invasor. Os registros de Log fornecem a única evidência real de que um
crime ocorreu.
O registro em Log no Linux é onipresente e ocorre nos níveis de sistema, de
aplicativo e mesmo de protocolo. E, embora hajam excessões (softwares de outros fabricantes
por exemplo), a maioria dos serviços Linux envia as informações de Log para arquivos de
saída-padrão ou mesmo para arquivos de Log compartilhados (Anônimo, 2000).
Segundo Zwicky (2001), conhecer o instante em que algo ocorreu pode ser muito útil
ao se lidar com invasões. Serão necessárias informações de data e hora se o administrador (ou
algum órgão jurídico) precisar pedir informações de outros sites.
Escolher as informações que são necessárias no arquivo de Log é um assunto
delicado. Arquivos de Log gigantescos, cheios de eventos de rotina só desperdiçam espaço e
tempo, além de tornar mais difícil encontrar informações importantes. O ideal seria registrar
tudo no Log, exceto eventos freqüentes e inofensivos. Limitar o registro do Log a eventos
perigosos ou interessantes é um erro pois é difícil prever com sucesso quais serão eles. Uma
solução é registrar tudo o que puder, eliminando apenas a desordem conhecida.
O ideal mesmo é saber absolutamente tudo o que passa no firewall – todo pacote
descartado ou aceito e toda conexão solicitada, o que acarretaria uma grande quantidade de
informações difíceis de se lidar. Portanto deve-se utilizar um meio-termo prático, ativando o
59
registro de Log mais completo que não reduza demais a velocidade das máquinas e que não
preencha os discos muito rápido.
Segundo Bartz (2001), bibliografia também referenciada no site oficial do
Netfilter/IpTables, uma descrição do formatos dos campos do Log do Netfilter/IpTables é
encontrada na Tabela 3:
Tabela 3 - Descrição do formato dos campos de Log do Netfilter/IpTables Exemplo de uma linha de log gerada pelo Firewall IpTables: Apr 16 00:30:45 Linux kernel: NF: D(I,Priv) IN=eth1 OUT= MAC=00:80:8c:1e:12:60:00:10:76:00:2f:c2:08:00 SRC=211.251.142.65 DST=203.164.4.223 LEN=60 TOS=0x00 PREC=0x00 TTL=44 ID=31526 CE DF MF FRAG=179 OPT (072728CBA404DFCBA40253CBA4032ECBA403A2CBA4033ECBA40 2C1180746EA18074C52892734A200) PROTO=TCP SPT=4515 DPT=111 SEQ=1168094040 ACK=0 WINDOW=32120 RES=0x03 URG ACK PSH RST SYN FIN URGP=0 OPT (020405B40402080A05E3F3C40000000001030300) Apr 16 00:30:45 Linux kernel:
Prefixo do SYSLOG
NF: D(I,Priv)
Habilitado através opção --log-prefix 'prefix' prefixo definido pelo usuário, incluindo os espaços necessários para separação do próximo campo
IN=eth1 Interface de onde os pacotes foram recebidos
Out= Interface para onde os pacotes foram enviados MAC= 00:80:8c:1e:12:60: 00:10:76:00:2f:c2: 08:00
Destino MAC=00:80:8c:1e:12:60, Origem MAC=00:10:76:00:2f:c2 Type=08:00(ethernet frame carrier an IPv4 datagram)
SRC=211.251.142.65 Endereço IP origem
DST=203.164.4.223 Endereço IP destino
LEN=60 Comprimento total do pacote IP em bytes
TOS=0X00 Type Of Service, campo "Type"
PREC=0X00 Type Of Service, campo "Precedence"
TTL=44 Tempo de vida remanescente é 44 saltos
ID=31526
ID exclusivo para este datagrama IP, compartilhado com todos os fragmentos, se fragmentados
CE .
Presume-se o atributo "ECN CE" Isto parece ser errado de acordo com a RFC2481, O bit CE está localizado no campo TOS
DF Atributo "não fragmentado"
MF Atributo "mais fragmentos seguidos"
60
FRAG=179
Seqüência do fragmento em unidade de "8-bytes". Neste caso o byte de seqüência neste pacote é 179*8=1432 bytes
OPT (0727--A200)
Habilitado com: --log-ip-options Opções IP. Este campo de tamanho variável raramente é usado.
PROTO=TCP
Nome ou número do protocolo.O Netfilter usa nomes para TCP, UDP, ICMP, AH e ESP. Outros protocolos serão identificados pelo número
SPT=4515 Porta de origem (TCP e UDP)
DPT=111 Porta de destino (TCP e UDP)
SEQ=1168094040
Habilitado com: --log-tcp-sequence número de seqüência de recepção, escolhendo inteligentemente este número, um “cookie” criptográfico pode ser implementado enquanto ainda satisfazer os requerimentos do protocolo TCP/IP. Estes “SYN-COOKIES” derrotam alguns tipos de SYN FLOOD, ataques DoS, e podem ser habilitados em todos sistemas rodando servidores TCP públicos
ACK=0 O mesmo que número de seqüência de recepção, mas para o outro lado da conexão TCP
WINDOW
Tamanho da janela de recepção do TCP. Isso pode ser escalado movendo se o bit a esquerda por um número de bits especificado na opção TCP “window scale”. Se as estação suporta ECN, então o tamanho da janela de recepção será controlado por isso
RES=0x03 Bits reservados. O atributo ECN “CWR” e “ECNE” vai mostrar os dois bits mais significantes deste campo
URG Atributo de urgente
ACK Atributo de Acknowledgement
PSH Atributo push
RST Atributo reset SYN
Atributo SYN, somente utilizado no momento de estabelecer uma conexão TCP
FIN
Atributo FIN, somente utilizado no momento de desconectar uma conexão TCP
URGP=0
Ponteiro para Urgent permitido para urgência, transferencia de dados “out of band”, infelizmente nem todas a implementações de protocolos concordam com isso, assim esta facilidade é dificilmente usada
OPT
Habilitado com: --log-tcp-options. Este campo de tamanho variável fornece muitas possibilidades de uso. Opções importantes são: Window Scaling, Selective Acknowledgement e Explicit Congestion Notification
Fonte: Bartz (2001)
61
Infelizmente o número da regra na chain na qual o pacote se encaixa, por razões de sua
arquitetura, não está disponível nos registros de Log do Netfilter/IpTables. Para isso é
necessário construir as regras para Log usando a opção –log-prefix.
3.4 TRABALHOS CORRELATOS
Essa seção propõe-se a apresentar uma síntese de algumas abordagens desenvolvidas
sobre análise de registros de Log e eventos. O primeiro é o IPTABLES LOG ANALIZER que
propõe analisar os registros de Log do IpTables (rejected, accepted, masqueraded packets) e
apresentar os resultados numa página HTML. O segundo é o FWLOGVIEW que faz a análise
em tempo real dos arquivos de Log do Netfilter/IpTables e apresenta os resultados em cores
num interface gráfica. O terceiro é o IPTLOG, que também faz análise dos registros de Log
do IpTables e apresenta os resultados em cores num terminal.
3.4.1 IPTABLES LOG ANALIZER
O IPTABLES LOG ANALIZER propõe analisar os registros de Log do IpTables
para Linux KERNEL 2.4 (rejected, acepted, e pacotes masqueraded) e apresentar os
resultados otimizados numa página HTML (além dos registros de Log do Netfilter, há suporte
para os registros de Log do Shorewall e SUSE firewall). Os relatórios produzidos são
disponibilizados de uma maneira fácil de ler e entender, reduzindo o tempo de uma análise
manual.
Funciona da seguinte maneira, um pequeno processo é inicializado pelo usuário para
ler os arquivos de Log, o Database Feeder. A cada pacote novo que for inserido no Log, esse
processo insere uma linha num banco de dados. As estatísticas são elaboradas na própria
página PHP, que também disponibiliza diferentes visualização dos pacotes armazenados no
banco de dados.
62
O IPTABLES LOG ANALYZER está apto a receber dados de diferentes firewalls,
assim, se a empresa está protegida por vários firewals, pode se rodar o Database Feeder em
cada servidor e obter as informações de um único banco de dados.
Demais informações sobre o IPTABLES LOG ANALYZER estão disponíveis em
Garcia (2002).
3.4.2 FWLOGVIEW
O FWLOGVIEW é uma aplicação java, para mostrar numa interface gráfica, as
entradas do Log preformatadas em tempo real. Este aplicativo é composto por mais
programas:
a) Fwlogview: a interface gráfica feita com JAVA, onde é possível personalizar o
modo de exibição dos dados, sendo possível classificá-los de acordo com
algumas colunas e escolher quais campos do Log serão exibidos;
b) fwlogd: um pequeno processo feito em linguagem PERL para analisar o Log do
firewall e armazenar o fwlog de maneira especial e preformatada. Este processo
tem suporte para os arquivos de Log do IpTables, IPCHAINS e PIX;
c) fwlogmgmd: um processo feito em linguagem PERL que lê um arquivo de fwlog
ou lê continuamente o fwlog atual para disponibilizar os dados para a interface
gráfica.
Demais informações sobre o FWLOGVIEW são encontradas em Goltz (2004).
63
3.4.3 IPTLOG
O IPTLOG é o registrador da queue do IpTables, que significa que registra os
pacotes que foram destinados ao alvo QUEUE pelo IpTables. Apresenta ao administrador as
informações de uma maneira fácil de compreender, num formato mais limpo e também no
formato padrão Packet Capture Library (PCAP) do TCPDUMP.
As características principais do IPTLOG são:
a) resolve nomes de host;
b) resolve nomes de serviços;
c) resolve nomes de protocolos;
d) suprime as entradas que são desnecessárias para a maioria dos usuários;
e) saída do Log formatada, simples, colorida;
f) possibilidade de personalizar o formato de apresentação com os campos que
forem escolhidos, usando PERL;
g) saída para a console, para o SYSLOG ou os dois;
h) exporta pacotes para o formato PCAP que pode ser processado com o
TCPDUMP, ETHEREAL, SNORT e outros;
i) faz Log somente daqueles pacotes que tem uma “marca” específica setada no
IpTables, especificada por uma expressão regular.
Demais informações sobre o IPTLOG são encontradas em Bali (2002).
64
4 DESENVOLVIMENTO DO PROTÓTIPO
Neste capítulo são apresentadas técnicas e ferramentas utilizadas no desenvolvimento
do protótipo de uma ferramenta para análise do Log de eventos de um firewall. O protótipo
desenvolvido é composto basicamente: por um script de firewall do IpTables otimizado para
apresentar as informações do Log necessárias para o desenvolvimento do protótipo; por um
aplicativo rodando como processo no ambiente operacional Linux com a finalidade de ler as
linhas do Log geradas pelo IpTables; por um banco de dados onde são armazenados os dados
obtidos do Log; e por uma página Web onde é realizada a análise das informações e são
apresentados os resultados.
Para especificação do protótipo foi utilizada como ferramenta a técnica de
modelagem orientada à objetos, utilizando a notação Unified Modeling Language (UML).
4.1 ESPECIFICAÇÃO DO PROTÓTIPO
Aqui são apresentados os diagramas de casos de uso, de classe, de seqüência e de
atividades do UML referentes à especificação do protótipo.
4.1.1 Diagrama de Casos de Uso
Os casos de uso descrevem a funcionalidade do sistema percebida por atores
externos. Um ator interage com o sistema podendo ser um usuário, dispositivo ou outro
sistema (Furlan,1998).
O diagrama de casos de uso do protótipo foi desenvolvido utilizando a notação da
UML. Na figura 2 são apresentados os casos de uso principais do sistema.
65
Figura 2 - Diagrama de Casos de Uso
O protótipo do sistema possui três módulos representados pelos três atores do
diagrama de caso de uso da figura 2:
a) LeitorLOG: este módulo é um script desenvolvido na linguagem PHP e serve
para receber como entrada as linhas do arquivo Log e armazená-las num banco
de dados;
b) Administrador: representa o administrador da rede que interage com o sistema,
mantendo as regras do firewall e consultando o sistema;
c) SistemaAnaliseLOG: este módulo é uma página Web desenvolvida na linguagem
PHP que serve para apresentar os resultados ao administrador.
Os casos de uso definidos para o módulo LeitorLOG são:
a) consultarLOG: o aplicativo LeitorLOG faz a leitura de cada linha das
informações do arquivo de Log;
66
b) analisarLOG: cada linha recebida do arquivo de Log é separada e as informações
necessárias são armazenada em vários campos pré-definidos;
c) alimentarBancoDadosLOG: após análise da linha de Log as informações são
armazenadas em um Banco de Dados denominado de LOG;
Os casos de uso para o módulo SistemaAnáliseLOG e Administrador são:
a) consultarBancoDados: o Sistema de análise de Log do firewall obtém todas as
informações necessárias do Banco de Dados LOG;
b) analisarBancoDadosLOG: o Sistema de análise de Log do firewall analisa e
classifica as informações obtidas do Banco de Dados LOG de acordo com sua
programação;
c) mostrarResultados: o Sistema de análise de Log do firewall exibe as informações
analisadas na tela;
d) consultarSistema: o Administrador interage com o sistema requisitando as
informações;
e) manterRegrasFirewall: o Administardor interage com a programação do filtro de
pacotes IpTables mantendo as regras de uma maneira adequada com a política de
segurança e funcionamento do Sistema de análise de Log do firewall.
4.1.2 Diagrama de Classes
Um diagrama de classe denota a estrutura estática de um sistema e as classes
representam coisas que são manipuladas por este sistema (Furlan, 1998).
67
Na fase de análise foram identificadas as classes principais do sistema, seus
relacionamentos e atributos, conforme a figura 3.
Figura 3 - Diagrama de Classes do Sistema
O Diagrama de Classes do Sistema é composto principalmente por sete classes:
a) LOG representa um componente do sistema, o arquivo de Log gerado pelo
firewall;
b) LeitorLOG representa o aplicativo responsável por obter as linhas do Log do
firewall e armazená-las na TableLOG;
c) TableLOG representa uma tabela responsável por armazenar as informações do
arquivo de LOG;
68
d) TablePortas representa uma tabela responsável para armazenar as informações
sobre as portas conhecidas pelo administrador da rede;
e) TableMonitorar representa uma tabela responsável para armazenar as
informações sobre as áreas apresentadas na página Web do sistema, com o
objetivo de identificar o que será apresentado em cada uma delas;
f) TableConfig representa uma tabela responsável por armazenar algumas
configurações de exibição da página Web do sistema como número de registros
por página, tempo de atualização dos registros na tela e ordem de classificação
dos dados;
g) SistemaAnaliseLOG é responsável pela análise e exibição das informações.
4.1.3 Diagrama de Seqüência
O diagrama de seqüência mostra a colaboração dinâmica entre um número de objetos
e o aspecto importante desse diagrama é mostrar a seqüência de mensagens enviadas entre
objetos (Furlan, 1998).
Os principais diagramas de seqüência dos estudos de caso encontrados no sistema
são:
a) consultarLOG: as linhas de Log recebidas através de um processo no ambiente
operacional Linux criado para ler e direcionar estas informações para o
aplicativo LeitorLOG, que faz a leitura de cada linha das informações do
arquivo do Log que são enviadas a ele, (Figura 4);
69
b) analisarLOG: cada linha recebida é separada e as informações necessárias
escolhidas na programação do aplicativo LeitorLOG são armazenada em vários
campos pré-definidos, (Figura 4);
c) alimentarBancoDadosLOG: após análise das informações feitas pelo aplicativo
LeitorLOG, estas são armazenadas adequadamente em um Banco de Dados
denominado de LOG, (Figura 4);
Figura 4 - Diagrama de seqüência a, b, c
d) consultarBancoDados: o Sistema de análise de Log do firewall, através da
programação de suas funções, obtém todas as informações necessárias das
tabelas TableLOG, TableMonitorar e TablePortas, (Figura 5);
e) analisarBancoDadosLOG: o Sistema de análise de Log do firewall analisa e
classifica as informações obtidas das tabelas TableLOG, TableMonitorar e
TablePortas através das funções de identificar itens da tabela TableMonitorar,
identificar pacotes classificados como GERAL, identificar ataques, identificar
70
itens da TablePorta, identificar portas estranhas e identificar portas conhecidas
(Figura 5);
f) mostrarResultados: o Sistema de análise de Log do firewall exibe as
informações analisadas na tela em áreas específicas através da função mostrar
resultados e mostrar estatísticas (Figura 5).
Figura 5 - Diagrama de Seqüência d, e, f
g) consultarSistema: o Administrador interage com o sistema visualizando as
informações de uma maneira otimizadas e ainda faz consultas específicas
(Figura 6);
h) manterRegrasFirewall: o Administardor interage com a programação do filtro
de pacotes IpTables mantendo as regras de uma maneira adequada com a
política de segurança e funcionamento do Sistema de análise de Log do firewall
(Figura 6).
71
Figura 6 - Diagrama de seqüência g, h
4.1.4 Diagrama de atividades
O diagrama de atividades descreve o processo em que o protótipo é executado e a
sequência em que os processos são chamados. O diagrama pode ser visto na figura 7.
Figura 7 - Diagrama de Atividades
72
O diagrama de atividades do sistema está dividido em 3 raias, uma para cada ator do
diagrama de casos de uso do sistema:
a) LeitorLOG: em primeiro lugar executa as funções representadas pelo caso de uso
consultarLOG para receber as linhas do arquivo de Log do firewall, em sequência
são executadas as funções representadas pelo caso de uso analisarLOG para
classificar os dados de cada linha recebida do Log, na sequência são executadas
as funções representadas pelo caso de uso AlimentarBancoDadosLOG para
armazenar os dados num banco de dados, e por fim esta sequência sempre se
repete;
b) Administrador: em primeiro lugar executa as funções representadas pelo caso de
uso consultarSistema para visualizar as informações do LOG, em sequência
executa as funções representadas pelo caso de uso manterRegrasFirewall para
manter e incluir novos dados que podem ser visualizados no sistemaAnaliseLOG;
c) SistemaAnaliseLOG: quando o Administrador faz a consulta ao sistema são
executadas as funções representadas pelo caso de uso consultarBancoDados para
obter as informações do banco de dados, em sequência são executadas as funções
representadas pelo caso de uso analisarBancoDadosLOG para classificar estes
dados, e por fim executa as funções representadas pelo caso de uso
mostrarResultados para exibir os resultados ao Administrador.
4.2 IMPLEMENTAÇÃO DO PROTÓTIPO
Neste capítulo são apresentadas considerações sobre a implementação do protótipo.
Para a implementação foram utilizadas as seguintes técnicas e ferramentas:
73
a) linguagem de programação PHP;
b) sistema operacional Linux Red Hat 9;
c) servidor Web apache;
d) banco de dados MySQL;
e) firewall IpTables.
4.2.1 Configuração do Firewall
A configuração do firewall foi definida da seguinte forma: a política padrão para
todas as chains é DROP, ou seja, bloquear tudo, e então as regras ACCEPT para aceitar o
tráfego permitido.
Antes de criar alguma regra específica para bloqueio ou liberação, foram criadas as
regras para gerar Log com a opção de prefixo seguindo basicamente o padrão de: “FW,
OQUE, CHAIN, ACAO”, onde: FW é um prefixo utilizado somente para identificar a linha
no Log que se refere ao firewall; OQUE compreende dados como MSN, KAZZAA,
SCANPORT, PTCON, dentre outros; CHAIN se refere às chains padrões FORWARD,
INPUT e OUTPUT; ACAO se refere a alguma ação tomada, ACCEPT, DROP REJECT.
O firewall foi configurado para monitorar e gerar Log de ameaças como alguns tipos
de ataques DDoS, SCANPORT, WORMS, alguns programas P2P e mensageiros como MSN;
também tentativas de acesso da rede externa ao servidor nas portas conhecidas (todas abaixo
da porta 1023, inclusive esta); e demais pacotes oriundos da rede interna destinados ao
servidor e também os destinados da rede interna para a rede externa.
74
Estes pacotes monitorados podem ser bloqueados ou aceitos de acordo com uma
política de segurança da organização ou necessidade do administrador, não alterando em nada
o funcionamento do protótipo.
A tabela 4 mostra um trecho da configuração do firewall IpTables responsável por
gerar o Log de portas conhecidas.
Tabela 4 - Exemplo de codigo do firewall (monitorar portas conhecidas)
4.2.2 Módulo LeitorLOG
O módulo LeitorLOG é iniciado através de um shell script, que executa um
comando do sistema operacional Linux que captura as informações do arquivo de Log
messages, onde são armazenadas as linhas de Log do firewall IpTables. A saída padrão deste
comando seria o terminal, mas esta saída foi direcionada através de pipes para um script PHP
que roda em linha de comando capturando estas linhas e armazenando num banco de dados
mysql.
#PORTAS CONHECIDAS PT_CON_ACCEPT $iptables -N PT_CON_ACCEPT $iptables -A PT_CON_ACCEPT -j LOG --log-tcp-options --log-ip-options --log-prefix 'FW PTCON INPUT ACCEPT ' $iptables -A PT_CON_ACCEPT -j ACCEPT #PORTAS CONHECIDAS PT_CON_DROP $iptables -N PT_CON_DROP $iptables -A PT_CON_DROP -j LOG --log-tcp-options --log-ip-options --log-prefix 'FW PTCON INPUT DROP ' $iptables -A PT_CON_DROP -j DROP #LOGAR CONEXÃO PORTAS DETERMINADAS (CONHECIDAS) $iptables -A INPUT -p tcp --dport 22 -i $IF_EXTERNA -j PT_CON_ACCEPT $iptables -A INPUT -p tcp --dport 80 -i $IF_EXTERNA -j PT_CON_ACCEPT $iptables -A INPUT -p tcp --dport 88 -i $IF_EXTERNA -j PT_CON_ACCEPT $iptables -A INPUT -p tcp --dport 0:1023 -i $IF_EXTERNA -j PT_CON_DROP
75
A tabela 5 mostra como é feita a inicialização do módulo e parte do seu código
fonte.
Tabela 5 - Trecho de código do módulo LeitorLog
4.2.3 Página Web do Sistema Análise de Log
A página Web do sistema foi desenvolvida para apresentar os resultados ao
administrador e está organizada da seguinte forma: a primeira área da tela é constituída por
algumas funções; as demais 5 áreas, cada uma com um conjunto diferente de informações a
apresentar, são exclusivas para exibição dos dados armazenados no banco de dados (Figura
8).
Inicialização do aplicativo LeitorLog #!/bin/sh tail -F /var/log/messages | /root/monografia/leitor/leitorlog & Trecho de código fonte da função principal de captura das linhas de Log function ler_linha() { set_magic_quotes_runtime(0); $fd=fopen("php://stdin","r"); // lê a entrada padrão if (!$fd) exit; return $fd; } Trecho de código da função que armazena os dados no Banco de Dados Function armazenar_dados ($datahora,$chain,$acao,$prefixo,$ifin,$ifout,$iporig,$ipdest,$proto,$portaorig,$portadest) { $consulta="INSERT INTO TableLOG (datahora,chain,acao,prefixo,ifin,ifout,iporig,ipdest,proto,portaorig,portadest) VALUES ('$datahora','$chain','$acao','$prefixo','$ifin','$ifout','$iporig','$ipdest','$proto','$portaorig','$portadest');"; mysql_query($consulta); }
76
Figura 8 - Página Web principal do protótipo
Ao se abrir a página, as áreas da tela são carregadas e apresentadas de acordo com
algumas configurações individuais disponíveis através da função Configuração. Estas
configurações compreendem: quantidade de registros exibidos na página, tempo de
atualização e ordem de classificação dos dados (Figura 9).
Figura 9 - Tela de configuração de exibição
A próxima função disponível é Monitorar, a qual serve para manter os dados na
TableMonitorar. Cada área da tela apresenta itens determinados, e estes itens são
77
apresentados de acordo com a TableMonitorar onde consta o que será exibido em cada área.
Quando o Administrador interagir com o firewall para identificação de outro ítem a
monitorar, este deve ser cadastrado nesta tabela informando a área que mais se adequa para
sua exibição, o prefixo que o identifica no Log e o tipo que foi classificado (Figura 10).
Figura 10 - Tela de manutenção da tabela TableMonitorar
A função Portas mantém os itens da tabela TablePorta (Figura 11).
Figura 11 - Tela de manutenção da tabela TablePorta
78
A última função, Estatísticas, abre uma tela onde o administrador pode requisitar
algumas estatísticas por período, de acordo com a área e o campo escolhido (Figura 12).
Figura 12 - Tela de Estatísticas
A área 1 da Figura 8, apresenta todos os dados classificados como GERAL pelas
regras do firewall, que são os pacotes oriundos da rede interna destinados ao servidor e
também os destinados da rede interna para rede externa.
A área 2 é destinada a exibir pacotes endereçados a portas estranhas oriundas da rede
interna, apresenta também os dados classificados como GERAL pelo firewall, mas somente
os que a porta de destino não esteja cadastrada na tabela TablePorta.
A área 3 é destinada a apresentar algumas ameaças como scan de portas e alguns
ataques identificados pelo firewall, como trinoo, ping da morte, entre outros, os quais são
informados através da tabela TableMonitorar.
79
A área 4 é destinada a apresentar alguns serviços específicos rodando na rede interna,
como redes P2P e serviços mensageiros, os quais são informados através da tabela
TableMonitorar.
A área 5, é destinada a apresentar as portas classificadas pelo firewall com portas
conhecidas, que são as portas até o número 1023, destinadas ao servidor.
4.3 RESULTADOS E DISCUSSÕES
A exibição dos resultados depende da correta implementação das regras do firewall.
Uma vez definidas, é necessário também cadastrar os novos ítens a serem identificados na
tabela monitorar.
Pode-se ajustar o tempo de atualização de cada área de informação de acordo com a
necessidade do administrador. Esta configuração como também as configurações de número
de registros por página e ordem de classificação das informações são mantidas na tabela
configurações.
Para exibir na tela informações como portas estranhas rodando na rede, é necessário
cadastrar todas as portas consideraras conhecidas na rede, o que poderá acarretar num
trabalho manual muito grande, dependendo dos serviços disponibilizados na rede que estiver
funcionando.
As portas conhecidas exibidas na tela são as portas que vão até o número 1023, e não
as denominadas conhecidas pela tabela de portas do sistema.
As informações sobre a identificação de possíveis tentativas de ataques e de uso de
programas P2P, também depende da funcionalidade de firewall IpTables, que é responsável
por realizar esta identificação.
80
A área denominada de GERAL tende a mostrar muitos registros, configurando o
firewall para fazer Log somente dos pacotes SYN na regra que gera este Log, foi possível
reduzir consideravelmente este número.
A função de estatísticas provê a exibição de alguns totais. Para isto é necessário
informar a área de exibição da tela, o campo de pesquisa e um período. Se o período não for
escolhido, subentende-se que é o dia atual. As informações exibidas nesta interface
desenvolvida para o protótipo, referem-se aos pacotes trafegantes do dia corrente do uso.
Uma vez ajustado corretamente ao ambiente que vai funcionar, o protótipo mostrou-
se eficaz, produzindo os resultados esperados pelo administrador.
81
5 CONCLUSÕES
A conclusão deste trabalho foi conseqüência do cumprimento de todas as etapas, uma
de cada vez, conforme o cronograma apresentado e aprovado na proposta da monografia.
A especificação e a implementação do protótipo foram as etapas que exigiram um
conhecimento mais aprofundado sobre segurança em redes.
A configuração do firewall IpTables foi o que mais exigiu tempo e dedicação, pois
foi necessário realizar um estudo muito aprofundado sobre o assunto. Esta etapa exigiu a
reconfiguração e recompilação do kernel do Linux, e reinstalação através dos fontes do
próprio IpTables aplicando patches necessários para ativação do módulo string do IpTables,
indispensável para identificar alguns serviços mensageiros de redes P2P, e do módulo PSD
necessário para identificar scan de portas.
É importante ressaltar que para implementação deste trabalho também foram
necessários conhecimentos na criação do banco de dados MySQL, e na criação da página
Web, e no sistema operacional Linux.
O protótipo foi desenvolvido para analisar o Log de eventos de um firewall. O
módulo LeitorLOG recebe as linhas do arquivo de Log do firewall IpTables e as armazena
num banco de dados. O Sistema de Análise de Log consulta, analisa e disponibiliza estas
informações contidas neste banco de dados através de uma página Web para o administrador.
Portanto, considera-se que o protótipo atingiu os objetivos propostos.
Como sugestão de melhoria, propõe-se a criação de novas regras para a identificação
de novos itens pelo firewall IpTables, a realização de mais uma análise das linhas e Log pelo
aplicativo LeitorLOG com intuíto de descartar linhas que aparecem duplicadas devido a
82
escolha dos campos que são armazenados no banco de dados e a criação de gráficos de uso na
página Web do protótipo.
A vantagem da utilização deste protótipo é a redução de tempo de análise do
administrador, pois as informações já vem analisadas e classificadas e disponibilizadas numa
página Web, sendo as mesmas exibidas praticamente em tempo real.
Uma desvantagem que o protótipo pode apresentar é o tamanho do arquivo de Log
pode aumentar muito para cada item à monitorar acrescentado no firewall.
5.1 EXTENSÕES
Como extensão do protótipo, propõe-se a implementação de um aplicativo
LeitorLOG para algum firewall de outro fabricante, como também o monitoramento de mais
de um firewall pelo protótipo.
83
REFERÊNCIAS
ALBUQUERQUE, Fernando. TCP/IP INTERNET: Protocolos & Tecnologias. 3. ed. Rio de Janeiro: Axcel Books do Brasil, 2001.
ANCHIESCHI, Olavo José Gomes. Segurança Total. São Paulo: Makron Books, 2000.
ANÔNIMO. Segurança Máxima para Linux: o guia de um hacker para proteger seu servidor e sua estação de trabalho Linux. Rio de Janeiro: Campus, 2000.
BALI, Andras. IPTLOG, março 2002. Disponível em <http://drewie.host.sk/iptqlog/>. Acesso em 13 jan. 2005.
BARTZ, Manfred. Netfilter Log Format, 2001. Disponível em <http://logi.cc/linux/netfilter-log-format.php3>. Acesso em 12 dez 2004.
BERNSTEIN, Terry. Segurança na Internet. Rio de Janeirio: Campus, 1997.
BORELLI, Walter da Cunha. Teoria e Problemas de Rede de Computadores. Porto Alegre: Bookmann, 2003.
COMER, Douglas E. Redes de computadores e Internet :abrange transmissao de dados, ligacao inter-redes e Web. Tradução: Marinho Barcellos. 2. ed. Porto Alegre : Bookman, 2001.
COSTA, Roberto Leibholz. Empresários, Funcionários e a Internet, abril 2004. Disponível em: <http://www.ibdi.org.br/index.php?secao=&id_noticia=309&acao=lendo>. Acesso em 26 set. 2004.
FURLAN, José D. Modelagem de objetos através da UML. São Paulo: Makron Books,1998. 329p.
GARCIA, Gérald. IPTABLES LOG ANALYZER, outubro 2002. Disponível em <http://www.gege.org/iptables/>. Acesso em 13 de jan 2005.
GOLTZ, Immo. FWLOGVIEW, março 2004. Disponível em: <http://www.nothrix.org/ computing/fwlogview/>. Acesso em 12 jan. 2005.
84
IDG, International Data Group. Quatro em dez pessoas usam P2P no trabalho, abril 2004a. Disponível em: <http://idgnow.uol.com.br/AdPortalv5/MercadoInterna.aspx?GUID=B3E0 55A0-2692-4158-867D-D869FCB043F4&ChannelID=2000002>. Acesso em 06 jan. 2005.
IDG, International Data Group. Mensagem instantânea no trabalho divide opiniões, setembro 2004b. Disponível em: <http://idgnow.uol.com.br/AdPortalv5/InternetInterna.aspx? GUID=3B09292C-60E1-4C3A-820C-31203E7DB7E9&ChannelID=2000012>. Acesso em 06 jan. 2005.
JANG, Michael. Dominando Red Hat Linux 9: Tudo o que você precisa saber para usar Red Hat Linux como um sistema operacional de servidor ou de desktop. Rio de Janeiro: Ciência Moderna, 2003.
LAUREANO, Marcos Aurelio Pchek. Firewall com IpTables no Linux, novembro 2002. Disponível em: <http://www.ppgia.pucpr.br/~laureano/guias/GuiaFirewallIpTables.htm>. Acesso em 26 set. 2004.
MENDES, Wayne Rocha. O submundo hacker do Linux: Ataques e defesas. Rio de janeiro: Ciência Moderna, 2000.
NBSO, NIC BR Security Office. Práticas de Segurança para Administradores de Rede Internet, maio 2003a. Disponível em: <http://www.nbso.nic.br/docs/seg-adm-redes/seg-adm-redes.html >. Acesso em 28 dez. 2004.
NBSO, NIC BR Security Office. Estatística dos incidentes reportados ao NBSO, maio 2003b. Disponível em < http://www.nbso.nic.br/stats/incidentes/>. Acesso em 05 jan. 2005.
PÉRICAS, Francisco Adell. Redes de Computadores: definições e a arquitetura internet. Blumenau: Edifurb, 2003.
RUSSELL, Rusty. Linux 2.4 Packet Filtering Howto, Revisão 1.19, maio 2001. Disponível em: <http://www.netfilter.org/documentation/HOWTO/pt/packet-filtering-HOWTO.html #toc1>. Acesso em 29 dez. 2004.
RNP, Rede Nacional de Pesquisa. Tudo o que você precisa saber sobre ataques DDoS, marco 2000. Disponível em: <http://www.rnp.br/newsgen/0003/ddos.html>. Acesso em 06 jan. 2005.
SILVA, Gleydson Mazioli da. Guia Foca/GNU Linux, Versão 6.38, agosto 2004. Disponível em: <http://focalinux.cipsga.org.br/guia/avancado/ch-fw-iptables.htm>. Acesso em: 29 dez. 2004.
85
SOARES, Luiz F. Gomes; LEMOS, Guido; COLCHER, Sérgio. Redes de computadores, das LANs MANs e WANs às redes ATM. 2 ed. Rio de Janeiro: Campus, 1995.
STARLIN, Gorki. Manual completo do hacker :como ser e evitá-los. 3. ed. Rio de Janeiro : Book Express, 1999.
WEBSENSE. Abuso da Internet no Ambiente de Trabalho Custa às Corporações Brasileiras Mais de R$ 3 bilhões por ano, Novembro 2002,. Disponível em: <http://www.websense.com/company/news/pr/Display.php?Release=021121205>. Acesso em 29 dez. 2004.
ZWICKY, Elizabeth D.; Cooper, Simon; Chapman, D. Brent. Construindo Firewalls para a Internet. 2. ed. Tradução de Vandenberg D. de Souza. Rio de Janeiro: Campus, 2001.
