caso UFBA - PoP-BA

Transcrição

caso UFBA - PoP-BA

UNIVERSIDADE FEDERAL DA BAHIA
INSTITUTO DE MATEMÁTICA
DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO
Thiago Lima Bomfim de Jesus
Detecção e contenção automatizada de atividade
maliciosa em redes de campus: caso UFBA
Salvador
2011.1
Thiago Lima Bomfim de Jesus
Detecção e contenção automatizada de
atividade maliciosa em redes de campus:
caso UFBA
Monografia apresentada ao Curso de
graduação em Ciência da Computação,
Departamento de Ciência da Computação,
Instituto de Matemática, Universidade Federal da Bahia, como requisito parcial para
obtenção do grau de Bacharel em Ciência da
Computação.
Orientador: Profo Dro Luciano Porto Barreto
Co-Orientador: Jerônimo Aguiar Bezerra
Salvador
2011.1
"Prepara-se o cavalo para o dia da batalha,
porém do SENHOR vem a vitória."
(Bíblia Sagrada - Provérbios 21;31)
DEDICATÓRIA
Nossa infância é marcada pela presença de muitos personagens e super-heróis, os quais
admiramos e fazemos de tudo para sermos como eles. O tempo passou e quase nos esquecemos que eles existiram algum dia, entretanto, há dois super-heróis que eu jamais conseguirei
esquecer.
Se não fosse através de seus super-poderes e habilidades incríveis, jamais teria conseguido
chegar até aqui: quando eu tive medo, eles sempre me inspiravam com sua coragem...quando eu
queria desistir, eles me incentivam a prosseguir...quando eu estava cansado, eles me ajudavam
a continuar...quando eu fazia algo de errado, eles me corrigiam e ensinavam...
Até hoje, eles me encantam, me protegem, me inspiram e ainda faço de tudo para ser igual
a eles. Sendo super-heróis, permanecem até hoje realizando seu trabalho de maneira totalmente
anônima, sem esperar reconhecimento ou recompensa, apenas com a plena convicção de estarem fazendo o que é correto.
Porém, eu sei a identidade deles e vejo tudo o que eles fazem, por isso, dedico esse trabalho
e toda minha gratidão aos meus eternos super-heróis, os quais atendem prontamente, apenas
quando eu chamo meu pai e minha mãe.
AGRADECIMENTOS
Antes de mais nada, agradeço ao Senhor Jesus, por tudo que Ele fez ao longo desses anos,
sem Ele nada do que foi feito, se faria. Aos meus pais, Luiz César França de Jesus e Rosana
Lima Bomfim de Jesus, jamais teria conseguido sem o auxílio de vocês, foram essenciais em
todo o tempo, nessa importante etapa de nossas vidas, essa conquista é nossa e se dependesse
somente de mim teria o nome de vocês em meu diploma; e claro, ao meu irmão Matheus
Bomfim, por sua preocupação, torcida e apoio nos momentos difíceis: você é meu orgulho. Ao
meus parentes por todo incentivo e motivação; a todos meus irmãos em Cristo, por suas orações
ao compartilhar minhas frustrações e sua alegria ao compartilhar minha alegria. Em particular,
agradeço a Rebeca Lorena, minha irmã muito querida por tudo, em especial pelo período que
estudamos juntos, a você minha gratidão. Aos meus pastores João Sobral e Carlos Sá, pessoas
sábias, que eu admiro e confio, onde sempre encontrei conselhos, muitas vezes, contrários ao
que eu esperava ou queria ouvir, mas escutando e com o passar do tempo sempre pude entender.
Mas, antes de continuar, foi uma longa jornada até aqui. Começou na escolinha Gente
Inocente, onde iniciei os primeiros passos para acadêmia. Ingressando ainda na alfabetização
no meu querido Colégio da Polícia Militar, estudei todo o primário, ginásio e ensino médio,
tendo dentre muitas coisas, o seu lema marcado em minha memória até hoje: “Cultivar a honra,
o dever e a retidão”. Nesta, tive excelente professores e um ensino de qualidade, não devendo
em nada à rede privada, proporcionando bases para sem ter cursado pré-vestibular e estudando
por conta própria, ser aprovado no concorrido vestibular de Ciência da Computação na UFBA
no ano de 2005: aos meus amigos professores, meu muito obrigado.
Já na UFBA, gostaria de agradecer a todos os professores que foram fundamentais para
essa formação, cada um de vocês fizeram parte dessa obra, hoje concluída. Agradeço especialmente, ao professor Adolfo Dúran (UFBA) por ter aberto as portas do CPD/UFBA, através
do grupo MEFES (Métodos Formais em Engenharia de Software) e por todo aprendizado e orientações, ao professor Leonardo Freitas (University of York) pelos conselhos e ensinamentos
nesse período, e a todo membros do grupo, aprendi muito com vocês.
Agradeço especialmente ao meu chefe Luiz Claúdio Mendonça (CPD/UFBA), por ter confiado em mim e me permitir compor a excelente equipe da Divisão de Suporte (DISUP) do
CPD/UFBA, onde o aprendizado obtido é impagável, minha gratidão. A Jerônimo Bezerra
(CPD/UFBA), por todo conhecimento transmitido, pela paciência, por diversas vezes repetindo
coisas, incansavelmente até que eu aprendesse, sua forma de ensino é excelente, além da coorientação desse trabalho, obrigado; e a claro, toda equipe da DISUP, cada um de vocês tiveram um papel fundamental em meu aprendizado e formação. A toda equipe do PoP-BA/RNP,
aprendi e aprendo muito com vocês, não tenho dúvidas que por melhor que seja o nosso curso
da UFBA, possibilite o conhecimento prático que temos aqui; e claro, não jamais deixando de
citar minha “chefa” Claudete Alves (CPD/UFBA), por essa excelente oportunidade de compôr
esse time ímpar e por sua amizade e toda dedicação em fazer o melhor pelo grupo. A equipe do
CERT.Bahia, ao GRACO, NetCafé, ReMeSSA: a todo vocês, obrigado.
Por fim, não menos importante, ao professor Luciano Porto Barreto (DCC/UFBA), por aceitar trabalharmos juntos, muito obrigado pelos conselhos e orientações, foi uma honra trabalhar
com o senhor. Ao professor Flávio Assis, que além da excelente formação proporcionada ao
longo do curso, aceitou gentilmente participar da banca avaliadora desse trabalho, fico muito
grato.
E a todos que direta ou indiretamente colaboram, não somente para execução desse trabalho,
mas para minha formação e desculpem se esqueci de alguém aqui, mas infelizmente não dá para
listar a todos, minha eterna gratidão a todos vocês.
RESUMO
Com o advento da Internet na era comercial e a diversificação dos serviços oferecidos, a
quantidade de dispositivos conectados à rede tem aumentado a cada ano. Simultaneamente,
um série de problemas vieram agregados dentre os quais, a elevação da ocorrência de atividade
maliciosa nas redes de computadores, conforme demonstram as estatísticas do CERT.br .
As redes de campus, em particular, a rede acadêmica da Universidade Federal da Bahia
(UFBA) é composta por um grande volume de computadores, tipos de equipamentos e perfis de
usuários, proporcionado um cenário crítico para a ação de usuários e softwares maliciosos sobre
a rede. Diversos grupos, tais como CAIS/RNP e o CERT.Bahia, realizam o monitoramento das
redes acadêmicas notificando eventos de incidentes de segurança.
Uma das tecnologias utilizadas para detecção destes eventos são os honeypots, recursos
projetados especificamente para serem atacados, tradicionalmente utilizando endereços IP públicos, detectam atividades oriundas da Internet, que podem ter sido iniciadas apenas em um
dispositivo com um IP público, ou em máquinas com endereços privados, através de NAT.
Neste contexto, propomos nesse trabalho uma abordagem diferente para detecção de atividade maliciosa, utilizando honeypots com endereços IP privados, dentro da rede interna, distribuídos por toda rede acadêmica da UFBA, detectando de forma automatizada atividades maliciosas que ocorrem dentro da rede de maneira mais veloz, devido a proximidade com as máquinas
e outros que possivelmente não seriam identificados pelos honeypots externos, como por exemplo, ataques do tipo port scan, dirigidos para rede interna, que afetam seu bom funcionamento.
Adicionalmente, propomos o desenvolvimento do módulo de contenção automática de incidentes de segurança, para ferramenta TRAIRA (desenvolvida pelo CERT.Bahia), a fim de tornar
todo o processo automatizado, desde o princípio com as notificações geradas pelos honeypots
deste trabalho e dos grupos de segurança até o final, com a identificação na rede da máquina
notificada e a realização da contenção. Atualmente, nossa solução encontra-se em produção
Palavras-chave: atividade maliciosa, Cert.Bahia, contenção, detecção, honeypot, incidentes de segurança, rede campus
ABSTRACT
With the advent of Internet in the age of trade and diversification services offered, the
number of devices connected to the network has increased each year. Simultaneously, a series
of problems came aggregates among which, the increase in occurrence of malicious activity on
networks computer, as shown by statistics CERT.br.
Networks of campus, in particular, the academic network of the Federal University of the
Bahia (UFBA) is composed of a large volume of computers, types equipment and user profiles,
providing a critical scenario for the action of users and malicious software over the network. Several groups, such as CAIS/RNP and CERT.Bahia, monitored the academic networks notifying
events of security incidents.
One of the technologies used for detection of these events are honeypots, features designed
specifically to be attacked, traditionally using public IP addresses, detect activity originating
from Internet, which may have been initiated only on a device with a public IP, or on machines
with private addresses through NAT.
In this context, we propose in this work a different approach to detect malicious activity,
using honeypots with private IP addresses, within the internal network, distributed throughout
the academic network of the university, detecting on an automated malicious activities that occur
within the network way faster, due to proximity to the machines and others possibly would not
be identified by external honeypots, for example, attacks of the type port scan, directed to the
internal network, which affect its functioning.
Additionally, we propose the development of automatic containment module security incidents to Trafra tool (developed by CERT.Bahia) to make the whole process automated, from
the beginning with the notifications generated by honeypots this work and security groups until
the end, identifying the machine on the network notified and the realization restraint. Currently,
our solution is in production
Keywords: campus network , Cert.Bahia, containment, detection, malicious activity, honeypot, incidents, safety.
LISTA DE FIGURAS
1.1
Incidentes Reportados ao CERT.br – Janeiro a Dezembro de 2010 (CERT.BR,
2010b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Estimativa de incidentes notificados relacionados a malwares em 2010 (CAIS/RNP,
2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
12
13
Ciclo do tratamento de incidentes de segurança (SCARFONE; GRANCE; MASONE, 2008) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.2
Honeyd simulando diferentes sistemas operacionais (PROVOS; HOLZ, 2007) .
24
3.1
Visão geral da Rede UFBA - Imagem adaptada do sistema de monitoramento
da CPD/UFBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.2
Estrutura lógica do sistema de detecção de malwares na rede interna da UFBA .
32
3.3
Estrutura física, utilizando VLAN, para o sistema de detecção de malwares na
rede interna da UFBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4
33
Resultado do sofware de anti-vírus, detectando presença de malwares vírus e
spywares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.1
Mensagem de conectividade nula ou limitada no Microsoft Windows XP . . . .
45
4.2
Conexão dos switches da rede UFBA . . . . . . . . . . . . . . . . . . . . . . .
46
4.3
Resultado da piloto utilizando Identity Management com Kerberos Snooping .
49
4.4
Experimento na rede de estações do CPD/UFBA - Id entity Management com
Kerberos Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.5
ACL criada em um roteador da rede UFBA para a faculdade de Letras . . . . .
54
4.6
ACLs aplicadas sobre interfaces do roteador . . . . . . . . . . . . . . . . . . .
56
4.7
Fluxo da notificação do incidente de segurança até o momento da execução do
4.8
código de bloqueio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
Visão geral da arquitetura do TRAIRA . . . . . . . . . . . . . . . . . . . . . .
64
4.9
Tela do módulo de contenção do TRAIRA . . . . . . . . . . . . . . . . . . . .
65
LISTA DE ABREVIATURAS E SIGLAS
ACL
Access Control List,
p. 27
ADSL
Asymmetric Digital Subscriber Line,
p. 26
ATM
Asynchronous Transfer Mode,
p. 23
CAIS
Centro de Atendimento a Incidentes de Segurança,
p. 11
CAN
Campus Area Network,
p. 22
CERT.Bahia
Grupo de Resposta a Incidentes de Segurança - Bahia/Brasil,
p. 13
CERT.br
Centro de Estudo, Resposta e Tratamento de Incidentes de Segu- p. 11
rança do Brasil,
DDoS
Distributed Denial of Service,
p. 16
DHCP
Dynamic Host Configuration Protocol,
p. 33
FBI
Federal Bureau of Investigation,
p. 12
FDDI
Fiber Distributed Data Interface,
p. 23
FTP
File Transfer Protocol,
p. 22
IDS
Intrusion detection system,
p. 20
IETF
Internet Engineering Task Force,
p. 34
IP
Internet Protocol,
p. 22
IPS
Intrusion Prevention Systems,
p. 18
LAN
Local Area Network,
p. 22
MAC
Media Access Control,
p. 27
NAT
Network Address Translation,
p. 24
NTP
Network Time Protocol ,
p. 35
QoS
Quality of Service,
p. 43
RNP
Rede Nacional de Ensino e Pesquisa,
p. 11
SSH
Secure Shell,
p. 15
TI
Tecnologia da Informação,
p. 10
TRAIRA
Tratamento de Incidentes de Rede Automatizado,
p. 13
TTL
Time to Live,
p. 33
UFBA
Universidade Federal da Bahia,
p. 11
SUMÁRIO
1
2
3
Introdução
11
1.1
Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.2
Objetivo do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.3
Estrutura da monografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Fundamentos da detecção e contenção de atividade maliciosa
16
2.1
Incidentes de segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.1.1
Ciclo do tratamento de incidentes de segurança . . . . . . . . . . . . .
18
2.2
Malware, Vírus e Worms . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.3
Honeypots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.3.1
Honeypots de alta-interatividade . . . . . . . . . . . . . . . . . . . . .
22
2.3.2
Honeypots de baixa-interatividade . . . . . . . . . . . . . . . . . . . .
22
2.4
Rede de Campus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.5
TRAIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.6
Trabalho correlatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Detecção de atividade maliciosa em redes campus
27
3.1
Visão geral da Rede UFBA . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.2
Detecção automática de atividade maliciosa na rede UFBA . . . . . . . . . . .
29
3.3
Avaliação experimental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.3.1
Simulação de propagação de atividade malicosa . . . . . . . . . . . . .
37
3.3.2
Caso Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4
5
Contenção de atividade maliciosa em redes de campus
41
4.1
Preliminares da etapa de contenção . . . . . . . . . . . . . . . . . . . . . . . .
41
4.2
Escolhendo a estratégia de contenção . . . . . . . . . . . . . . . . . . . . . . .
43
4.3
Contenção no roteador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.4
Contenção no switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.4.1
Identity Management com Kerberos Snooping . . . . . . . . . . . . .
47
4.5
Contenção manual de atividade maliciosa na rede UFBA . . . . . . . . . . . .
52
4.6
Contenção automatizada de atividade maliciosa na rede UFBA . . . . . . . . .
55
4.6.1
Semi-automatizando a contenção da atividade maliciosa na rede UFBA
56
4.6.2
Automatizando a contenção da atividade maliciosa na rede UFBA . . .
62
Conclusão
67
Apêndice A -- Resultado do experimento: Identity Management com com Kerberos
Snooping no CPD/UFBA
Referências Bibliográficas
71
72
12
1
INTRODUÇÃO
Com o advento da era comercial na Internet e o desenvolvimento de protocolos que estenderam seu uso, a diversidade de serviços oferecidos e o número de equipamentos com acesso à
rede tem aumentado a cada ano. Simultaneamente, uma série de problemas vieram agregados,
dentre os quais, o crescimento das ocorrências dos incidentes de segurança (CERT.BR, 2011).
Os incidentes de segurança acarretam uma série de danos às instituições, sejam no caráter financeiro, em aspectos morais e éticos ou associados às atividades que contribuam para saturar
os recursos da rede, como ocorre quando grande quantidade de máquina infectadas acessam um
serviço em um mesmo instante de tempo, como nos ataques distribuído por serviços (DDoS).
Consequentemente, deve haver um esforço por parte das equipes de TI nas instituições em
definir políticas e ações para uso da rede, a fim de minimizar esse tipo de evento. Atualizações
automatizadas dos pacotes de segurança, atualizações e varreduras periódicas dos softwares
anti-vírus sobre os sistemas operacionais são alguns exemplos simples dessas ações. Contudo,
em redes extensas como as redes de campus, essas atividades ficam bastante prejudicadas devido
a quantidade de máquinas conectadas à rede que não seguem as políticas. Computadores fora
do controle de domínio que não receberão as atualizações automatizadas, e comumente não
são bem configuradas, sem possuir algum software de proteção contra ação dos malwares são
exemplos clássicos.
Em particular, esse fato é bastante comum em instituições de ensino e pesquisa, devido a
diversificação dos perfis de usuários, que por muitas vezes, adquirem equipamentos para montar
suas salas e laboratórios de maneira autonômica ou utilizam dispositivos móveis particulares,
como os notebooks, que são conectados indiscriminadamente à rede.
Desta forma, tornam-se, de maneira não consciente, potencias ameaças à instituição e
contra-medidas são necessárias em busca de detectar e conter os incidentes de segurança, possivelmente causados por esses dispositivos, a fim de manter a qualidade de operação da rede,
evitar a propagação dos software maliciosa (e.g. vírus) sobre os demais dispositivos da rede,
reduzir custos de mão de obra e contratação de largura de banda, além de evitar que o nome da
13
Figura 1.1: Incidentes Reportados ao CERT.br – Janeiro a Dezembro de 2010 (CERT.BR,
2010b)
instituição seja maculada, dentre outros problemas inerentes.
Este trabalho tem como alvo primário a rede acadêmica da Universidade Federal da Bahia(UFBA),
que possui o formato de rede de campus, na qual conduziremos o estudo de caso para detecção
e contenção de atividade maliciosa. Acreditamos que o cenário encontrado da rede UFBA é
semelhante ao das demais instituições acadêmicas, haja vista ao modelo de faculdades e campis universitários serem muito comuns, dentro e fora do Brasil, tornando a proposta de deste
trabalho facilmente adaptável a outros contextos.
1.1
MOTIVAÇÃO
Estatísticas mais recentes do CERT.br (CERT.BR, 2010b) mostram que atividades maliciosas relacionadas à ação dos malwares correspondem a aproximadamente 70% do total dos
incidentes de segurança da informação reportados no Brasil, conforme mostrado no gráfico
da Figura 1.1. Estas estatísticas refletem como clareza a necessidade do combate à atividade
maliciosa.
Infelizmente, nas instituições acadêmicas de ensino e pesquisa o cenário não é diferente.
Em 2010, o Centro de Atendimento a Incidentes de Segurança (CAIS) , responsável pela detecção, resolução e prevenção de incidentes de segurança da Rede Nacional de Ensino e Pesquisa
(RNP) notificou às instituições acadêmicas mais de 100 mil incidentes de segurança; desses
aproximadamente 80% estavam relacionados a ação de malwares, como pode ser visto no gráfico da Figura 1.2
A UFBA é uma das instituições de ensino e pesquisa conectada a RNP, e segundo relatórios
14
Figura 1.2: Estimativa de incidentes notificados relacionados a malwares em 2010 (CAIS/RNP,
2010)
internos do Divisão de Suporte do Centro de Processamento de Dados, ela tem participado
nestas estatísticas. Para se ter uma ideia, no ano de 2009, a UFBA recebeu um total de 478.111
notificações de incidentes de segurança (BEZERRA, 2009), através do CAIS/RNP e outros
grupos de segurança. Essa quantidade de notificações para UFBA, está diretamente associada
à propagação mundial do malware conhecido como Conficker. Este worm infectou milhões de
computadores ao redor do mundo, apresentando diversas formas de atuação, atingindo diversos
países, principalmente a China, Brasil, Rússia e Índia (PORRAS, 2009).
O atuação do Conficker na UFBA, ocasionou uma série de prejuízos à instituição difíceis
de serem estimados, como saturação da largura de banda disponível para campis localizados
interior do estado, levando em alguns momentos a indisponibilidade da rede, devido a incidência
de tráfego maliciosa. A fim de combater esses incidentes, foi necessário a alocação exclusiva de
mãos de obra dedicadas durante várias semanas de bolsistas, técnicos e analistas, para efetuar a
detecção, contenção e tratamento das máquinas infectadas.
Para se ter uma noção da gravidade da ação desse malware e as proporções alcançadas, a
Microsoft ofereceu recompensa de 250 mil dólares por informações que levassem ao criador do
Conficker. Essa operação envolveu o FBI, Serviço Secreto do EUA e a Interpol, e o montante
das recompensas oferecidas junto com outras empresas alcançou a marca de 5 bilhões de dólares
(MICROSOFT, 2009).
Problemas provocados pela incidência de software malicioso na rede, podem eclodir à qualquer instante e ações preventivas devem ser tomadas pelas instituições, de forma automatizada
a fim, dentre outros, reduzir os custos de mão de obra e outros prejuízos à instituição, detendo
com maior velocidade a propagação dos incidentes.
15
1.2
OBJETIVO DO TRABALHO
Tendo como motivação os problemas apresentados anteriormente, esse trabalho visa construir um sistema de detecção e contenção automatizada de atividade maliciosa, originada por
atividade maliciosa dentro das redes de campus, em particular um estudo de caso dentro da rede
UFBA.
A proposta desse trabalho surgiu com o objetivo de completar o ciclo do tratamento de
incidentes de segurança, proposto por (SCARFONE; GRANCE; MASONE, 2008), no contexto da Universidade Federal da Bahia, que tem buscado através de ações ativas, a redução
do número de incidentes de segurança. como no combate de atividade maliciosa. Dentre essas
ações, destacam-se a criação do Grupo de Resposta a Incidentes de Segurança - Bahia/Brasil(CERT.Bahia) e o desenvolvimento da ferramenta TRAIRA - Tratamento de Incidentes de
Rede Automatizado (CERT.BAHIA, 2010), que atua nas duas primeiras fases do ciclo do tratamento de incidentes.
Desta forma, a proposta de detecção automatizada desse trabalho utiliza honeypots de
baixa-interatividade na rede acadêmica da UFBA, atuando na fase de detecção e análise do
ciclo de vida da resposta a incidentes de segurança, que será descrito na Seção 2.1. Na etapa
posterior, realizamos desenvolvemos o módulo de contenção automatizada para o TRAIRA,
atuando na fase de Contenção, Erradicação e Recuperação deste ciclo. Assim, aliados o resultado desse trabalho com o TRAIRA (descrita na Seção 2.5) e a mão de obra da equipe de TI da
UFBA que atua na etapa quatro, Ações Pós-Incidentes, teremos o ciclo completo. Exceto onde
deve-se de fato ter intervenção direta e manual (etapa quatro), teremos um processo de tratamento totalmente automatizado, para ações de atividade maliciosas contribuindo para melhoria
das estatísticas supra citadas.
1.3
ESTRUTURA DA MONOGRAFIA
O trabalho continua seguindo a seguinte estrutura: O Capítulo 2 aborda os principais conceitos e dificuldades envolvidos relacionados a detecção e contenção de atividade maliciosa,
com alguns trabalhos correlatos. O Capítulo 3 apresenta uma visão geral da rede UFBA e suas
principais características, seguido da primeira proposta desse trabalho, detecção de automática
de atividade maliciosa, e avalia a eficácia da solução através de experimentos e um estudo de
caso na UFBA. Já o Capítulo 4, é apresentado a segunda parte da prosposto desse trabalho, a
solução de contenção automatizada de atividade maliciosa, através do desenvolvimento de um
16
módulo para o TRAIRA. Por fim, o Capítulo 5 é apresentada as conclusões obtidas a partir da
realização deste trabalho e propõe-se alguns possíveis trabalhos futuros.
17
2
FUNDAMENTOS DA DETECÇÃO
E CONTENÇÃO DE ATIVIDADE
MALICIOSA
Este capítulo apresenta os principais conceitos envolvidos na detecção e contenção de incidentes de segurança em redes de campus, os quais são objetos de estudo deste trabalho. Será exibido o conceito de incidente de segurança e seus impactos relacionados; apresentado o recurso
computacional para detecção de incidentes de segurança, o honeypot e suas principais características; exposto o modelo de campus e as dificuldades das instituições acadêmicas; demonstradas as principais técnicas de contenção dos incidentes de segurança; e, por fim relaciona-se
alguns trabalhos correlatos.
2.1
INCIDENTES DE SEGURANÇA
Antes de apresentarmos o conceito de incidente de segurança, faz-se necessário definir
o conceito de evento, devido à sensível relação existente entre eles. Segundo (SCARFONE;
GRANCE; MASONE, 2008) um evento é qualquer ocorrência em um sistema ou rede de computadores. Por exemplo, um usuário ao acessar um arquivo compartilhado, um envio de uma
mensagem eletrônica (email) ou um firewall bloqueando uma tentativa de conexão. Em contrapartida, eventos adversos são aqueles que trazem consequências negativas, como a quebra
de um sistema (crash), inundação de pacotes em uma rede de computadores (flooding), acesso
não autorizado a dados ou privilégios no sistema, ou ainda, a execução de código malicioso
que corrompe ou destroem dados. É importante ressaltar que esses eventos estão relacionados
a área de segurança dos sistemas computacionais, desconsiderando-se, desastres naturais ou
falhas relacionadas à perda de energia.
Um incidente de segurança é a violação ou iminente ameaça de violação1 de políticas ou
1 Refere-se
a situação onde uma organização tem argumentos suficientes para crer que um incidente está para
ocorrer, como por exemplo, receber dos sistemas de monitoramento informações de aumento de uso de CPU de
18
regras de segurança, políticas de uso aceitável ou padrão de práticas de segurança (SCARFONE;
GRANCE; MASONE, 2008). A seguir são caracterizados alguns exemplos de incidentes de
segurança:
• Ataques de negação de serviço. Um atacante utiliza apenas um computador (DoS) ou
um conjunto de computadores distríbuidos (DDoS) para tirar de operação um serviço ou
computador conectado à rede. Pode-se citar, um ataque destinado a provocar um aumento
na carga do processamento dos dados de um computador, de tal forma que impossibilite
seu uso ou o direcionamento de centenas de pacotes originadas em milhares de máquinas
comprometidas2 , contra um serviço de uma organização;
• Acesso não autorizado. um atacante utiliza alguma ferramenta de exploit3 para obter
acesso a um servidor ou aumentar o nível de acesso ao sistema (como super-usuário ou
administrador) obtendo assim, acesso a dados confidenciais; eventualmente, ameaçando
vazar informações das vítimas se não receber certa quantia em dinheiro.
• Código Malicioso Uma vez que o sistema possua vulnerabilidades e essas sejam exploradas, o atacante executa código malicioso nesse sistema, obtendo acesso e controle
desse computador, podendo usá-lo para, propagar vírus/worm pela rede e infectar outros
máquinas.
• Uso inapropriado Um usuário utiliza a rede de uma organização para acessar ou prover
conteúdo ilegal para outros usuários . Por exemplo, utilizar artifícios para acessar redes
sociais ou material pornográfico em empresas onde esse tipo de acesso é proibido. Outro
exemplo comum, é utilizar redes do tipo torrent para compartilhar ou obter filmes, jogos,
músicas ou qualquer material protegido por copyright.
Ainda, segundo o CERT.br (CERT.BR, 2006) incidente de segurança pode ser definido
como qualquer evento adverso, confirmado ou sob suspeita, relacionado à segurança de sistemas
computacionais. Portanto, a fim minimizar as ocorrências e os impactos associados aos incidentes de segurança, cabe à organização definir e disponibilizar orientações claras aos usuários
quanto ao uso dos sistemas e da própria rede, bem como investir em recursos que os protejam.
um determinado processo, como o serviço SSH em um roteador, indicando um possível ataque de força bruta ou
bug.
2 Conhecidas por botnets ou zombie, são máquinas infectadas por um ou mais bot; que são scripts ou conjunto
de programas que podem ser controlados remotamente por um ou mais grupos de hackers.
3 Um programa de computador ou sequência de comandos, que se aproveitam da vulnerabilidade de um sistema
computacionais
19
Entretanto, por maiores que sejam os esforços para impedir os acontecimentos dos incidentes de segurança, é improvável eliminá-los completamente. Assim um conjunto de medidas é
aplicado para recuperação e estabelecimento dos sistemas afetados. Esse conjunto de medidas
constitui o chamado de tratamento de incidentes de segurança,que são compostos por fases que
compõe esse processo.
2.1.1
CICLO DO TRATAMENTO DE INCIDENTES DE SEGURANÇA
O tratamento dos incidentes dos segurança pode ser divido em fases, conforme ilustra a
Figura 2.1.
Figura 2.1: Ciclo do tratamento de incidentes de segurança (SCARFONE; GRANCE; MASONE, 2008)
As etapas desse ciclo são descritas como:
• Preparação: nesta fase temos o processo de criação e formação de uma equipe de resposta a incidentes, e a aquisição de ferramentas e recursos necessários. Durante a preparação, a instituição também tenta limitar o número de incidentes que ocorrerão, através
da seleção e implementação de um conjunto de controles com base nos resultados da
análise de risco. Entretanto, inevitávelmente alguns riscos persistirão mesmo após esses
controles terem sido implementados, dado ao fato que nenhum controle é infalível.
Ainda nessa etapa, algumas práticas de segurança para as redes, sistemas e aplicações são
recomendadas, tais como:
– Gerenciamento de patches: grande parte dos incidentes envolvem exploração de um
número relativamente pequeno de vulnerabilidades em sistemas e aplicações. Assim, instituições devem implementar um programa de gerenciamento de patches4 de
segurança a fim de auxiliar os administradores de sistemas na identificação, aquisição, análise e implantação dos patches.Ainda, os sistemas operacionais devem estar
configurados de forma que possam receber as devidas correções de segurança, comumente disponibilizadas pelos fabricantes.
4 Nesse
contexto, são pequenos programas para correções de bugs de outros programas
20
– Configuração dos hosts: Os hosts devem ser configurados de maneira correta, comumente por um profissional devidamente qualificado e indicado pela instituição.
Além de configurar corretamente, devem dar ao usuário final o número mínimo de
permissões sobre o sistema e as configurações padrões devem ser revistas. Senhas
fracas e simples, por exemplo, devem ser alteradas. Quando possível, deve-se manter máquinas dentro do controle de domínio da instituição.
– Sistema de prevenção de código malicioso: deve haver nos sistemas operacionais
algum software para detectar e parar a ação de códigos maliciosos, tais como os vírus
e outros malwares. Eles são importantes a fim de reduzir a quantidade de atividade
maliciosa na rede, levando em conta o principio de que boa parte das ameaças são
conhecidas e podem ser detectadas (SCARFONE; GRANCE; MASONE, 2008), se
esses softwares estiverem atualizados, como os anti-vírus.
• Detecção e Análise: nesta etapa deve-se detectar ou identificar a existência de um incidente. Estes incidentes podem ser detectados de diversas maneiras, em diferentes níveis
de detalhes e precisão. O processo de detecção automatizada pode conter IDS, IPS, honeypots, softwares de anti-vírus e spywares,analisadores de logs, flows dentre outros. A
detecção manual normalmente consiste do recebimento de notificações de outros usuários
ou grupos, tais como o CERT.br, CERT.Bahia e CAIS/RNP. Assim, os responsáveis pelo
tratamento e resposta devem focar em identificar o formato e características dos eventos,
analisando o nível de criticidade e os ordenando. Ordenados, o tratamento dos incidentes devem ser executados, tradicionalmente, pelos que oferecem maior risco e impacto à
instituição para os menores.
• Contenção, erradicação e recuperação: uma vez que o incidente foi previamente detectado e analisado, devem-se realizar procedimentos de contenção do incidentes, para
minimizar ou impedir sua propagação sobre demais sistemas computacionais. Diversas
técnicas de contenção podem ser aplicadas, como por exemplo, retirar o equipamento fisicamente da rede, colocar o dispositivo em uma rede de quarentena (rede com extrema
escassez de recursos, como limitação de banda e restrição de acesso aos demais dispositivos da rede) e realizar o bloqueio no equipamento mais próximo ao qual ele está
conectado (por exemplo, switch no qual está conectado). Em seguida, deve-se realizar o
processo de recuperação e restabelecimento dos sistemas envolvidos, por exemplo máquinas infectadas com vírus/worm deve-se realizar o processo de varredura de anti-vírus
e spywares. A depender do grau de infecção, será necessário reinstalar todo sistema,
cuidando que o backup seja livre de infecção. No caso de um site que tenha suas informações comprometidas realizar a remoção do conteúdo ou tirar a página do ar, até sua
21
restauração.
• Atividades pós-incidente: a equipe de resposta a incidentes deve refletir sobre possíveis
novas ameaças, o que melhorar na estrutura utilizada e procedimentos adotados, fazendo
o levantamento das “lições aprendidas”. Discutir com a equipe de TI , logo após um
incidente mais grave, e periodicamente depois de incidentes menores, é bastante útil para
melhoria das técnicas de segurança e do próprio tratamento de segurança em si. Aprender
com eventos passados é importante para evitar a reincidência ou até mesmo, orientar
adequadamente os usuários.
2.2
MALWARE, VÍRUS E WORMS
Apesar de alguns conceitos como vírus, worms e malwares serem comumente utilizados,
incluindo o contexto dos profissionais da computação, algumas vezes são empregados de forma
diversas. A fim de tornar claro as diferenças entre esses termo, a seguir são definidos cada um
deles:
• Malware: É um termo amplo e genérico que abrange todos os tipos de programas desenvolvidos para executar ações maliciosas em um computador, também podendo ser
chamado de código ou sofware malicioso (malware = malicious software) (CERT.BR,
2010a). Em outras palavras, código malicioso se refere a um programa que é inserido
em outro programa com a intenção de corromper ou destruir dados, comprometendo a
segurança, a confidencialidade, integridade ou disponibilidade dos dados da vítima.
• Vírus: É um programa de computador desenvolvido para causar algum tipo de dano
aos sistemas computacionais. São comumente projetados para se auto-replicar (fazerem
cópias de si mesmo) e distribuir suas cópias em arquivos, programas ou computadores,
não sendo auto-suficientes, dessa maneira, dependem de um programa hospedeiro (ao
contrário dos worms, definido logo abaixo) (SCARFONE; GRANCE; MASONE, 2008).
Geralmente, os vírus só são ativados quando há algum tipo de interação com o usuário.
Por exemplo, ao abrir um anexo infectado em uma mensagem de email ou ao conectar
um pendrive com o autorun5 ativado e infectado.
• Worm: Também conhecidos como vermes, são programas auto-replicantes e auto-suficientes,
o que significa que não requerem um programa hospedeiro para infectar sua vítima. Possuem a peculiaridade de auto-propagação, ao contrário dos vírus, podendo criar cópias
5É
uma característica de alguns sistemas operacionais que executam automaticamente certos arquivos. No
Microsoft Windows, um arquivo autorun comum é o autorun.inf
22
plenamente funcionais e auto-executar sem intervenção de um usuário (REYNOLDS,
1989). Frequentemente, se aproveitam, de vulnerabilidades e erros de configuração, como
no caso de sistemas operacionais desatualizados e sem patches.
• Spyware / Adware. Termo usado para descrever um software que executa determinados comportamentos, como publicidade, coleta de informações pessoais ou alteração da
configuração do computador, normalmente sem consentimento prévio do usuário (MICROSOFT, 2006). Spyware quando associado a publicidade pode comumente é chamado
adware (KASPERSKY, 2011). Um adware não necessariamente pode estar associado a
intenções maliciosas, como por exemplo, as propagandas existentes em software gratuitos
que proveêm propagandas nativas como parte do sofware, distribuídas oficialmente com
eles. Portanto, é recomendado ler todos termos de acordos, como contrato de licença e
declaração de privacidade do software, a fim de o usuário possa concordar ou não com as
políticas adota por esses.
2.3
HONEYPOTS
Com o crescimento dos números e formas de ataques dos sistemas computacionais, membros da equipe segurança adotado diversas estratégias a fim de manter os serviços e a própria
rede protegida e operacional. Uma dessas estratégias é o uso de honeypots. Os honeypots
são recursos de segurança, cujo valor reside em serem sondados, atacados ou comprometidos (SPITZNER, 2003). Em uma primeira impressão, parece ser o oposto do objetivo inicialmente proposto. Contudo, pela própria definição, os honeypots apresentam um comportamento
diferente das demais ferramentas de segurança que não são projetadas para serem atacadas,
sondadas ou comprometidas, e sim, voltadas a resolver problemas bastante específicos, como
controlar acesso de entrada e saída da rede (firewall) ou detectar tráfego anômalo (uso deflows).
Por exemplo, os IDS tem a propósito de detectar atividades maliciosas previamente conhecidas,
monitorando a rede ou algum sistema e reportando para seu administrador. Firewalls devem
controlar acesso (autorizado ou não), bloqueando ou liberando alguns serviços. Em outras palavras, são ferramentas de escopo bastante limitado, apesar de possuirem grande importância
no cenário de segurança. Porém, os honeypots são amplamente flexíveis em termos de sua usabilidade, ou seja, em sua concepção ele foi projetado para não resolver apenas um problema em
específico. Através de falhas de seguranças reais ou simuladas, colocadas de maneira proposital,
os honeypots cumprem seu papel, dentre outros, os descritos abaixo:
1. Podem desviar a atenção dos atacantes das máquinas ou sistemas de maior valor na rede;
23
2. Proveêm um sistema de alertas antecipados sobre novos ataques e ameaças;
3. Permite o aprendizado com os atacantes, durante e após o ataque aos honeypots;
4. Coletar dados de ataques, worms e ferramentas com a finalidade de um estudo futuro;
Entretanto, uma característica fundamental dos honeypots está no fato de que todo contato
ou tentativa de acesso a estes devem ser classificados com suspeito(SPITZNER, 2003), uma
vez que esses não fazem parte dos serviços em produção e suas existências não são conhecidas
(SPITZNER, 2003). Eles podem ser classificados baseados em seu nível de interatividade,
como sendo de alta ou baixa interatividade, como veremos à seguir.
2.3.1
HONEYPOTS DE ALTA-INTERATIVIDADE
Os honeypots de alta-interatividade fornecem aos atacantes aplicações, serviços e sistemas
operacionais reais, dispensando emulação ou restrições (MOKUBE; ADAMS, 2007). Embora
sejam mais complexos de construir e manter, possibilitam obter grande quantidade de informações sobre os atacantes. Como é disponibilizado ao atacante um sistema real, se não for
bem planejado e configurando pode ser utilizado com um vetor de ataque dentro da própria
rede, uma vez que o atacante tem a possibilidade de controlar por completo o sistema. Todavia,
oportunidades de aprendizado são enormes, pois pode-se descobrir quais foram as ferramentas
utilizadas (artefatos), identificar novas vulnerabilidades, anteriormente desconhecidas, tanto nos
sistemas operacionais quanto nas aplicações e serviços expostos no honeypot, além de fornecer
grande possibilidade de observar a interação do atacante com outros atacantes, como discutido
exaustivamente em (PROJECT, 2001).
Na prática, esse tipo de honeypot não se diferem das máquinas da rede de produção, mas
apenas no propósito de uso. Como comentando anteriormente, deve-se ter bastante cuidado ao
planejar tais sistemas, levando-se em considerações os riscos para rede, sendo recomendado
construir uma rede dedicada e específica para os honeypot, tradicionalmente conhecida como
honeynet. Nesse sentido, é dito que “aqui está o segredo entre sucesso e o fracasso” pois devese construir um modelo robusto o suficiente para que possa surtir o efeito desejado para o
aprendizado, impedir que essa rede possa oferecer riscos para rede de produção e ao mesmo
tempo, não permitir que o atacante perceba que está sendo monitorado, pois assim acontecendo,
todo trabalho do preparo pode ser arruinado, levando o atacante a enganar o administrador ou à
exposição da honeynet.
24
2.3.2
HONEYPOTS DE BAIXA-INTERATIVIDADE
Os honeypots de baixa interatividade são caracterizados por serem típicamente fáceis de
instalar, manter e configurar, devido sua simplicidade (PROVOS; HOLZ, 2007).
Esse tipo de honeypot, ao contrário dos de alta-interatividade, não fornecem ao atacante
sistemas ou serviços reais: tudo é emulado. Para deixar claro o contexto de emulação, suponhamos um servidor Unix com alguns serviços em execução, tais como o Telnet, SSH e FTP.
Em sua implantação, entretanto, esse servidor nada mais é do que o honeypot simulando as
caracteríscas inerentes a esses. Assim, ao tentar conectar-se via SSH no servidor, o atacante
terá a impressão de estar acessando um servidor real, uma vez que um prompt6 de login lhe
é fornecido. Assim, todas tentativas de acesso login/senha são capturadas e armazenados em
arquivos de log. Um exemplo prático que pode ser utilizado para esse fim é o Kippo (KIPPO,
2010).
A facilidade dos honeypots de baixa-interatividade está no fato de que após uma simples
instalação, e algumas configurações de serviços desejados o honeypot está pronto. Isso torna a
manutenção muito fácil dado ao risco de comprometimento do honeypot e do sistema operacional ser muito baixo.
HONEYD
O honeyd (PROVOS; HOLZ, 2007) é um pequeno daemon7 que permite a criação de diversos hosts virtuais em uma rede. Esses hosts podem ser configurados para rodar diferentes tipos
serviços, de tal forma que possam assumir caracteríscas de sistemas operacionais reais. Como
o honeyd suporta assumir até milhares de endereços IP em uma rede, estes podem responder
as requisições na rede de acordo com os serviços que lhe foi configurado em cada honeypot,
conforme na Figura 2.2. Neste exemplo, um host físico (10.0.0.2) contendo o honeyd, pode
conter diversos hosts virtuais, que possuem caracteríscas de diferentes sistemas operacionais, e
respondem cada um por IP’s diferentes, como se fosse máquinas reais independentes.
Dessa forma, o uso do honeyd pode ser aplicado para diversas finalidades, como por exemplo, detecção de atividade maliciosa, através de simulação de vulnerabilidades e as tentativas de
exploits ou simplesmente possuir diversos host desse tipo, a fim de enganar o atacante e faze-lo
perder tempo tentando comprometer um sistema que realmente não existe.
6É
um pequeno programa de computador que tem por objetivo realizar ações de acordo com a orientação do
usuário, através de comunicação textual.
7 é um software que roda em background, ao invés de ser controlado diretamente por um usuário. Comumente,
os daemons tem em sua nomenclatura terminada em "d"; por exemplo, o próprio honeyd.
25
Figura 2.2: Honeyd simulando diferentes sistemas operacionais (PROVOS; HOLZ, 2007)
2.4
REDE DE CAMPUS
Rede de campus ou CAN (Campus Area Network) pode ser definida como um agrupamento
de redes LAN (Local Area Network) dentro de um edifício ou agrupamento de edifícios que se
conectam a fim de formar uma única rede (EDWARDS et al., 2005). Normalmente, a instituição
tem a propriedade de toda a rede, incluindo toda a parte de interconexão entre as construções;
que podem ser compostas de diferentes tecnologias, dentre as quais destaca-se Ethernet, Token
Ring, FDDI (Fiber Distributed Data Interface) e ATM (Asynchronous Transfer Mode).
Diferente de como ocorre com outros tipos de rede, que possuem tamanho definido, (como
a LAN que possui extensão máxima aproximada em 200 metros (KUROSE; ROSS, 2006), as
redes de campus não possuem tamanho definido, podendo estar em um único edíficio extendida
por dezenas de andares, ou conectando diversas faculdades em diferentes campus universitários.
2.5
TRAIRA
Observando o aumento do número de incidentes de segurança nas instituições acadêmicas
de ensino e pesquisa, o CERT.Bahia8 desenvolveu uma ferramenta e confeccionou documentos
de boas práticas que utilizados em conjunto, possibilitam o tratamento dos incidentes de segu8 http://www.pop-ba.rnp.br/Cert
26
rança automatizado. Esse agrupamento de documentos de boas práticas, programas e interfaces
que compõe a solução de tratamento das notificações de incidentes de segurança ficou conhecido por TRAIRA (Tratamento de Incidentes de Rede Automatizado) (CERT.BAHIA, 2010).
Essa ferramenta é uma consolidação de um conjunto de scripts previamente desenvolvidos e
utilizados pela Universidade Federal da Bahia (UFBA) para localizar nos logs dos equipamentos
por fatos que levassem a computadores da rede interna que gerou o incidente, dado ao uso de
NAT , o endereço mencionado na notificação quase em sua totalidade não é o mesmo da rede
interna (tradicionalmente, a notificação vem com o chamado “IP de saída” ou “IP roteável na
Internet”.
Entretanto, os scripts anteriormente desenvolvidos eram orientados a resolver o problema
específico da UFBA. Com a consolidação do CERT.Bahia, esses scripts foram refatorados e
transformados em uma ferramenta modular e de fácil adaptação à outros cenários de rede.
Na atual versão, o TRAIRA atua nas fases de preparação e detecção e análise conforme
descrito na Seção 2.1.Ela é distribuída sob a licença GPLv2 ou superior, e pode ser adquirida
em (CERT.BAHIA, 2010).
2.6
TRABALHO CORRELATOS
A incidência de atividade maliciosa sobre as redes de computadores acarretam uma série
prejuízos, que vão além de números em estatísticas. O simples fato de ter uma máquina comprometida e ignora-la, possibilita o comprometimento de muitos outros dispositivos na rede,
que em dado momento podem ocasionar a indisponibilidade parcial ou total da rede, através da
saturação dos recursos computacionais. No aspecto financeiro, os danos podem ocorrer de diversas formas, como na necessidade da aumento da capacidade de banda9 devido ao volume de
tráfego malicioso ou de forma mais grave, através de sanções nas administrativas aplicadas por
outros provedores, através do bloqueio parcial ou total do tráfego oriundos destas instituições,
por vezes, danos incalculáveis.
Desta forma, medidas preventivas são fundamentais nas instituições, a fim de minimizar
a ocorrência dos incidentes de segurança, mesmo sabendo que, nem todos podem ser evitados. Assim, devem haver esforços por parte das instituição na implantação de recursos computacionais que possibilitem a detecção, e tratamento das notificações e a depender do tipo de
ocorrência, realizar a contenção do dispositivo causador do incidente, de forma eficaz. Na lite9 Em
particular, no interior dos estados esse valor pode vir a ser muito alto e inviável, ou apenas o provedor
local não possuir capacidade de oferecer aumento de banda para aquela região.
27
ratura, encontramos diversos trabalhos que demonstram a aplicabilidade, usabilidade e eficácia
dos honeypot, para detecção de atividade maliciosa, tais como (KARTHIK; SAMUDRALA;
YANG, 2005; PROJECT, 2001; PROVOS; HOLZ, 2007; SPITZNER, 2003; BäCHER; HOLZ;
WICHERSKI, 2005; MOKUBE; ADAMS, 2007; FILHO et al., 2002; MARCELO; PITANGA,
2003; CERT.BR, 2007; KARTHIK; SAMUDRALA; YANG, 2005), todavia, em nenhum deles
encontramos uma proposta ou estudo utilizando honeypots na rede interna; sendo por vezes teóricos, demostrando situações de uso na rede externa ou na maioria das vezes, omitindo a forma
utilizada.
Em (PROJECT, 2001), fornece um conjunto completo no que diz respeito aos honeypots.
Ele apresenta sua principal motivação, apresentando de maneira bastante didática, uma analógica entre a guerra, o campo de batalha, os inimigos e soldados associando-os as atividades
maliciosas, as redes de computadores, atacantes e os responsáveis das equipes de TI, demonstrando que uma das principais estratégias para se vencer um inimigo é conhecê-lo. Apresenta
os conceitos referentes aos honeypots, com seus tipos e suas características, apresentando a
arquitetura geral e como projetar os honeypot, como ferramentas da "guerra”. Prossegue apresentando os "inimigos”, de forma didática e técnica, os risco que eles oferecem aos recursos
computacionais, as suas "táticas”, mostrando suas formas de atuação, e apresenta alguns motivos e razões para que os atacantes, desfira ataques e tentando ou comprometendo diversas redes
e dispositivos. Por fim, apresenta um estudo de caso, com as experiências do projeto ao qual estava envolvido, apresentando resultados, por vezes, detalhados; demonstrando a aplicabilidade
e flexibilidade do uso de honeypots. Todavia, em nenhum momento foi apresentado de maneira
objetiva a estrutura de como os honeypots foram implantados, deixando apenas o leitor entender
que foi uma rede projetada especificamente para o projeto, e não aplicado a uma rede real ou
em produção.
No que diz respeito a soluções de gerenciamento de redes, que permitem possibilitam o
gerenciamento centralizado dos equipamentos distribuídos pela rede, encontramos no mercado
algumas soluções proprietárias que oferecem recursos disponíveis, permitindo algum nível de
contenção, em particular, efetuando direto nos switchs que um determinado dispositivo esteja
conectado, tais como (CISCO, 2011; EXTREMENETWORKS, 2011; D-LINK, 2011); todavia
apresentam uma série de restrições, não desejáveis, dentre as quais destacamos: a quantidade
de equipamentos que podem ser gerenciados e a restrição dos modelos de equipamentos, como
soluções proprietárias, só funcionam com determinados modelos de equipamentos, e não gerenciam equipamentos de outros fabricantes, tornando esse tipo de solução inviável para redes
acadêmicas, que possuem grande quantidade de equipamentos e grande diversidade de modelos
e fabricantes. Contudo, em nosso estudo, não foi encontrada uma solução, mesmo que pro-
28
prietária, que realize a contenção de maneira automatizada, sendo necessário realizar alguma
intervenção manual para o isolamento do dispositivo notificado.
29
3
DETECÇÃO DE ATIVIDADE
MALICIOSA EM REDES CAMPUS
Neste capítulo, serão apresentados os detalhes que envolvem a implementação de um sistema de detecção automatizado de malwares em rede de campus, em particular uma estudo de
caso na rede UFBA, parte da proposta desse trabalho. Inicialmente será apresentada uma visão geral da rede UFBA e suas principais características, bem como o porque da escolha desta
para este estudo de caso. Em seguida, serão abordados os detalhes do sistema de detecção de
atividade maliciosa, e sua importância no cenário desta e das demais instituições acadêmicas.
3.1
VISÃO GERAL DA REDE UFBA
Como explanado na Seção 2.4, uma rede do tipo campus é uma rede que pode ser definida
como um agrupamento de redes LAN dentro de um edifício ou agrupamento de edifícios que
se conectam a fim de formar uma única rede.
A rede UFBA é uma rede de campus de grande extensão, composta por mais de cinquenta
edifícios, distribuídos em três campi pela cidade do Salvador; sendo utilizados com diferentes
propósitos para universidade, abrigando pavilhões de aulas, institutos, faculdades, prédios administrativos, residências universitárias, creche e hospitais. Todos estes edifícios estão ligados
ao prédio do Centro de Processamento de Dados, por meio de fibras óticas, sendo as únicas
exceções algumas residências universitárias que estão conectadas via ADSL . Nesses casos, em
particular, optou-se por essa tecnologia, devido ao custo-benefício em manter os links com essas
unidades1 , sendo que esses foram contratados pela própria universidade à provedores privados.
No interior do estado, a UFBA ainda possui mais três campi que são distibuídos pelos municípios de Barreiras, Vitória da Conquista e Oliveira do Campinhos e estão conectados com o
CPD/UFBA via frame-relay 2 .
1 Nesse
trabalho, unidade é um sinônimo para edifício ou prédio, pois é um termo bastante comum empregado
pela universidade ao se referir a uma faculdade ou pavilhão de aula, por exemplo.
2 É um protocolo para WAN de alto desempenho que opera nas camadas física e enlace do modelo OSI.
30
Em termos de equipamentos, segundo relatórios internos da Divisão de Suporte do CPD/UFBA,
a rede possui mais de 200 switches gerenciáveis, com ampla variedade de modelos e fabricantes,
dentre eles: D-Link, Cisco, 3Com e Alcatel. Os switches gerenciáveis são aqueles que permitem algum tipo de acesso, de tal forma que seja possível efetuar configurações, dentre outras, a
configuração de endereços IP para monitoramento e gerência, criação e configuração de VLAN
e algumas regras básicas de segurança, como a criação de ACL A diversidade de modelos e fabricantes estão diretamente associados, dentre outros possíveis motivos, as diferentes épocas em
que foram adquiridos e ao fabricante vencedor do referido processo licitatório, forma comum
de aquisição de certos tipos de bens em orgãos públicos. O número total de switches e hubs é
difícil de ser estimado com precisão, mas sabesse que são muitos, haja vista a quantidade de
endereços MAC distintos registrados nas tabelas dos roteadores da rede3 que hoje representam
a ordem aproximadamente 15 mil, difundidos sobre mais de 150 VLANs ativas.
A rede UFBA ilustrada pela Figura 3.1 é estruturada na topologia do formato estrela, sendo
composta por três estrelas interligadas, com pontos centrais no Centro de Processamento de
Dados no bairro de Ondina, na Reitoria da universidade no bairro Canela e na Faculdade de
Economia no bairro da Piedade. O roteamento da rede UFBA em Salvador é feito por três
equipamentos principais (chamados pelo CPD/UFBA de Core) que possuem as seguintes responsabilidades:
1. Core 1: responsável pelo roteamento de VLANs acadêmicas do campus Ondina;
2. Core 2: responsável pelo roteamento de todas as VLANs administrativas;
3. Core 3: responsável pelo roteamento de VLANs acadêmicas do campus Canela/Piedade;
As VLANs acadêmicas são dedicadas as redes vinculadas ao domínio de usuários acadêmicos da universidade, entre eles, professores, alunos e departamentos diretamente ligados ao
acadêmico, como os colegiados. Estas, concentram a maior parte das rede, onde será aplicado
nosso estudo de caso, explanado mais à frente. As VLANs administrativas (cerca de 15% do
total de VLANs) são destinadas aos usuários de orgãos e setores com vinculo administrativos
da faculdade, que não possuem ligação direta como o acadêmico, como por exemplo, rede de
câmeras de segurança da universidade, rede de estações de uso público ou a própria rede de
estações da Divisão de Suporte do CPD/UFBA.
Essa características de separação do roteamento das VLANs acadêmicas das VLANs administrativas tem algumas importâncias, dentre as quais, não sobrecarregar determinados equipa3 Considerando
à média de portas por equipamentos versus a quantidade de equipamentos conhecidos, subentendesse que excede em muito os 200 switches
31
mentos, ter e manter estrutura bem definida e organizada, além de não ter um ponto central de
falhas para rede.
No que tange aos usuários da rede estes podem ser dividos em 4 grandes grupos: alunos,
servidores, professores e visitantes. Alunos são aqueles que ingressaram na universidade via
algum processo seletivo um dos cursos da instituição. Servidores são pessoas que prestam serviço a universidade sem exercer a docência e ingressaram comumente por concurso público.
Professores são funcionários públicos ou contratados temporariamente que lidam com atividade de ensino e pesquisa na instituição. Por fim, visitantes são pessoas que não pertencem a
nenhum dos grupos anteriores, e tem tempo de estadia não definida na instituição. O número
estimado desses usuários hoje, segundo a informações da Divisão de Suporte do CPD/UFBA,
está na ordem de mais de 12 mil usuários. Isso pode ser facilmente associado com a estatística
apresentada anteriormente sobre a quantidade de endereços MAC registrados nos roteadores.
Esses números tendem a crescer, graças ao aumento do número de cursos e vagas oferecidas
nos vestibulares e concursos pelo governo federal, e associado a esses, o aumento de visitantes
na instituição, sejam por meio de intercâmbios ou simplesmente pessoas de passagem durante
eventos promovidos na universidade. Esse crescimento é importante em diversos aspectos,
como no desenvolvimento nos níveis da educação brasileira, entretanto para os responsáveis
pela área de TI da instituição, o crescimento pode ser enxergado pelo crescimento dos dispositivos que terão a necessidade de acesso à rede de computadores, estes cada vez mais populares
e economicamente acessíveis, como desktops, notebooks, netbooks, tablets, smartphones, dentre outros, que são de fundamental importância para condução de seus respectivos estudos e
trabalhos.
Todavia, como explicado na Seção 1.1, o aumento do número de dispositivos conectados à
rede podem trazer consigo uma série de problemas, como o crescimento do número de incidentes de segurança, em particular, das ocorrências de atividade maliciosa gerada por malwares,
conforme demostram as estatísticas do CAIS/RNP na Figura 1.2.
3.2
DETECÇÃO AUTOMÁTICA DE ATIVIDADE MALICIOSA NA REDE UFBA
Haja vista a situação das instituições acadêmicas e da própria UFBA diante do problema
do crescimento das ocorrências das atividades maliciosas, propomos nesse trabalho um sistema
de detecção automatizado de malwares utilizando honeypots de baixa-interatividade dentro da
rede interna da UFBA, em particular, na rede acadêmica desta instituição.
32
Figura 3.1: Visão geral da Rede UFBA - Imagem adaptada do sistema de monitoramento da
CPD/UFBA
Os honeypots são algumas das tecnologias empregadas por grupos relacionados ao tratamento e notificação de incidentes de segurança, como o CAIS/RNP, CERT.Br e o CERT.Bahia.
Tradicionalmente esses honeypots ficam localizados na rede externa, utilizando um ou mais endereços IP reais e expostos para Internet coletando atividades maliciosas oriundas de qualquer
lugar do mundo. Assim, para detectar os ataques originados nas redes acadêmicas, alguns filtros devem ser utilizados por esses grupos e, após formalizada a notificação esta é encaminhada
a instituição responsável pelas gerações dos incidentes. Todavia, esse processo pode vir a ser
bastante demorado, conforme descrito à seguir:
• Um host infectado por algum tipo malware, estando comumente atrás de um equipamento que efetua NAT, quando começa a gerar incidentes de segurança para rede externa
(para própria Internet), possívelmente esteve ou estará em algum momento propagando
atividade maliciosa para rede interna;
• Uma vez que este se propagou para rede externa é possível que essa propagação seja detectada em um dado instante por algum honeypot de um determinado grupo, por exemplo
do CAIS/RNP, que identificará o ataque como proveniente de um IP válido na Internet,
comumente chamado de IP roteável4 ;
• Este grupo, em uma dada periodicidade, executará seus filtros e enviará as notificações às
instituições responsáveis pela geração dos incidentes de segurança;
• A instituição geradora do incidente ao receber a notificação buscará utilizar algum método
para encontrar a máquina que dentro da instituição gerou o incidente de segurança, seja
4 Lembrando
que diversos hosts atrás de um NAT sai apenas com um IP real na Internet.
33
através de análise de logs do firewall ou através de ferramentas como o TRAIRA, no caso
da UFBA;
• Após ser detectada, alguma medida de contenção é tomada pela equipe de TI desta instituição e o host é submetido a algum tipo tratamento. No caso da UFBA, o host tem seu
endereço mac-address bloqueado manualmente no roteador mais próximo por membros
da equipe, a fim de evitar que ele gere novos incidentes e um processo localização física
e desinfecção é executados nessas máquinas.
Observa-se que esse período pode vir há ser demasiadamente longo, permitindo que a atividade maliciosa se prolongue por um extenso período de tempo na rede até que o host seja
finalmente isolado. Ainda, essa forma de detecção utilizando honeypots na rede externa identificará apenas ataques que chegaram a sair para rede externa, em outras palavras, se o ataque só
foi propagado somente em rede local, esses honeypots nunca identificarão a existência de uma
ameaça.
Para auxiliar no combate das atividades maliciosas ocasionadas por malwares, minimizar
os tempos de detecção e notificação, e ainda, identificar ataques dentro da rede interna (não
detectado por honeypots externos à rede), como na redes de campus da UFBA, propomos a
utilização de cerca de 70 honeypots de baixa-interatividade distribuídos por toda a rede acadêmica da UFBA, um em cada VLAN, correspondendo a cada uma das unidades acadêmicas da
instituição, conforme ilustrado na Figura 3.2.
Essa proposta de utilizar honeypots dentro da rede interna permite detectar de forma mais
rápida os hosts que estejam propagando atividade maliciosa, pois estando no mesmo segmento
de rede estarão mais próximos das máquinas infectadas por malwares. Consequentemente, poderão estar notificando em intervalos de tempos mais curtos, reduzindo o tempo de atividade
do malware na rede, haja vista que menos etapas são necessárias com base no processo anteriormente citado. A escolha de honeypots de baixa-interatividade dá-se ao fato que estes estarão
dentro da rede de produção e não queríamos expor a rede a mais riscos, como os oferecidos nos
honeypots de alta-interatividade, conforme discutido na Seção 2.3.1.
Entretanto, manter 70 máquinas físicas distintas, localizadas em cada segmento de rede
hospedando honeypots seria algo bastante complexo e custoso. Isto por diversos motivos, dentre
os quais destacamos:
• Geração alto custo para aquisição de todas essas máquinas;
• Elevação razoável do aumento do consumo de energia da instituição, por ter a necessidade
34
Figura 3.2: Estrutura lógica do sistema de detecção de malwares na rede interna da UFBA
de estarem 24 horas por dia ligadas;
• Necessidade e dificuldade de obter espaço físico seguro para abrigar cada uma das máquinas nos prédios da rede acadêmica;
• Cenário amplo com diversos pontos sucetíveis a falhas, tais como, problemas físicos nas
máquinas ou problemas de falta de energia;
• Custo de manutenção e administração destes hosts na rede, sejam por meio de ações
corretivas ou preventivas;
• Comprometimento da escalabilidade desse sistema, pois com o surgimento de novos prédios no campus, como é o atual cenário da UFBA, novas máquinas teriam que ser adquiridas, configuradas, dentre outros supracitados;
• Explosição e conhecimento da existência de honeypots na rede;
Desta maneira, decimos criar um ambiemte que resolvesse essas problemas. Para isso,
utilizamos um único servidor físico, utilizando o sistema operacional Debian GNU/Linux, configurando sua interface de rede para ter suporte VLAN. Assim, configuramos e utilizamos uma
35
Figura 3.3: Estrutura física, utilizando VLAN, para o sistema de detecção de malwares na rede
interna da UFBA
porta no Core da rede, contento todas as VLAN e conectamos nosso servidor nela. Dessa
forma, temos físicamente uma única máquina, localizada no datacenter da UFBA, mas lógicamente temos 70 máquinas espalhadas pela rede. Em verdade, em um ambiente proporcionado
pela UFBA, não tivemos nem a necessidade de ter um servidor físico. Utilizando o conceito
de virtualização, nosso servidor foi criado virtualmente, e apenas uma interface física de rede,
desse servidor que abriga outros servidores virtuais, foi utilizada. A estrutura de nossa proposta
é exemplificada na Figura 3.3.
Dando continuidade ao nossa proposta, através de informações obtidas com a Divisão de
Suporte do CPD/UFBA, descobrimos que a maior parte dos sistemas operacionais instalados
nos computadores da instituição são pertencentes a alguma versão do Microsoft Windows. Aliado aos tradicionais problemas de segurança enfrentados por esses sistema operacional, e aos
vírus, worms e toda sorte de malwares comumente desenvolvidos para este, decidimos projetar
os honeypots simulando o comportamento de um host rodando o sistema operacional Windows
36
XP. Desta forma, configuramos os nossos scripts do honeyd, o nosso honeypot, que utiliza a
base de dados do NMAP (BERRUETA, 2003) para emular o comportamento desse sistema operacional na rede. O NMAP5 se baseia no princípio de que todo sistema operacional tem seu
OS FingerPrint, ou seja, uma impressão digital semelhante as dos seres humanos que possuem
características únicas. Dessa forma, os sistemas operacionais podem ser identificados por características, como por exemplo, partes do cabeçalho TCP/IP, como TTL , TCP Options, IP Packet
Length, entre outros que podem ser vistos em detalhes em (TANENBAUM; WOODHULL,
2004).
Todavia, após a configuração do honeyd para emular o comportamento do sistema operacional, ainda é necessário abrir algumas portas, dado ao fato que, por padrão, todas as portas
do sistema estão fechadas. Esse comportamento padrão de portas fechadas é o que permite
projetar o honeypot para simular vulnerabilidades específicas. Baseado em estatísticas de grupos de segurança, como do CERT.Bahia em (CERT.BAHIA, 2011a), abrimos as portas onde há
as maiores incidências da ação de malwares, tais como as portas 445, 139, 135 e 9988. Isso
pode ser observado também a partir da ação de malwares, como o Conficker que explora algumas vulnerabilidades em sistemas operacionais Windows, explorando as portas 445, 139 e 135,
conforme alerta em (CAIS/RNP, 2009). Ou ainda, o caso recente do worm W32.Qakbot que
se propaga por portas de compartilhamento de dados padrão do Windows, e gerou mais de 20
mil casos por dia ao redor do mundo, sendo o Brasil o terceiro país em número de máquinas
infectadas, permitindo o envio de informações de transações bancárias em tempo real para o
atacante, conforme relatório do grupo de resposta à incidentes de segurança da Symantec do
primeiro semestre desse ano, em (RESPONSE, 2011).
Para colocarmos os honeypots em produção, foi necessário configurar IP estáticos, um por
VLAN, a fim de que o honeypot fosse inserido como um host na rede. Dessa forma, uma vez
configurado ele está pronto para ser sondado por atividades maliciosas. A necessidade de ter
um IP estático, dá-se ao fato de que eles precisam ter um IP na rede, e ao mesmo tempo seja
desconhecido pelos demais host, a fim de que mantenha-se a propriedade básica do honeypot,
que diz que todo tráfego ou tentativa de conexão com ele é potencialmente suspeito. Para isso,
efetuamos a reserva dos endereços IP no servidor DHCP da UFBA, a fim de evitar IP duplicado
na rede.
Para enviar as notifições dos incidentes identificados, alguns scripts foram escritos na linguagem Shell Script, para notificar a equipe de segurança da UFBA das ocorrências registradas.
Poderia ser escolhida qualquer linguagem, mas essa foi utilizada dada a natividade desta nos
5 http://
nmap.org/book/osdetect-fingerprint-format.html
37
sistemas Unix e a relativa facilidade em escrever scripts que interagam com o sistema e seus
aplicativos, como por exemplo, o servidor de email, necessário para envio das notificações.
Como supracitado, todo tráfego ou tentativa de conexão é classificado como suspeito, contudo,
como é possível que algum usuário erre na tentativa de acessar alguma máquina, decidimos
por registrar e notificar a partir de 3 tentativas, em um intervalo de cada 6 horas. Dessa forma,
quatro vezes por dia, o servidor que contém o honeypot trata os arquivos de log, e notifica por
email os responsáveis, seguindo o modelo abaixo:
Prezado(a) responsavel pela rede UFBA,
O endereco IP xxx.xxx.xxx.xxx foi detectado como possivelmente
infectado e propagando virus/worm. Abaixo seguem algumas evidencias coletadas:
| xxx.xxx.xxx.xxx | srcport 1293 | 2011-06-08 14:17:49 (GMT-3) |
Pedimos a gentileza de verificar. Caso tenha alguma duvida, favor entrar em contat
Grupo de Seguranca da Rede UFBA
Apesar de haver tentativas na padronização internacional para todas notificações de incidentes de segurança para permitir uma melhor colaboração entre os grupos de segurança ao redor
do mundo, conforme propõe o IETF com as propostas de padronizações IDMEF (Intrusion
Detection Message Exchange Format) (DEBAR; CURRY; FEINSTEIN, 2007) e IODEF (Incident Object Description Exchange Format) (DANYLIW; MEIJER; DEMCHENKO, 2007), os
grupos de segurança brasileiros ainda não adotaram tais modelos.
Contudo, enquanto essa padronização ainda não é adotada, o CERT.Bahia, segue o modelo
anteriormente demostrado, que se baseia nas recomendações do CERT.br (CERT.BR, 2006)
para notificar incidentes do tipo, propagação de vírus/worm, que também foi adotado por esse
trabalho. O primeiro campo exibe o IP do host que foi detectado com gerador do incidente de
segurança, seguido pela porta de origem e o horário que foi detectado o incidente, junto com a
indicação de fuso horário.
Essa informações são fundamentais para os honeypots localizados na rede externa, pois
com o uso de NAT nas instituições, as notificações serão enviadas com o IP real da rede da
38
instituição, conhecido popularmente como IP de saída. Logo, cada uma dessas informações
utilizadas em conjunto facilitarão localizar nos registro dos logs dos equipamentos a máquina
da rede interna que gerou o incidente. Para a notificação que geramos com os honeypots da rede
interna, a informação de fuso poderia ser omitido, pois todos os servidores da rede comumente
utilizam a mesma fonte de sincronização de relógios, seguindo o protocolo NTP , todavia a fim
de seguir o padrão decidimos mantê-lo. Porém, as demais informações não podem ser omitidas,
mesmo na rede interna, independente do fato que o IP notificado já conhecido (o padrão adotado
na rede acadêmica da UFBA é 192.168.xxx.0/24, onde xxx corresponde a VLAN da rede) .
Isso porque, como os endereços IP são distribuídos por DHCP, um IP pode ter pertencido a
várias máquinas, em um dado intervalo de tempo. Assim, a única informação que garante a
identificação única da máquina é o seu endereço mac address. Por isso, nas etapas discutidas
no início dessa são foi dito que o bloqueio é baseado no mac address, e não no endereço IP.
Nesse ponto, na rede UFBA, a notificação é encaminhada ao TRAIRA através de um email
previamente cadastrado a equipe de operação, e através um pequeno parser escrito em Perl
(linguagem de programação utilizada pelo TRAIRA) os dados informados de endereço IP, porta
de origem e horário da notificação são processados e é retornado o mac address do host gerador
do incidente, conforme modelo abaixo:
Prezados,
Segue abaixo uma relacao <IP | MAC | UNIDADE | STATUS> das máquinas detectadas como
possívelmente comprometidas com vírus/worm. O campo STATUS informa se a maquina já
foi bloqueada ('host-bloqueado') ou se esta pendente de bloqueio por algum dos
seguintes motivos: host que não pode ser bloqueado ('não-bloqueável') -- e.g. um
servidor; falha no bloqueio ('falha-ao-bloquear'); ou que o bloqueio deve ser feito
manualmente ('bloqueio-pendente'). Favor verificar as informaçõees e realizar o
tratamento dos hosts listados abaixo (e.g. anti-vírus, etc.).
xxx.xxx.xxx.xxx | aa-bb-cc-dd-ee-ff | Rede_VLAN1 | bloqueio-pendente
Atenciosamente,
-TRAIRA :: Tratamento de Incidentes de Rede Automatizado.
UFBA CSIRT
De posse do mac address, o host gerador de incidentes pode vir a ser isolado (detalhes
39
sobre este assunto serão tratados no capítulo seguinte) e então dado início ao tratamento de
desinfecção pela equipe de apoio (helpdesk), seja por execução de anti-vírus e softwares de
detecção de malwares ou em alguns casos a reinstação do sistema operacional.
3.3
AVALIAÇÃO EXPERIMENTAL
A fim de realizar a verificação da eficácia desta proposta, colocamos os honeypots em produção na rede acadêmica da UFBA, e realizamos algumas simulações e estudo de caso real.
Estas tiveram por objetivo verificar se o sistema de detecção automatizada utilizando os honeypots na rede interna estavam correspondendo em detectar a ação de malwares nos segmentos de
redes. Dessa maneira, saberíamos que, quando ocorressem ataques reais aos honeypots, esses
identificariam corretamente e seríamos notificados da existência de atividade maliciosa em cada
segmento de rede da UFBA.
3.3.1
SIMULAÇÃO DE PROPAGAÇÃO DE ATIVIDADE MALICOSA
Para realizarmos os testes, foram escolhidos aleatoriamente algumas das VLAN onde tínhamos colocados os honeypots. Como não é trivial capturar malwares reais e colocá-los em
execução e executá-los forma controlada e segura, decidimos utilizar algum software que pudesse simular o comportamento de máquinas infectados por vírus/worm, sem oferecer risco real
à rede.
Contando com a colaboração da Divisão de Suporte do CPD/UFBA, utilizamos um ponto
da rede deles, já que esta rede é roteada para todas as demais redes da instituição o que facilitaria a execução dos testes. Utilizando um notebook com o sofware nmap6 realizamos scans
nas redes simulando ataques de malwares nas portas 445 (Compartilhamento do Windows),
139 (NetBIOS), 135 (Location service), 22 (SSH) e 9988 (Software Essentials Secure HTTP
server), através da execução do comando nmap -p 445, 139, 135, 22, 9988 xxx.xxx.xxx.xxx/xx,
onde xxx.xxx.xxx.xxx./xx representa os segmentos de rede testados, não exibidos por razões de
segurança. A escolha dessas portas já foi justificada na Seção 3.2
Após essas simulações de propagação de malwares, aguardamos o próximo ciclo de notificações, já que o servidor com os honeypots enviam as mensagens a cada 6 horas. No tempo
oportuno, foram emitidas e enviadas as notificações, uma por honeypot que sofreu o “ataque”,
para o email da equipe de segurança da UFBA contendo o IP da máquina da simulação, porta
6 Nmap
ou Network Mapper é um sofware livre de código aberto projetado para executar exploração de redes
ou realizar auditoria de segurança. Mais informações em http://nmap.org/
40
de origem e horário da ocorrência, o qual foi recebido e tratado pelo TRAIRA, retornando
a informação do mac address da máquina, com esta sendo possívelmente comprometida por
algum malware. Todavia, para evitar que a máquina fosse bloqueada, as notificações foram
posteriormente excluídas, além de evitar agregação de falsas estatísticas para instituição.
Portanto, os honeypots já em um ambiente de produção, mostraram-se bastante eficazes
no processo de detecção automática de atividade maliciosa, sendo que esses permanecem em
execução auxiliando no combate de ações de atividade maliciosa na rede UFBA, e contribuindo
com o CERT.Bahia, sendo que, somente nos dois primeiros meses que os honeypots foram postos em produção, aproximadamente 300 notificações de incidentes de segurança foram emitidas,
contribuindo ativamente no cenário de segurança da instituição.
3.3.2
CASO REAL
Dentre essas notificações o incidentes reais, destacamos a ocorrência de um caso que julgamos interessante, dado ao fato de onde originou-se o ataque. Pouco tempo depois dos honeypots
estarem em produção, a equipe de segurança recebeu uma notificação indicando um atividade
maliciosa proveniente de um endereço IP de um dos servidores da rede UFBA. A rede de servidores da UFBA é considerada por sua equipe de TI com sendo uma das redes mais seguras
da instituição, pois possui acesso administrativo restrito por uma equipe qualificada, servidores
seguindo diversas políticas de segurança, tais como atualizações rotineiras de segurança dos
sistemas operacionais e softwares de anti-vírus, dentre outros.
Entretanto, como nenhum sistema é perfeito e falhas humanas acontecem, um analista recém chegado à instituição, a fim de realizar testes em um solução de anti-virus, instalou um
servidor com o sistema operacional Windows Server 2008 R2 e por algum motivo não deu continuidade a configuração das políticas de segurança da UFBA, deixando o servidor com uma
instalação padrão, sem executar nenhuma atualização do sistema ou algum software de antivírus. Como o endereço atribuído a esse servidor permitia acesso à Internet e a todas as redes
da instituição, tornou-se um ponto crítico e potencialmente perigoso à rede.
Recebida a notificação, com este servidor era voltado apenas para testes e detectado ausência de sofwares de anti-vírus, este foi retirado preventivamente da rede e foi submetido a análise.
Instalou-se então um software de anti-vírus e anti-malwares, homologado pela instituição, e foi
executado um varredura completa sobre o sistema.
Concluída a varredura sobre o sistema, foram detectados a existência de 4 malwares, um
classificado pelo software com um vírus e três como spywares, conforme ilustrado na Figura
41
3.4. Realizado o procedimento de desinfecção do servidor, o responsável por este foi notificado
e solicitado que fosse efetuado todos procedimentos de segurança antes que esse servidor fosse
re-inserido na rede. Buscando entender e aprender sobre o funcionamento e a severidade dos
malwares detectados, constatamos que os spywares identificados não ofereciam risco potencial
para a rede, pois estes não possuem a características de deflagar sobre a rede (F-SECURE,
2011a). Como acessar à Internet via browser em um servidor não é algo tradicional, também
não ofereceria risco a este servidor, porém esses spywares em máquinas de usuários oferecem
risco de exposição de privacidade, pois apesar dos tracking cookies (cookies de rastreamento)
serem utilizados por alguns sites para apresentar ao visitante um conteúdo customizado, mas
em outros sites maliciosos podem ser potencialmente utilizados para monitorar a navegação do
usuário na Internet, assim representando um risco à privacidade.
Entretanto, o vírus/worm que foi detectado representava um sério nível de ameaça para o
sistema e a rede UFBA, sendo caracterizado como um programa ou conjunto de programas
que se escondem para subverter ou enganar mecanismos de segurança do computador, e em
seguida, permitir acesso a usuários remotos, de forma oculta, controle total do sistema do computador (F-SECURE, 2011b). Esse malware explora vulnerabilidades para se propagar através
da rede e poderia ter sido prevenido se correções de segurança do sistema operacional ouvessem
sido efetuadas (US-CERT/NIST, 2011), e poderiam já ter sido previamente detectado se algum
software de anti-vírus estivesse em execução.
Desta forma, neste caso real e prático, nossa solução mostrou-se bastante útil em uma etapa
do combate de atividade maliciosa dentro da rede UFBA, sendo que esse caso destacou-se dos
demais, pois conseguimos além de ter acesso detalhes do incidente, retiramos da rede um host
que poderia causar possíveis dados a rede da instituição.
42
Figura 3.4: Resultado do sofware de anti-vírus, detectando presença de malwares vírus e spywares
43
4
CONTENÇÃO DE ATIVIDADE
MALICIOSA EM REDES DE
CAMPUS
No capítulo 3 foi exibida a estrutura e principais características da rede UFBA, bem como
uma solução para detecção automática de atividade maliciosa na rede interna da instituição utilizando honeypots de baixa-interatividade. Neste capítulo, serão apresentados os detalhes que
norteiam a implementação de um sistema de contenção automatizada dos dispositivos identificados como possivelmente infectadas por malwares em rede de campus: em particular, um
estudo de caso realizado na rede UFBA, parte da proposta deste trabalho. Será mostrado que
esta solução de contenção automatizada será útil não somente para notificações originadas pela
solução proposta neste trabalho, mas para quaisquer outras que sejam direcionadas à instituição.
4.1
PRELIMINARES DA ETAPA DE CONTENÇÃO
Conforme demonstrado na Seção 3.2, após o processo de detecção de possível propagação de atividade maliciosa na rede, seja esta detecção por intermédio da solução proposta
nesse trabalho exibida no Capítulo 3 ou via algum grupo de segurança, como o CERT.Bahia
ou CAIS/RNP, uma ou mais notificações de incidentes de segurança são geradas e enviadas à
instituição.
Haja vista que o endereço IP não permite identificar unicamente a máquina geradora da
notificação, devida a comum distribuição de IP via DHCP, permitindo que múltiplas máquinas
em horários distintos, em um mesmo dia, possam assumir o mesmo endereço IP, o endereço
físico de uma máquina (mac addresss) é o único dado que permite identificar univocamente a
máquina na rede (SOCIETY, 2001).
Na UFBA, quando uma notificação de incidente de segurança é reportado, esta é encaminhada ao software TRAIRA que, como visto na Seção 2.5, é uma ferramenta desenvolvida pelo
44
CERT.Bahia, para o auxílio ao tratamento de incidentes de segurança. Esta ferramenta recebendo um conjunto de dados (demonstrados no Capítulo 3), após o processamento, retorna para
equipe de TI da UFBA o endereço MAC da máquina geradora do incidente de segurança. De
posse do endereço MAC o procedimento de contenção pode ser inicializado.
A partir desse momento, de posse do endereço MAC, como será demonstrado no decorrer desse
capítulo, propomos uma solução de contenção automatiza como um módulo do TRAIRA, tendo
o objetivo de alcançar os seguintes resultados:
• Minimização do tempo de exposição das máquinas possivelmente infectadas na rede:
com o objetivo de impedir a continuidade da propagação de atividade maliciosa sobre os
demais dispositivos e recursos da rede. Na contenção manual (detalhada mais à frente
nesse mesmo capítulo), existe um intervalo de tempo, por menor que seja, até que os
responsáveis realizem os procedimentos de contenção de todas as máquinas notificadas;
• Redução de custos da instituição: o procedimento manual de contenção requer mãode-obra de pessoas da instituição que são naturalmente remuneradas para isso, sendo
eventualmente contratadas para este ofício ou desviadas de outras atividades para tal. Se
em um dado período, o número de ocorrências de incidentes for alta, o número de pessoas alocadas para se dedicar as atividades de contenção aumenta, elevando diretamente
esses custos. Como exemplo, citamos o que ocorreu em 2009, na propagação da ação do
Conficker na UFBA, onde eram alocados pelo menos, um analista de segurança e dois
técnicos para conter a propagação desse malware; por vezes, ao longo de diversas horas
por dia, segundo informações internas do CPD/UFBA;
• Redução das ocorrências de erros: nas etapas do procedimento de contenção manual
podem ocorrer falhas humunas. Dentre outras possíveis, destacamos o bloqueio de dispositivos incorretos. Como por exemplo, a simples troca de um caractere por outro do
endereço MAC pode causar transtorno, retirando da rede um dispositivo “saudável” e
mantendo na rede uma máquina infectada; sendo este não apenas um, mas dois erros.
• Colaborar com o desenvolvimento do CERT.Bahia: através do desenvolvimento de
um módulo para o TRAIRA, o módulo de contenção, permitimos que essa ferramenta
complete o ciclo do tratamento de incidentes de segurança representado pela Figura 2.1,
auxiliando no combate automatizado dos incidentes de segurança;
45
4.2
ESCOLHENDO A ESTRATÉGIA DE CONTENÇÃO
Alguns tipos de incidentes de segurança, quando detectados, antes que a propagação deste
incidente leve ao esgotamento dos recursos computacionais disponíveis ou aumentem os níveis
de danos (como ocorre na propagação de vírus/worm) é importante que seja realizado alguma
estratégia de contenção.
A escolha da estratégia de contenção adotada pode variar de acordo com o tipo de incidente: a estratégia usada para contenção de propagação de vírus é bem diferente da adotada
para ataques de negação de serviço (DoS) ou envio de spam.
Em (SCARFONE; GRANCE; MASONE, 2008), diversas estratégias específicas são fornecidas de acordo com os variados tipos de incidentes, porém de forma bastante genérica. Todavia, este recomenda que instituições criem suas próprias estratégias de contenção, de acordo
com suas próprias particularidades. Essas estratégias devem ser documentados de forma bastante clara, a fim de tornar rápida e eficaz a tomada de decisão. Alguns critérios sugeridos por
(SCARFONE; GRANCE; MASONE, 2008) para definir as estrátégias são:
• Analisar o risco potencial de danos ou roubo das informações;
• Avaliar a necessidade de preservação de evidências;
• Disponibilidade do serviço (conectividade de rede, serviços prestados a comunidade externa);
• Tempo e recursos necessários para implementar a estratégia
• Eficácia da estratégia (abordar parcialmente ou totalmente o tratamento do incidente);
• Duração da solução adotada (solução de emergência para ser removido em algumas horas,
semanas ou permanente);
Em alguns casos, as instituições decidem propositalmente demorar em executar a etapa de
contenção de um incidente para que seja possível monitorar a atividade atacante, geralmente
para recolher evidencias adicionais. Esse tipo de situação deve ser executada com bastante cautela e acordo entre os membros da equipe de TI, pois uma vez ciente do incidente, a instituição
se compromete com os riscos que podem ser ocasionados. Suponha um sistema comprometido
que está sendo utilizado para atacar a rede de um outra instituição. A estratégia em atrasar a
contenção pode ser perigosa, pois a depender do nível de comprometimento, o atacante pode
46
levar a rede a outra (ou a sua própria) indisponível em fração de minutos. Portanto, é necessário
avaliar minuciosamente a relação de aprendizado versus risco oferecido.
Todavia, alguns tipos de ataque podem causar danos colaterais por terem sido contidos.
Uma máquina comprometida pode executar um processo malicioso que efetua pings para outra
máquina periodicamente (um controlador de botnet, por exemplo). Uma vez que essa máquina
comprometida seja detectada e seja isolada (contida), os pings seguintes falharão. O resultado
dessa falha pode levar ao processo malicioso a destruir todas evidências do disco rígido do hospedeiro e em seguida se auto-destruir. Assim, em casos que evidências precisem ser preservadas
deve-se ter um cuidado adicional nesse sentido.
A seguir, serão demonstradas algumas estratégias de contenção de máquinas compremetidas por malwares, avaliadas na rede de campus da UFBA, mas que pode ser adaptável ao
contexto de outras instituições acadêmicas.
4.3
CONTENÇÃO NO ROTEADOR
A abordagem de efetuar contenção da máquina comprometida no roteador da rede da instituição consiste em criar e adicionar em alguma regra, conhecidas como Listas de Controle de
Acesso (ACL), o endereço MAC desta máquina a fim de que este dispositivo perca total acesso
à rede, consequentemente realizando à contenção da atividade maliciosa.
As ACLs realizam decisões de filtragem de pacotes e encaminhamento de tráfego que passam
no equipamento. Cada pacote que chega em uma porta ou VLAN é inspecionado com as regras
da ACL, liberando ou não o tráfego (NETWORKS, 2011). A depender do equipamento, as
ACLs podem efetuar mais que encaminhar ou descartar pacotes. Podem também realizar outras operações, tais como, incremento de contadores, registrar cabeçalhos dos pacotes, espelhar
tráfego de uma porta em outra, aplicar QoS, dentre outros.
Todavia, essa abordagem apesar de resolver de certa forma o problema, não impede que
essa máquina continue propagando o incidente para seu segmento de rede, enquanto ela tiver
um IP atribuído. Tipicamente, enquanto essa máquina estiver com lease DHCP não expirado,
ela pode continuar causando problemas ao continuar propagando atividade maliciosa para seu
segmento de rede durante um período indefinido de tempo. Porém com essa concessão é temporária em algum momento ela irá expirar. Antes da concessão expirar, o servidor DHCP deve
renovar a concessão para o cliente ou o cliente deve obter uma nova concessão, entretanto como
máquina estará bloqueada, não conseguirá se comunicar com o servidor DHCP, garantindo seu
isolamento. Similarmente, quando essa máquina for desligada, e posteriormente ligada, ao ten-
47
Figura 4.1: Mensagem de conectividade nula ou limitada no Microsoft Windows XP
tar obter um IP do servidor DHCP, ela não irá conseguir.
Um outro caso que pode ocorrer é um usuário com um pouco de conhecimento, poderá
configurar um endereço IP manualmente, e continuar acessando o segmento de rede, por consequência propagando atividade maliciosa naquele segmento. Contudo, nesse casso, como os
usuários estão cada vez mais dependentes de trabalhar conectados na Internet, é possível que
esses casos sejam cada vez mais raros, porém possíveis.
Um fator que não pode ser desprezado nessa estratégia, é o nível de informação do usuário
quanto ao estado de sua máquina. Uma vez que o endereço MAC está bloqueado no roteador, em
algum momento, o usuário perceberá que não está acessando a rede mas não saberá o motivo
pelo qual ele não consegue acesso, recebendo apenas alertas do sistema, como no Microsoft
Windows, de conexão nula ou limitada, conforme Figura 4.1. Esse tipo de mensagem não
permite ao usuário saber que ele foi bloqueado, podendo ser um cabo de rede danificado ou
defeito na interface de rede. Idealmente, uma vez bloqueado, o usuário deveria ser notificado
de alguma forma, de quando e porque foi bloqueado, bem como o que fazer a partir desse
momento para resolver o problema de sua máquina; porém isso não é possível nesta solução.
Um outro ponto a ser considerado, é que a única informação que se tem da máquina infectada é o endereço MAC e a rede da unidade, correspondente a uma faculdade ou instituto, por
exemplo. Assim, para a equipe de TI possa realizar o processo de reparo do sistema comprometido ou infectado, há uma certa dificuldade de localizar a máquina no prédio, pois além de
haver uma grande quantidade de setores e máquinas distribuídas por diversos andares, o endereço MAC não é algo trivial em ser detectado, dependendo disposição do técnico em encontrar a
máquina ou então, esperar o usuário reclamar da dificuldade de acesso à rede e assim, informar
sua localização física.
Portanto, como vimos, essa abordagem é de certa maneira funcional, porém não completamente eficiente e alguns aspectos. Todavia, devido a limitações dos recursos da rede da instituição, como é o caso da rede UFBA, essa é por vezes, a única solução disponível, até que novos
48
Figura 4.2: Conexão dos switches da rede UFBA
equipamentos sejam adquiridos, e possuam um melhor suporte recursos de segurança.
4.4
CONTENÇÃO NO SWITCH
Uma outra estratégia analisada para contenção de máquinas que estejam realizando propagação de atividade maliciosa, no contexto da rede de campus da UFBA, foi realizaros bloqueios
no nível dos switches.
Como vimos na seção 3.1, a rede UFBA tem uma topologia em anel, tendo como pontos centrais três roteadores. Conectado diretamente a eles têm-se diversos switches, sendo um switch
principal (chamado também de switch de borda) por unidade da instituição, predominantemente
conectados ao roteador por fibra ótica. Os demais switches de cada unidade são conectados ao
switch principal, alguns diretamente, outros inter-conectados, formando uma estrutura tradicionalmente conhecida por cascateamento. Essa estrutura é ilustrada pela Figura 4.2.
Na rede UFBA, as máquinas podem estar conectadas em qualquer um desses switches, in-
49
clusive no principal, desde que este tenha uma porta livre e disponível1 .
Idealmente, seria desejável que a contenção fosse realizada no switch na qual a máquina
está conectada, pois a contenção seria o mais próximo possível do dispositivo infectado, e o que
ocorre no bloqueio no roteador (propagação temporária de atividade maliciosa no segmento de
rede) não correria nessa solução, porque ele seria bloqueado na porta ao qual está conectado,
sendo retirado instantaneamente da rede.
Entretanto, a rede UFBA, assim como muitas outras rede acadêmicas, se expandiu ao longo
de diversos anos, e os equipamentos foram adquiridos em épocas diferentes e consequentemente
com diferentes características e funcionalidades, em particular, no que diz respeito a requisitos
voltados a área de segurança. Na rede da instituição é possível encontrar switches gerenciáveis,
switches não gerenciáveis (muitas das vezes adquiridos e conectados a rede por usuários finais,
sem o conhecimento prévio e autorização do CPD/UFBA), hubs, roteadores sem-fio, dentre
outros. Além de uma diversidade de fabricantes, como visto na seção 3.1, cada desde equipamentos mesmo sendo de um única fabricante, apresentam uma ampla diversidade de modelos;
e ainda, mesmo fabricante e modelos idênticos, contudo com versões de software e licenças
diferentes, ocasionando o suporte de diversas funcionalidades.
Dentro deste contexto de grande diversidade de fabricantes, modelos e versões, buscamos
por funcionalidades nos equipamentos que fossem desejáveis encontrar em todos os switches
da rede, objetivando aplicar uma solução uniforme, eficaz e eficiente das atividades maliciosas;
realizando não somente a contenção dos dispositivos infectados, mas também a notificação e
eventual identificação do possível usuário da máquina comprometida.
Contudo, como não foi possível, diante de tamanha diversidade encontrar o mínimo de uniformidade das funcionalidades, então buscamos examinar o que era relacionado à segurança
(que pudesse ser associado à contenção) nos equipamentos, a fim de que as futuras aquisições de equipamentos, essas possam fornecer auxílio na escritas das especificações de compra.
Encontramos em alguns deles a funcionalidade de ACL, como funcionamento similar ao dos
roteadores, seguindo naturalmente a sintaxe do fabricante. Todavia, uma funcionalidade encontrada, bastante interessante, que permite identificar o usuário, associando-o ao endereço MAC
da notificação, descrita na sub-seção seguinte.
1 Alguns
tipos de equipamentos possuem portas livres, porém não estão disponíveis por serem utilizadas como
ligação lógica XOR. Por exemplo, o switch pode ter 2 portas 24, uma para cobre e outra para fibra ótica, sendo
essas XOR: ou se utiliza uma ou outra, cobre ou fibra.
50
4.4.1
IDENTITY MANAGEMENT COM KERBEROS SNOOPING
Identity Management ou Gerenciamento de Identidade é uma funcionalidade que permite
efetuar a identificação de usuários e dos dispositivos conectados a um switch (NETWORKS,
2011). Essas informações são armazenadas em um banco de dados local no switch, e pode
então ser visualizado por usuários pertencentes ao grupo dos administradores do equipamento
ou através de algum software de monitoramento, onde essas informações podem ser coletadas
via SNMP.
O gerenciamento de identidade coleta essas informações baseadas em atributos capturados
dos pacotes que passam pelo equipamento. A quantidade de atributos que podem ser capturados,
depende dos protocolos que trafegam na rede, conforme a Tabela 4.4.1 à seguir:
Atributo
NetLogin LLDP
Identidade do usuário
x
x
Porta do usuário
x
x
Endereço MAC do dispositivo
x
x
VLAN
x
Protocolo autenticação NetLogin
x
Falhas na autenticação
x
Associação entre MAC e IP
FDB IP-Security Kerberos Snooping
x
x
x
x
x
x
x
Tabela 4.1: Tabela de atributos que podem ser capturados versus protocolo - adaptado de
(NETWORKS, 2011)
A autenticação Kerberos é usado pelo Active Directory da Microsoft, e por vários sistemas
UNIX, como o Linux e Mac OSX (NETWORKS, 2011). Dada a quantidade de informações
que podem ser obtidas a partir desse protocolo, e devido a integração com o Active Directory
(base de autenticação de usuários utilizados pela UFBA) decidimos fazer um piloto com este
protocolo.
O Kerberos é um protocolo de autenticação de rede, projetado para fornecer autenticação segura para aplicações do modelo cliente / servidor usando criptografia de chave secreta,
sendo projetado sobre plataforma livre, porém muito utilizados por muitas aplicações comerciais (MIT, 1993).
O recurso Kerberos Snooping é uma solução proprietária, provido pela Extreme Networks2 e
coleta informações de identidade a partir de pacotes Kerberos que trafegam pelo switch, quando
essa funcionalidade está ativada.
2 http://www.extremenetworks.com/
51
Com apoio do CPD/UFBA, conseguimos um switch Extreme, modelo X150 com software
atualizado em sua última versão disponível; e nos foi dado emprestado pelo período de 15 dias,
para ser utilizado e realizado experimentos nas instalações do próprio CPD.
CONHECENDO E TESTANDO A FUNCIONALIDADE
De posse do equipamento e após realização um estudo de como testar a funcionalidade,
criamos inicialmente um pequeno piloto que consistiu em basicamente em:
• Colocar o switch em uma das VLANs da UFBA (escolhida aleatoriamente);
• Habilitar e configurar a funcionalidade de Identity Management;
• Utilizar uma máquina com Windows para se autenticar no domínio UFBA e colocamos
este em uma porta do switch;
• Usar uma outra máquina com GNU/Linux (fora do domínio) e colocamos este em uma
porta do switch;
Montado o laboratório, ligamos nossos computadores configurados para o teste que inicializaram normalmente. Logamos em ambas as máquinas uma no domínio e outra fora do domínio,
e todo ocorreu de forma transparente.
Acessando o switch para verificar as informações coletadas, observamos os dados exibidos
pela Figura 4.3. Esse resultado, apesar de ser proveniente de um experimento relativamente simples, demonstra uma grande possibilidade de uso. No mínimo, obtivemos duas funcionalidades
bastante desejáveis ao combate da atividade maliciosa nas redes de campus, à saber:
1. Associar o username ao endereço MAC e o endereço IP; para máquinas dentro do domínio
UFBA;
2. Identificar a porta física que um dispositivo está conectado, tanto para máquinas dentro e
fora do domínio;
Para ter acesso a rede UFBA e assim obter um username, o usuário teve que ter preenchido
um formulário, no qual consta algumas informações sobre o mesmo, como matrícula (de servidor ou aluno), telefone de contato e e-mail. Ou seja, pode-se facilmente correlacionar essas
52
Figura 4.3: Resultado da piloto utilizando Identity Management com Kerberos Snooping
informações do cadastro com os dados coletados pela funcionalidade assim como como o endereço IP e MAC da notificação, emitindo assim algum tipo de notificação ao usuário informando
que sua máquina gerou um incidente de segurança, e a mesma será bloqueada por questões de
segurança e pelo benefício comum. Ainda, como essa funcionalidade, sabendo a porta física
que o dispositivo está conectado, o bloqueio pode ser feito de maneira bastante preciso, exatamente na porta que o usuário está conectado. Para os casos de máquina fora do domínio, não
será possível identificar o usuário, mas mesmo assim, o bloqueio na porta pode ser feito da
mesma maneira.
Algo que pode representar um problema em efetuar o bloqueio exatamente na porta em que
o dispositivo está conectado, é que esse pode efetuar a troca de ponto de rede facilmente, seja
dentro de sua sala ou se ele tiver acesso ao switch em seu prédio. Portanto, essa abordagem,
apesar de ser possível, deve ser analisada cuidadosamente.
EXPERIMENTO NA REDE DE ESTAÇÕES DO CPD/UFBA
Para que nosso experimento pudesse ter resultados mais próximos de um ambiente de produção real, propomos ao CPD/UFBA realizar um experimento em toda rede de estações do
CPD; uma vez que essa unidade possui, de maneira aproximada, mais de 100 usuários.
53
O número de switches e portas físicas que conectam as estações do CPD é muito superior
ao número de portas disponíveis em nosso switch de teste (48 portas - 100M + 2 portas 1000M
Fibra Ótica ou 2 portas 1000M Par Trançado 3 )). Então propomos a solução ilustrada na Figura
4.4.
Figura 4.4: Experimento na rede de estações do CPD/UFBA - Id entity Management com Kerberos Snooping
Está solução prezou em não trazer prejuízo ao desempenho da rede dos usuários, e pudesse
ser inserida (e posteriormente removida) de maneira rápida na rede.
Desta forma, como existem mais de uma VLAN nos switches do CPD, configuramos as 2
portas Gigabit Ethernet em todas as VLANs existentes no CPD, e a ligação anteriormente
do switch principal (na Figura 4.4 o switch A) com o Core da UFBA foi desviada para nosso
switch. Assim, uma interface de nosso switch se conectava ao Core e a outra ao switch principal,
possibilitando todo tráfego passar por ele. Esse procedimento foi realizado seguindo todas as
recomendações e políticas do CPD/UFBA, e para não gerar indisponibilidade para os usuários,
foi realizada fora do horário de expediente.
Mantivemos o equipamento ativo na rede pelo período de uma semana, e os resultado são
apresentados no Apêndice A. Neste resultado, podemos observar que pouco mais de 50% das
3 Portas
XOR
54
máquinas estão no domínio UFBA. Nesse caso em particular, observamos que muitos dispositivos identificadas como fora do domínio,representam máquina rodando alguma distribuição
baseada em UNIX ou eram algum switch gerenciável. Observa-se nesse resultado que todos
foram identificados na porta 49, o que é facilmente justificado pelo formato do nosso experimento.
Apesar da solução ser proprietária e representar certa desvantagem, contudo, o protocolo
Kerberos é aberto e livre, podendo ser implementada de forma similar por outros fabricantes.
Através do CPD/UFBA, contactamos dois fabricantes (não citados nesse trabalho, porque não
tivemos autorização destes) por telefone, perguntando por funcionalidade igual ou equivalente
nos seus produtos. Em ambos os casos foi informado posteriormente, que eles não possuem
e justificam que seus clientes ainda não haviam sentido a necessidade de característica semelhante, mas que nosso questionamento foi registrado como sugestão.
Concluímos que essa funcionalidade pode ser bastante útil para auxiliar as instituições que
tenham interesse em combater de forma eficiente as atividades maliciosas em sua rede, possibilitando o correlacionamento das informações e a identificação dos usuários. Acreditamos
ainda, que cabe as instituições de ensino e pesquisa, como a UFBA e outras de grande porte, que
adquirem muitos equipamentos, sugerir ou exigir em seus editais licitatórios que os fabricantes
disponibilizem em seus produtos funcionalidade semelhante, haja visto o valor agregado para
instituição.
4.5
CONTENÇÃO MANUAL DE ATIVIDADE MALICIOSA
NA REDE UFBA
O processo de contenção manual de atividade maliciosa na UFBA dá-se início após o recebimento da notificação da ocorrência do incidente de segurança. Recebida a notificação, ela
é encaminhada ao TRAIRA, que efetua os devidos tratamentos e retorna um email destinado a
equipe TI contendo: o endereço IP, endereço MAC e a VLAN, conforme citado anteriormente
na Seção 3.2).
As atividades da equipe de TI da UFBA são bem definidas e divididas, e ficou a cargo da
equipe de operação (parte da equipe de TI) realizar o procedimento de contenção manual dos
incidentes. Essa equipe contém aproximadamente por 10 pessoas, dividida em dois turnos (manhã e tarde), sendo composta por funcionários da UFBA e terceirizados que realizam diversas
atividades no CPD/UFBA, dentre outras:
55
• Controle e manutenção da temperatura do sistema de ar-condicionado do datacenter e
das instalações do CPD;
• Gerenciamento dos níveis do tonner, cartuchos, e papel, bem como das próprias impressoras;
• Troca periódica das fitas de backup dos servidores, assim como o armazenamento e organização dessas em cofre seguro no datacenter;
• Monitoramento dos ativos da rede, como servidores e equipamentos, alertando os respectivos responsáveis por indisponibilidade, o problemas de espaço em disco ou link
saturado, etc;
Mais especificamente, 4 operadores realizam de segunda à sábado realizam a contenção
nos roteadores da instituição, podendo a depender do volume de notificações ter apoio de um
ou dois bolsistas, que realizam algumas atividades como parte da equipe de TI.
Como vimos anteriormente, a estratégia de realizar o bloqueio nos roteadores é em dado
momento eficaz, e detém a propagação da atividade maliciosa; contudo não permite o usuário
saber que sua máquina foi bloqueada. Na UFBA, o processo de contenção é feita nos roteadores,
como alternativa viável para instituição bloquear os endereços MAC notificados. Seria desejável
realizar o bloqueio mais próximo possível (nos switches) das máquinas infectadas, mas essa
decisão foi escolhida fundamentalmente por:
• Ausência de recursos de segurança que possibilitem o tratamento de incidentes de segurança de maneira eficiente e eficaz, devido a diversidade de fabricantes, modelos, versões
e funcionalidade, contando com relativa presença de equipamentos não-gerenciáveis espalhados pela rede;
• Contenção nos roteadores permite que procedimentos sejam executados de maneira uniforme e centraliza em regiões (conforme seção 3.1) realizada em equipamentos robustos
de mesmo fabricante, possibilitando o uso das mesma funcionalidades, em particular a
criação de ACLs sobre as interfaces do roteador, que na UFBA representam de maneira
geral, uma para cada unidade da instituição;
Desda forma, o operador ao receber a notificação observa a VLAN onde a máquina foi
identificada, e sabendo ele onde essa VLAN é roteada, a acessa o respectivo equipamento: Se a
ACL não existe para aquela unidade ele criará uma nova e aplicará a respectiva interface, senão
56
adicionará a ACL já existente uma nova entrada, contendo o endereço MAC notificado. A ACL
é composta basicamente por 4 partes:
1. Nome da ACL: normalmente criadas com as iniciais do nome da unidade, por exemplo,
LET para Letras, BIO para Biologia, ARQ para Arquitetura, entre outros;
2. Sequência de entradas: cada entrada representa um dispositivo onde foi aplicada a contenção. No início de cada entrada temos um número, que representa apenas a posição
na sequência, que deve ser menor que o delimitador (explicado à seguir). Em seguida,
têm-se a possibilidade de negar (deny) ou permir (allow) um dispositivo (host) colocando
seu endereço MAC logo após ou todos (any). E por fim, o tipo de protocolo de origem
seguido pelo de destino.
3. Delimitador da ACL: similar a sequência anterior, como a diferença que o número deste
representa a quantidade máxima de possíveis bloqueios ou permissões, e seguido pela
regra que será aplicada a qualquer outro endereço MAC na contido na sequência anterior;
4. Quantidade de pacotes filtrados: única entrada dinâmica da ACL, que indica a quantidade pacotes que passaram por alguma regra menor que a do delimitador da sequência;
Figura 4.5: ACL criada em um roteador da rede UFBA para a faculdade de Letras
Para ilustrar, vejamos a Figura 4.5 e 4.6, exemplos de ACL real para unidade de UFBA e
ACLs associadas a interfaces, respectivamente.
57
Assim, uma nova notificação para a faculdade de Letras, um operador acessaria o roteador
de Ondina, que efetua o roteamento dessa rede, acessaria a ACL e observaria um número disponível na sequência menor que 50 (número máximo nesta ACL), 4 por exemplo, e bloquearia
o tráfego do dispositivo de qualquer protocolo de origem, para qualquer protocolo de destino.
Esse procedimento de contenção apesar de ser relativamente simples, está sujeito a algumas
falhas, dentre as quais destacamos:
• Troca de caractere no endereço MAC : Como o modelo de notificação dos grupos de
segurança seguem o modelo do (CERT.BR, 2006), o formato do endereço MAC4 vem
em seis grupos de dois caracteres hexadecimais e deve ser convertido pelo operador para
o formato de três grupos de quatro dígitos hexadecimais separados por pontos (formato
adotado pelo fabricante do roteador da UFBA). Assim, eventuais trocas de caracteres
podem ocorrer, retirando a rede um dispositivo não notificado e mantendo na rede um
dispositivo infectado (ou seja, ocorrência de dois erros);
• Contenção em ACL inativa: uma ACL só tem validade, depois de criada, quando está
associada a alguma interface. Se ela apenas for criada, e um conjunto de endereços MAC
tiver sido inserido, todas esses bloqueios estarão inativos. Assim, um operador pode criar
uma ACL e por algum descuido, não associar a alguma interface; posteriormente ele
mesmo ou outro operador pode adicionar entradas nesta ACL e todas essas sendo inúteis,
do ponto de vista de contenção. A Figura 4.6 exemplifica ACLs associadas interfaces do
roteador.
• Contenção em ACL incorreta: efetuar a contenção utilizando ACL associada a uma interface (que representa uma unidade) permite bloquear um dispositivo naquele segmento
de rede da instituição. Desta forma, se um operador adicionar um endereço MAC em
uma ACL diferente da correspondente a informada na notificação, aquele dispositivo estará bloqueado em um segmento de rede diferente do qual ele pertence, assim sendo, a
contenção não foi eficaz. Como exemplo, uma notificação chega para uma máquina do
PAF3, e o operador efetua o bloqueia na ACL correspondente ao PAF;
Posteriormente, quando o incidente for tratado (execução de anti-vírus e anti-spyware,
reinstação do sistema operacional, etc) o operador será notificado e então o endereço
4O
endereço MAC tem seu formato padrão definido por (IEEE, 1990) para os endereços físicos podendo ser
no formato de seis grupos de dois caracteres hexadecimais, separados por hífens “-” ou dois pontos “:”, como
exemplo, ab-cd-ef-01-02-06 ou ab:cd:ef:01:02:06. É possível usar outra convenção, utilizada por alguns equipamentos de rede que utiliza três grupos de quatro dígitos hexadecimais separados por pontos “.”, como por exemplo,
abcd.ef01.0206;
58
MAC será removido da ACL. Por isso, em nossa ilustração da Figura 4.5 há intervalos e
os números não são contínuos.
Figura 4.6: ACLs aplicadas sobre interfaces do roteador
4.6
CONTENÇÃO AUTOMATIZADA DE ATIVIDADE MALICIOSA NA REDE UFBA
Para equacionar o problema da propagação de atividade maliciosa na rede, estratégias de
contenção devem ser escolhidas e executadas de acordo com a as particularidades da instituição
(SCARFONE; GRANCE; MASONE, 2008). Como abordado na seção 4.6.1, a UFBA, através
de seus operadores e eventualmente bolsistas, efetua a contenção dos dispositivos no roteador
mais próximo da unidade onde a máquina foi notificada.
Propomos nessa seção nossa solução de contenção automatizada de atividade maliciosa na
rede de campus da UFBA. Para isso, inicialmente, desenvolvemos alguns scripts que possibilitavam a contenção semi-automatizada. Em seguida, tornamos o processo totalmente automatizado, através do desenvolvimento o módulo de contenção para o TRAIRA, concluindo com
este a proposta desse trabalho.
4.6.1
SEMI-AUTOMATIZANDO A CONTENÇÃO DA ATIVIDADE MALICIOSA NA REDE UFBA
Conhecida a estratégia de contenção da UFBA efetuada em seus roteadores, e os processos
envolvidos na contenção manual executados por parte de sua equipe, e as possíveis falhas associadas a esse processo, decidimos desenvolver um script que automatizasse o procedimento
59
contenção. A contenção é chamada nessa seção de semi-automatizada, pelo fato dele ainda
ser executado manualmente (na seção seguinte, isso foi resolvido com o desenvolvimento do
módulo do TRAIRA), recebendo alguns parâmetros para que ele possa realizar o bloqueio do
endereço MAC. Entretanto, posto em execução com as respectivas entradas, o script realiza todo
o procedimento de bloqueio automaticamente.
Antes de dar início ao desenvolvimento do script, nos foi concedido acesso a cada um dos
roteadores, onde foi verificado se a sintaxe de comandos era similar entre eles; mesmo sabendo
que o fabricante, modelo e software desses roteadores eram iguais, poderia existir versões do
software diferente, tradicionalmente oferecendo mudanças na sintaxe dos comandos. Foi constatado que as versões dos softwares eram iguais, todavia, apresentavam pequenas mudanças na
sintaxe. Com autorização do CPD/UFBA, ajustamos as configurações do software, de tal forma
que os equipamentos ficassem idênticos, permitindo que o código a ser desenvolvido fosse único
para todos os equipamentos, indicando apenas em alguma parte do script sobre qual roteador
ele seria executado.
Escolhemos a linguagem Shell Script, para escrever o código, pelo mesmo motivo apresentado na Seção 3.2: familiaridade com esta linguagem e a natividade desta nos sistemas Unix,
e ainda, a relativa facilidade do script interagir com os aplicativos do sistema. O Shell Script,
assim como outras linguagens mais tradicionais de programação (Perl, C, Java, por exemplo)
podem ser utilizados no núcleo do código, para compor sua lógica, todavia teriam a limitação de executar comandos nos equipamentos, obedecendo as sintaxes definidas pelo fabricante,
e principalmente fazer a interação com eles, dependendo possivelmente de alguma biblioteca
proprietária, se disponível.
Para resolver essa questão, quando era necessário realizar interação com os equipamentos,
utilizamos o Expect5 , que é uma ferramenta opensource utilizada para automatizar aplicações
interativas, tais como Telnet, FTP, passwd, fsck, rlogin, SSH, e outros (LIBES, 1991). Com essa
ferramenta, foi possível estabelecer e interagir em sessões Telnet ou SSH, comumente utilizadas
para acessar servidores e equipamentos gerenciáveis, como o caso dos roteadores. A Listagem
4.1, demonstra uma pequeno código escrito em Expect, que acessa um equipamento via Telnet,
executa um comando, e em seguida finaliza a sessão.
5 http://www.nist.gov/el/msid/expect.cfm
60
Listagem 4.1: Código escrito em Expect - inicia uma sessão Telnet, envia um comando e finaliza
a sessão
# Variaveis previamente valoradas :
# $ r e m o t e _ s e r v e r , $ m y _ u s e r _ i d , $my_password , e $my_command
# Abre uma s e s s a o T e l n e t com s e r v i d o r remoto , e e s p e r a
# o u s u a r i o no p r o m p t .
spawn t e l n e t $ r e m o t e _ s e r v e r
e x p e c t " username : "
# E n v i a o username , e a g u a r d a a s e n h a no p r o m p t .
send " $my_user_id \ r "
expect " password : "
# E n v i a a senha , e e s p e r a no p r o m p t de comandos
s e n d " $my_password \ r "
e x p e c t "%"
# E n v i a uma comando , p r e v i a m e n t e d e f i n i d o
# e e s p e r a no p r o m p t de comandos
s e n d " $my_command \ r "
e x p e c t "%"
# Finaliza sessao Telnet , e espera pelo caracter especial
# de f i m de a r q u i v o
send " e x i t \ r "
expect eof
Resolvidas as questões de equivalência de sintaxe, conhecendo os equipamentos e as etapas
de contenção manual, foi escrito o script, composto adicionalmente por cinco scripts: três em
Expect e dois em Shell Script. Os códigos adicionais poderiam ter sidos mantidos no código
principal, com funções por exemplo, entretanto como esses códigos podem ser executados e
trazer resultados de forma independente do código principal, decidimos mantê-los separados.
À seguir, descreveremos de maneira geral cada um deles, seguido da exibição do principal
na listagem 4.2
• posicao_bloqueio.sh : desenvolvido em Shell Script, recebe por parâmetro um bloco de
texto, contendo uma determinada ACL. Esse código percorrerá a ACL para tentar encontrar o primeiro primeira posição disponível na sequência, para retorná-lo como sendo a
posição em que deve ser realizado a contenção na ACL.
61
• cria_acl.sh : quando não houver uma ACL para se adicionar um dado endereço MAC
para efetuar a contenção, esse script cria uma ACL e em seguida já realiza o bloqueio.
Este, recebe por parâmetro o nome do equipamento, o nome da ACL, o endereço MAC
e uma interface do roteador. Com esses dados, ele acessa via Expect o roteador, cria a
ACL com o nome recebido, efetua a contenção na primeira posição, já que a não existia
e consequentemente está vazia. Por fim, associa a recém-criada ACL a uma interface do
roteador, para que essa tenha o efeito desejado de contenção e não torne a ACL inativa,
como visto na Seção ;
• bloqueia_mac.sh : esse script efetua o bloqueio automaticamente de um endereço MAC.
Para isso, ele recebe o nome do equipamento onde deve ser feito o bloqueio, a ACL
correspondente a contenção, o endereço MAC fornecido e a posição na sequência da ACL
a ser adicionada. Assim, quando executado, o código em Expect efetua a contenção;
• conversor_formato_macaddress.sh : após a execução do TRAIRA, é fornecido o endereço MAC no formato mais comum, seis grupos de dois dígitos em hexadecimal, separados por dois pontos “ :” ou hifens “-” (por exemplo, aa:bb:cc:dd:ee:ff ou aa-bb-ccdd-ee-ff). Esse script, escrito em Shell Script, converte o formato do endereço MAC de
entrada, passado por parâmetro, para o formato aceito por alguns equipamentos de rede,
que são três grupos de dígitos em hexadecimal separados por pontos “.” (por exempo
aabb.ccdd.eeff), como o caso do roteador da UFBA;
• show_access_list.sh : esse script, escrito em Expect, recebe por o nome do roteador
e unidade da UFBA que deve ser realizado o futuro bloqueio, e retorna a ACL e suas
respectivas entradas. Se a ACL ainda não existe, consequentemente retornará a ACL com
inexistente e vazia. Como há um processo de interação com o roteador até o momento
de exibir a ACL, e posteriormente, interagir até efetuar o logoff, o script retorna em texto
todas as etapas, similar a uma interação manual que tem os dados impressos em tela;
Listagem 4.2: Código principal de contenção
# ! / bin / bash
# V a r i a v e i s p a s s a d a s p o r p a r a m e t r o ao s c r i p t
m a c a d d r e s s =$1
a c l _ d e s t i n o =$2
62
e q u i p a m e n t o =$3
i n t e r f a c e =$4
# Executa o s c r i p t " conversor_formato_macaddress . sh " ( S h e l l )
# a f i m de c o n v e r t e r o f o r m a t o do e n d e r e c o MAC
# ( aa . bb . c c . dd . e e . f f ou aa−bb−cc−dd−ee− f f ) da
# n o t i f i c a c a o , no f o r m a t o a c e i t o p e l o r o t e a d o r da UFBA
# ( aabb . c c d d . e e f f )
macaddress = ‘ . / c o n v e r s o r _ f o r m a t o _ m a c a d d r e s s . sh $macaddress ‘
# Executa o s c r i p t " s h o w _ a c c e s s _ l i s t . sh " ( Expect ) para e x i b i r
# a ACL p a s s a d a como p a r a m e t r o e s u a s e n t r a d a s , e armazena a
# s a i d a da e x e c u c a o no a r q u i v o t e x t o " s a i d a _ c o m p l e t a . t x t "
. / s h o w _ a c c e s s _ l i s t . sh $equipamento $ a c l _ d e s t i n o
>
saida_completa . txt
# F i l t r a do a r q u i v o de t e x t o " s a i d a _ c o m p l e t a . t x t " s o m e n t e o
bloco
# de t e x t o que c o n t e m a ACL e t o d a s s u a s e n t r a d a s armazendo em
# " b l o c o _ a c l . t x t " d e s p r e z a n d o t o d o t e x t o g e r a d o do l o g i n a t e a
# e x i b i c a o da ACL e o t e x t o pos−ACL a t e o l o g o u t
i n i c i o _ b l o c o = ‘ g r e p −n e x t e n d e d s a i d a _ c o m p l e t a . t x t | c u t −d : −f1
‘
f i m _ b l o c o = ‘ g r e p −n " \ b p e r m i t any any \ b " s a i d a _ c o m p l e t a . t x t |
c u t −d : −f1 ‘
awk "NR >= $ i n i c i o _ b l o c o && NR <= $ f i m _ b l o c o " s a i d a _ c o m p l e t a .
txt > bloco_acl . txt
# Apaga o a r q u i v o " s a i d a _ c o m p l e t a . t x t " que nao eh m a i s u t i l
rm −f s a i d a _ c o m p l e t a . t x t
# V e r i f i c a o numero de l i n h a s que o b l o c o c o n t e m :
63
# ACL e x i s t e : d i f e r e n t e de z e r o
# ACL nao e x i s t e : i g u a l a z e r o
n u m e r o _ l i n h a s _ b l o c o = ‘wc − l b l o c o _ a c l . t x t | awk ’{ p r i n t $1 } ’ ‘
# E x e c u t a o s c r i p t " p o s i c a o _ b l o q u e i o . s h " p a s s a n d o como
parametro
# o b l o c o de t e x t o " b l o c o _ a c l . t x t " que c o n t e m a ACL , p a r a
identificar
# a p r i m e i r a p o s i c a o d i s p o n i v e l da s e q u e n c i a p a r a e f e t u a r o
bloqueio
p o s i c a o = ‘ . / p o s i c a o _ b l o q u e i o . sh b l o c o _ a c l . t x t ‘
# Se o " n u m e r o _ l i n h a s _ b l o c o " f o r i g u a l a z e r o a ACL nao e x i s t e
i f [ $ n u m e r o _ l i n h a s _ b l o c o −eq 0 ]
then
# C r i a a ACL a t e o momento i n e x i s t e n t e e b l o q u e i a o e n d e r e c o
MAC
. / c r i a _ a c l . sh $equipamento $ a c l _ d e s t i n o $macaddress
$interface
else
# A ACL j a e x i s t e , e n t a o b l o q u e i a o e n d e r e c o MAC
. / bloqueia_mac . sh $equipamento $ a c l _ d e s t i n o $macaddress
$posicao
O diagrama da Figura 4.7, demonstrasse de maneira resumida e visual, o caminho desde a
notificação do incidente de segurança, seja por intermédio dos honeypots da rede interna propostos nesse trabalho ou grupos de segurança com CAIS/RNP ou CERT.br, até o encaminhamento
na UFBA para o TRAIRA. Com a VLAN informada na notificação, obtêm-se a partir de um
banco de dados CPD/UFBA, algumas informações associadas a ela, a saber:
1. Unidade da UFBA: Nomenclatura utilizada para as VLANs na UFBA, a mesma informada no campo VLAN, da notificação enviada pelo TRAIRA, que é utilizada nessa busca;
2. Endereçamento IP: Faixa de endereçamento da rede associada a VLAN, e também, a
mesma contida na notificação do TRAIRA;
64
3. Número da VLAN: valor numérico associado a VLAN;
4. Nome da ACL: nome que deve ser utilizada para a ACL no roteador, onde serão adicionadas as entradas para o bloqueio. Inicialmente poderia ser o mesmo nome da VLAN,
contudo, algumas unidades, como exemplificado logo à seguir, possuem mais de uma
VLAN porém na mesma interface física. Consolidou-se uma coluna para indicar o nome
da ACL nesses casos. Logo, por exemplo, as VLANs Rede_LASID e Rede_CPD, serão
bloqueada na mesma interface física, no mesmo equipamento, contudo usando somente
uma ACL. Em particular, isso foi necessário, pois o equipamento não oferece suporte a
mais de uma ACL por interface.
5. Equipamento que roteia a VLAN: equipamento que roteia a VLAN, que não necessariamente será o mesmo equipamento no qual a unidade está fisicamente conectada (dois
roteadores pode estar interconectados, um efetuando o roteamento da VLAN e o outro
apenas conectando fisicamente );
6. Interface Física: porta física do roteador (interface) associada a VLAN, onde fisicamente
a unidade está conectada, e onde deve ser realizado o bloqueio;
7. Equipamento da contenção: roteador onde a unidade está fisicamente conectada e onde
o a ACL será aplicada, ou seja, realizada a contenção;
Uma porção da tabela do banco de dados, populado com dados ilustrativos, similares aos
reais que foram omitidos por questão de segurança e privacidade da rede UFBA, pode ser visto
abaixo à seguir:
+-----------+-------------+-----+--------+--------+---------------------+--------+
| unidade
|
ipaddr
|vlan |nome_acl| equip
|
interface
|eq_bloq |
+-----------+-------------+-----+--------+--------+---------------------+--------+
...
...
...
...
...
...
...
| Rede_BIBC | 192.168.108 | 108 | BIBC
| core01 | GigabitEthernet 1/20| core02 |
| Rede_LASID| 192.168.149 | 149 | CPD
| Rede_CPD | 192.168.102 | 102 | CPD
| Rede_MED | 192.168.118 | 118 | MED
+-----------+-------------+-----+--------+--------+---------------------+--------+
Assim, o caminho originado na notificação do incidente a UFBA, que é encaminhada ao
TRAIRA, pode através desse código semi-automatizado, efetuar a contenção minimizando ou
65
eliminando os erros apresentados durante a contenção manual. Esse caminho pode ser ilustrado
pela Figura 4.7
Figura 4.7: Fluxo da notificação do incidente de segurança até o momento da execução do
código de bloqueio
4.6.2
AUTOMATIZANDO A CONTENÇÃO DA ATIVIDADE MALICIOSA NA REDE UFBA
Foi exibido anteriormente o processo de contenção manual as suas principais características, bem como as possíveis falhas ao longo desse processo. Em seguida, demonstramos nossa
proposta de contenção semi-automatizada, que permite a redução das falhas do processo e possibilita a aceleração do processo de bloqueio, por meio de um código que através do recebimento de alguns parâmetros, realiza a contenção do dispositivo notificado como propagador de
atividade maliciosa.
Entretanto, esse processo de contenção exigia alguma intervenção manual, que por consequência permitia ainda a ocorrência de algumas falhas, tal como, erro na passagem de endereço MAC, bloqueando um dispositivo incorreto.
Em sua concepção atual, o TRAIRA atua nas duas primeiras fases do tratamento de incidentes (SCARFONE; GRANCE; MASONE, 2008), preparação e detecção e análise, descritos
na Seção 2.1.1, possibilitando à detecção de uma máquina na rede interna que gerou o incidente
ao retornar seu endereço MAC, de maneira totalmente automatizada (VALCY, 2010).
Todavia, em sua arquitetura, a ferramenta trazia a possibilidade do desenvolvimento de um
módulo de contenção, esta a última fase automatizável do tratamento de incidentes, possibilitando o isolamento das máquinas comprometidas, e consequentemente fechando o ciclo de de
tratamento de incidentes de forma totalmente automatizada.
66
Desta forma, com os scripts de contenção de desenvolvidos anteriormente, implementamos o módulo de contenção do TRAIRA, chamado pelo criador da ferramenta Containment,
conforme ilustra a Figura 4.8
Figura 4.8: Visão geral da arquitetura do TRAIRA
A arquitetura do TRAIRA é composta por cinco módulos, sendo que apenas o último ainda
não havia sido desenvolvido. Esses são descritos à seguir:
• Parser: é o módulo responsável pelo recebimento da notificação e pela extração das informações essenciais ao tratamento do incidente: endereço IP e porta de origem, data e
horário.
• NAT Mapping: este módulo utiliza as informações extraídas pelo parser e realiza uma
busca nos logs do dispositivo de NAT para associar a tupla <data, hora, IP, porta> a um
endereço IP interno, responsável de fato pelo incidente.
• IP2MAC: aqui é feita a associação do IP interno ao endereço MAC da máquina. Esse
passo é importante em instituições que utilizam o DHCP, pois um IP pode ter sido usado
por mais de uma máquina ao longo do tempo.
• Post-Detection: Este módulo é responsável pela extração de dados da notificação e do
tratamento realizado a fim de gerar estatísticas sobre os incidentes, gerar relatórios à
67
equipe de helpdesk (para, por exemplo, efetuar o isolamento e desinfecção da máquina) e
responder à instituição que reportou o incidente.
• Containment: Neste módulo é feito o isolamento do dispositivo que causou o incidente
para evitar que ele continue com a atividade maliciosa na rede ou afete outros recursos.
Figura 4.9: Tela do módulo de contenção do TRAIRA
Desta maneira, foi escrito o código desse último módulo em Perl6 , linguagem de desenvolvimento do TRAIRA, para realizar a contenção automática dos dispositivos notificados, através
das notificações que integradas aos scritps anteriormente desenvolvidos, tornam o processo totalmente automatizado, eliminando todas as etapas manuais, e minimizados as falhas anteriormente apresentas. Ainda, serviu como contribuição para (CERT.BAHIA, 2010), que atualmente
está em produção na rede UFBA, auxiliando no combate automatizado de atividade maliciosa.
A tela deste módulo no TRAIRA pode ser visto em 4.9.
6 Perl
é uma linguagem de programação interpretada, multiplataforma e bastante usada no processamento de
cadeias de caracteres, manipulação de texto e casamento de padrões (através de expressões regulares) (PERL.ORG,
2010).
68
Entretanto, em dado momento por algum motivo, a equipe de TI da UFBA pode desejar
interromper a automatização. Assim, foi pensado durante a implementação deste módulo, a
opção de ativar ou não o bloqueio automático das máquinas notificadas, através do checkbox
“Bloquear Host”, conforme visto na Figura 4.9.
Adicionalmente, ao manter a contenção de maneira automatizada, pode haver a necessidade
de não realizar a contenção de algumas máquinas em detrimento a outras ou de algumas redes
(VLANs). Suponhamos que um servidor de DHCP da rede ou o servidor DNS de alguma forma
esteja comprometido e seja identificado e notificado (similar ao incidente que ocorreu com o
servidor, descrito em 3.3). Para isso, concebeu-se o conceito de “Writelists”, tanto por VLAN
ou por endereço MAC. Desta forma, de maneira simultânea, pode-se adicionar exceções na lista
de unidades, através do nome da VLAN ou por endereço MAC. A única restrição imposta, é
que o nome da VLAN siga o mesmo padrão adotado no procedimento manual, a fim da regra
funcionar corretamente e, o endereço MAC seja adotado no formato aa:aa:aa:aa:aa:aa ou aa-aaaa-aa-aa-aa; deixando a cargo do script realizar a conversão para o formato do equipamento.
69
5
CONCLUSÃO
O advento da era comercial na Internet e o desenvolvimento de protocolos que estenderam
seu uso, associado a diversidade de serviços oferecidos, tem alavancado o número de equipamentos com acesso à rede a cada ano. Simultaneamente, um série de problemas vieram
agregados, dentre os quais, a elevação da ocorrência de incidentes de segurança, em particular,
a ação de atividade maliciosa nas redes de computadores, conforme demonstram as estatísticas
do CERT.br (CERT.BR, 2011).
Esse fato é bastante comum em instituições de ensino e pesquisa, devido a extensão da
rede e diversificação dos perfis de usuários, que recorrentemente, adquirem equipamentos para
montar suas salas e laboratórios de maneira autonômica ou utilizam dispositivos móveis particulares, como os notebooks, que são conectados indiscriminadamente à rede, sem seguir políticas
de segurança da instituição, e muitas vezes, não possuem softwares de anti-vírus instalados ou
mantêm seus sistemas operacionais com as devidas atualizações de segurança.
A incidência de atividade maliciosa sobre as redes de computadores acarretam uma série
prejuízos, que vão além de números em estatísticas. O simples fato de ter uma máquina comprometida e ignorá-la, pode permitir o comprometimento de outros dispositivos na rede que, em
dado momento podem ocasionar a indisponibilidade parcial ou total da rede, através da saturação dos recursos computacionais. No aspecto financeiro, os danos podem ocorrer de diversas
formas, seja pela necessidade de contratação de mais pessoas, para realizar o tratamento dos
incidentes e restabelecimento dos sistemas comprometidos, ou na necessidade do aumento de
capacidade de banda, devido ao tráfego malicioso. Ainda, de maneira mais grave, sanções administrativas podem vir a ser aplicadas por outros provedores, através do bloqueio do tráfego
originada destas instituições, trazendo danos incalculáveis.
Por essa razão, medidas preventivas são fundamentais nas instituições, a fim de minimizar
a ocorrência dos incidentes de segurança, mesmo sabendo que, nem todos podem ser evitados
(SCARFONE; GRANCE; MASONE, 2008). Assim, devem haver esforços por parte das instituição na implantação de recursos computacionais que possibilitem a detecção, tratamento das
70
notificações e a depender do tipo de ocorrência, realizar a contenção do dispositivo causador do
incidente, de forma eficaz.
Este trabalho foi condizido no ambiente da rede acadêmica da Universidade Federal da
Bahia (UFBA), uma rede de campus, na qual conduzimos um estudo de caso de detecção e contenção automatizada de atividade maliciosa. Para detecção automatizada, utilizamos um recurso
computacional de segurança projetado e dedicado a ser sondado, atacado ou comprometido, conhecido como honeypots (SPITZNER, 2003). Tradicionalmente, grupos de segurança, como
o CERT.Bahia, utilizam essa recurso com um endereço IP público (popularmente chamado de
IP roteável), expostos para Internet, detectando incidentes de segurança originadas em outras
redes, ou ocasionalmente de sua própria rede, todavia identificando apenas atividade maliciosa direcionada de endereços IP da Internet para Internet, conforme estatísticas do CERT.Bahia
(CERT.BAHIA, 2011b). Nesse trabalho, propomos uma estratégia diferente da convencional,
utilizando os honeypots distribuídos por toda rede acadêmica da instituição utilizando, endereços IP privados, na chamada rede interna.
Como a rede acadêmica da UFBA é bastante extensa, composta por aproximadamente setenta unidades, contabilizando apenas as acadêmicas, utilizamos setenta honeypots de baixainteratividade, implantando um honeypot por unidade. Essa proposta permitiu detectar de forma
mais rápida dispositivos que estavam propagando atividade maliciosa, pois estando no mesmo
segmento de rede das máquinas estavam mais próximos também das máquinas infectadas por
algum tipo de malware. Consequentemente, notificamos em intervalos de tempos mais curtos,
minimizando a atividade do malware na rede. A escolha de honeypots de baixa-interatividade
deu-se pelo fato que estes estão dentro da rede de produção e não queríamos expor a rede a riscos, como pode oferecer os honeypots de alta-interatividade. Ainda, para evitar o uso de muitas
máquinas, que levaria a possível necessidade de hospedagem de máquinas na unidade, espaço
para armazenamento, dificuldade de manutenção, consumo de energia, dentre outros; utilizando
apenas uma máquina física, com a interface de rede em todas as redes acadêmicas, utilizamos o
conceito de VLAN, permitindo uma estrutura centralizada, de baixo custo e fácil manutenção.
Apesar de ser uma arquitetura centralizada, essa ofereceu maior vantagem sobre uma fisicamente distribuída, pelos pontos apresentados anteriormente; e no caso de falha, a realização da
restauração do backup da máquina, colocaria reativaria o sistema. Essa solução encontra-se em
produção atualmente na rede acadêmica da UFBA, e somente nos dois primeiros meses de sua
implantação, foram registradas mais de 250 notificações de incidentes de segurança, através de
atividade maliciosa gerada por malwares na rede.
Adicionalmente, a ferramenta TRAIRA (acrônimo para Tratamento de Incidentes de Rede
71
Automatizado), desenvolvida pelo CERT.Bahia (CERT.BAHIA, 2010) a fim de automatizar o
processo do tratamento de incidentes de segurança, permitia sua extensão, através do desenvolvimento de um módulo, para a realização da contenção automatizada; permitindo que todo
ciclo, originado na notificação até a contenção do dispositivo infectado, possa ser totalmente
automatizado. Na UFBA, essa ferramenta já é utilizada com sucesso a algum tempo, porém
toda contenção era realizada por técnicos manualmente, permitindo que falhas nesse processo
ocorressem, como a contenção de dispositivo incorreto e consequente permanência da máquina
infectada na rede. Nesse processo manual, pessoas eram desviados de suas atividades para
realizar o procedimento de contenção ou pessoas eram contratadas para tal atividade, o que
diretamente impacta em custo para instituição.
Dessa forma, foram desenvolvidos um conjunto de scripts, que juntos e executados manualmente, permitiam a realização da contenção automatizada dos dispositivos. Para eliminar
qualquer intervenção manual, minimizando as possibilidades da ocorrência de falhas, realizamos o desenvolvimento do módulo de contenção para o TRAIRA, tornando dessa forma o
processo totalmente automatizado.
Acreditamos, que os resultados alcançados nesse trabalho trouxeram uma colaboração significativa para o combate a atividade maliciosa na rede UFBA, permitindo que o modelo adotado
nessa instituição, possa ser implementado em qualquer outra instituição de ensino e pesquisa,
que tenham desejo de contribuir para redução da ocorrência de atividade maliciosa, tanto em
sua rede, quando na propagação de malwares para Internet.
Como possibilidades de extensão desse trabalho não foram esgotadas, sugere-se alguns
pontos com contribuições futuras:
• No primeiro momento, os honeypots foram implantados apenas da rede acadêmica da
UFBA, para realização do nosso estudo de caso. Todavia, pode-se expandir a implantação
dos honeypots por todas as redes da instituição, incluindo a rede administrativa, com
significativa quantidade de dispositivos e usuários; além da expansão para os campus do
interior, como Vitória da Conquista, Barreiras e Oliveira dos Campinho.
• Na implantação de honeypots da rede interna dos campi do interior do estado, uma avaliação do consumo médio de tráfego de rede, antes e após as detecções e contenções,
possibilitam um ótimo estudo de caso na identificação do volume de tráfego malicioso,
haja vista a reduzida velocidade de tráfego oferecidos pelas operadoras no interior do
estado;
• Analisar as possibilidades de aumentar o nível de interação dos honeypot, a fim de que não
72
apenas sejam detectados, mas possamos aprender com os atacantes, capturando artefatos
maliciosos e desenvolvendo técnicas de análise;
• Com o recente anúncio do fim dos endereços do protocolo IPv4, verifica-se a eminente
necessidade do uso do protocolo IPv6. Desta maneira, projetar a migração e implantação de honeypots com IPv6 é uma abordagem futura, além de estudar quais as possíveis
vulnerabilidades que podem ser estudadas do próprio protocolo;
• A padronização de notificação de incidentes de segurança desse trabalho seguiu a mesmo
modelo utilizada pelo CERT.Bahia, que segue as recomendações do CERT.br . Todavia,
não é um modelo universalmente adotado, o que impede a colaboração entre os grupos. Para isso, recomendasse com trabalhos futuros utilizar a padronização proposta pelo
IETF, a Intrusion Detection Message Exchange Format (IDMEF) para compartilhamento
de informações e definição de um formato universal de notificação;
• Na UFBA, como possivelmente em outras instituições, diversas ferramentas são utilizadas
como recursos computacionais de segurança. Assim, agrupar as notificações coletadas
a partir dos honeypots e correlacionar com os dados de outras ferramentas é bastante
interessante, para obter-se uma base integrada de dados, relacionadas a incidentes de
segurança;
73
APÊNDICE A -- RESULTADO DO
EXPERIMENTO: IDENTITY
MANAGEMENT COM COM
KERBEROS SNOOPING NO
CPD/UFBA
REMOVIDO TEMPORARIAMENTE (06/07/2011)
74
REFERÊNCIAS BIBLIOGRÁFICAS
BERRUETA, D. A practical approach for defeating nmap os- fingerprinting. Retrieved April,
v. 24, 2003.
BEZERRA, J. A. Relatório interno da divisão de suporte do cpd/ufba : Implantanção de
honeypots:experiência da ufba/pop-ba. 2009.
BäCHER, P.; HOLZ, M. K. T.; WICHERSKI, G. Know your Enemy:Tracking Botnets - Using
honeynets to learn more about Bots. [S.l.], 2005.
CAIS/RNP. Como identificar e remover o malware Conficker. 2009. Último acesso em 08 de
Junho de 2011. Disponível em: <http://www.rnp.br/cais/alertas/2009/cais-alr-2009-2a.html>.
CAIS/RNP. Relatório anual - Destaques do Tratamento de Incidentes em 2010. 2010.
Disponível em: <http://www.rnp.br/cais/relatorios>. Acesso em: 25 de maio 2011.
CERT.BAHIA. TRAIRA :: Tratamento de Incidentes de Rede Automatizado. 2010. Último
acesso em 27 de Maio de 2011. Disponível em: <http://www.pop-ba.rnp.br/Cert>.
CERT.BAHIA. Estatísticas do TOP 10 Mensal - Portas TCP. 2011. Último acesso em 06 de
Junho de 2011. Disponível em: <http://www.pop-ba.rnp.br/Cert/EstatisticasTCP>.
CERT.BAHIA. Estatísticas Honeypot - Total de acessos. 2011. Último acesso em 30 de Junho
de 2011. Disponível em: <http://www.pop-ba.rnp.br/Cert/EstatisticasTotal>.
CERT.BR. Cartilha de Segurança para Internet. Parte VII:Incidentes de Segurança e
Uso Abusivo da Rede. 2006. Último acesso em 21 de Maio de 2011. Disponível em:
<http://cartilha.cert.br/download/cartilha-01-conceitos.pdf>.
CERT.BR. Honeypots e Honeynets: Definições e Aplicações. 2007. Disponível em:
<http://www.cert.br/docs/whitepapers/honeypots-honeynets/>. Acesso em: 23 de maio 2011.
CERT.BR. Cartilha de Segurança para Internet. Parte I:Conceitos de Segurança. 2010. Último
acesso em 22 de Maio de 2011. Disponível em: <http://www.cartilha.cert.br/download/cartilha01-conceitos.pdf>.
CERT.BR. Incidentes Reportados ao CERT.br – Janeiro a Dezembro de 2010. 2010. Disponível
em: <http://www.cert.br/stats/incidentes/2010-jan-dec/tipos-ataque.html>. Acesso em: 26 de
maio 2011.
CERT.BR. Estatísticas dos Incidentes Reportados ao CERT.br. 2011. Disponível em:
<http://www.cert.br/stats/incidentes/>. Acesso em: 25 de maio 2011.
CISCO. CiscoWorks LAN Management Solution. 2011. Último acesso em 22 de Junho de 2011.
Disponível em: <http://www.cisco.com/en/US/products/sw/cscowork/ps2425/index.html>.
75
D-LINK. D-View 6.0 Network Management Software, Professional Version. 2011. Último
acesso em 22 de Junho de 2011. Disponível em: <http://www.dlink.com/products/?pid=677>.
DANYLIW, R.; MEIJER, J.; DEMCHENKO, Y. The incident object description exchange
format. Request for Comments, Internet Engineering Task Force, v. 5070, 2007.
DEBAR, H.; CURRY, D.; FEINSTEIN, B. The intrusion detection message exchange format
(idmef). 2007.
EDWARDS, W. et al. CCNP complete study guide. [S.l.]: Sybex Inc, 2005.
EXTREMENETWORKS. Ridgeline Network and Service Management. 2011. Último acesso em 22 de Junho de 2011. Disponível em:
<http://www.extremenetworks.com/products/Ridgeline.aspx>.
F-SECURE. Trackware:W32/Tracking_Cookie. 2011. Último acesso em 12 de Junho de 2011.
Disponível em: <http://www.f-secure.com/sw-desc/trackware_w32_tracking_cookie.shtml>.
F-SECURE. Trojan-Dropper:W32/Stuxnet. 2011. Último acesso em 12 de Junho de 2011.
Disponível em: <http://www.f-secure.com/v-descs/trojan-dropper_w32_stuxnet.shtml>.
FILHO, A. B. et al. Honeynet.br: Desenvolvimento e implantação de um sistema para
avaliação de atividades hostis na internet brasileira. In: Anais do IV Simpósio sobre Segurança
em Informática (SSI’2002). São José dos Campos, SP: [s.n.], 2002. p. 19–25.
IEEE. IEEE 802 LAN/MAN Standards Committee. 1990. Último acesso em 24 de Junho de
2011. Disponível em: <http://www.ieee802.org/>.
KARTHIK, S.; SAMUDRALA, B.; YANG, A. Design of network security projects using
honeypots. In: Journal of Computing Sciences in Colleges. Houston, Texas: [s.n.], 2005. p.
282–293.
KASPERSKY. What is Adware, riskware, pornware and how can I fight these
programs? 2011. Último acesso em 13 de Junho de 2011. Disponível em:
<http://support.kaspersky.com/viruses/common?qid=193238514>.
KIPPO. Kippo - SSH Honeypot. 2010. Último acesso em 24 de Maio de 2011. Disponível em:
<http://code.google.com/p/kippo/>.
KUROSE, J.; ROSS, K. W. Redes de Computadores e a Internet. [S.l.]: Pearson Addison
Wesley, 2006.
LIBES, D. Expect: Scripts for controlling interactive processes. Computing Systems, Citeseer,
v. 4, n. 2, p. 99–125, 1991.
MARCELO, A.; PITANGA, M. Honeypots: a Arte de Iludir Hackers. [S.l.]: Brasport, 2003.
MICROSOFT. Microsof - O que é o spyware? 2006. Último acesso em 13 de Junho de 2011. Disponível em:
<http://www.microsoft.com/portugal/athome/security/spyware/spywarewhat.mspx>.
MICROSOFT. Microsoft Offers $250,000 Reward for Information Leading to Conviction
of MyDoom.B Perpetrators. 2009. Último acesso em 23 de Maio de 2011. Disponível em:
<http://www.microsoft.com/presspass/press/2004/jan04/01-29mydoombrewardpr.mspx>.
76
MIT. Kerberos: The Network Authentication Protocol. 1993. Último acesso em 22 de Junho de
2011. Disponível em: <http://web.mit.edu/Kerberos/>.
MOKUBE, I.; ADAMS, M. Honeypots: concepts, approaches, and challenges. In: ACM-SE
45: Proceedings of the 45th annual southeast regional conference. New York, NY, USA:
ACM, 2007. p. 321–326. ISBN 978-1-59593-629-5.
NETWORKS, E. Extremexos concepts guide - software version 12.5.2. Extreme, 2011.
PERL.ORG. The Perl Programming Language. 2010. Último acesso em 14 de Novembro de
2010. Disponível em: <http://www.perl.org>.
PORRAS, P. Inside risks reflections on conficker. Communications of the ACM, ACM, v. 52,
n. 10, p. 23–24, 2009.
PROJECT, T. H. Know Your Enemy: Revealing the Security Tools, Tactics, and Motives of the
Blackhat Community. 1st. ed. [S.l.]: Addison-Wesley, 2001. ISBN 0-201-74613-1.
PROVOS, N.; HOLZ, T. Virtual honeypots: from botnet tracking to intrusion detection.
Addison-Wesley Professional, 2007.
RESPONSE, S. S. W32.Qakbot in Detail. 2011. Último acesso em 08 de Junho de 2011. Disponível em:
<http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_qakbot_in
REYNOLDS, J. Rfc1135: Helminthiasis of the internet. RFC Editor United States, RFC
Editor, United States, 1989.
SCARFONE, K.; GRANCE, T.; MASONE, K. Computer Security Incident Handling Guide.
NIST Special Publication, v. 800–61, 2008.
SOCIETY, I. C. Ieee standard for local and metropolitan area networks: Overview and
architecture. IEEE Standards, ACM, 2001.
SPITZNER, L. Honeypots: Tracking Hackers. 1st. ed. [S.l.]: Addison-Wesley, 2003. ISBN
0-321-10895-7.
TANENBAUM, A.; WOODHULL, A. Operating systems design and implementation. 2004.
US-CERT/NIST. National Vulnerability Database. 2011. Último acesso em 12 de Junho de
2011. Disponível em: <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-2568>.
VALCY, I. Traira: uma ferramenta para o tratamento de incidentes de rede automatizado.
Monografia de Conclusão de Graduação, DCC/UFBA, 2010.

caso UFBA - PoP-BA

Transcrição

Documentos relacionados

Formulário Prudential Foundation TWC

http://raulhc.cc

FORMULÁRIO DE HOSPEDAGEM DE SITE (F-AT-04)

Microsoft PowerPoint - Seguran\347a na Rede - PoP-BA

instituiç ão tema título orientador/ departament o membros - Crea-BA

Programação_Seminário_Fortunati e Horn_de

UNIVERSIDADE FEDERAL DA BAHIA PRÓ

declaração de desistência

Boletim Nº 34, Novembro de 2009

Ernst Widmer - MHCC-UFBA - Universidade Federal da Bahia