MINISTÉRIO DA DEFESA...4.2 Firewall..... 42 4.2.1 Netfilter/iptables 43 6 4.2.2 Requerimentos da...
78
MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA INSTITUTO MILITAR DE ENGENHARIA CURSO DE GRADUAÇÃO EM ENGENHARIA DE COMPUTAÇÃO MARCOS DE AUGUSTINIS VALLE MACHADO DA SILVA MATHEUS VANZAN PIMENTEL DE OLIVEIRA ARQUITETURA DE SEGURANÇA PARA SERVIÇOS WEB DE DISPONIBILIZAÇÃO DE DADOS ESPACIAIS EM OPERAÇÕES MILITARES Rio de Janeiro 2015
Transcript of MINISTÉRIO DA DEFESA...4.2 Firewall..... 42 4.2.1 Netfilter/iptables 43 6 4.2.2 Requerimentos da...
MINISTÉRIO DA DEFESA
EXÉRCITO BRASILEIRO
DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA
INSTITUTO MILITAR DE ENGENHARIA
CURSO DE GRADUAÇÃO EM ENGENHARIA DE
COMPUTAÇÃO
MARCOS DE AUGUSTINIS VALLE MACHADO DA SILVA
MATHEUS VANZAN PIMENTEL DE OLIVEIRA
ARQUITETURA DE SEGURANÇA PARA SERVIÇOS WEB DE
DISPONIBILIZAÇÃO DE DADOS ESPACIAIS EM
OPERAÇÕES MILITARES
Rio de Janeiro
2015
2
INSTITUTO MILITAR DE ENGENHARIA
MARCOS DE AUGUSTINIS VALLE MACHADO DA SILVA
MATHEUS VANZAN PIMENTEL DE OLIVEIRA
ARQUITETURA DE SEGURANÇA PARA SERVIÇOS WEB DE
DISPONIBILIZAÇÃO DE DADOS ESPACIAIS EM OPERAÇÕES
MILITARES
Trabalho apresentado ao Curso de Graduação em
Engenharia de Computação do Instituto Militar de
Engenharia, como Verificação Especial do Projeto de Fim
de Curso.
Orientador: Prof. Maj. Ivanildo Barbosa, D.C.
Rio de Janeiro
2015
3
c2015
INSTITUTO MILITAR DE ENGENHARIA
Praça General Tibúrcio, 80 – Praia Vermelha
Rio de Janeiro – RJ CEP: 22290-270
Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá incluí-lo em
base de dados, armazenar em computador, microfilmar ou adotar qualquer forma de
arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas deste
trabalho, sem modificação de seu texto, em qualquer meio que esteja ou venha a ser fixado,
para pesquisa acadêmica, comentários e citações, desde que sem finalidade comercial e que seja
feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade dos autores e do orientador.
Silva, M. A. V. M.;, Oliveira, M. V. P.
Arquitetura de segurança para serviços web de
disponibilização de dados espaciais em operações militares /
Marcos de Augustinis Valle Machado da Silva, Matheus Vanzan
Pimentel de Oliveira; orientados por Ivanildo Barbosa - Rio de
Janeiro: Instituto Militar de Engenharia, 2015.
77p. : il.
Projeto de Fim de Curso (Engenharia de Computação) - Instituto
Militar de Engenharia, Rio de Janeiro, 2015.
1. Segurança da informação. 2. Sistemas de detecção de intrusão.
I. Arquitetura para segurança de aplicações web de disponibilização
de dados geoespaciais em operações militares.
005.8
S586a
4
INSTITUTO MILITAR DE ENGENHARIA
Ten MARCOS DE AUGUSTINIS VALLE MACHADO DA SILVA
Ten MATHEUS VANZAN PIMENTEL DE OLIVEIRA
ARQUITETURA DE SEGURANÇA PARA SERVIÇOS WEB DE DISPONIBILIZAÇÃO
DE DADOS ESPACIAIS EM OPERAÇÕES MILITARES
Trabalho apresentado ao Curso de Graduação em Engenharia de Computação do
Instituto Militar de Engenharia, como Verificação Especial do Projeto de Fim de Curso.
Orientador: Ivanildo Barbosa, D.Sc.
Aprovada em 19 de outubro de 2015 pela seguinte Banca Examinadora:
___________________________________________________________________
Prof. Maj. Ivanildo Barbosa – D.Sc, do IME
___________________________________________________________________
Prof. Cap. Humberto Henriques de Arruda – M.Sc, do IME
___________________________________________________________________
Prof. Ricardo Choren Noya – D.Sc, do IME
Rio de Janeiro
2015
5
SUMÁRIO
LISTA DE ILUSTRAÇÕES .................................................................................................... 6
LISTA DE TABELAS .............................................................................................................. 7
LISTA DE SIGLAS .................................................................................................................. 8
1 ..... INTRODUÇÃO 14
1.1 Objetivo ..................................................................................................................... 16
1.2 Motivação .................................................................................................................. 16
1.3 Metodologia ............................................................................................................... 17
1.4 Organização da monografia ....................................................................................... 19
2 ..... DESCRIÇÃO DO PROBLEMA 20
2.1 Aplicação WEB .......................................................................................................... 20
2.2 Dados Geoespaciais ................................................................................................... 20
2.2.1 PostgreSQL e PostGIS 21
2.2.2 Geoserver 21
2.3 Cenários ..................................................................................................................... 22
2.4 Ambiente de testes 23
2.4.1 Configurações 23
3 SEGURANÇA ORGÂNICA DE DADOS 25
3.1 Controle de usuários ....................................................................................................... 25
3.2 Segurança no PostgreSQL/PostGIS................................................................................ 29
3.3 Segurança no Geoserver ................................................................................................. 31
3.3.1 Configurações gerais 31
3.3.2 Senhas 32
3.3.3 Autenticação, senhas, usuários, grupos e funções 33
3.3.4 Dados 34
3.3.5 Serviços 35
3.4 Criptografia do banco de dados ...................................................................................... 35
3.5 Protocolo de transferência segura de dados (HTTPS) .................................................... 37
4 SEGURANÇA DA REDE 41
4.1 Estrutura geral ................................................................................................................. 41
4.2 Firewall .......................................................................................................................... 42
4.2.1 Netfilter/iptables 43
6
4.2.2 Requerimentos da política de segurança 44
4.3 Sistema de detecção de intrusão ..................................................................................... 45
4.3.1 Snort 47
4.3.2 Fwsnort 48
4.4 psad ................................................................................................................................. 49
4.5 Honeypots ....................................................................................................................... 51
4.6 Arquitetura final ............................................................................................................. 52
4.7 Dificuldades encontradas ................................................................................................ 53
5 TESTES 57
5.1 Penetração ....................................................................................................................... 57
5.1.1 Testes com a arquitetura parcial (sem honeypot) 59
5.1.2 Testes com a arquitetura completa (com honeypot) 66
5.2 Quality of Service (QoS) ................................................................................................. 73
6 CONCLUSÃO 75
7 REFERÊNCIAS BIBLIOGRÁFICAS 77
7
LISTA DE ILUSTRAÇÕES
FIG. 1.1 - Representações gráficas de atividades maliciosas e origens de ataques web por país.
.................................................................................................................................................. 17
FIG. 2.1 - Resultado de uma requisição WMS ao GeoServer .................................................. 22
FIG. 3.1 - Arquitetura da segurança orgânica ....................................................................... 255
FIG. 3.2 - Esquematização do mapeamento de usuários em seus grupos ............................. 277
FIG. 3.3 - Extrato do mapeamento de usuários em seus grupos ............................................ 288
FIG. 3.4 - Painel GlassFish de controle dos mapeamentos de usuários ................................ 299
FIG. 3.5 - Configurações de segurança do GeoServer .......................................................... 311
FIG. 3.6 - URL sem funcionalidade de criptografia ............................................................ 322
FIG. 3.7 - URL com funcionalidade de criptografia ............................................................. 322
FIG. 3.8 - Interface administrativa do GeoServer ................................................................. 344
FIG. 3.9 - Regras de acesso a serviços específicos do GeoServer ........................................ 355
FIG. 3.10 - Esquema simplificado do funcionamento de um algoritmo criptográfico genérico
................................................................................................................................................ 366
FIG. 3.11 - Relação entre HTTP e HTTPS (HTTPS = HTTP + SSL) .................................. 377
FIG. 3.12 - Esquema gráfico do protocolo SSL .................................................................... 388
FIG. 3.13 – Certificado auto assinado gerado para a aplicação .............................................. 40
FIG. 4.1 - Fluxo de recebimento de pacotes na arquitetura proposta. ..................................... 41
FIG. 4.2 - Fluxo de pacotes no iptables ................................................................................... 44
FIG. 4.3 - Conversão das regras Snort para regras iptables com fwsnort (taxa de sucesso em
destaque). .................................................................................................................................. 49
FIG. 4.4 - Exemplo de regra Snort convertida com sucesso pelo fwsnort. ............................. 49
FIG. 4.5 – Diagrama detalhado do fluxo de pacotes na arquitetura proposta. ........................ 52
FIG. 4.6 – Código do daemon responsável por monitorar os IPs bloqueados. ....................... 53
FIG. 4.7 – Problemas e soluções encontrados durante a implementação do encaminhamento do
honeypot.. ................................................................................................................................. 54
8
FIG. 4.8 – Mecanismo de retroalimentação com destaque para o update_daemon, ponto crítico
durante a implementação. ......................................................................................................... 56
FIG. 4.9 – Extrato das regras do firewall responsáveis por realizar o encaminhamento
bidirecional para o honeypot.. .................................................................................................. 56
FIG. 5.1 - Fases principais de um teste de penetração ............................................................ 57
FIG. 5.2 - Exemplo de varredura de portas contra o servidor sem regras de firewall ativas. . 59
FIG. 5.3 - Exemplo de varredura de portas contra o servidor com regras de firewall ativas. . 60
FIG. 5.4 – Registro de logs do firewall com pacotes descartados. ......................................... 60
FIG. 5.5 - Exemplo de tentativa de impersonação de IP. ........................................................ 61
FIG. 5.6 - Extrato do log do firewall registrando os pacotes impersonados descartados. ...... 61
FIG. 5.7 - Tráfego de entrada e saída na interface do servidor sem regras de firewall e sem estar
sob ataque de negação de serviço. ............................................................................................ 62
FIG. 5.8 - Painel de controle do LOIC em execução contra o servidor alvo .......................... 62
FIG. 5.9 - Tráfego de entrada e saída na interface do servidor sem regras de firewall e sob
ataque de negação de serviço. .................................................................................................. 63
FIG. 5.10 - Tráfego de entrada e saída na interface do servidor com regras de firewall e sob
ataque de negação de serviço. .................................................................................................. 63
FIG. 5.11 - Extrato do syslog indicando o bloqueio do atacante pelo psad e os emails enviados.
.................................................................................................................................................. 64
FIG. 5.12 - Estado do psad após o bloqueio do atacante. ....................................................... 65
FIG. 5.14 – Cenário para simulação dos ataques, envolvendo três máquinas virtuais. .......... 67
FIG. 5.13 - Visualização da página alvo antes do ataque. ...................................................... 67
FIG. 5.14 - Varredura de portas no servidor (IP ainda não bloqueado). ................................. 67
FIG. 5.16 - Varredura de portas no servidor (IP bloqueado). ................................................. 68
FIG. 5.17 - Varredura de portas no honeypot.. ...................................................................... 618
FIG. 5.18 - Visualização da página alvo após o ataque bloqueado com sucesso. ................... 69
FIG. 5.19 – Visualização dos resultados da varredura de vulnerabilidades na aplicação do
servidor, com os resultados encaminhados pelo honeypot.. ..................................................... 70
FIG. 5.20 –Visualização dos resultados do ataque de força bruta na aplicação do servidor, com
os resultados encaminhados pelo honeypot. ............................................................................. 70
9
FIG. 5.21 – Resultados do fluxo de dados durante um ataque DoS com utilização do honeypot..
.................................................................................................................................................. 71
FIG. 5.22 – Interface gráfica web para exibição dos resultados coletados pelo honeypot .. ... 72
10
LISTA DE SIGLAS.
AES Advanced Encryption Standard
CBC Cipher-Block Chaining
DDoS Distributed Denial of Service
DES Data Encryption Standard
DNS Domain Name System
DoS Denial of Service
GUI Graphical User Interface
HIDS Host-based Intrusion Detection System
HTTP Hyper Text Transfer Protocol
HTTPS Hyper Text Transfer Protocol Secure
IDS Intrusion Detection System
NIDS Network Intrusion Detection System
NTP Network Time Protocol
PBE Password Based Encryption
PSAD Port Scan Attack Detector
SGBD Sistema de Gerenciamento de Banco de Dados
SSH Secure Shell
SMTP Simple Mail Transfer Protocol
SSL Secure Socket Layer
QoS Quality of Service
TCP Transmission Control Protocol
TDE Transparent Data Encryption
11
TSL Transport Layer Security
URL Uniform Resource Locator
WMS Web Map Service
12
RESUMO
A disponibilização de dados geoespaciais é de alta relevância para o apoio de operações
militares e, portanto, a confidencialidade, integridade e disponibilidade dos dados e serviços
deve ser garantida. Este projeto propõe uma arquitetura de segurança para uma aplicação web
que permite a disponibilização de dados geoespaciais em operações militares, bem como para
seu servidor de hospedagem. Para tanto, o desenvolvimento da arquitetura divide-se em
soluções de segurança orgânica de dados – proteção da informação no âmbito intra-servidor –
e de rede – proteção da informação no âmbito externo ao servidor. Após a implementação do
sistema foram realizados testes de penetração, de forma a garantir que as soluções sugeridas
neste trabalho tenham utilidade de fato e que aumentam o nível de segurança do serviço em
nível satisfatório.
13
ABSTRACT
The availability of geospatial data is of high importance for the support of military
operations and, therefore, the confidentiality, integrity and availability of data and services must
be assured. This project proposes a security architecture for a web application that allows
geospatial data to be accessed in military operations as well as it’s hosting server. To that end,
the protocol development is divided into organic security of data solutions - information
protection on an intra-server level - and network solutions - information protection outside the
server. After the system implementation, penetration tests were be performed to ensure the
solutions suggested in this paper have, in fact, utility and increase the service level of security
at a satisfactory level.
14
1 INTRODUÇÃO
A segurança é um elemento dependente do contexto, de modo que a eficácia de quaisquer
medidas de proteção depende do contexto em que as mesmas são aplicadas. A segurança
também é frequentemente não incremental e a insegurança em uma área pode levar à
insegurança em todas as áreas. Ataques a sistemas computacionais podem, portanto, assumir
diversas facetas, das mais simples às mais complexas e, por meio de apenas uma brecha
comprometerem a confidencialidade e integridade de dados sensíveis ou a disponibilidade de
serviços. Hackers podem tentar invadir a rede da casa de um funcionário e roubar senhas, contas
de e-mail ou mesmo sequestrar conexões consideradas seguras com o intuito de invadir uma
rede corporativa, o que requer a existência de mecanismos de segurança frente a ameaças
internas e externas. Hackers podem estacionar fora do prédio da organização alvo e monitorar
o tráfego da rede sem fio, de modo que a criptografia se faz necessária nas conexões e nos dados
sensíveis.
O conceito de segurança é um conjunto de políticas e procedimentos que tratam, em última
instância, da disponibilização de informações (ZWICY, COOPER e CHAPMAN, 2000). Para
que se desenvolva uma arquitetura de segurança efetiva é necessário seguir alguns princípios
adaptados do meio militar para a esfera cibernética, dos quais foram adotados para o presente
projeto:
Princípio do menor privilégio
Defesa em profundidade
Centralização de fluxo
O princípio do menor privilégio talvez seja o mais fundamental para qualquer sistema de
defesa, não somente em relação a sistemas digitais. Seu significado consiste basicamente em
qualquer objeto, seja ele um usuário, programa, sistema ou outra entidade afim, deve possuir
apenas os privilégios de que o objeto necessita para desempenhar as tarefas que lhe cabem - e
nada mais. O menor privilégio é um princípio importante para limitar a exposição a ataques e
para limitar os danos causados por ataques particulares.
15
Outro princípio de segurança genérico é o de defesa em profundidade. Por mais forte que
um mecanismo de segurança possa parecer, não se deve depender apenas dele. Ao contrário,
devem ser instalados múltiplos mecanismos que cubram as falhas entre si, de modo que um
problema em um único mecanismo de segurança não comprometa a segurança como um todo.
É comum que pontos de estrangulamentos, regiões em que o atacante é forçado a utilizar um
canal estreito que pode ser monitorado e controlado, sejam utilizados em conjunto com o
princípio de defesa em profundidade, formando barreiras de defesa. Embora a vantagem de
restringir um fluxo do sistema aumente a segurança do mesmo, é preciso analisar possíveis
perdas de desempenho de forma a manter o sistema funcional.
Uma máxima fundamental na segurança é que uma corrente é tão forte quanto seu elo mais
fraco. O princípio contido nessa frase indica a metodologia do atacante, buscar o ponto mais
fraco do sistema e concentrar nele as atenções. Embora não seja impossível eliminar a
existência do elo mais fraco, é importante atentar para que não haja grandes diferenças quanto
ao nível de insegurança entre as partes, fornecendo força suficiente e proporcional aos riscos
(PROWELL, KRAUS e BORKIN, 2010).
A observação rigorosa dos princípios de segurança mais significativos proporciona um
sistema de segurança menos vulnerável a ataques. Ainda assim, o sistema puramente passivo
incorre no risco de ter seus dispositivos de segurança superados por elementos persistentes,
especialmente quando a informação armazenada possuir grau de restrição elevado. Sistemas de
defesa ativa podem ser definidos como “quaisquer medidas originadas pelo defensor contra o
atacante” e divididos em categorias de contra-ataque, ataque preemptivo e ilusão ativa
(JOHNSON, 2013). Quando corretamente implementado, o sistema ativo pode fornecer
resultados mais consistentes frente a ataques novos ou mais potentes.
O número de ataques cibernéticos a órgãos governamentais vem crescendo ao longo dos
últimos anos, especialmente no Brasil (PWC, 2015). A criação de um sistema web de
disponibilização de dados geoespaciais não pode negligenciar a ocorrência de ataques que
visam a derrubada do serviço bem como o acesso não-autorizado a certos tipos de dados. A
utilização dos princípios fundamentais da segurança guiarão, portanto, a elaboração de uma
arquitetura de defesa efetiva com o foco na defesa ativa.
16
1.1 Objetivo
O presente projeto tem por objetivo elaborar, implementar e testar uma arquitetura de
segurança para uma aplicação militar web que exibe dados geoespaciais previamente coletados,
independentemente de proteções externas ao servidor. Para a garantia da segurança orgânica
dos dados e da aplicação, será entregue um sistema de controle de acesso às informações
armazenadas, de acordo com perfis de usuários e camadas de dados requisitadas. Serão
avaliados e selecionados também os recursos de segurança disponíveis no GeoServer, incluindo
algoritmos criptográficos do banco e formato das requisições. De forma a garantir a segurança
dos dados em trânsito na comunicação cliente-servidor, será implementado o protocolo HTTPS.
Para a segurança externa ao servidor, será entregue uma arquitetura de fluxo de pacotes
consistindo em um firewall, um sistema de detecção de intrusão e um honeypot baseados em
host, de modo a impedir ou mitigar, de forma ativa, ameaças web comuns e tornar a segurança
da aplicação independente da infraestrutura de hospedagem. Por meio de cenários que simulam
situações de uso real da aplicação em operações militares, serão executados testes de invasão e
performance, com o intuito de comparar os resultados com o sistema desprotegido, garantindo
a qualidade da arquitetura proposta.
1.2 Motivação
Ataques cibernéticos vêm aumentando ano após ano, sendo que em 2015 foram detectados
42.8 milhões de incidentes de segurança, 48% a mais do que em 2013 (PWC, 2015). Apenas
em 2014 cerca de 76% dos sites apresentavam vulnerabilidades e 496.657 ataques web foram
bloqueados por dia. Em 2013, 60% das organizações foram impactadas por ataques DDoS e
87% foram atingidas mais de uma vez. O setor de administração pública recebe 29% dos
ataques, envolvendo atividades de roubo de informações confidenciais, negação de serviço e
outras de cunho hacktivista (SYMANTEC, 2015).
17
O Brasil é visto atualmente não apenas como um dos principais focos de origem de ataques
cibernéticos como também um dos maiores alvos, especialmente devido à ocorrência de eventos
internacionais sediados no país (TIGER SECURITY, 2015). Dessa forma, os dados
geoespaciais revelados pelo Exército Brasileiro por meio de uma aplicação web devem ter
assegurada sua disponibilidade, mas também suas confidencialidade e integridade.
O desenvolvimento de uma arquitetura de segurança consistente e apta a assegurar a
segurança de uma aplicação web é, portanto, imprescindível, especialmente no caso presente
em que informações sensíveis são disponibilizadas por meio de uma organização-alvo em um
momento em que o Brasil encontra-se em foco no cenário internacional. A FIG. 1.1 ilustra as
atividades maliciosas e origens de ataques web por país em 2014, de acordo com os dados
presentes em (SYMANTEC, 2015).
FIG. 1.1 - Representações gráficas de atividades maliciosas e origens de ataques web por país.
1.3 Metodologia
Na fase 1, foi realizado o levantamento de requisitos. O sistema deve ser capaz de impedir
ou reduzir a ação de potenciais ataques que comprometam a confidencialidade, integridade ou
disponibilidade dos dados geoespaciais contidos na aplicação. Para tanto, foi necessário analisar
18
o funcionamento do GeoServer e seus dispositivos de segurança, as técnicas de ataque mais
comuns bem como suas respectivas medidas de proteção atualmente mais empregadas.
Na fase 2, foi definida a arquitetura da solução. Para garantir sua segurança, conforme o
objetivo proposto, o sistema foi analisado sob os aspectos de segurança internos, que visam à
segurança orgânica dos dados, e externos ao servidor, relacionados aos mecanismos de
segurança da rede. No âmbito intra-servidor foi desenvolvido um sistema de autenticação de
usuários de acordo com grupos e funções previamente definidas para cada perfil. A criptografia
é aplicada ostensivamente tanto sobre os dados armazenados no banco de dados bem como na
comunicação cliente-servidor por meio do uso do protocolo HTTPS. A proteção da rede é
realizada utilizando-se ferramentas de código aberto e consolidadas no mercado, contando com
barreiras de redundância frente a ataques. O firewall é o responsável pelo contato direto com a
rede externa. O IDS, convertido em regras do iptables pela ferramenta fwsnort, é aplicado para
o monitoramento da rede interna, atuando como segundo dispositivo de proteção. Todas as
atividades do firewall são registradas em um log, o qual é analisado com o uso da ferramenta
de automação psad, resultando no envio de alertas por e-mail para os administradores. Por fim,
o sistema conta com a instalação de honeypots para influenciar o atacante a atacar máquinas
que simulem o servidor, mas sem conteúdo sensível.
Na fase 3, foram analisados os recursos necessários para a implementação da arquitetura
elaborada. Todas as ferramentas selecionadas são consolidadas no mercado e de código aberto,
o que reduz os gastos do projeto e aumenta a confiabilidade em termos de segurança. O sistema
operacional adotado foi o Linux, na distribuição Ubuntu Server. O firewall empregado é o
netfilter/iptables, disponível no kernel do Linux. O IDS é o Snort, por sua estabilidade e ampla
gama de recursos. O sistema conta ainda com o fwsnort, ferramenta de tradução das regras do
Snort para regras do iptables. Os logs são analisados pelo psad e o honeypot implementado em
uma máquina virtual HoneyDrive 3. O hardware a ser utilizado deve corresponder aos recursos
mínimos para o correto funcionamento das aplicações, devendo dispor preferencialmente de
uma máquina exclusiva para rodar os serviços do honeypot. Entretanto, caso não haja
disponibilidade de máquinas físicas, o sistema pode contar com virtualização por meio de
solução gratuitas, como o VirtualBox.
Na fase 4 foi executada a implementação do sistema, dividida em módulos correspondentes
a cada um dos componentes da arquitetura.
19
Na fase 5 foram executados testes de penetração e apresentados testes de Qualidade de
Serviço (Quality of Service – QoS) para serem empregados futuramente. O teste de penetração
é uma metodologia que valida a eficácia do sistema ao reduzir a efetividade de ataques e
ameaças potenciais. Já os testes de QoS avaliarão aspectos de confiabilidade, atraso, jitter e
largura de banda. A medição dessas variáveis permite confirmar e adaptar a arquitetura de
segurança proposta, sem que esta acarrete em prejuízo da atividade fim da aplicação.
Na fase 6 foi finalizada a documentação do projeto e proposta de melhorias futuras, que
servirá como principal fonte de consulta após a sua implementação.
1.4 Organização da monografia
No capítulo 2 será apresentada a fundamentação teórica acerca das bases de dados
geoespaciais a serem protegidas, bem como a análise dos ataques mais comuns e suas
metodologias.
No capítulo 3 serão introduzidas as soluções de segurança orgânica dos dados,
considerando-se seu armazenamento, métodos de acesso e transferência.
No capítulo 4 serão abordados os aspectos da segurança da rede em que se encontra o
servidor de modo a reduzir a possibilidade de quebra da confidencialidade ou integridade dos
dados armazenados bem como a indisponibilização do serviço.
No capítulo 5 serão esclarecidas as metodologias dos testes de penetração e de garantia da
qualidade do serviço. Ainda neste capítulo são realizados alguns testes para ilustrar o
funcionamento da arquitetura.
No capítulo 6 será apresentada a conclusão, além de propostas para trabalhos futuros,
incluindo melhorias e novos conceitos a serem agregados ao projeto. Por fim, no capítulo 7
encontram-se as referências bibliográficas consultadas.
20
2 DESCRIÇÃO DO PROBLEMA
A coleta de dados geoespaciais é realizada para a utilização em operações militares que
necessitam de apoio de geolocalização. Existem softwares e extensões específicas para o
armazenamento e a consulta desse tipo de dado, que fornecem recursos próprios para tratar não
somente para gerenciar o alto volume, mas também para fornecer soluções de segurança.
2.1 Aplicação WEB
A interface do usuário para a utilização do serviço se dará por meio de uma aplicação web
escrita em Java, atualmente desenvolvida em um projeto paralelo. As requisições são realizadas
graficamente em um mapa, gerado pela ferramenta Open Layers. As camadas de dados
sobrepõem-se, permitindo a personalização do mapa a ser visto pelo usuário. Os dados são
restritos a usuários por meio do uso de grupos e funções, de modo que o usuário passa por um
processo de autenticação antes de utilizar o sistema.
Vale notar que, embora voltada para suprir as vulnerabilidades específicas da aplicação em
pauta, a arquitetura proposta é independente da mesma. Dessa forma, os testes serão realizados
em uma aplicação de fachada, apenas a título de ilustração.
2.2 Dados Geoespaciais
Os dados geoespaciais coletados podem ser das propriedades geométricas e topológicas e
armazenados em bases de dados gerenciadas por Sistemas Gerenciadores de Bancos de Dados
(SGDBs) comuns, porém utilizando-se extensões específicas para o tratamento do conteúdo.
Os dados requisitados pelo usuário serão buscados nessas bases e disponibilizados na interface
web. Por serem dados sensíveis, é preciso garantir sua integridade e confiabilidade ainda que a
21
rede seja invadida, de acordo com o princípio de defesa em profundidade. Dessa forma, faz-se
mister a análise dos sistemas criptográficos disponibilizados pelas ferramentas utilizadas de
modo a verificar se são satisfatórios.
2.2.1 PostgreSQL e PostGIS
PostgreSQL é um SGBD objeto-relacional, com ênfase na capacidade de extensão e
padrões de conformidade. Como um servidor de banco de dados, sua principal função é
armazenar dados de forma segura, conforme as boas práticas.
Já o PostGIS é uma extensão da base de dados espaciais para banco de dados objeto-
relacional PostgreSQL. Ele adiciona suporte para objetos geográficos, permitindo consultas de
localização a serem executadas em SQL. Além de reconhecimento espacial, o PostGIS oferece
muitos recursos raramente encontrados em outros bancos de dados espaciais concorrentes,
como Oracle Locator / Spatial ou SQL Server.
2.2.2 Geoserver
O GeoServer é um software livre escrito em Java que possibilita aos usuários o
compartilhamento e edição de dados geoespaciais como servidor Web Map Service (WMS). Foi
projetado com foco na interoperabilidade, ou seja, é capaz de extrair dados de qualquer fonte
de dados espaciais dos padrões abertos da atualidade. O servidor em questão conta com uma
interface de administração web, Web Administration Tool, usada para configurá-lo em diversos
aspectos desde adicionar dados aos bancos até mudanças nas configurações – inclusive
configurações de segurança, que serão exploradas mais a frente.
Existem algumas maneiras padronizadas de se integrar o GeoServer em uma aplicação
Java, uma delas é pelo uso de requisições especificas ao servidor do GeoServer para criar uma
imagem de mapa personalizado. Essa imagem é composta por diversas camadas sobrepostas
com informações adicionais ao mapa base. Por exemplo, um mapa de um bairro pode conter
uma camada para escolas e outra para pontos de ônibus.
Como exemplo, temos a seguinte requisição WMS e sua respectiva resposta:
22
http://localhost:8080/geoserver/wms?bbox=-130,24,-66,50&styles=polygon&Format=
application/openlayers&request=GetMap&layers=usa:states&width=550&height=250&
srs=EPSG:4326
Essa requisição tem como resultado um mapa com uma única camada contendo os estados
dos Estados Unidos da América. O resultado da consulta será disponibilizado conforme ilustra
a FIG. 2.1
FIG. 2.1 - Resultado de uma requisição WMS ao GeoServer
2.3 Cenários
Com o intuito de verificar as soluções de segurança desta arquitetura, um cenário foi
visualizado como forma de exemplificar e testar as soluções. Considere uma operação militar
destinada a realizar a segurança de comitivas na locomoção entre hotéis e locais de jogo durante
as Olimpíadas de 2016 no Rio de Janeiro. O sistema fornecerá mapas que auxiliam a equipe de
segurança, assegurando a confidencialidade, integridade e disponibilidade dos dados,
independentemente da infraestrutura externa da rede.
As camadas de mapas existentes são:
atrações
23
bairros
atrações
comitês
competições
corpo de bombeiros
delegacias
policiais
hotéis
Os grupos de usuários são:
Administrador
Estratégico
Tático
Operacional
Os dados referentes às camadas acessadas por cada grupo de usuário serão armazenados
em um arquivo xml da aplicação. Como parte do cenário, algumas situações de risco serão
implementadas, para que a arquitetura possa ser testada. Para tanto, supõe-se que o sistema
estará sob ação de usuários mal-intencionados que realizam as seguintes atividades a serem
mitigadas:
Ataques DoS
Varredura de portas
2.4 Ambiente de testes
O ambiente no qual foram realizados os testes determina parte do desempenho obtido,
especialmente a capacidade de processamento e memória disponíveis. A utilização de máquinas
virtuais foi escolhida principalmente para que não fosse necessário utilizar mais de uma
máquina física. Embora essa solução não simule as condições precisas em que o servidor de
hospedagem encontrar-se-á, é suficiente para a demonstração da funcionalidade do sistema.
2.4.1 Configurações
Todos os testes unitários foram executados utilizando-se:
24
1 máquina física hospedeira Inspiron 15 7000 Series:
o processador Intel® Core i7 TM
o Placa gráfica dedicada NVIDIA® de 2GB
o 16 GB de memória RAM
o 1 TB de armazenamento
o Sistema operacional Windows 8
1 máquina virtualizada no Virtual Box simulando o servidor que hospeda a
aplicação:
o Sistema operacional Ubuntu Server 14.04 LTS (64 bits)
o 3072 MB de memória RAM
o 1 CPU
o 16 MB de memória de vídeo
o Conectada à placa de rede exclusiva de hospedeiro (host-only) em modo
promíscuo
1 máquina virtualizada no Virtual Box® simulando o atacante:
o Sistema operacional Kali 1.1.0 (64 bits)
o 2816 MB de memória RAM
o 1 CPU
o 16 MB de memória de vídeo
o Conectada à placa de rede exclusiva de hospedeiro (host-only) em modo
promíscuo
25
3 SEGURANÇA ORGÂNICA DE DADOS
A segurança dos dados é mantida por meio de sistemas de autenticação e criptografia,
conforme ilustra a FIG. 3.1. A requisição é feita utilizando-se o protocolo seguro HTTPS, que
implementa criptografia. Antes de acessar os dados, o usuário deve ser autenticado pelo sistema
a ser desenvolvido, que consulta o banco de dados local de usuários. Caso o usuário seja
autorizado, a requisição é encaminhada para o servidor web, que consulta o Geoserver e seu
banco de dados geoespaciais, também criptografados. A resposta segue o caminho inverso e
retorna/ para a aplicação no lado do usuário na forma de uma imagem.
FIG 3.1 - Arquitetura da segurança orgânica
3.1 Controle de usuários
De acordo com o princípio de mínimo privilégio, o usuário deve ter acesso somente aos
recursos realmente necessários. Apesar do sistema final possuir páginas públicas – que
poderiam ser acessadas por qualquer usuário da rede - algumas delas podem conter conteúdo
sensível ou páginas de configuração que deveriam ser acessadas somente por usuários
26
devidamente autorizados. Para o sistema, a informação sensível é o conteúdo dos mapas
discretizado por suas camadas. Logo o objetivo do controle de usuário é identificar um usuário
e decidir se ele possui ou não acesso à camada que está solicitando.
Para o usuário do sistema, esta autenticação consiste basicamente na inserção do par Nome
de usuário (login) e Senha. Uma vez que estes dados são inseridos e verificados, o usuário terá
acesso a páginas especificas previamente definidas pelo sistema.
Para isso, o sistema de controle é baseado em quatro conceitos: Reinos, Usuários, Grupos
e Funções (Realms, Users, Groups and Roles). Cada um desses conceitos é definido a seguir:
Reino: é um completo banco de dados de usuários e grupos que identificam usuários
válidos de uma aplicação web (ou um conjunto de aplicações web) e são controladas pela
mesma política de autenticação.
Usuário: é uma identidade individual (ou o programa aplicativo) que foi definido no
servidor de aplicações, geralmente representando pessoas. Em uma aplicação web, um usuário
pode ter um conjunto de funções associadas a essa identidade, o que lhes dá direito a acessar
todos os recursos protegidos por essas funções. Os utilizadores podem ser associados com um
grupo.
Grupo: é um conjunto de usuários autenticados, classificados por traços comuns,
definidas no servidor de aplicações.
Função: é um nome abstrato para a permissão acesso a um determinado conjunto de
recursos em um aplicativo.
O processo de mapeamento de usuários em seus grupos com respectivas funções pode ser
é ilustrado na FIG. 3.2.
27
FIG. 3.2 - Esquematização do mapeamento de usuários em seus grupos
Um mapa é composto de uma ou mais Camadas sobrepostas e o Usuário tem acesso restrito
a estas. Para isso, cada Função de Usuários está relacionada a um conjunto de Camadas a que
tem acesso, o que também está ilustrado na FIG. 3.2.
Para o sistema em si, poderá ser utilizado o sistema de Autorização da Oracle para sistemas
em Java Web (ORACLE, 2015). A Autorização fornece acesso controlado a recursos
protegidos e baseia-se nos conceitos de Identificação e Autenticação:
Identificação: processo que permite o reconhecimento de uma entidade por um sistema.
O procedimento de Identificação é realizado com auxílio das funções login e logout built-in do
Java EE GlassFish Server (ORACLE, 2015). Para isso, foram criadas as classes Login, Logout
e LoggedInHttpServlet que herdam a classe HttpServlet, disponíveis em anexo. Todas as
páginas que necessitam de identificação do usuário são filhas de LoggedInHttpServlet e quando
acessadas podem ocorrer dois casos. No primeiro, se o usuário ainda não está identificado
(logado) o sistema é redirecionado à página de login (Classe Login) e após inserir seu login e
senha o sistema o redireciona novamente a página desejada anteriormente. Caso o usuário já
esteja identificado a página é acessada normalmente.
Autenticação: processo que verifica a identidade de um utilizador, dispositivo, ou outra
entidade num sistema de computador, geralmente como um pré-requisito para permitir o acesso
aos recursos num sistema. No sistema em questão, a Autenticação do Usuário se faz necessária
28
no momento em que este solicita o acesso a uma determinada Camada de um mapa. Para isso,
o sistema possui um arquivo xml, config-camadas.xml, que relaciona as Funções de cada Grupo
ou Usuário as respectivas Camadas que tem acesso. Uma vez que o usuário está identificado, a
classe LoggedInHttpServlet é capaz de acessar o arquivo acima e dizer se o Usuário tem direito
ao acesso àquela camada usando o método userHasCamada.
A FIG. 3.3 ilustra a estrutura do arquivo de configuração que possibilita a autenticação no
sistema. Vale ressaltar que o arquivo se encontra criptografado no Sistema Operacional pelo
servidor Glassfish e que a única maneira de modifica-lo é através do Sistema Web.
FIG. 3.3 - Extrato do mapeamento de usuários em seus grupos
O gerenciamento do sistema de controle de usuários é feito pelo painel de administrador
do Java EE GlassFish Server, conforme ilustra a FIG. 3.4.
29
FIG. 3.4 - Painel GlassFish de controle dos mapeamentos de usuários
Através do menu lateral Configurations/server-config/Security/Realms/file pode-se criar e
alterar Usuários, Grupos e Funções do Reino file (Reino padrão do Java EE, utilizado no
projeto). Deve-se também especificar as Funções no arquivo web.xml para que o Java EE possa
identifica-las e fazer a correlação com os Usuários e Grupos.
3.2 Segurança no PostgreSQL/PostGIS
A segurança dentro do banco de dados é baseada em Funções ou Papéis. Uma Função ou
Papel é geralmente relacionada a um usuário (uma Função que podem exercer), ou a um grupo
30
(uma Função composta por uma ou mais Funções). O PostgreSQL apresenta diversas
funcionalidades de segurança, as quais serão exploradas ao longo do projeto, o que facilita a
segurança do SGBD.
As permissões podem ser concedidas ou revogadas em qualquer objeto até o nível mais
baixo de abstração (uma coluna de uma tabela), e também pode permitir ou impedir a criação
de novos objetos em nível de banco de dados, esquemas ou tabelas.
Existem também outros recursos de segurança externos utilizados pelo PostgreSQL:
Senhas (utilizando MD5 ou em texto claro)
GSSAPI
SSPI
Kerberos
ident (mapeia nomes de usuário O/S conforme fornecido por um servidor de identidades
para nomes de usuário no banco de dados)
peer (mapeia nomes de usuários locais para nomes de usuário no banco de dados)
LDAP
Active Directory
RADIUS
Certificados de segurança
PAM
Estes métodos são especificados em um arquivo de configuração de autenticação
(pg_hba.conf), que determina quais conexões são permitidas. Isso permite o controle de qual
usuário pode se conectar a qual banco de dados, de onde eles podem se conectar (endereço IP
ou intervalo de endereços IP / socket de domínio), que o sistema de autenticação será aplicado,
e se a conexão deve usar TLS.
31
Como o PostGIS é uma extensão do PostgreSQL, ele possui basicamente as mesmas
características quando em se tratando de segurança.
3.3 Segurança no Geoserver
O GeoServer possui um subsistema de segurança bastante robusto, com base no Spring
Security - uma estrutura que se concentra em fornecer autenticação e autorização para
aplicações Java. A maior parte dos recursos de segurança podem ser configurados diretamente
pela interface de administração web.
Como um todo, as configurações de segurança do GeoServer podem ser divididas de
acordo com o menu exibido na FIG. 3.5 (definido no próprio GeoServer):
FIG. 3.5 - Configurações de segurança do GeoServer
3.3.1 Configurações gerais
A interface de usuário do GeoServer pode, por vezes, expor parâmetros em texto simples
no interior das URLs. Como resultado, pode ser desejável a criptografia desses parâmetros.
Como exemplo, pode-se ver nas FIG. 3.6 e FIG. 3.7 duas URL sem e com a funcionalidade
de criptografia, respectivamente.
32
FIG. 3.6 - URL sem funcionalidade de criptografia
FIG. 3.7 - URL com funcionalidade de criptografia
3.3.2 Senhas
De maneira análoga ao que ocorre no PostgreSQL/PostGIS, o GeoServer possui a função
de criptografar as senhas utilizadas no servidor. Como essas senhas são normalmente
armazenadas no disco é fortemente recomendado que elas sejam criptografadas e não
armazenadas em texto claro. O GeoServer fornece quatro esquemas de criptografia de senhas:
empty, plain text, Digest, e Password-based encryption (PBE). Neste caso, a criptografia não é
reversível. As senhas são codificadas como uma cadeia vazia, e, como consequência, não é
possível recuperar a senha em texto claro. Este esquema é utilizado quando outros serviços de
autenticação estão disponíveis.
Senhas de texto simples não possuem qualquer criptografia. Neste caso, as senhas são
legíveis por qualquer pessoa que tenha acesso ao sistema de arquivos. Por razões óbvias, este
esquema não é recomendado exceto em caso de simples testes do servidor. Por exemplo, a
senha mypassword é codificada simplesmente como: plain:mypassword, o prefixo é usado
apenas para descrever o algoritmo usado para codificação/decodificação.
Digest é um modo de criptografia não reversível. Aplica-se 100.000 vezes através de um
processo iterativo uma função hash usando SHA-256. Este esquema é "one-way", no sentido
de que é praticamente impossível reverter e obter a senha original a partir de sua representação
hash. Para proteger contra ataques conhecidos, um valor aleatório chamado salt é adicionado a
senha. Para cada Digest, é adicionado um salt de forma aleatória de modo que a mesma senha
criptografada duas vezes resulta em diferentes representações hash.
33
A PBE, normalmente emprega uma senha fornecida pelo usuário para gerar uma chave de
criptografia. Este esquema é reversível e utiliza um salt aleatório para aumentar a segurança
contra ataques de força bruta. O GeoServer suporta duas formas de PBE:
PBE fraco (o padrão do GeoServer): utiliza um método de criptografia básica que é
relativamente fácil de quebrar. A chave de criptografia é derivada da senha usando MD5 1000
vezes de forma iterativa. O algoritmo de criptografia utilizado é o DES. O DES tem um
comprimento de chave eficaz de 56 bits, o que não é realmente um desafio para os sistemas de
computador nestes dias.
PBE forte: utiliza um método de criptografia mais forte baseado em um algoritmo AES
de 256 bits com CBC. O comprimento da chave é de 256 bits e é derivado utilizando SHA-256,
em vez de MD5. A utilização do PBE forte é altamente recomendável e será a forma utilizada
como padrão para este projeto.
3.3.3 Autenticação, senhas, usuários, grupos e funções
Por padrão, o GeoServer permite o acesso anônimo a interface de administração web. Sem
autenticação, os usuários ainda são capazes de acessar algumas funcionalidades como visualizar
camadas e detalhes básicos GeoServer.
Essa autenticação consiste basicamente em um par Usuário-Senha para permitir ou não o
acesso a determinados recursos. Usuários podem ser divididos em Grupos com características
especificas (Funções específicas) de acesso ao sistema e do próprio controle administrativo
sobre outros usuários. A interface do GeoServer é bastante intuitiva e aproveita os recursos já
existentes de usuários das próprias tabelas do postgresSQL/postGIS, ou seja, pode-se reutilizar
os Usuários e Grupos do postgresSQL/postGIS no GeoServer.
34
3.3.4 Dados
Pela interface administrativa do GeoServer, é possível especificar regras de acesso a Dados
específicos para Usuários ou Grupos específicos. Para cada par Workspace-Layer definem-se o
tipo de modo de acesso (Leitura, escrita ou admin) e as Funções acessíveis. A FIG. 3.8 ilustra
a interface administrativa do GeoServer.
FIG. 3.8 - Interface administrativa do GeoServer
35
3.3.5 Serviços
De maneira análoga aos Dados, podemos especificar regras de acesso a Serviços
específicos. Para cada par Service-Method definem-se as Funções acessíveis. A FIG. 3.9 ilustra
regras de acesso a serviços específicos do GeoServer.
FIG. 3.9 - Regras de acesso a serviços específicos do GeoServer
3.4 Criptografia do banco de dados
De acordo com o princípio da segurança em profundidade, se as linhas de defesa mais
externas – como por exemplo firewalls ou autenticação – forem derrubadas, é necessário que
haja outra linha de defesa que suporte a falha da primeira. Essa linha de defesa consiste em
criptografar o texto claro armazenado.
36
Segundo (STALLINGS, 2006), dois tipos principais de criptografia de dados podem ser
implementados em uma aplicação – pode-se criptografar elementos de uma tabela, como linhas
ou células, ou a TDE.
Para o primeiro tipo, a aplicação deverá implementar funcionalidades tais que, cada vez
que um dado for salvo no banco de dados, este, se necessário, não seja salvo em texto claro,
mas sim criptografado. A aplicação deve se responsabilizar por criptografar e descriptografar
as informações quando necessário e de todo o controle de chaves que realizarão este sistema de
criptografia. A FIG. 3.10 ilustra o funcionamento simplificado de um algoritmo criptográfico.
FIG. 3.10 - Esquema simplificado do funcionamento de um algoritmo criptográfico genérico
Se algum usuário mal-intencionado obtiver acesso aos arquivos do sistema burlando a
segurança mais externa ou até mesmo com o acesso físico ao servidor, o acesso ao arquivo
config-camadas.xml não pode ser permitido. Por isso, seu conteúdo será criptografado e seu
acesso será através do próprio sistema, para usuários devidamente autorizados (Usuários
pertencentes ao Grupo de Administradores). Em uma página específica da aplicação é possível
alterar o conteúdo desse arquivo de maneira segura.
Existe também uma abordagem em que a aplicação web deixa a responsabilidade da
criptografia de dados para um outro módulo utilizando o método de TDE, a qual foi utilizada
no presente projeto. De acordo com (CHESWICK, BELLOVIN e RUBIN, 2003), uma TDE
permite a criptografia simples e fácil para dados sensíveis em colunas sem que os usuários ou
aplicativos gerenciem a chave de criptografia. Não há necessidade de implementar módulos
para criptografar ou descriptografar os dados, porque os dados são transparentes para a
37
aplicação – uma vez que um usuário passou verificações de controle de acesso necessárias. Os
administradores de segurança têm a garantia de que os dados no disco são criptografados, mas
a manipulação de dados criptografados se torna transparente para os aplicativos. Este tipo de
criptografia é utilizado na criação e no gerenciamento de Usuários, Grupos e Funções pela
plataforma do Java EE GlassFish Server.
3.5 Protocolo de transferência segura de dados (HTTPS)
De acordo com (STALLINGS, 2006), HTTPS se refere a combinação dos protocolos
HTTP e SSL na implementação de uma comunicação segura entre o navegador e o servidor
web, conforme ilustra a FIG. 3.11. A capacidade de suportar HTTPS é nativa na maioria dos
navegadores modernos, mas seu uso depende do servidor web suportar a comunicação HTTPS.
Páginas HTTPS normalmente utilizam um dos dois protocolos de segurança para
criptografia de dados - SSL ou TLS (ORACLE, 2015), sendo o primeiro o mais comum. Tanto
o SSL quanto o TLS utilizam um sistema de criptografia assimétrica.
FIG 3.11 - Relação entre HTTP e HTTPS (HTTPS = HTTP + SSL)
38
SSL é usado juntamente ao protocolo TCP para fornecer um serviço seguro de confiança
ponta-a-ponta. Na verdade, SSL não é um único protocolo, mas sim duas camadas de
protocolos, como ilustrado na FIG. 3.12 Três protocolos de camadas mais altas são definidos
como parte do SSL: o Protocolo de Handshake, o Protocolo de troca de cifras, e o Protocolo de
Alerta (Handshake Protocol, The Change Cipher Spec Protocol, e Alert Protocol).
FIG. 3.12 - Esquema gráfico do protocolo SSL
A principal diferença vista pelos usuários é que na URL endereços começam com https: //
em vez de http: //. Tem-se também que uma conexão HTTP usa a porta 80 enquanto HTTPS
usa a porta 443, utilizando-se do SSL.
Em geral, em uma conexão HTTPS, os seguintes elementos são criptografados:
URL do documento requisitado
Conteúdo do documento
Conteúdo de formulários preenchidos pelo usuário
Cookies enviados do navegador para o servidor e vice-versa
39
Conteúdo do cabeçalho HTTP(S)
HTTPS é frequentemente usado para proteger transações on-line altamente confidenciais,
como serviços bancários on-line e formulários de pedidos de compras on-line. No caso deste
projeto, será utilizado para proteger o sistema contra a ataques mal-intencionados e prevenção
do roubo de informações que transitam na rede.
Para que o protocolo HTTPS seja utilizado, é necessário especificar no arquivo web.xml
quais páginas utilizarão o protocolo. Como o protocolo implica em uma perda de desempenho
na transmissão de requisições e respostas, devido ao tempo de criptografia e decriptografia, ele
só deve ser utilizado nas páginas do sistema em que seja realmente necessário. Para efeito deste
trabalho, quando um usuário tenta acessar uma página reservada - com acesso restrito em que
é necessário realizar o login do usuário - ele é automaticamente redirecionado para a página
inicial de login, caso não esteja logado. Logo, na página inicial de login será usado o protocolo
HTTPS enquanto que nas outras páginas será utilizado o HTTP.
O GlassFish Server utiliza um certificado auto assinado que é gerado automaticamente
mas, para este projeto, será criado um novo certificado que substituirá este. Para tal criação,
utiliza-se a ferramenta Keytool, que é instalada junto ao GlassFish. Com os comandos abaixo
pode-se criar um certificado auto assinado e adicioná-lo a biblioteca de certificados do
GlassFish Server.
Criar certificado keystore.jks
keytool -genkey -alias s1as -keyalg RSA -keypass changeit -keystore keystore.jks
Exportar certificado para um arquivo server.cer
keytool -export -alias s1as -keypass changeit -storepass changeit -keystore
keystore.jks -file pfc.cer
Deletar o certificado original
keytool -delete -alias s1as -keystore /{glassfish-
path}/glassfish/domains/domain1/config/cacerts.jks
-storepass changeit
40
Adicionar o certificado criado a trustsore
keytool -import -trustcacerts -alias s1as-file pfc.cer -keystore /{glassfish-
path}/glassfish/domains/domain1/config/cacerts.jks,
em que s1as é o alias e changeit é a senha do certificado, ambos mantidos como o padrão
original.
Assim, quando a página de login do sistema é acessada, as informações do certificado
podem ser vistas por qualquer navegador, como pode ser visto na FIG. 3.13:
FIG. 3.13 – Certificado auto assinado gerado para a aplicação
Portanto, para o certificado ser completamente válido, deve ser verificado por uma
Autoridade Certificadora. Contudo, isso não afeta em nada a criptografia na transmissão de
dados do sistema.
41
4 SEGURANÇA DA REDE
4.1 Estrutura geral
A FIG. 4.1 ilustra a arquitetura proposta para a segurança da rede, de modo a tornar o
sistema independente de sistemas de defesa externos. Os componentes são exibidos
independentemente para fins de ilustração, sendo que as setas indicam o sentido do fluxo de
pacotes recebidos.
FIG. 4.1 - Fluxo de recebimento de pacotes na arquitetura proposta.
O fluxo de um pacote malicioso que entra no sistema é passar pelas regras do firewall e,
caso não esteja de acordo com alguma delas, o pacote é registrado em um arquivo de logs do
42
sistema. Esse mesmo arquivo é monitorado pelo psad, que, ao verificar a existência de um
abuso, gera e-mails para os administradores e bloqueia o IP do atacante. Uma ferramenta
desenvolvida durante o projeto monitora os IPs bloqueados e fornece como entrada para o
firewall. Dessa forma, os próximos pacotes vindos desse IP serão encaminhados para um
honeypot, ao invés de seguirem para a aplicação normalmente.
4.2 Firewall
O firewall é um dispositivo inserido entre a rede a ser defendida e a Internet de modo a
estabelecer um enlace controlado bem como uma barreira ou um perímetro de segurança. Na
arquitetura proposta, portanto, o firewall tem por objetivo atuar como a primeira barreira de
defesa, isolando os sistemas interno e externo, além de estabelecer um ponto de
estrangulamento onde auditorias de segurança podem ser realizadas (RASH, 2007). A ausência
do mesmo implica na abertura do sistema para qualquer tipo de ataque, incluindo negação de
serviço, varredura de portas e impersonação de IP.
Os firewalls possuem as seguintes propriedades (JOSHI, SARDANA, 2011):
1. todo tráfego de dentro para fora de uma rede, e vice-versa, deve passar pelo firewall;
2. apenas tráfego autorizado, como definido pela política de segurança local, terá
permissão de passar;
3. o próprio firewall é imune a penetrações.
Podemos afirmar, portanto, que o firewall atua sob os princípios de defesa em profundidade
e centralização de fluxo.
Embora o firewall ofereça uma importante proteção contra ameaças externas à rede,
existem alguns pontos em que o firewall não é efetivo, fazendo-se as demais ferramentas mister
para o completo funcionamento da arquitetura em pauta, a saber:
O firewall não pode proteger contra ataques que o transpassem.
O firewall é incapaz de proteger a rede contra ameaças internas.
43
O firewall não oferece resistência frente à transferência de vírus instalados em arquivos
e programas.
Em certos casos altos volumes de tráfego de rede podem sobrecarregar a capacidade de
monitoramento do firewall, resultando na possiblidade de tráfego malicioso entre redes
(ANDREU, 2006).
4.2.1 Netfilter/iptables
A implementação do firewall foi feita utilizando-se o módulo netfilter do Linux e a
aplicação iptables, para a criação das regras. O netfilter é uma ferramenta nativa do kernel do
Linux que fornece funções de controle de fluxo interno em termos de firewall. O netfilter é
dividido em três tabelas padrões: Filter, Nat e Mangle, cada qual com seus objetivos
específicos. A tabela Filter guarda todas as regras aplicadas a um firewall filtro de pacotes; a
tabela Nat armazena as regras direcionadas a um firewall Nat e a tabela Mangle funções mais
complexas de tratamento de pacotes.
O iptables foi desenvolvido pelo Projeto Netfilter e tornou-se público como parte do
sistema Linux desde o lançamento do Linux 2.4 em janeiro de 2001 (Russel, 2001). Consiste
basicamente em uma interface front-end para manipular as tabelas do Netfilter e não em um
firewall especificamente. Ao longo dos anos o iptables amadureceu em uma aplicação completa
com a maior parte das funcionalidades típicas encontradas em firewalls comerciais. Dentre suas
principais funcionalidades citamos (Rash, 2007):
Rastreamento de estado de protocolo
Inspeção de pacotes de camada de aplicação
Política de filtragem
A filtragem de pacotes, um dos principais recursos a ser utilizado, é, portanto, facilitada
por meio do controle do kernel do Linux pelo iptables. Uma política pode ser construída
explicitando-se um conjunto de regras que permitem a passagem de pacotes a serem aceitos e
rejeitando os demais. Cada regra é aplicada a uma cadeia em uma das tabelas do Netfilter. Uma
44
cadeia, portanto, é uma sequência ordenada de regras que são comparadas com pacotes que
compartilham uma característica em comum. As três cadeias mais importantes embutidas na
tabela Filter são INPUT, OUTPUT e FORWARD.
A cadeia INPUT contém regras que determinam o que será feito com todos os pacotes que
entram em uma interface específica (Urubatan, 2004). A cadeia FORWARD trata dos pacotes
que chegam ao host mas devem ser redirecionados a um host secundário ou outra interface de
rede, enquanto que a cadeia OUTPUT trata os pacotes que saem do host.
As tabelas Nat e Mangle contém duas cadeias adicionais denominadas PREROUTING, que
altera os pacotes quando entram na interface, e POSTROUTING, que é utilizada para alterar
pacotes quando estes estão prontos para deixar o host A FIG. 4.2 esquematiza o funcionamento
de filtragem de pacotes pelo iptables (RUSSEL, 2001).
FIG. 4.2 - Fluxo de pacotes no iptables
4.2.2 Requerimentos da política de segurança
A definição das regras de firewall deve seguir os requisitos estabelecidos na política de
segurança do sistema. É comum ser requisito do administrador liberar o acesso da máquina
servidora pelo firewall para acessar sistemas externos à rede, nos seguintes serviços:
Consultas Domain Name System (DNS)
Consultas Network Time Protocol (NTP)
45
Sessões Secure SHell (SSH)
Sessões Simple Mail Transfer Protocol (SMTP)
Sessões Web via HTTP/HTTPS
Consultas whois
Exceto pelos serviços listados, todo tráfego deve ser bloqueado. Sessões iniciadas a partir
da rede interna ou diretamente do firewall devem ter estado rastreado pelo iptables, de modo
que pacotes que não estejam de acordo com um estado válido sejam registrados e descartados.
Além disso, o firewall deve implementar ainda os seguintes controles contra pacotes spoofed
provenientes da rede interna com destino para IPs externos, assim como pacotes característicos
de varreduras de portas de acordo com as flags utilizadas:
O sistema deve ser acessível via SSH somente a partir da rede interna.
O firewall deve aceitar requisições ICMP Echo tanto das redes interna quanto externa,
mas pacotes que não sejam requisições ICMP Echo devem ser descartados independente
do IP de origem.
O sistema deve ser configurado de forma a registrar e descartar quaisquer pacotes
inválidos, tentativas de varredura de porta ou outras tentativas de conexão não
explicitamente permitidas.
Considerando as restrições acima, foram elaboradas as regras do iptables, disponíveis em
arquivo anexo.
4.3 Sistema de detecção de intrusão
Tendo em vista a incapacidade do firewall em proteger a rede sob diversos aspectos, o
sistema de detecção de intrusão torna-se um componente importante dentro do arsenal de defesa
do sistema e tem como objetivo detectar atividades suspeitas, impróprias, incorretas ou
anômalas. Além de ser crucial para a segurança interna, o IDS pode detectar ataques que são
46
realizados por meio de portas legítimas e que, portanto, não podem ser protegidos pelo firewall.
(STALLINGS, 2007)
Enquanto o firewall atua como a primeira linha de defesa para a rede, impedindo conexões
indesejadas, o IDS pode ser definido como um monitor de atividades na rede em tempo real,
capaz de enviar alertas quando detectar pacotes que possam fazer parte de um possível ataque.
(NAKAMURA, GEUS, 2002) A utilização em conjunto dos dois dispositivos, portanto, está de
acordo com o princípio de defesa em profundidade e oferece nível considerável de segurança
ao administrador do sistema.
Assim como o firewall, o IDS falha em diversos aspectos críticos da proteção da rede, o
que torna interessante a utilização das demais ferramentas presentes na arquitetura em pauta, a
saber:
A implementação mais comum do IDS é no próprio gateway da rede, normalmente um
switch, implicando na impossibilidade do IDS monitorar parte do tráfego na rede e na
consequente vulnerabilidade contra ataques internos.
A velocidade das redes modernas é tão alta que muitas vezes um IDS apresenta
dificuldades em manter-se ativo.
Produção de sobrecarga de dados ao gerar um volume extremamente grande de alertas,
o que consome tempo, recursos e investimentos para a analisar e revisar os alertas.
O intenso monitoramento da rede pode, portanto, exigir hardware que suporte a atividade
e o tráfego intenso da rede. Alguns IDS apresentam também dificuldade em descobrir ou
identificar ataques ou comportamentos desconhecidos, tornando a organização vulnerável a
novos ataques. Por fim, com a presença cada vez maior da criptografia em protocolos como
SSH, SSL e IPSec cegam os IDS, que se tornam incapazes de monitorar o tráfego da rede
(JOSHI, SARDANA, 2011).
47
4.3.1 Snort
O Snort é um IDS leve que tem capacidade de registrar pacotes que entram na rede. Suas
regras seguem uma sintaxe específica e serão utilizadas para a conversão em regras iptables por
meio do fwsnort. O Snort pode atuar em três modos diferentes, de modo que suas regras se
adequam a uma das três situações seguintes: (KOZIOL, 2003)
Modo sniffer, que simplesmente lê os pacotes da rede e os exibe em fluxo contínuo no
console.
Modo registrador de pacotes, que registra no disco os pacotes recebidos.
Modo NIDS, que realiza detecção e análise do tráfego da rede. Esse é o modo mais
configurável e complexo.
Embora o Snort não seja o único IDS disponível, as seguintes características fizeram com
que fosse escolhido para o protocolo em pauta (SCOTT, WOLFE, HAYES, 2004), o que
confere credibilidade e disponibilidade de suas regras e sintaxe:
Código aberto: seu código fonte está disponível gratuitamente, o que lhe confere maior
adaptabilidade e maior segurança sobre seu funcionamento.
Largamente utilizado: o Snort surgiu em 1998 e hoje conta com milhões de sensores
instalados ao redor do mundo. (CISCO, 2014)
Completamente configurável: é possível configurar o Snort para atuar sob a arquitetura
do sistema, bem como estabelecer regras específicas para ataques.
Atualizações constantes: novas assinaturas são disponibilizadas regularmente,
garantindo sua funcionalidade perante novos ataques.
Multiplataforma: roda tanto em plataformas Unix (incluindo Linux) quanto em sistemas
Microsof Windows, permitindo migrações futuras, caso necessário.
As regras Snort não são gratuitas desde 7 de Março de 2005 (SNORT, 2015), de modo que
foram utilizadas regras provenientes da comunidade para alimentar o fwsnort. Dessa forma,
48
foram utilizadas as regras disponibilizadas pela comunidade, organizadas pela Emerging
Threats (EMERGING THREATS, 2015), anteriormente denominada Bleeding Edge. Os
conjuntos de regras disponíveis são públicos, gratuitos e atualizados constantemente, servido
como fonte suficiente para as regras gerais do sistema de detecção de intrusão.
4.3.2 Fwsnort
O fwsnort é um software escrito em Perl que traduz regras Snort em regras iptables
equivalentes. O projeto fwsnort utiliza as capacidades de filtragem e inspeção de pacotes
disponíveis no iptables, incluindo uso intenso da extensão de casamento de strings, com o
intuito de encontrar regras Snort as mais próximas possível do conjunto de regras iptables.
Embora não seja possível traduzir completamente as regras Snort, cerca de 70% das regras
podem ser reescritas como regras iptables.
Ao contrário do Snort, que normalmente é empregado como uma instância passiva para
monitorar o tráfego de rede em busca de atividades suspeitas, o fwsnort é sempre empregado
em linha. Dessa forma, qualquer política do fwsnort pode ser configurada para rejeitar pacotes
maliciosos por meio do comando DROP do iptables (RASH, 2007).
Utilizando-se as regras Snort para proteção de servidores web disponibilizadas pela
comunidade, foi possível obter uma taxa de conversão de mais de 55%, conforme ilustra a FIG.
4.3. Embora este resultado exclua muitas regras, seu resultado é satisfatório, considerando-se
que o fwsnort é utilizado como complemento para o psad.
49
FIG. 4.3 - Conversão das regras Snort para regras iptables com fwsnort (taxa de sucesso em destaque).
A FIG 4.4 mostra um exemplo de uma regra snort convertida pelo fwsnort em regra
iptables.
FIG. 4.4 - Exemplo de regra Snort convertida com sucesso pelo fwsnort.
4.4 psad
O psad é um IDS que atua na camada de aplicação e é baseado na análise de logs gerados
pelo iptables, incluindo aqueles provenientes das regras Snort traduzidas pelo fwsnort. Quando
utilizado em conjunto com o fwsnort e a extensão de localização de strings do Netfliter, o psad
é capaz de detectar muitos ataques descritos pelo conjunto de regras do Snort que envolvem a
50
camada de aplicação de dados. Como exemplos de características do psad que justificam seu
emprego citamos sua capacidade de detectar ferramentas de DDoS (mstream, shaft), programas
de backdoor (e.g. EvilFTP, GirlFriend, SubSeven) e técnicas avançadas de varredura de portas
(FIN, NULL, XMAS), comumente executados por meio da ferramenta nmap. Por utilizar
campos dos cabeçalhos dos pacotes recebidos em conjunto com pacotes TCP SYN, o psad pode
ainda determinar passivamente sistemas operacionais remotos das máquinas de onde os ataques
se originam (RASH, 2007).
A defesa ativa do psad consiste primariamente em bloquear automaticamente os endereços
IP que representem ameaça ao sistema, adicionando regras de firewall que impedem a
comunicação do atacante com o servidor. O bloqueio por IP é uma estratégia comum para a
mitigação de ataques como DoS, porém, como toda solução, possui falhas. Ataques mais
sofisticados podem utilizar redes de anonimato ou impersonação de IPs legítimos. Dessa forma,
é possível que o bloqueio de um IP não impeça outros ataques, ou mesmo evite acessos
legítimos ao sistema. O psad pode ainda, opcionalmente, ser configurado para realizar consultas
WHOIS aos atacantes, de forma a extrair mais informações.
Para reduzir falsos-positivos ou bloqueios indevidos, o psad classifica as ameaças de
acordo com sua base de dados em 5 níveis de gravidade. Dessa forma, é possível alterar o grau
de conservadorismo do sistema, que pode bloquear IPs apenas quando um nível pré-
determinado de ameaça for detectado. Ademais, ainda que haja algum bloqueio indevido, o
psad remove os itens de sua lista negra após um timeout configurável, definido como uma hora,
por padrão. Com isso, evita-se que usuários legítimos, vítimas de impersonação de IP, sejam
impedidos de comunicarem-se com o servidor.
Além do bloqueio automático, o psad conta ainda com um módulo de envio automático de
e-mails para os administradores da rede, de forma a alertá-los sobre possíveis ameaças. Caso
configurado para tal, o psad envia também os resultados das buscas WHOIS por e-mail.
51
4.5 Honeypots
Segundo (Joshi, Sardana, 2011), um honeypot é “Um programa que se parece com um
serviço atraente, um conjunto de serviços, um sistema operacional inteiro ou mesmo uma rede
inteira, mas é na verdade um compartimento fortemente isolado construído para iludir e conter
um atacante”. Dessa forma, a utilização de honeypots está de acordo com o princípio de defesa
ativa e permite a captura de informações relevantes sobre o comportamento do atacante.
O honeypot resolve parte das falhas deixadas pelo firewall e pelo IDS e permite que o
sistema seja protegido contra-ataques zero-day, ou seja, ainda não divulgados ou conhecidos
pela comunidade. Primeiramente, o honeypot apenas coleta dados quando ocorre interação com
o mesmo, de modo que o volume de alertas produzidos é consideravelmente menor, fazendo
com que os dados coletados pelo honeypot sejam muito mais fáceis de tratar e analisar.
Honeypots também reduzem dramaticamente falsos positivos, já que qualquer atividade com
honeypots é por definição não autorizada. Novos ataques podem ser facilmente identificados e
capturados por meio da análise das anomalias apresentadas nos logs. A baixa atividade dos
honeypots implica ainda em poucos requisitos de hardware. Por fim, ainda que um ataque ocorra
contra uma entidade criptografada, a atividade será registrada pelo honeypot (RASH, 2007).
Um honeypot deve ser colocado na mesma rede que o servidor, seja como um software ou
um dispositivo físico, mas devemos separar o honeypot das outras máquinas, no caso utilizando
as regras do firewall. Isso é importante para que a máquina que roda o serviço real seja
resguardada e ao mesmo tempo adicionarmos valor ao honeypot de modo a torná-lo atraente a
ataques. A virtualização, embora custosa em termos de recursos, é uma possível solução para
implementarem-se honeypots sem a disponibilidade de máquinas físicas (CHEWSICK,
BELLOVIN e RUBIN, 2003).
Com o crescimento da popularidade dos honeypots, as máquinas virtuais passaram a
desempenhar um papel importante. Como os honeypots não atendem a usuários legítimos,
apenas uma pequena parcela dos recursos do sistema é requisitada. As máquinas virtuais
proveem multiplexação de recursos, que permite que mais honeypots de alta interação rodem
no mesmo hardware. A tecnologia das máquinas virtuais torna realizável a colocação de mais
honeypots de alta interação no mesmo hardware. Além disso, as máquinas virtuais permitem
52
monitoramento mais profundo de atividades maliciosas em máquinas honeypot sem que os
atacantes percebam ou desabilitem o software de monitoramento.
A utilização de máquinas virtuais para honeypots têm suas desvantagens, entretanto. Até o
presente momento a virtualização completa de hardware não é suportada por processadores
Intel ou AMD. Um programa pode determinar se está rodando em uma máquina virtual
executando a instrução x86 SIDT em um nível não privilegiado. Um exemplo de programa que
faz isso é o redpill, ao examinar o resultado para determinar se está sendo executado em uma
máquina virtual. Atacantes podem usar o ataque redpill para evitarem honeypots que rodam
nesse tipo de máquinas. Para mitigar esses ataques com os processadores atuais seria necessário
traduzir instruções de emulação para binário, o que comprometeria o desempenho. No futuro,
tanto a Intel quanto a AMD pretendem lançar processadores que suportam virtualização
completa, tornando mais fácil que os honeypots sejam detectados por atacantes, de modo que é
possível que modificações à arquitetura apresentada sejam propostas.
4.6 Arquitetura final
A arquitetura proposta é descrita detalhadamente no fluxograma representado FIG. 4.5, em
que as setas azuis indicam a resposta do sistema.
FIG. 4.5 – Diagrama detalhado do fluxo de pacotes na arquitetura proposta
53
O daemon é um script desenvolvido para monitorar alterações no arquivo
auto_blocked_iptables, em que o psad armazena os endereços bloqueados. Dessa forma, cada
vez que um novo IP intrusivo é detectado pelo psad, o daemon o adiciona a um ipset, criado no
momento da instalação. A FIG. 4.6 apresenta o código do daemon.
FIG. 4.6 – Código do daemon responsável por monitorar os IPs bloqueados
4.7 Dificuldades encontradas
Como forma de contribuir para desenvolvimentos futuros, vale ressaltar aqui uma
dificuldade de implementação e a solução encontrada para que futuros usuários possam
executar a manutenção sem maiores dificuldades. Após o atacante ser redirecionado para o
honeypot, é fundamental que os pacotes de resposta sejam redirecionados para a máquina
servidora, de forma que esta encaminhe a resposta para o atacante. Caso essa etapa seja
negligenciada, ou seja, se o pacote de resposta for direcionado diretamente do honeypot para o
atacante, este o recusará, visto que não haverá coerência entre os cabeçalhos TCP.
A FIG. 4.7 ilustra o caminho correto de requisição (setas vermelhas) e resposta (setas azuis)
provenientes do atacante e do honeypot, respectivamente. O identificador FLAG X/Y simboliza
um pacote TCP com endereço de origem e destino X e Y, respectivamente, com a flag FLAG
ativada. No caso da FIG. 4.7, o atacante envia um pacote SYN para início do three-way
54
handhsake de A (atacante) para B (servidor). Em uma primeira tentativa, o servidor, já tendo
identificado o ataque, modifica o endereço de destino do pacote antes da decisão de roteamento,
portanto na cadeia PREROUTING do iptables, de B para C (honeypot). O ponto crítico surge
na reposta (seta verde), já que caso o honeypot simplesmente responda com um pacote ACK
C/A, o atacante receberá enviará RST A/C (seta amarela), já que a resposta esperada era ACK
B/A.
Dessa forma, foi preciso alterar a forma do honeypot de responder às requisições
encaminhadas do servidor. O servidor então deve alterar tanto o endereço de origem do pacote
a ser encaminhado quanto preparar para receber o retorno. Dessa forma, o servidor transforma
o pacote SYN A/C em SYN A/C e logo em seguida em SYN B/C. Assim, o pacote que chega no
honeypot é encaminhado novamente para o servidor, de onde é respondido para o atacante.
FIG. 4.7 – Problemas e soluções encontrados durante a implementação do encaminhamento do honeypot.
55
Outra dificuldade encontrada foi implementar o mecanismo de retroalimentação que
permite que novos IPs sejam dinamicamente adicionados à lista de IPs bloqueados pelo firewall.
A solução encontrada foi utilizar o módulo ipset e a opção - -match-set. Por meio do
daemon_update, os IPs registrados pelo psad no arquivo de texto auto_blocked_iptables são
inseridos no ipset banned_nets e novamente utilizados pelo firewall. A FIG. 4.8 ilustra o
mecanismo de retroalimentação em pauta.
.
FIG. 4.8 – Mecanismo de retroalimentação com destaque para o update_daemon, ponto crítico durante a
implementação
A FIG. 4.9 é um extrato das regras do firewall que permitem o encaminhamento
bidirecional para o honeypot. Vale notar ainda que a utilização do HTTPS não prejudica a
alteração dos cabeçalhos dos pacotes.
56
FIG. 4.9 – Extrato das regras do firewall responsáveis por realizar o encaminhamento bidirecional para o
honeypot
Visando ainda a facilitar a utilização do sistema, foram desenvolvidos scripts específicos
para a instalação e execução. Os scripts utilizam os repositórios debian e assumem que os
caminhos em que os pacotes são instalados equivalem aos da versão 14.04 do Ubuntu.
57
5 TESTES
A utilidade da arquitetura é validada por meio de testes que simulam possíveis cenários
reais. A comparação das situações com e sem o sistema fornecerá o grau de eficiência da
solução.
5.1 Penetração
Teste de penetração pode ser definido como uma tentativa legal e autorizada de localizar e
explorar com sucesso sistemas de computadores com o propósito de torná-los mais seguros. O
processo inclui a busca por vulnerabilidades bem como o fornecimento de provas de conceito
por meio de ataques para comprovar a existência das vulnerabilidades. Testes de penetração
sempre terminam com recomendações específicas para endereçar e resolver os problemas
encontrados durante o teste. Visto como um todo, esse processo é utilizado para ajudar a
proteger computadores e redes contra-ataques futuros (ANDREU, 2006). O teste de penetração,
portanto, será o recurso principal para que seja confirmada a validade da arquitetura quanto à
sua finalidade de proteger os recursos do servidor.
FIG. 5.1 - Fases principais de um teste de penetração
58
A metodologia a ser seguida nos testes de penetração segue padrões bem estabelecidos e
pode ser esquematizada de modo a simplificá-la pelo diagrama da FIG. 5.1. O princípio básico
de um teste de penetração é pensar e agir conforme um atacante e utilizar-se de todos os recursos
legais disponíveis para comprometer o sistema alvo. A utilização de uma metodologia
consagrada reduz o risco de falhas na identificação de possíveis problemas de segurança no
sistema.
A primeira etapa em qualquer teste de penetração é o reconhecimento, em que é realizada
a coleta do máximo de informações disponíveis. Pode ser passivo, caso em que não há contato
direto com o alvo e apenas informações públicas são agrupadas, ou ativo, quando há contato
direto com a vítima como no caso da utilização de engenharia social. Um dos produtos
essenciais da primeira fase é uma lista de endereços IP alvos a serem utilizados na próxima
fase. É fundamental ainda que essa etapa seja realizada de forma extensiva e recorrente para
que se tenha conhecimento das informações disponíveis a possíveis atacantes
(ENGEBRETSON, 2013).
A segunda fase da metodologia consiste em planejar o ataque e pode ser dividida em duas
atividades de varredura distintas. A primeira ocorre com a condução da varredura de portas,
cujo resultado esperado é uma lista de portas abertas e potenciais serviços rodando em cada
um dos alvos. A segunda atividade da fase de varredura é a varredura de vulnerabilidades, na
qual são localizadas e identificadas falhas específicas nos softwares e serviços de nossos alvos.
Com os resultados da fase anterior procedemos para a fase de obtenção de acesso, na qual
as vulnerabilidades serão exploradas. Como já se sabem exatamente quais as portas estão
abertas bem como quais os serviços que nelas rodam e quais as vulnerabilidades associadas a
esses serviços, é possível iniciar efetivamente o ataque ao alvo.
A fase final é conhecida como manutenção do acesso e consiste em implantar meios de se
permitir o acesso permanente do atacante. Essa fase é necessária uma vez que a maior parte dos
procedimentos da fase de exploração de vulnerabilidades não são persistentes, permitindo
apenas acesso temporário ao sistema. Com a implementação de backdoors criam-se
mecanismos de sobrevivência do sistema mesmo após o fechamento de programas e até da
59
reinicialização do sistema. Incluímos ainda na fase final a etapa de limpeza de rastros, em que
são apagadas as possíveis indicações do ataque.
5.1.1 Testes com a arquitetura parcial (sem honeypot)
Embora a arquitetura completa envolva a participação de um honeypot, sua utilização
implica em maior necessidade de recursos. Uma vez que naquele sistema todos os pacotes de
um atacante bloqueado seriam encaminhados para outra máquina, ao invés de descartados, a
arquitetura torna-se fortemente vulnerável a ataques de negação de serviço. Considerando então
a possibilidade de se necessitar de uma forma de reagir a ataques de DoS, o sistema fornece
também a possibilidade de, por meio da decisão do administrador, alternar-se entre as
arquiteturas com e sem honeypot.
5.1.1.1 Varredura de portas
A FIG. 5.2 ilustra uma tentativa de varredura de portas por um atacante com endereço IP
192.169.0.101 na mesma rede do servidor alvo, cujo IP é 192.169.0.103, sem qualquer tipo de
regras de firewall.
FIG. 5.2 - Exemplo de varredura de portas contra o servidor sem regras de firewall ativas.
Já a FIG. 5.3 representa o caso em que o firewall está ativo. O atacante recebe como
resultado apenas a porta 22 aberta, o que está de acordo com a política estabelecida, já que
apenas conexões SSH são admitidas na rede interna.
60
FIG. 5.3 - Exemplo de varredura de portas contra o servidor com regras de firewall ativas.
Conforme ilustra a FIG. 5.4, que apresenta os registros do log do firewall, diversos pacotes
são identificados de acordo com as regras do firewall e automaticamente descartados. O
resultado do ataque aparece como se todas as portas estivessem filtradas, sendo apenas a porta
22 aberta, o que está de acordo com as regras implementadas, já que o sistema deve ser acessível
via SSH a partir da rede interna.
FIG. 5.4 - Exemplo de tentativa de impersonação de IP.
61
Já a FIG 5.5 ilustra uma tentativa de conexão ICMP por um atacante de uma rede externa
utilizando o IP reservado 192.168.1.17, o que é negado pelas regras do firewall.
FIG. 5.5 - Exemplo de tentativa de impersonação de IP.
Conforme ilustra a FIG 5.6, os pacotes são identificados como tendo sido impersonados e
são rejeitados, de forma que o atacante não recebe resposta.
FIG 5.6 - Extrato do log do firewall registrando os pacotes impersonados descartados.
5.1.1.2 Ataque de negação de serviço (DoS)
A FIG. 5.7 ilustra o servidor em uma situação vulnerável, sem as regras de firewall ativas,
porém sem estar sendo atacado. O gráfico plotado registra o tráfego de pacotes tanto recebidos
(RX) quanto transmitidos (TX) na única interface, utilizando-se a ferramenta speedometer.
62
FIG. 5.7 - Tráfego de entrada e saída na interface do servidor sem regras de firewall e sem estar sob ataque de
negação de serviço.
O LOIC é uma das ferramentas de ataque de negação de serviço mais utilizadas atualmente,
tendo ganhado força por meio da divulgação do mesmo em ataques hacktivistas colaborativos
pelo grupo Anonymous. A FIG. 5.8 ilustra a interface gráfica do LOIC em execução contra o
servidor.
FIG. 5.8 - Painel de controle do LOIC em execução contra o servidor alvo.
Com o servidor vulnerável, sem regras de firewall, o servidor sofre nítida sobrecarga, se
comparado com a situação anterior, conforme atesta a FIG 5.9.
63
FIG. 5.9 - Tráfego de entrada e saída na interface do servidor sem regras de firewall e sob ataque de
negação de serviço.
Após as regras do firewall serem levantadas em conjunto com as regras de detecção do
fwsnort, o tráfego volta à situação de normalidade, conforme revela a FIG. 5.10. Após a
detecção do ataque, diversos pacotes são descartados
FIG. 5.10 - Tráfego de entrada e saída na interface do servidor com regras de firewall e sob ataque de
negação de serviço.
64
Em pouco tempo o psad detecta o ataque e em aproximadamente cinco minutos ocorre o
bloqueio. A FIG. 5.11 ilustra a situação do syslog quando do bloqueio. É possível notar ainda
que os emails são disparados em sequência, alertando o administrador remoto. Vale notar,
entretanto, que dependendo do nível de sensibilidade configurado para o psad, a quantidade de
e-mails pode tornar-se muito grande, dificultando a gerência do administrador.
FIG. 5.11 - Extrato do syslog indicando o bloqueio do atacante pelo psad e os emails enviados.
É possível visualizar ainda o estado do psad, incluindo principais ameaças e atacantes
bloqueados, conforme a FIG. 5.12.
65
FIG. 5.12 - Estado do psad após o bloqueio do atacante.
66
5.1.2 Testes com a arquitetura completa (com honeypot)
A presente simulação envolve agora três máquinas, representando um atacante, o servidor
da aplicação e um honeypot. Os endereços IP são 192.168.56.102, 192.168.56.101 e
192.168.56.100, respectivamente.
Conforme ilustra a FIG. 5.13, O cenário envolve novamente um atacante iniciando seu
ataque com uma varredura de portas. Em seguida, o sistema identifica o ataque e agora o
redireciona para o honeypot, que hospeda uma aplicação idêntica à do servidor real, mas com
dados fictícios. Dessa forma, toda movimentação do atacante será registrada em uma máquina
a parte, estando os dados da aplicação seguros.
FIG. 5.13 – Cenário para simulação dos ataques, envolvendo três maquinas virtuais.
5.1.2.1 Varredura de portas
Em um primeiro momento, o atacante visualiza a página alvo, obtendo como resultado em
seu navegador imagem semelhante à da FIG 5.14.
67
FIG. 5.14 – Visualização da página alvo antes do ataque
Em seguida, o mesmo atacante inicia uma varredura de portas, obtendo como resposta
os resultados ilustrados na FIG 5.15.
FIG. 5.15 - Varredura de portas no servidor (IP ainda não bloqueado)
Nesse momento, o servidor está com o sistema de segurança com honeypot ativo, de modo
que o atacante é identificado como ameaça. Seu endereço IP é adicionado a um ipset pelo
update_daemon e todos os seus pacotes encaminhados para 192.168.56.101 (servidor) passam
a ser redirecionados para 192.168.56.102 (honeypot).
68
Uma nova varredura de portas no servidor, por exemplo, resultaria agora nos dados da FIG.
5.16.
FIG. 5.16 - Varredura de portas no servidor (IP bloqueado)
De fato, a mesma varredura executada no honeypot revela que o atacante não está mais em
contato direto com o servidor, conforme ilustra a FIG. 5.17.
FIG. 5.17 - Varredura de portas no honeypot
Caso o atacante deseje acessar a página alvo pelo navegador novamente, encontrará
imagem semelhante à da FIG. 5.18. Vale notar que o título da página difere da aplicação original
69
unicamente por motivos de ilustração. Em um serviço funcional a página teria aparência
idêntica à da aplicação original, de modo a reduzir as suspeitas do atacante.
FIG. 5.18 - Visualização da página alvo após o ataque bloqueado com sucesso
5.1.2.2 Varredura de vulnerabilidades
A FIG. 5.19 ilustra o resultado da varredura de vulnerabilidades com alvo no servidor,
utilizando-se a ferramenta nikto. De acordo com os resultados exibidos, o escaneamento não
está sendo realizado na aplicação real, já que a máquina alvo utiliza o servidor Glassfish e não
Apache. Dessa forma, as vulnerabilidades coletadas pelo atacante são provenientes da aplicação
do honeypot, e não da aplicação real.
Vale notar aqui que a aplicação do honeypot deve assemelhar-se ao máximo à aplicação
real, de forma a não despertar suspeitas por parte do atacante. Assim, poder-se-ia inserir
vulnerabilidades propositais na aplicação ou mesmo uma versão diferente do mesmo servidor,
de modo a estimular a atividade do invasor.
70
FIG. 5.19 - Visualização dos resultados da varredura de vulnerabilidades na aplicação do servidor, com os
resultados encaminhados do honeypot.
5.1.2.3 Ataque de força bruta
A FIG. 5.20 ilustra um ataque de força bruta simplificado como prova de conceito sobre a
aplicação teste. O ataque utiliza a ferramenta Hydra, com os seguintes parâmetros:
–s <IP DA VÍTIMA>, para indicar a porta
-S para indicar o uso do protocolo SSL
-l <LOGIN > para indicar o login
-p <SENHA> para indicar a senha
O ataque em pauta foi direcionado para o servidor, tendo sido realizado após o bloqueio
prévio do atacante. De acordo com os resultados da FIG. 5.20, a combinação de login e senha
honey e pot é determinada como válida, o que indica que a aplicação atacada na verdade é a do
honeypot, e não a original. Dessa forma, foi possível proteger o banco de dados da aplicação
real, ao mesmo tempo que se poderia registrar o dicionário do atacante.
FIG. 5.20 - Visualização dos resultados do ataque de força bruta na aplicação do servidor, com os resultados
encaminhados do honeypot.
71
5.1.2.4 Ataque de negação de serviço (DoS)
A defesa contra-ataques de negação de serviço constitui o ponto fraco da arquitetura
proposta, uma vez que o encaminhamento de pacotes maliciosos para o honeypot implica no
aumento do fluxo de dados. Considerando, portanto, um ataque de negação de serviço, espera-
se que o desempenho do sistema piore com o sistema de defesa em funcionamento,
especialmente se for utilizada a opção de virtualização.
A FIG. 5.21 ilustra o resultado de um ataque DoS após o bloqueio prévio do atacante. Para
a realização do ataque foi utilizada a ferramenta hping3 com os seguintes parâmetros:
-c <REQS> para indicar a quantidade de requisições
-d <TAMANHO> para indicar o tamanho de cada requisição
-p <PORTA> para indicar a porta alvo
--flood para indicar que deseja-se executar uma enchente de requisições no alvo
-S para indicar a utilização do protocolo SSL
FIG. 5.21 – Resultados do fluxo de dados durante um ataque DoS com utilização do honeypot.
72
Embora não exista solução definitiva para ataques DoS, recomenda-se o estudo de melhoria
de soluções para o problema em pauta em trabalhos futuros. Como atual alternativa, recomenda-
se a utilização da solução parcial da arquitetura, com o descarte de pacotes. Embora essa
transição deva ocorrer de forma manual pelo administrador, sua aplicação evita o aumento do
tráfego malicioso na rede.
5.1.2.5 Visualização dos resultados
Para facilitar a visualização dos resultados coletados no honeypot pelo administrador,
utilizou-se a ferramenta DionaeaFR, já disponível no HoneyDrive 3. Com esta ferramenta pode-
se facilmente demonstrar os dados coletados na forma pcap em uma interface web, destacando-
se informações relevantes como conexões por país ou portas mais atacadas. A FIG. 5.22 ilustra
resultados dos ataques realizados na aplicação teste.
FIG. 5.22 – Interface gráfica web para exibição dos resultados coletados pelo honeypot.
73
5.2 Quality of Service (QoS)
A disponibilidade de um serviço é um dos pilares da segurança da informação (JOHNSON,
2013). A inserção de camadas de segurança, embora de acordo com o princípio da defesa em
profundidade, implica no aumento do consumo de recursos como capacidade de processamento
do servidor, podendo reduzir sua disponibilidade. A qualidade do serviço deve portanto ser
testada após a implementação da arquitetura e de cada um de seus módulos.
São atribuídos quatro tipos de características a um fluxo, tradicionalmente: confiabilidade,
atraso, jitter e largura de banda. A confiabilidade está relacionada à entrega de um pacote e o
recebimento de sua respectiva confirmação. A perda de um pacote ou de sua confirmação
implica em consequente retransmissão. O serviço de consulta a dados geoespaciais requer alto
grau de confiabilidade, uma vez que a falta de um dado no lado do cliente compromete a
aplicação como um todo.
O sistema em pauta possui baixa tolerância a atrasos origem-destino, já que a aplicação
web de renderização das informações requisitadas pelo cliente é dinâmica. O usuário pode, por
exemplo, alterar seguidamente a aproximação de uma região do mapa ou adicionar uma nova
camada de dados sobreposta. O atraso nessas atividades pode significar o comprometimento da
aplicação em tempo real.
Jitter é a variação no atraso entre pacotes pertencentes ao mesmo fluxo. Por não se tratar
de uma transmissão de áudio ou vídeo em tempo real, é aceitável certa diferença entre os
pacotes, embora o ideal é que todos cheguem com o mesmo intervalo de tempo. No caso de um
jitter extremamente alto é possível que o usuário renderize uma camada e em seguida execute
outra atividade no mapa sem que as informações da camada adicionada tenham sido
renderizadas, causando inconsistência entre os dados geográficos.
A largura de banda é essencial para o correto funcionamento da aplicação, especialmente
se a transmissão de dados for exigir alta taxa de bits. A passagem de poucos parâmetros
geográficos não implica, porém, em uma sobrecarga da largura de banda. Seu correto
dimensionamento deve ser testado considerando-se o tipo de requisição efetuada em serviços
de dados geoespaciais (FOROUZAN, 2006).
74
Em função da dependência de uma aplicação completa e funcional, bem como de uma
máquina servidora definitiva, os testes de QoS não puderam ser realizados. O teste em ambiente
local, com aplicações de fachada, não seria coerente, já que os diversos serviços de uma
aplicação afetam o desempenho. Da mesma forma, as configurações específicas da máquina
afetam diretamente o desempenho do sistema na visão do cliente. Assim, os testes de QoS
poderão ser realizados a partir dos conceitos aqui apresentados em um desenvolvimento futuro.
75
6 CONCLUSÃO
O presente projeto teve por objetivo desenvolver uma arquitetura de segurança para uma
aplicação web que disponibilizasse dados geoespaciais. A arquitetura conta primeiramente em
uma camada de segurança de dados, em que foram aplicados algoritmos criptográficos, um
sistema de autenticação e o protocolo de segurança HTTPS. Ademais, a arquitetura possui
mecanismos de proteção do servidor e da rede, contanto com um sistema de detecção
automática de intrusão, baseado em análise de logs do firewall.
Como parte do sistema integral, os atacantes identificados são encaminhados para uma
máquina honeypot isolada ou virtualizada, o que permite que sejam extraídas informações sobre
o atacante. É possível ainda executar uma versão mais simples que não conta com o recurso do
honeypot, apenas descartando os pacotes. Esse recurso, embora menos sofisticado, foi mantido
em função de atender melhor a ataques de negação de serviço do que a versão completa.
Houve preocupação com a utilização prática por usuários com menos conhecimento
técnico ou sem conhecimento do sistema. Portanto, foram desenvolvidos scripts que
automatizam toda a parte da instalação e execução do sistema.
Embora o projeto tenha sido concluído com sucesso, tendo o produto final alcançado os
objetivos desejados, existem diversas melhorias que podem ser implementadas futuramente. A
integração do sistema de segurança com uma aplicação real que disponibilize dados geográficos
é fundamental para que o sistema seja completamente validado. Ademais, a instalação do
sistema e da aplicação em uma máquina servidora é interessante para que o serviço fique
disponível para uso em situação real, bem como para as medições de qualidade de serviço.
Os scripts de execução também podem receber melhorias, como a implementação de
opções de linha de comando. Dessa forma, torna-se possível automatizar dados de configuração
como endereço de IP do honeypot e email do administrador, a serem inseridos diretamente nos
arquivos por enquanto. A utilização de argumentos via linha de comando torna-se ainda
indispensável caso sejam adicionadas mais funcionalidades que exijam parâmetros.
Nem todos os ataques podem ser detectados ou prevenidos pela arquitetura proposta.
Dentre os principais pontos de vulnerabilidade no sistema completo com honeypot, ataques de
negação de serviço permanecem críticos. O encaminhamento dos pacotes do servidor para o
76
honeypot não somente não reduz o fluxo como ainda o amplia, no caso de o honeypot estar
virtualizado no servidor. Dessa forma, pode-se alternar entre os módulos de segurança com e
sem honeypot, uma vez que este, por descartar pacotes provenientes do atacante, não
sobrecarrega a rede. Algoritmos de inteligência artificial poderiam ser utilizados nesse caso
para automatizar a transição entre as duas aplicações em tempo real, de modo a oferecer o
máximo de segurança em todos os casos.
Por fim, a implementação de uma interface gráfica que facilite a configuração da
ferramenta é interessante para que usuários leigos possam usufruir do sistema de proteção.
Além disso, a existência de meios visuais permite o melhor entendimento e a divulgação mais
eficiente do sistema.
Embora não tenha sido possível executar a arquitetura diretamente sobre uma aplicação
web completa que disponibilizasse dados geoespaciais, toda a aplicação foi testada em
máquinas locais com aplicações de fachada. Isso foi suficiente para atestar a validade do
sistema, garantindo que o mesmo atende com sucesso aos requisitos solicitados.
77
7 REFERÊNCIAS BIBLIOGRÁFICAS
PROWELL, Stacy; KRAUS, Rob; BORKIN, Mike. Seven Deadliest Network Attacks. Elsevier,
2010.
ZWICKY, Elizabeth D.; COOPER, Simon; CHAPMAN, D. Brent. Building internet firewalls. "
O'Reilly Media, Inc.", 2000.
JOHNSON, John. Implementing Active Defense Systems on Private Networks. 2013. Disponível
em: <http://www.sans.org/reading-room/whitepapers/detection/implementing-active-defense-
systems-private-networks-34312>. Acesso em 05/05/2015.
PWC. Managing cyber risks in an interconnected world: Key findings from The Global State
of Information Security® Survey 2015. Disponível em:
<http://www.pwc.com/gx/en/consulting-services/information-security-survey/assets/the-
global-state-of-information-security-survey-2015.pdf>. Acesso em: 05/05/2015
SYMANTEC. Internet Security Threat Report. v. 20, Abr. 2015. Disponível em:
<https://www4.symantec.com/mktginfo/whitepaper/ISTR/21347932_GA-internet-security-
threat-report-volume-20-2015-social_v2.pdf>. Acesso em: 05/05/2015.
TIGER SECURITY. Analysis Report: The State of the art of digital guerrilla during the 2014
Brazilian World Cup. Disponível em:
<https://www.tigersecurity.pro/free_reports/AR_EN20140615_BR_v1.pdf>. Acesso em:
05/05/2015.
VARA, Edison. Hackers target Brazil's World Cup for cyber attacks. Reuters, São Paulo, 26
fev. 2014. Disponível em: <http://www.reuters.com/article/2014/02/26/us-worldcup-brazil-
hackers-idUSBREA1P1DE20140226>. Acesso em: 05/05/2015.
STALLINGS, William. Network security essentials: applications and standards. Pearson
Education India, 2007.
STALLINGS, William. Cryptography and Network Security, 4/E. Pearson Education India, 2006.
ORACLE. The Java EE 5 Tutorial. Disponível em:
<http://docs.oracle.com/javaee/5/tutorial/doc/bnbxw.html>. Acesso em: 03/05/2015.
CHESWICK, William R.; BELLOVIN, Steven M.; RUBIN, Aviel D. Firewalls and Internet
security: repelling the wily hacker. Addison-Wesley Longman Publishing Co., Inc., 2003.
RASH, Michael. Linux Firewalls: Attack Detection and Response with iptables, psad, and
fwsnort. No Starch Press, 2007.
JOSHI, R. C.; SARDANA, Anjali (Ed.). Honeypots: A New Paradigm to Information Security.
CRC Press, 2011.
78
URUBATAN, N. E. T. O. Dominando Linux Firewall Iptables. Rio de Janeiro: Ed. Ciência
Moderna, 2004.
ANDREU, Andres. Professional pen testing for Web applications. John Wiley & Sons, 2006.
RUSSEL, Rusty. Linux 2.4 Packet Filtering HOWTO. 2001. Disponível em:
<http://www.netfilter.org/documentation/HOWTO/pt/packet-filtering-HOWTO.html>.
Acesso em: 23/04/2015
NAKAMURA, Emilio Tissato; GEUS, Paulo Lício. Segurança de redes. Berkeley, 2002.
KOZIOL, Jack. Intrusion detection with SNORT. Sams Publishing, 2003.
SCOTT, Charlie; WOLFE, Paul; HAYES, Bert. SNORT for Dummies. John Wiley & Sons, 2004.
CISCO. Snort Users Manual 2.9.6. 2014. Disponível em: <https://s3.amazonaws.com/snort-
org/www/assets/166/snort_manual.pdf>. Acesso em: 12/04/2015.
ENGEBRETSON, Patrick. The basics of hacking and penetration testing: ethical hacking and
penetration testing made easy. Elsevier, 2013.
FOROUZAN, Behrouz A. Comunicação de dados e redes de computadores. Mcgraw Hill Brasil,
2006.
SNORT. Snort License. Disponível em: <https://www.snort.org/snort_license>. Acesso em:
25/07/2015.
EMERGIN THREATES. Ruleset Downloads. Disponível em:
<http://doc.emergingthreats.net/bin/view/Main/AllRulesets>. Acesso em: 12/06/2015.
ORACLE. Oracle GlassFish Server 3.1 Application Development Guide. Disponível em:
<http://docs.oracle.com/cd/E18930_01/html/821-2418/beacm.html>. Acesso em: 22/07/2015.
