Éder Cássio Rocha Ribeiro - eventos.ufu.br · Venvanse, Ritalina, Concerta, Ritalina LA e Strattera.
FACULDADES INTEGRADAS PROMOVE DE BRASÍLIA ÉDER...
58
FACULDADES INTEGRADAS PROMOVE DE BRASÍLIA ÉDER FERREIRA DE ANDRADE PREPARAÇÃO DE AMBIENTE PARA FIREWALL DE APLICAÇÃO WEB VIA SCRIPT AUTOMATIZADO BRASÍLIA 2015
Transcript of FACULDADES INTEGRADAS PROMOVE DE BRASÍLIA ÉDER...
FACULDADES INTEGRADAS PROMOVE DE BRASÍLIA
ÉDER FERREIRA DE ANDRADE
PREPARAÇÃO DE AMBIENTE PARA FIREWALL DE APLICAÇÃO WEB VIA
SCRIPT AUTOMATIZADO
BRASÍLIA
2015
ÉDER FERREIRA DE ANDRADE
PREPARAÇÃO DE AMBIENTE PARA FIREWALL DE APLICAÇÃO VIA SCRIPT
AUTOMATIZADO
Trabalho de conclusão de curso apresentado a faculdade Integradas Promove de Brasília com requisito parcial para obtenção do título de Tecnólogo em Segurança da Informação. Prof. MSc. Cid Bendahan Coelho Cintra
BRASÍLIA
2015
ÉDER FERREIRA DE ANDRADE
PREPARAÇÃO DE AMBIENTE PARA FIREWALL DE APLICAÇÃO VIA SCRIPT AUTOMATIZADO
Trabalho de conclusão de curso apresentado a faculdade Integradas Promove de Brasília com requisito parcial para obtenção do título de Tecnólogo em Segurança da Informação. Prof. MSc. Cid Bendahan Coelho Cintra
Aprovado em ____/____/2015 ________________________________________ Aprovado por ________________________________________ Prof. Orientador ________________________________________
Prof. Orientador
BRASÍLIA
2015
AGRADECIMENTOS
Agradeço primeiramente ao meu orientador, prof. Cid por sua dedicação
durante esse período de convivência. Gostaria de expressar minha gratidão a minha
noiva, Christiane e minha família que deram-me apoio durante todo processo de
conclusão. Estendo um agradecimento especial aos colegas do underground que
indiretamente, ajudaram nesse trabalho.
RESUMO
Este trabalho tem como objetivo apresentar uma ferramenta com a finalidade de
preparar ambiente para um firewall de aplicação web e mostrar como ela pode facilitar
a vida de pessoas que necessitam usá-la. Para a criação do ambiente em questão,
foram empregadas as práticas de desenvolvimento de script usando a linguagem de
ambiente Unix/Linux, shell script. Diante disso, foram analisadas todas as questões
de atualização e restrição do sistema operacional para que não gerasse erro no
momento de execução. Finalmente, o resultado apresentou que essa ferramenta foi
eficiente no que tange a configuração e instalação do ambiente.
Palavra-chave: ataque, firewall de aplicação, waf, aplicação web, owasp.
ABSTRACT
This work aims at presenting a tool that aims to prepare the environment for a
web application firewall and show how it can facilitate the user's life. To create the
environment in question, the script development practices were employed using the
environment language Unix/Linux shell script. Therefore, all update issues were
analyzed and operating system restriction for not generates error at runtime. Finally,
the results showed that this tool was efficient when it comes to installation and
environment configuration.
Keywords: attack, web application firewall, waf, application, owasp
LISTA DE FIGURAS
FIGURA 1 - MODELO LAN ............................................................................................................................................ 16
FIGURA 2 – MODELO MAN ......................................................................................................................................... 17
FIGURA 3 – MODELO WAN ......................................................................................................................................... 18
FIGURA 4 - MODELO OSI ............................................................................................................................................. 19
FIGURA 5 – MODELO DE REFERÊNCIA TCP/IP .................................................................................................................. 20
FIGURA 6 – MODELO OSI E TCP/IP .............................................................................................................................. 22
FIGURA 7 - TRANSAÇÃO HTTP ...................................................................................................................................... 24
FIGURA 8 – EXEMPLO DE URI ....................................................................................................................................... 25
FIGURA 9 – ATAQUE DE SQL INJECTION NA PÁGINA DE AUTENTICAÇÃO .................................................................................. 30
FIGURA 10 - EXEMPLO DO ATAQUE XSS ......................................................................................................................... 32
FIGURA 11 – ACESSO LEGÍTIMO .................................................................................................................................... 32
FIGURA 12 - ACESSO INDEVIDO ..................................................................................................................................... 32
FIGURA 13 – ARQUIVO QUE DEVERIA SER REMOVIDO APÓS A INSTALAÇÃO ............................................................................. 33
FIGURA 14 – EXPOSIÇÃO DE ÁREA SENSÍVEL NA APLICAÇÃO ................................................................................................. 34
FIGURA 15 – REDIRECIONANDO O ACESSO PARA O SITE DO ATACANTE .................................................................................. 35
FIGURA 16 - FIREWALL ................................................................................................................................................ 37
FIGURA 17 – ARQUITETURA DO AMBIENTE ...................................................................................................................... 42
FIGURA 18 - INÍCIO DA EXECUÇÃO ................................................................................................................................. 47
FIGURA 19 - INTERAÇÃO COM USUÁRIO .......................................................................................................................... 48
FIGURA 20 - FINALIZAÇÃO DA EXECUÇÃO ........................................................................................................................ 48
FIGURA 21 - APLICAÇÃO SENDO PROTEGIDA .................................................................................................................... 49
FIGURA 22 - ATAQUE SHELLSHOCK ................................................................................................................................ 56
LISTA DE ABREVIATURAS E SIGLAS
CMS Content Management System CSRF Cross-Site Request Forgery DOS Denial Of Service HIDS Host-based Intrusion Detection System HTTP Hypertext Transfer Protocol IDS Intrusion Detection System IPS Intrusion Prevention System LFI Local File Inclusion MITM Man-In-The-Middle NAXSI Nginx Anti XSS & SQL Injection NIDS Network Intrusion Detection System OSI Open Systems Interconnection OWASP Open Web Application Security Project RFI Remote File Inclusion SQL Structured Query Language URI Uniform Resource Identifier URL Uniform Resource Locators WAF Web Application Firewall WWW World Wide Web XSS Cross-Site Scripting
SUMÁRIO
1 CAPÍTULO I - APRESENTAÇÃO ........................................................... 10
1.1 INTRODUÇÃO .......................................................................................... 10
1.2 JUSTIFICATIVA ........................................................................................ 12
1.3 OBJETIVO GERAL ................................................................................... 12
1.4 OBJETIVOS ESPECÍFICOS ........................................................................ 12
1.5 METODOLOGIA ....................................................................................... 13
2 CAPÍTULO II – REFERENCIAL TEÓRICO ............................................ 14
2.1 INFORMAÇÃO ......................................................................................... 14
2.2 SEGURANÇA DA INFORMAÇÃO .................................................................. 14
Confidencialidade ......................................................................... 14
Integridade .................................................................................... 15
Disponibilidade ............................................................................. 15
2.3 REDES DE COMPUTADORES .................................................................... 15
LAN ............................................................................................... 16
MAN .............................................................................................. 16
WAN ............................................................................................. 17
Modelo OSI ................................................................................... 18
Protocolo TCP/IP .......................................................................... 19
Aplicação ...................................................................................... 20
Transporte .................................................................................... 21
Internet.......................................................................................... 21
Host rede ou interface de rede ..................................................... 21
Protocolos de redes ...................................................................... 21
2.4 SEGURANÇA EM REDES DE COMPUTADORES ............................................. 22
2.5 INTERNET .............................................................................................. 23
2.6 PROTOCOLO DE COMUNICAÇÃO .................................................... 24
Http ............................................................................................... 24
Https ............................................................................................. 25
Uri e Url......................................................................................... 25
Principais Métodos ....................................................................... 26
Códigos de Status ........................................................................ 27
2.7 APLICAÇÕES PARA INTERNET ................................................................... 28
Servidor Web ................................................................................ 28
Aplicação Web .............................................................................. 28
Vulnerabilidade ............................................................................. 28
Owasp........................................................................................... 29
Aplicações Vulneráveis ................................................................. 36
2.8 FIREWALL .............................................................................................. 37
Firewall da camada de aplicação .................................................. 38
Modelos de Segurança ................................................................. 39
Frameworks .................................................................................. 40
Naxsi ............................................................................................. 41
3 CAPÍTULO III – CRIAÇÃO DO PACOTE ............................................... 42
3.1 IMPLANTAÇÃO DO CENÁRIO ...................................................................... 42
3.2 IMPLEMENTAÇÃO DO SCRIPT .................................................................... 43
3.3 TESTES ................................................................................................. 47
4 CAPÍTULO VI – CONCLUSÃO ............................................................... 50
10
1 CAPÍTULO I - APRESENTAÇÃO
1.1 Introdução
Atualmente, as aplicações webs são muitos populares, visto que quase todos
os sistemas de informação, aplicações de negócios, e-commerce, transações
bancárias, e-mails, mídias sociais, blogs, entre outros, são construídos com
aplicações baseadas em web. Essas aplicações são um dos principais alvos para
criminosos cibernéticos. Vulnerabilidade de segurança nas aplicações ou erros de
código de programação tem contribuído para sucesso dos ataques. Atacantes usam
diversos métodos para realizarem ataques a sites, entre eles, injeção de comandos,
injeção de sql, xss, local file inclusion e remote file inclusion são alguns dos ataques
mais populares que exploram os mesmos.
Empresas como Imperva, apresentou esse ano um relatório – conforme anexo
A - voltado para segurança web e nele afirma-se que um dos ataques mais utilizados
no período de análise foi o shellshock, sendo que boa parte da aplicação alvejada era
cms (wordpress1). CERT-BR, conclui que todos os ataques recebidos naquele período
tiveram um aumento de 197% em relação ao mesmo período de 2013. Isso confirma
que as ameaças estão aumentando e utilizando como vetor a aplicação web.
Nos últimos meses, tem-se testemunhado extensivamente ataques que
resultaram em grandes vazamentos de dados, tanto no governo quanto nas empresas
privadas, incluindo Itamaraty, Ashley Madison, Sony, Hacking Team, Pentágono e
Exército. Algumas das empresas/órgãos citados tiveram impacto negativo quanto à
reputação sobre clientes e utilizadores, outras até sofreram danos financeiros.
Mecanismos de segurança tradicionais como firewall, IPS/IDS/HIDS/NIDS
podem proteger a rede, mas não podem mitigar de forma precisa os ataques contra
1 Wordpress é uma ferramenta/aplicativo voltada para criação de sites e blogs.
11
a aplicação web, mesmo que tais componentes de infraestrutura como servidores web
estejam seguros. Firewall de aplicação web é voltado especificamente para proteger
os ataques na camada de aplicação, porém, não garante 100% de eficácia,
principalmente quando o problema é específico na implementação ou código fonte da
aplicação. Portanto, a adoção e implementação de uma ferramenta para este fim é
essencial.
12
1.2 Justificativa
Firewall de aplicação é uma excelente ferramenta para fazer a proteção de
sites. Disponíveis na Internet de forma livre e open source para serem baixados e
usados em ambientes que contenham página virtuais disponíveis para o mundo. O
processo de instalação do Naxsi requer alguns componentes no sistema e é
mandatório que seja instalado com o servidor web Nginx.
A presente proposta de trabalho visa apresentar uma solução “automatizada”
para o firewall de aplicação, com o intuito de facilitar o processo de instalação e
configuração. Seja ela para usuário comum, que deseja fazer teste e/ou estudo, ou
para um administrador de sistema que deseja testá-lo em sua organização, tendo
benefício não apenas em tempo, mas também em otimização.
1.3 Objetivo Geral
O presente trabalho tem como objetivo principal, adaptar um script para
configurar e instalar um firewall de aplicação web, visando automatizar serviço para
um administrador.
1.4 Objetivos Específicos
Levantar a documentação necessária do firewall de aplicação.
Instalar, configurar e implementar o ambiente para o firewall.
Propor uma solução automatizada para instalação e configuração do
firewall de aplicação web.
13
1.5 Metodologia
A metodologia usada consistiu-se, em primeiro lugar, da análise bibliográfica
dos assuntos abordados no trabalho: segurança web, aplicação web, firewall de
aplicação, ataques, vulnerabilidades entre outros. Em seguida, foi preparado o
ambiente de forma manual (instalação e configuração), revisando as documentações
do próprio firewall para que posteriormente fosse desenvolvido o script que pudesse
agilizar todo esse processo. Uma vez concluído, foi testado em outro ambiente para
que atingisse resultado satisfatório. Por fim, foi entregue a ferramenta em
funcionamento, testada e implantada em uma máquina virtual fornecida pelo
pesquisador.
14
2 CAPÍTULO II – REFERENCIAL TEÓRICO
2.1 Informação
Na definição da ABNT NBR ISO/IEC 27002 (2005, p.10), “a informação é um
ativo que, como qualquer outro ativo importante, é essencial para os negócios de uma
organização e consequentemente necessita ser adequadamente protegido. ”
Conforme (INFOSEC, 2002), “informação é um ativo para todos os indivíduos
e negócios. Segurança da informação se refere a proteção destes ativos, a fim de
obter a confidencialidade, integridade e disponibilidade dos mesmos. ”
2.2 Segurança da informação
O decreto nº 3.505 da presidência da república define segurança da informação
como:
“Proteção dos sistemas de informação contra a negação de serviço a usuários autorizados, assim como contra a intrusão, e a modificação desautorizada de dados ou informações, armazenados, em processamento ou em trânsito, abrangendo, inclusive, a segurança dos recursos humanos, da documentação e do material, das áreas e instalações das comunicações e computacional, assim como as destinadas a prevenir, detectar, deter e documentar eventuais ameaças a seu desenvolvimento”
Confidencialidade
A garantia de que um dado ou sistema de informação esteja acessível apenas
para pessoas autorizadas. Lista de controle de acesso, credenciais e senhas são
alguns métodos no qual a confidencialidade é alcançada (FONTES, 2012). Isto refere-
se a prática de prevenir a divulgação e acesso não autorizados a dados e sistemas.
15
Um exemplo disso é um site de compras, onde deve manter os dados de cartões de
créditos dos clientes em sigilo.
Integridade
Segundo Fontes (2012, p. 209) “É um dos objetivos da segurança da
informação que garante que a informação mantenha a sua representação original e
não foi corrompida por aspectos de ambiente físico ou de falhas no ambiente logico”.
Disponibilidade
Conforme Fontes (2012, p. 208), disponibilidade visa "busca garantir que a
informação esteja acessível para o usuário quando este necessitar utilizar o serviço,
respeitando os acordos de nível de disponibilidade previamente acertados".
Apesar dos diversos significados para o termo segurança da informação, pode-
se dizer que, de modo geral, e de acordo com a lei nº 3542 da legislação norte
americana é proteger a informação e o sistema de informação de acesso não
autorizado contra o uso, descoberta, interrupção, modificação ou destruição.
2.3 Redes de Computadores
Para Tanenbaum (2003, p. 02) redes de computadores é um “conjunto de
computadores autônomos interconectados por uma única tecnologia”. Para se ter uma
rede de computadores é necessário apenas que dois computadores estejam
conectados, trocando informações entre si.
16
Quando se fala de redes de computadores, é importante conhecer os principais
tipos de infraestrutura de redes:
LAN
Local Area Network – LAN (rede de área local), figura 1, é uma rede restrita a
um pequeno conjunto de áreas, como por exemplo: casa, escola, escritórios etc.
Dentro de uma rede LAN, a velocidade de transferência de dados pode chegar até
10Mbps, sendo maior do que a rede WAN e MAN (MALIK, 2014).
Figura 1 - modelo LAN
Fonte: O autor
MAN
Metropolitan Area Network – MAN (rede de área metropolitana), para Elias e
Lobato (2013, pag. 13), “são redes de comunicação que cobrem uma área do tamanho
17
de uma cidade ou bairro. Permitem a interligação de redes e equipamentos numa área
metropolitana, como em locais situados em diversos pontos de uma cidade.”
Conforme MALIK (2014), figura 3, é uma rede que conecta dois ou mais
computadores, comunicando dispositivos ou redes em uma única rede que tenha uma
grande área geográfica que abrange uma LAN e, entretanto, menor que a WAN. Ela
é limitada a um certo campo geográfico.
Figura 2 – Modelo MAN
Fonte: O autor
WAN
Wide Area Network – WAN (rede de grande área) segundo Siqueira (2011, pag.
22), "é a rede formada por diferentes LANs separadas geograficamente. Muitas
tecnologias diferentes podem ser usadas para conectar LANs, como links de rádio,
ADSL, 3G, cable modems etc."
18
De modo geral, Siqueira (2011, pag. 22), diz que “a Internet em si é uma WAN,
na qual os mais diversos tipos de conectividade são empregados para interligar os
inúmeros nós e LANs ligados a ela".
Para Malik (2014), a rede WAN, figura 2, por cobrir uma larga região geográfica,
tais como, estado, província ou país, é interessante para empresas ou companhias
que estejam separados por uma região e precisam se comunicar ou trocar
informações.
Figura 3 – Modelo WAN
Fonte: O autor
Modelo OSI
Modelo de referência Open System Interconnection – OSI (Sistema de
Interconexão Aberto), é um modelo de arquitetura de rede aberto criado pela
International Organization for Standardization - ISO (Organização Internacional para
19
Padronização) para fazer a comunicação com outros sistemas. O modelo possui sete
camadas no qual é especificado na figura 4:
Figura 4 - Modelo OSI
Fonte: Mosharraf e Forouzan (2005, p. 20)
Protocolo TCP/IP
De acordo com Forouzan e Mosharraf (2013, p.12):
“O TCP/IP consiste em uma pilha de protocolos (um conjunto de protocolos organizados em diferentes camadas) usados na internet atual. É um protocolo hierárquico composto de módulos interativos, cada um dos quais provendo uma funcionalidade específica. O termo hierárquico significa que cada protocolo do nível superior é apoiado pelos serviços fornecidos por um ou mais protocolos dos níveis abaixo dele.”
Para Ferreira (2000, pag. 48), “O TCP/IP é um conjunto de protocolos usados
em redes na internet. Um “protocolo” é um conjunto de normas que dois ou mais
computadores devem usar para se comunicarem entre si”.
20
O protocolo TCP/IP é dividido em quatro camadas: aplicação, transporte,
internet e host/rede. Em relação a essas camadas, Ferreira (2000, pag. 48), diz que
“o que cada uma faz é pegar um pacote de dados enviado pela camada imediatamente
superior ou inferior e tratá-lo para que ele possa continuar sendo enviado”. A figura 5,
apresenta o protocolo TCP/IP:
Figura 5 – Modelo de referência TCP/IP
Fonte: Forouzan e Fegan (2010, p. 30)
Aplicação
Segundo Nascimento; Tavares (2012, p. 14) “A camada de aplicação trata de
protocolos de alto nível, questões de representação, codificação e controle de
diálogo”. Essa camada possui funções das camadas de aplicação, apresentação e
sessão do modelo OSI. Conforme (Tanenbaum, 2003), “Um protocolo de aplicação
amplamente utilizado é o HTTP (HyperText Transfer Protocol) que constitui a base
para a World Wide Web”.
21
Transporte
Segundo Tanenbaum (2003, p. 45), “A finalidade dessa camada é permitir que
as entidades pares dos hosts2 de origem e destino mantenham uma conversação,
exatamente como acontece na camada de transporte do modelo OSI”.
Internet
A tarefa da camada inter-redes é permitir que os hosts injetem pacotes em
qualquer rede e garantir que eles sejam transmitidos independentemente do destino
e entregar pacotes IP onde eles são necessários (Tanenbaum, 2003).
Host rede ou interface de rede
Conforme Elias e Lobato (2013, p. 64) “A camada de interface de rede, também
conhecida como camada de enlace de dados, é responsável por aceitar datagramas
IP da camada de rede e transmiti-los, na rede física específica, na forma de quadros”.
Protocolos de redes
Todos os dispositivos conectados dentro de uma rede se conectam através de
algum tipo de protocolo. Existem diversos tipos de protocolos e cada um possui um
propósito específico. Neste âmbito, serão listados alguns dos principais protocolos da
pilha TCP/IP, relacionando-os com suas respectivas camadas, conforme a figura 6.
2Host é um computador ou dispositivo conectado a uma rede de computadores.
22
A figura 6 demonstra um comparativo entre os modelos OSI e TCP/IP:
Figura 6 – Modelo OSI e TCP/IP
Fonte: Tanenbaum (2003, pag. 46)
2.4 Segurança em redes de computadores
Conforme CISCO (2011) “segurança de redes refere-se a quaisquer atividades
destinadas para proteger a sua rede. Especificamente, essas atividades protege a
usabilidade, confiabilidade, integridade e segurança da sua rede e dados.”
Quando se fala em segurança de redes, é importante saber alguns tipos de
ameaças (CURTIN, 1997):
Negação de serviço (DoS) - ataque que visa indisponibilizar um servidor
ou host.
Acesso não autorizado – ato do usuário acessar determinados arquivos
que não deveria.
23
Quebra de confidencialidade – ocorre quando uma informação
confidencial de uma pessoa é divulgada para outrem, sem seu
consentimento.
De acordo com CISCO (2011), as ameaças mais comuns são:
Malwares – programas maliciosos.
Ataques de zero day - uma falha que não é publicamente conhecida e
não possui correção.
Ataques de hackers.
Ataques de DoS.
Interceptação de dados.
Ameaça de identidade.
2.5 Internet
Na definição de Curtin (1997), “internet é a rede mundial de redes. Portanto,
quando surge a necessidade de se conectar na internet, nós estamos apenas
conectando numa rede que está conectada no backbone3”. Nesse ponto o autor deixa
claro em sua definição que a “internet é uma rede de redes e não uma rede de hosts”.
Para Brasil Escola (2008):
“A Internet é um grande conjunto de redes de computadores interligadas pelo mundo inteiro; de forma integrada viabilizando a conectividade independente do tipo de máquina que seja utilizada, que para manter essa multi-compatibilidade se utiliza de um conjunto de protocolos e serviços em comum, podendo assim, os usuários a ela conectados usufruir de serviços de informação de alcance mundial. ”
3 Backbone é parte de uma infraestrutura de redes que conecta várias peças de redes.
24
Para Tanenbaum (2003, pag. 53), "A Internet não é de modo algum uma rede,
mas sim um vasto conjunto de redes diferentes que utilizam certos protocolos comuns
e fornecem determinados serviços comuns".
2.6 PROTOCOLO DE COMUNICAÇÃO
Http
Para (Pauli, 2014), “O HTTP é um protocolo stateless (sem estados), de modo
que toda solicitação de cliente e a resposta da aplicação web corresponde a um
evento totalmente novo e independente, que não tem conhecimento de solicitações
anteriores. ”
O protocolo http é genérico e amplamente usado por todas as aplicações web,
além de ser utilizado para acessar a internet. Ele trabalha no modelo onde o cliente
solicita um pedido e o servidor devolve a resposta (Stuttard e Pinto, 2011). O cliente,
por sua vez, pode ser tanto o user agents (navegador, como por exemplo: internet
explore, firefox, chrome, ou robôs automatizados, como por exemplo: googlebot,
baidu, yandex) ou proxies (programa intermediário que atua como cliente/servidor
para fazer pedidos em nome de outros clientes) (BERNERS-LEE et al., 1999). A figura
7 exemplifica o funcionamento do protocolo http:
Figura 7 - Transação HTTP
Fonte: O autor
25
Https
O protocolo https é basicamente a mesma coisa que o http, o que difere é que
a conexão utilizada sobre o https é criptografada, e está sendo tunelada por um canal
de comunicação seguro, evitando assim, um possível ataque do tipo man-the-middle,
que visa interceptar a comunicação entre o navegador e a aplicação (Pauli, 2014).
Uri e Url
Conforme Berners-lee, Fielding e Masinter (2005), a “URI pode ainda ser
classificada como um localizador, um nome ou ambas. ”
“O termo URL refere-se ao subconjunto de URIs que, além de identificar um
recurso, fornece um meio de localizar o recurso através da descrição de seu
mecanismo de acesso primário (por exemplo, sua “localização” na rede)” (BERNERS-
LEE; FIELDING; MASINTER, 2005).
Exemplo de uma URI e seus respectivos componentes:
protocolo://hostname[:porta]/[caminho/]arquivo[?parâmetro=valor]
De maneira mais legível, o exemplo fica conforme a figura 8:
Figura 8 – Exemplo de URI
Fonte: O autor
Nesse caso, o número da porta é opcional, sendo mandatório apenas quando
for contrário a porta padrão (80).
26
Principais Métodos
Para Cravens e Burtoft (2012, p. 445), os métodos HTTP servem para “indicar
a ação desejada para ser executada no recurso identificado”. Cada método possui um
propósito específico. Durante a avaliação do firewall nesse trabalho, os métodos mais
utilizados serão o GET e POST.
Berners-lee et al. (1999), especifica oito tipos de métodos mais importantes,
são eles: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE e CONNECT.
2.6.4.1 OPTIONS
É usado para identificar quais métodos são utilizados pelo servidor.
2.6.4.2 GET
É usado para solicitar um recurso, como por exemplo, conteúdo de um arquivo
estático no servidor.
2.6.4.3 HEAD
É parecido com o método GET, porém o diferencial é que o servidor não retorna
nenhum dado depois do cabeçalho. Nesse método, você solicita apenas uma
informação de um documento e não o documento em si.
2.6.4.4 POST
Este método refere-se a fornecimento de informação por parte do solicitante.
2.6.4.5 PUT
27
É usado para inserir um arquivo no servidor.
2.6.4.6 DELETE
É usado para remover um arquivo no servidor.
2.6.4.7 TRACE
Método usado para identificar as modificações realizadas durante o pedido e
resposta.
2.6.4.8 CONNECT
É usado quando um cliente precisa falar com um servidor HTTPS através de
um servidor de proxy.
Códigos de Status
Conforme Uto (2013, p. 18) “são valores numéricos de três dígitos, que fazem
parte da primeira linha da resposta do servidor a uma requisição e denotam o
resultado da solicitação”. O protocolo HTTP define alguns específicos códigos de
status, conforme a tabela 1:
Tabela 1 – Informações do status do protocolo HTTP
Código Descrição
1xx Informação
2xx Solicitação bem-sucedida
3xx Solicitação redirecionada
4xx Solicitação incompleta
5xx Erro no servidor
Fonte: Berners-Lee et al. (1999)
28
2.7 Aplicações para internet
Servidor Web
Segundo Tanenbaum e Wetherall (2011, p. 651), “a web, é uma estrutura
arquitetônica que permite o acesso a documentos vinculados espalhados por milhões
de maquinas de internet”.
Já Forouzan e Mosharraf (2013, p. 44) definem WEB como “um repositório de
informações no qual os documentos, chamados páginas web, são distribuídos por
todo o mundo e os documentos relacionados são vinculados entre si”.
Pauli (2014, p. 27) afirma que:
“Um servidor web nada mais é do que uma porção de software executada no sistema operacional de um servidor e que permite conexões para acessar uma aplicação web. Os servidores web mais comuns são o Internet Information Services (IIS) em um servidor Windows e o servidor HTTP (HypertextTransfer Protocol, ou Protocolo de Transferência de Hipertexto) Apache em um servidor Linux. Esses servidores possuem estruturas normais de diretório como qualquer outro computador e são esses diretórios que hospedam a aplicação web. ”
Aplicação Web
Conforme (Pauli, 2014), é o “código-fonte em execução no servidor web, que
provê as funcionalidades com as quais os usuários web interagem”. Ainda assim, o
autor ressalva que “As aplicações web nada mais são do que um conjunto de
programas de computador que permitem que visitantes de sites enviem pedidos e
recebam dados de um banco de dados utilizando um navegador web”.
Vulnerabilidade
Conforme (CERT-BR, 2012), “Uma vulnerabilidade é definida como uma
condição que, quando explorada por um atacante, pode resultar em uma violação de
segurança”.
29
A vulnerabilidade é um buraco ou uma fraqueza na aplicação que pode ser
uma falha de projeto ou um bug de implementação, que permite um atacante causar
danos às partes interessadas de um aplicativo, seja o proprietário do aplicativo, os
usuários do aplicativo e outras entidades que dependem da aplicação (OWASP,
[2003?]).
Owasp
Open Web Application Security Project – OWASP (Projeto Aberto de
Segurança em Aplicações Web) é uma comunidade aberta dedicada a capacitar as
organizações a desenvolver, adquirir e manter as aplicações seguras. Todas as
ferramentas do OWASP, documentos, fóruns e capítulos são gratuitas e estão abertas
a qualquer pessoa interessada em melhorar a segurança das aplicações (MEUCCI et
al., 2008).
OWASP é uma organização sem fins lucrativos, mantida por ela mesma, e que
colabora com projetos e conferências sobre Owasp Application Security e não é filiada
com empresas de tecnologia, sendo que todos os seus materiais são produzidos de
forma colaborativa, além de estarem sob licença open source (MEUCCI et al., 2008).
Um dos projetos importantes do OWASP é o top 10, que visa orientar
desenvolvedores, projetistas, gestores e organizações sobre as consequências das
vulnerabilidades das aplicações web (OWASP, 2013).
Segundo OWASP (2013), os principais tipos de ataques são:
1. Injeção SQL; 2. Quebra de Autenticação e Gerenciamento de Sessão; 3. Cross-Site Script (XSS); 4. Referência Segura aos Objetos; 5. Configuração Insegura de Segurança; 6. Exposição de Dados Sensíveis; 7. Falta de Restrição para Controle de Acesso; 8. Cross-Site Request Forgery;
30
9. Utilização de Componentes Vulneráveis; e 10. Redirecionamentos e Encaminhamentos inválidos;
2.7.4.1 Injeção SQL
É um ataque onde o invasor utiliza a capacidade de influenciar uma consulta
SQL (Structured Query Language) que um aplicativo passa para um banco de dados.
Ao ser capaz de influenciar o que é passado para o banco de dados, o atacante pode
utilizar a sintaxe e as capacidades do próprio SQL com o objetivo acessar todas as
informações confidenciais armazenadas em banco de dados de uma aplicação, como
por exemplo, nomes de usuários, senhas, nomes, endereços, informações de cartão
de crédito entre outros (OWASP, 2013).
Figura 9 – Ataque de sql injection na página de autenticação
Fonte: O autor
No primeiro momento, o atacante solicita a página da administração do site
(admin.php). No segundo momento, a aplicação devolve a página solicitada. Na
terceira parte, o atacante insere o código do ataque no formulário de "login" e envia
31
novamente para aplicação. A aplicação por sua vez, que não efetuou a sanitização
dos dados recebidos, interpretou aqueles dados como instrução de sql, enviou
comandos para o banco de dados e retornou o resultado para o atacante. Por fim,
acesso garantido ao site como se fosse administrador, conforme a quarta parte.
2.7.4.2 Quebra de Autenticação e Gerenciamento de Sessão
Quando uma função relacionada a autenticação não está corretamente
implementada, atacantes podem comprometer senhas ou IDs de sessão ou explorar
essas falhas usando credenciais de outros usuários ativos no sistema (OWASP,
2013).
2.7.4.3 Cross-Site Script (XSS)
XSS, também conhecido como Cross-Site Scripting, é um ataque onde o
invasor utiliza uma aplicação web para injetar scripts maliciosos – geralmente em
javascript ou html - em um site legítimo para realizar ações maliciosas, como por
exemplo, roubar credenciais (sessão, login e senha) de vítimas, utilizar o site para
lançar phishing4 entre outros (OWASP, 2013). Exemplo na figura abaixo:
4 É um termo que se refere a uma tentativa fraudulenta para obter informação confidencial
32
Figura 10 - Exemplo do ataque XSS
Fonte: Dadario (2012)
2.7.4.4 Referência Segura aos Objetos
Essa vulnerabilidade ocorre quando uma aplicação fornece acesso direto a
objetos baseados em um dado fornecido pelo usuário. Como resultado desta
vulnerabilidade, atacantes podem contornar essa autorização e acessar recursos
diretamente no sistema, como por exemplo, arquivos ou dados de banco de dados
(OWASP, 2013).
Figura 11 – Acesso legítimo
Fonte: O autor
Figura 12 - Acesso indevido
Fonte: O autor
33
2.7.4.5 Configuração Insegura de Segurança
O atacante se aproveita das falhas não corrigidas como: senhas padrão,
páginas não utilizadas, arquivos e diretórios desprotegidos, entre outras coisas, para
obter acesso não autorizado do sistema. Essas falhas além de poderem está em
qualquer parte nos aplicativos, podem conduzir acesso a dados e funcionalidades
importantes do sistema, o que pode causar o comprometimento total do sistema
(OWASP, 2013). A figura 13, exemplifica a falha:
Figura 13 – Arquivo que deveria ser removido após a instalação
Fonte: O autor
2.7.4.6 Exposição de Dados Sensíveis
Considerando o cenário onde um site possui páginas de autenticação que
trafegam pela conexão não segura, o http. Um atacante pode monitorar o tráfego de
rede (usando o ataque MITM5), e roubar o cookie de sessão do usuário. Sendo assim,
o atacante então reproduz este cookie e sequestra a sessão do usuário, podendo
acessar dados privados do mesmo (OWASP, 2013).
Neste exemplo, a figura 10 demonstra que o arquivo “robots.txt” apresenta
informações úteis para uma pessoa mal-intencionada.
5 Ataque man-in-the middle (MITM) tem por finalidade interceptar e manipular a conversa entre
cliente e servidor.
34
Figura 14 – exposição de área sensível na aplicação
Fonte: O autor
2.7.4.7 Falta de Restrição para Controle de Acesso
Supondo que exista uma página onde deveria ser acessada apenas por um
usuário autenticado, neste caso, o usuário.
http://www.exemplo.com.br/usuario/paineldesenhas
Caso este usuário autenticado (ou um atacante) consiga forçar a navegação e
acessar a URL na página do administrador com sucesso, isso consiste em uma falha
grave que pode levar a mais páginas desprotegidas.
http://www.exemplo.com.br/admin/paineldesenhas
Este risco é realmente tão simples quanto parece, principalmente quando
qualquer um é capaz de acessar um recurso que não deve, pois, os controles de
acesso apropriados não existem (OWASP, 2013).
2.7.4.8 Cross-Site Request Forgery (CSRF)
Ataque CSRF obriga o usuário final a executar ações indesejadas em uma
aplicação web em que o mesmo está autenticado. Com um pouco de ajuda de
engenharia social (como enviar um link por e-mail), um atacante pode enganar os
usuários de uma aplicação web para executar ações de sua escolha. Um sucesso da
exploração CSRF pode comprometer os dados do usuário final. Se o alvo, usuário
35
final, for a conta de administrador, isso pode comprometer toda a aplicação web
(OWASP, 2013).
Conforme Mcclure, Scambray e Kurtz (2014, p. 562):
“Os aplicativos web fornecem aos usuários sessões autenticadas persistentes; portanto, eles não precisam se autenticar novamente a cada vez que solicitam uma página. No entanto, se um invasor puder convencer o navegador web do usuário a enviar um pedido para o site, poderá tirar proveito da sessão persistente para executar ações como se fosse a vítima. Os ataques podem resultar em uma variedade de resultados prejudiciais para as vítimas: as senhas podem ser alteradas, dinheiro pode ser transferido, mercadorias podem ser compradas e muito mais.”
2.7.4.9 Utilização de Componentes Vulneráveis
Isto se refere onde uma aplicação usa componentes/bibliotecas de terceiros
para implementar funcionalidades. As falhas nesses componentes, tais como, CMS
(Sistema de Gerenciamento de Conteúdo) e Plugins, fazem com que a aplicação se
torne vulnerável. Exemplo de alguns CMS são: Drupal, Wordpress, Joomla e Wikis.
2.7.4.10 Redirecionamentos e Encaminhamentos Inválidos
A aplicação usa encaminhamentos para rotear requisições entre partes
diferentes do site. Num cenário onde a aplicação possui uma página chamada
“redirect.jsp” que recebe apenas um parâmetro “url”, o atacante pode colocar outra url
no parâmetro para redirecionar a vítima a um site no qual pode conter links maliciosos
e instaladores de malwares para serem baixados no computador da vítima (OWASP,
2013). Exemplo do ataque:
Figura 15 – Redirecionando o acesso para o site do atacante
Fonte: O autor
36
Aplicações Vulneráveis
Aplicações com vulnerabilidades são excelentes frameworks para realização
de teste de intrusão, treinamentos e também para obter um conhecimento
diferenciado no que tange a vulnerabilidade de aplicação web e serviços.
Alguns frameworks vulneráveis que estão disponíveis ao público são: Hacme
Bank, Insecure Web App Project, WebGoat, XSSeducation, Damn Vulnerable Web
Application (DVWA) e BTS PenTesting Lab.
Hacme Bank – Foi projetado para ensinar os desenvolvedores de
aplicativos, programadores, arquitetos e profissionais de segurança
como desenvolver software seguro. Hacme Bank simula um aplicativo
bancário on-line da web de forma real e o mesmo foi construído com
algumas vulnerabilidades conhecidas e comuns. Isso permite aos
usuários efetuarem explorações reais contra a aplicação web e, assim,
aprender as especificidades do problema e a melhor maneira de corrigi-
lo (MCAFEE, 2006).
OWASP Insecure Web App Project – esse projeto foi desenvolvido em
2004, onde possui vulnerabilidades comuns em aplicação e é destinado
para análise de vulnerabilidade e teste de intrusão. Ela possui três
objetivos, o primeiro é como vulnerabilidades podem ocorrer, segundo é
fechar o gap entre a teoria da segurança da aplicação e o atual código
que é projetado e o terceiro aprender como tais falhas podem ser
corrigidas (OWASP, 2004).
OWASP WebGoat – é uma aplicação vulnerável escrita em java, cujo
objetivo é fornecer um ambiente de aprendizado para segurança de
aplicação web (OWASP, [2008?]).
XSSeducation – é um conjunto de páginas web vulneráveis para testar
a falha de segurança XSS.
37
Damn Vulnerable Web Application – conhecido como DVWA, é uma
aplicação extremamente vulnerável, construída em php/mysql para ser
realizado o estudo de ataque e defesa (DVWA, [2010?]).
BTS PenTesting Lab – mais uma aplicação vulnerável que foi elaborada
para testar alguns ataques web, entre eles, sql injection, xss, file
inclusion, Server Side Includes entre outros (BREAKTHESEC, 2013).
hackxor - este é um jogo hacking baseado em aplicação web que visa
incentivar os jogadores a resolverem os desafios através de histórias
relacionadas a vulnerabilidades (HACKXOR, [2011?]).
2.8 Firewall
Firewall é uma solução de segurança que fica situado entre o ponto de entrada
da rede privada e a Internet onde todos os pacotes, tanto de entrada quanto o de
saída, devem passar através do mesmo (figura 16).
Figura 16 - Firewall
Fonte: O autor
38
Essa solução de segurança é um elemento crucial para a proteção da rede e é
amplamente utilizado nos dias de hoje.
Para entender melhor sobre o firewall, Tanenbaum (2003, p. 825) faz a seguinte
analogia:
“Os firewalls são apenas uma adaptação moderna de uma antiga forma de segurança medieval: cavar um fosse profundo em torno do castelo. Esse recurso forçava todos aqueles que quisessem entrar ou sair do castelo a passar por uma única ponte levadiça, onde poderiam ser revistados por guardas."
Considerando um cenário onde uma empresa possui um servidor web e a
mesma está sob proteção do firewall, para que um usuário acesse o servidor web, é
necessário que o firewall de rede esteja permitindo o tráfego na porta 80 do protocolo
http, caso contrário o mesmo não terá acesso. Segundo Forster (2002), uma vez que
o firewall de rede permite o acesso ao servidor web, usuários e atacantes podem ter
acesso ao servidor e o resultado é que ambos possuem acesso autorizados ao site.
Isto significa que a tecnologia de firewall não é adequada para realizar a inspeção do
protocolo http, pois o mesmo não consegue distinguir entre um pedido malicioso e o
legítimo.
Firewall da camada de aplicação
Ataques relacionados a camada de aplicação têm se tornado cada vez mais
comuns e apresenta um grande desafio de segurança, o que levou a necessidade de
um firewall de aplicação para proteger servidor web. Entretanto, comparado com o
tradicional firewall de rede, o firewall de aplicação é projetado para fornecer a
capacidade de filtrar qualquer conteúdo anômalo que é enviado para aplicação,
permitindo a capacidade de interceptar e analisar o tráfego.
39
De acordo com Gartner (2005), 75% de todos os ataques externos ocorrem na
camada de aplicação. Os atacantes foram capazes de manipular a entrada do
aplicativo e obter dados confidenciais sem ser detectado pelos sistemas de defesa de
rede. Gartner (2005), ainda ressalta que a camada web é um ótimo vetor de ataque,
porque há uma grande possibilidade de possuir falhas.
Na definição do OWASP (2015), Web Application Firewall (WAF) é uma
“solução de segurança a nível de aplicação que – de um ponto de vista técnico - não
depende da própria aplicação”. Com isso, entende-se que além de prevenir ataques
que uma solução de firewall comum não consegue, não há necessidade de fazer
ajuste no código fonte da aplicação.
Modelos de Segurança
Na tecnologia de firewall de aplicação, existem dois tipos de modelos de
segurança: modelo positivo (whitelist) e negativo (blacklist).
2.8.2.1 Modelo Negativo
Modelo que define quais dados não são permitidos, baseando-se em um
conjunto de regras definidas. Caso alguma entrada não corresponda a regra, ela é
considerada válida e o tráfego é permitido, se não, é inválida e será bloqueada. Essa
abordagem previne que ataques conhecidos ou conexões suspeitas passem através
do filtro, porém, não previne de ataques de zeroday, além de apresentar muitos falsos
positivos.
2.8.2.2 Modelo Positivo
Modelo onde observa e reponde a qualquer comportamento incomum ou não
autorizado, bloqueando ataques antes de chegar ao servidor web. Nesse modelo a
40
aplicação web pode ser usada da maneira que o desenvolvedor projetou. Qualquer
tentativa de manipulação será automaticamente bloqueada, evitando desse modo,
qualquer tentativa de uso de recurso não autorizado do site. Esse modelo é
importante, principalmente quando se tem uma aplicação vulnerável e que não pode
ser aplicada correção ou atualização.
Frameworks
Atualmente, a tecnologia da informação possui diversos frameworks de firewall
de aplicação web, tanto comerciais quanto gratuitos. Abaixo segue a listagem de
ambas versões:
2.8.3.1 Comerciais
Uspses
Secureiis
nevisProxy
Cisco ACE Web Application Firewall
Imperva - SecureSphere
F5 - Application Security Manager
Barracuda
Urlscan
ibmwas
Alert Logic Web Security Manager
2.8.3.2 Software livre
Ironbee
Modsecurity
41
Shadow Daemon
Vulture WebSSO
OWASP ESAPI WAF
OpenWAF
AQTRONIX WebKnight
Naxsi
Naxsi é um firewall de aplicação web open source, módulo a parte de aplicação
web nginx e está disponível para diversas distribuições linux. Ele trabalha em modo
de aprendizagem, onde o objetivo é acompanhar o comportamento do site para gerar
a whitelist necessárias, evitando, dessa maneira, falsos positivos. Naxsi aborda um
modelo positivo (whitelist) onde possui seus pós (rápido, resiliente e não depende de
atualização de assinaturas) e contras (configuração complexa dependendo da
aplicação usada).
O significado para o nome Naxsi é NGINX ANTI XSS & SQL INJECTION. A
ideia da criação surgiu da necessidade de ter um firewall rápido, seguro e que não
tivesse um custo elevado quanto wafs comerciais.
Segundo Koechlin (2012), a maioria das empresas deveriam mudar o nome de
seus produtos de Web Application Firewall (WAF) para Web Application Antivirus
(WAA), pois estes produtos, baseados em assinaturas, apenas combinam o conteúdo
das requisições com os padrões de ataques conhecidos, ao invés de fazer análise
exaustiva do comportamento da requisição. O autor ainda destaca que tais wafs
podem ser eficazes quando os ataques são conhecidos, porém, em outros casos,
podem ser facilmente contornados (bypass). Isso não se dá pelo fato dos softwares
serem ruins, mas porque eles não funcionam em um modelo que não é adaptado para
a segurança das aplicações webs (KOECHLIN, 2012).
42
3 CAPÍTULO III – CRIAÇÃO DO PACOTE
Basicamente, são utilizados dois contextos para adaptação do script, a primeira
é implantar o ambiente, suas configurações e adaptar o script. No segundo momento
a execução dos testes.
3.1 Implantação do cenário
Três máquinas virtuais são criadas na mesma máquina física para o ambiente
do laboratório conforme a figura 17. O servidor C executa o sistema operacional Linux,
com a distribuição Centos 6.7. Nele ainda há um servidor web apache, onde o mesmo
está executando uma aplicação chamada DVWA. No servidor B também executa um
sistema Linux, distribuição Centos 6.6, sem nenhuma aplicação instalada. Da mesma
forma que foi configurado o ambiente B se repete para o ambiente A, pois se trata de
um clone completo das configurações para fazer com que o script seja executado sem
erros. Desse modo, todos os servidores possuem alguns fatores em comuns como,
arquitetura do sistema operacional utilizado (i686), memória física (1 GB) e disco rígido
(8 GB).
Figura 17 – Arquitetura do ambiente
Fonte: O autor
43
3.2 Implementação do script
Este script tem sido baseado na linguagem shell script do Linux, uma vez que
esse é o ambiente utilizado. Esse script cobre os aspectos de planejamento,
configuração e implementação do projeto que facilita a operação e o trabalho com o
firewall de aplicação. No quadro 1, é apresentado o código fonte do script que, por
sua vez, é autoexplicativo e tem comentário detalhado sobre como ele foi montado.
Os métodos usados devem garantir que os objetivos do projeto sejam alcançados com
sucesso.
Quadro 1 - Código fonte do script
#!/bin/sh
#
#
#
### DEFININDO AS VARIÁVEIS DO SISTEMA
ARQ=$(uname -m)
NGINX="http://nginx.org/download/nginx-1.8.0.tar.gz"
NAXSI="https://github.com/nbs-system/naxsi/archive/master.zip"
LOG_ACCESS="nginx_access.log"
LOG_ERROR="nginx_error.log"
CORE_RULES="https://raw.githubusercontent.com/nbs-
system/naxsi/master/naxsi_config/naxsi_core.rules"
PID_NGINX="nginx.pid"
INIT_NGINX="https://raw.githubusercontent.com/L3V14TH4N/NGINX-
Init-Scripts/master/nginx"
### TELA INCIAL
echo " "
echo "iniciando a preparação do ambiente para instalação e
configuração do waf no `cat /etc/centos-release`"
echo " "
echo "Iniciando em `date +%d-%m-20%y` às `date +%H:%M:%S`"
echo " "
#echo "Testado no `cat /etc/centos-release`"
### BANNER ;)
Banner() {
44
echo
"#############################################################
#########"
echo -e ">>>" $*
echo
"#############################################################
#########"
}
### CASO A ARQUITETURA SEJA DIFERENTE, O PROGRAMA SERÁ
ENCERRADO
if [ $ARQ != 'i686' ]; then
echo "$ARQ não é suportada para a instalação! Use o sistema
i686"
fi
### DESATIVANDO O FIREWALL
service iptables stop
### CERTIFIQUE-SE QUE O AMBIENTE ESTEJA ATUALIZADO
echo "Executando upgrade..."
yum -y update 2>&1 /dev/null
### INSTALANDO COMPONENTES NECESSARIOS
yum install -y gcc g++ make cmake autoconf automake unzip
pcre-devel.i686 pcre-static.i686 pcre.i686 openssl.i686
openssl-devel.i686 openssl-perl.i686 openssl-static.i686
pyOpenSSL.i686 php-devel.i686 php-gd.i686 php-fpm.i686 php-
pear.noarch php-mysql.i6862> /tmp/LOG.txt
### ADICIONANDO USUÁRIO PARA APLICAÇÃO
groupadd -r nginx
useradd -r -g nginx nginx
### CLEAN UP
yum --quiet clean all
### BAIXANDO O NAXSI E NGINX
cd /tmp
wget $NGINX 2> /dev/null
wget $NAXSI 2> /dev/null
tar -xvzf nginx-*.tar.gz 2> /tmp/LOG2.txt
unzip master.zip 2> /tmp/LOG3.txt
mv naxsi-* naxsi
### CONFIGURANDO E INSTALANDO NGINX
Install_NGINX () {
cd nginx-*
45
./configure --conf-path=/etc/nginx/nginx.conf --add-
module=/tmp/naxsi/naxsi_src --user=nginx --group=nginx \
--error-log-path=/var/log/nginx/error.log --http-client-
body-temp-path=/var/lib/nginx/body \
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-
log-path=/var/log/nginx/access.log \
--http-proxy-temp-path=/var/lib/nginx/proxy --lock-
path=/var/lock/nginx.lock \
--pid-path=/var/run/nginx.pid --with-http_ssl_module \
--without-mail_pop3_module --without-mail_smtp_module \
--without-mail_imap_module --without-http_uwsgi_module \
--without-http_scgi_module --with-ipv6 --prefix=/usr
make
make install
Banner "\033[01;32mInstalação NGINX [ok]\033[00;37m"
}
Config_NAXSI () {
touch /tmp/$LOG_ACCESS
touch /tmp/$LOG_ERROR
mkdir -p /etc/nginx/sites-enabled
echo "Digite o caminho do site a ser protegido: "
echo "Exemplo: www.meusite.com.br/test"
read location
echo "
server {
proxy_set_header Proxy-Connection \"\";
listen *:80;
access_log /tmp/nginx_access.log;
error_log /tmp/nginx_error.log debug;
location / {
include /etc/nginx/naxsi.rules;
proxy_pass http://$location/;
#proxy_set_header Host www.mysite.com;
}
location /RequestDenied {
return 418;
}
}" > /etc/nginx/sites-enabled/default
### CRIANDO ARQUIVO DE CONFIGURAÇÃO DO NAXSI
echo -e "
LearningMode; #Enables learning mode
SecRulesEnabled;
#SecRulesDisabled;
DeniedUrl \"/RequestDenied\";
## check rules
46
CheckRule \"\$SQL >= 8\" BLOCK; CheckRule \"\$RFI >= 8\" BLOCK;
CheckRule \"\$TRAVERSAL >= 4\" BLOCK;
CheckRule \"\$EVADE >= 4\" BLOCK;
CheckRule \"\$XSS >= 8\" BLOCK;" > /etc/nginx/naxsi.rules
### core rules
wget -O /etc/nginx/naxsi_core.rules $CORE_RULES
Banner "\033[01;32mConfiguração NAXSI [ok]\033[00;37m"
}
Config_NGINX () {
### CRIANDO O DIRETÓRIO PARA PERMISSÃO DE SITES
mkdir -p /var/lib/nginx/body
### Configuração do NGINX
touch /var/run/$PID_NGINX
echo "
user nginx;
worker_processes 1;
worker_rlimit_core 500M;
working_directory /tmp/;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
use epoll;
# multi_accept on;
}
http {
include
/etc/nginx/naxsi_core.rules;
include /etc/nginx/mime.types;
server_names_hash_bucket_size 128;
access_log /var/log/nginx/access.log;
sendfile on;
keepalive_timeout 65;
tcp_nodelay on;
gzip on;
gzip_disable \"MSIE [1-6]\.(?!.*SV1)\";
include /etc/nginx/sites-
enabled/*;
}
" > /etc/nginx/nginx.conf
Banner "\033[01;32m[ok]\033[00;37m"
}
Install_INITD () {
47
### ADICIONANDO A INICIALIZAÇÃO APÓS REINICIO DO SISTEMA
wget -O /etc/init.d/nginx $INIT_NGINX 2> /dev/null
chmod +x /etc/init.d/nginx
chkconfig nginx on
service nginx start
Banner "\033[01;32mConfiguração NGINX [OK]\033[00;37m"
}
Install_NGINX
Config_NAXSI
Config_NGINX
Install_INITD
echo "Finalizado em `date +%d-%m-20%y` às `date +%H:%M:%S`"
Banner "\033[01;32m[Concluído!!!]\033[00;37m"
3.3 Testes
Todos os resultados foram analisados e serão esclarecidos nas figuras
seguintes.
Na figura 18, é possível observar o tempo inicial quando o script foi executado.
Figura 18 - Início da execução
Fonte: O autor
48
Na figura 19 apresenta o momento que há interação com o usuário. Nesse
caso, é para indicar qual aplicação a ser protegida.
Figura 19 - Interação com usuário
Fonte: O autor
Conforme a figura 20, é notado que o script foi instalado com sucesso.
Observando ainda a imagem, pode-se verificar o tempo que foi levado para finalizar
todo o processo de preparação do ambiente. Notadamente, isso não apenas mostra
a eficiência que o script tem, como também revela sua simplicidade.
Figura 20 - Finalização da execução
Fonte: O autor
49
Para ter certeza de que tudo está funcional, a figura 21 apresenta o firewall de
aplicação em funcionamento e pronto para realizar a defesa da aplicação vulnerável.
Figura 21 - Aplicação sendo protegida
Fonte: O autor
50
4 CAPÍTULO VI – CONCLUSÃO
Diante da teoria exposta no trabalho, conclui-se que uma organização que
tenha aplicação na Internet deve considerar a implantação do firewall de aplicação e
inclui-lo como parte de estratégia de segurança.
A intenção deste trabalho deu-se em demonstrar uma abordagem para
automatizar ambiente para o firewall de aplicação web Naxsi, através da aplicação
prática do script ng-nx.
Notadamente, esta prática mostra-se útil quando é necessário agilizar certas
tarefas para evitar a perda de tempo, quando consideradas outras demandas no
serviço. A importância de automação não se dá apenas para isso, mas também para
amenizar serviço.
Logo, tem-se que o resultado do trabalho é confirmar que o script mostrou-se
eficiente na preparação do ambiente e substitui o trabalho manual de instalar, baixar
pacotes e suas dependências, criar componentes no sistema, adicionar usuário da
aplicação e o ponto de inicialização da aplicação.
Finalmente, tentou-se apresentar a simplicidade e a utilidade de usar ng-nx
para o propósito de implantar o ambiente, pois é perceptível sua utilidade.
Para trabalhos futuros, pretende-se acrescentar outras funcionalidades no
script, como a instalação em multiplataforma do sistema operacional, criação de
arquivo Make e hardening6, visando contribuir com a necessidade, seja do ambiente
ou do utente.
6 Hardening é o processo de reforçar a segurança em sistemas.
51
REFERÊNCIAS ABNT – Associação Brasileira de Normas Técnicas. ABNT NBR ISO/IEC 27002 –Tecnologia da informação – Técnicas de segurança – Código de prática para a gestão de segurança da informação. ABNT, 2005. AJ00200 (Org.). Xssed. [2011?]. Disponível em: <https://github.com/aj00200/xssed>. Acesso em: 07 dez. 2015. BARKER, Keith; WALLACE, Kevin. CompTIA Network+ N10-006 Cert Guide. 1. ed. Texas: Pearson It Certification, 2015. BERNERS-LEE, T. et al. Hypertext Transfer Protocol -- HTTP/1.1. 1999. Disponível em: <http://tools.ietf.org/html/rfc2616>. Acesso em: 08 nov. 2015. BERNERS-LEE, T.; FIELDING, R.; MASINTER, L.. Uniform Resource Identifiers (URI): Generic Syntax. 2005. RFC 3986. Disponível em: <https://www.ietf.org/rfc/rfc3986.txt >. Acesso em: 08 nov. 2015. BRANDEL, Mary. Web Application Firewalls: How to Evaluate, Purchase and Implement. 2009. Disponível em: <http://www.csoonline.com/article/2124082/application-security/web-application-firewalls--how-to-evaluate--purchase-and-implement.html>. Acesso em: 08 nov. 2015. BRASIL ESCOLA. Internet. Disponível em: <http://www.brasilescola.com/informatica/internet.htm>. Acesso em: 08 nov. 2015. BRASIL. Constituição (2000). Decreto nº 3.505, de 13 de junho de 2000. Institui A Política de Segurança da Informação nos órgãos e Entidades da Administração Pública Federal. Brasília, BREAKTHESEC. BTS PenTesting Lab. 2013. Disponível em: <BTS PenTesting Lab>. Acesso em: 07 dez. 2015. CERT-BR. Cartilha de Segurança: Ataques na Internet. 2012. Disponível em: <http://cartilha.cert.br/ataques>. Acesso em: 08 nov. 2015. CERT-BR. Incidentes Reportados ao CERT.br -- janeiro a dezembro de 2014: Análise de alguns fatos de interesse observados neste período. 2015. Disponível em: <http://www.cert.br/stats/incidentes/2014-jan-dec/analise.html>. Acesso em: 30 mar. 2015. CISCO. What Is Network Security? Disponível em: <http://www.cisco.com/cisco/web/solutions/small_business/resource_center/articles/secure_my_business/what_is_network_security/index.html?referring_site=smartnavRD>. Acesso em: 08 nov. 2015.
52
CLULEY, Graham. The insider threat highlighted by Hacking Team and Ashley Madison hacks. 2015. Disponível em: <http://www.hotforsecurity.com/blog/the-insider-threat-highlighted-by-hacking-team-and-ashley-madison-hacks-12316.html>. Acesso em: 06 dez. 2015. CRAVENS, Jesse; BURTOFT, Jeff. HTML5 Hacks. [s. L.]: O'reilly Media, 2012. CURTIN, Matt. Introduction to Network Security. 1997. Disponível em: <http://www.interhack.net/pubs/network-security/network-security.html>. Acesso em: 08 nov. 2015. DADARIO, Anderson. XSS – Guia explicativo. 2012. Disponível em: <https://dadario.com.br/public/images/posts/xss-guia-exploit.png>. Acesso em: 07 dez. 2015. DVWA. DAMN VULNERABLE WEB APPLICATION. [2010?]. Disponível em: <https://github.com/RandomStorm/DVWA>. Acesso em: 07 dez. 2015. ELIAS, Glêdson; LOBATO, Luiz Carlos. Arquitetura e Protocolos de Rede TCP-IP. Rio de Janeiro: Escola Superior de Redes, 2013. ESTADOS UNIDOS. Código de Lei nº 3552, de 1994. Coordination Of Federal Information Policy: INFORMATION SECURITY. [S. l.], 2015. Seção 3552. Disponível em: <http://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title44-section3552&num=0&edition=prelim>. Acesso em: 09 nov. 2015. FEDON, Sensei. Best Open source Web Application Firewalls. 2011. Exemplo de WAF. Disponível em: <http://netsectr.blogspot.com.br/2011/10/best-open-source-web-application.html>. Acesso em: 08 nov. 2015. FEGAN, Sophia Chung; FOROUZAN, Behrouz A.. Protocolo Tcp/ip. 3. ed. S.l: Mcgraw-hill, 2010. Tradução por João Eduardo Nóbrega Tortello. FERREIRA, Silvio. Gerenciamento avançado de redes de computadores. [s. L.]: Digerati Books, 2000. FONTES, Edison. Políticas e Normas para a Segurança da Informação. São Paulo: Brasport, 2012. FOROUZAN, Behrouz A.; MOSHARRAF, Firouz. Redes de Computadores: Uma Abordagem Top-down. Texas: Mcgraw-hill Brasil, 2013. G1. Hackers invadem servidores do Exército e vazam CPFs de militares. 2015. Disponível em: <http://g1.globo.com/tecnologia/noticia/2015/11/hackers-invadem-servidores-do-exercito-e-vazam-cpfs-de-militares.html>. Acesso em: 06 dez. 2015. GARTNER. Now Is the Time for Security at the Application Level. 2005. Disponível em: <http://www.sigist.org.il/_Uploads/dbsAttachedFiles/GartnerNowIsTheTimeForSecurity.pdf>. Acesso em: 12 out. 2015.
53
HACKXOR. Hackxor. [2011?]. Disponível em: <http://hackxor.sourceforge.net/cgi-bin/index.pl>. Acesso em: 07 dez. 2015. IMPERVA (Org.). 2015 Web Application Attack Report (WAAR). 6. ed. [s. L.]: Imperva, 2015. INFOSEC. What is Information Security? Disponível em: <http://www.infosec.gov.hk/english/information/what.html>. Acesso em: 08 nov. 2015. KARL FORSTER. Why Firewalls Fail to Protect Web Sites. [s. L.]: Lockstep Systems, Inc, 2002. KOECHLIN, Thibault. What is Naxsi? 2013. Disponível em: <https://github.com/nbs-system/naxsi>. Acesso em: 08 nov. 2015. KOECHLIN, Thibault. Why naxsi ? Why is it different ? How it works ? 2012. Disponível em: <http://blog.memze.ro/?m=201202>. Acesso em: 08 nov. 2015. KUBE, Courtney; MIKLASZEWSKI, Jim. Russian Cyber Attack Targets Pentagon Email Systems: Officials. 2015. Disponível em: <http://www.nbcnews.com/tech/security/cyberattack-pentagons-joint-staff-emails-take-system-offline-n405321>. Acesso em: 06 dez. 2015. MALIK, Usman. Introduction to LAN, WAN and MAN: Networking Tutorial. 2014. Disponível em: <https://blog.udemy.com/lan-wan-man/>. Acesso em: 08 nov. 2015. MCAFEE. Hacme Bank v2.0 Released 5/19/2006. 2006. Disponível em: <http://www.mcafee.com/br/downloads/free-tools/hacme-bank.aspx>. Acesso em: 07 dez. 2015. MCCLURE, Stuart; SCAMBRAY, Joel; KURTZ, George. Hackers Expostos: Segredos e Soluções. 7. ed. [s. L.]: Bookman, 2014. MEUCCI, Matteo et al. OWASP TESTING GUIDE v3. Texas: Owasp Foundation, 2008. NASCIMENTO, Marcelo Brenzink do; TAVARES, Alexei Corrêa. Roteadores e Switches: Guia Para Certificação CCNA E CCENT. 2. ed. Rio de Janeiro: Editora Ciência Moderna, 2012. NYMITY. Nymity Corporate Privacy Compliance Handbook. [s. L.]: Nymity, 2010. OWASP. OWASP Best Practices: Use of Web Application Firewalls. Disponível em: <https://www.owasp.org/index.php/Category:OWASP_Best_Practices:_Use_of_Web_Application_Firewalls>. Acesso em: 08 nov. 2015. OWASP. Introduction. 2013. Disponível em: <https://www.owasp.org/index.php/Top_10_2013-Introduction>. Acesso em: 07 dez. 2015.
54
OWASP. OWASP Insecure Web App Project. 2004. Disponível em: <https://www.owasp.org/index.php/Category:OWASP_Insecure_Web_App_Project>. Acesso em: 07 dez. 2015. OWASP. OWASP Top 10 - 2013: Os dez riscos de segurança mais críticos em aplicações web. 2013. Disponível em: <http://owasptop10.googlecode.com/files/OWASP_Top_10_-_2013_Brazilian_Portuguese.pdf>. Acesso em: 07 dez. 2015. OWASP. OWASP WebGoat Project. [2008?]. Disponível em: <https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project>. Acesso em: 07 dez. 2015. OWASP. What is a vulnerability? [2003?]. Disponível em: <https://www.owasp.org/index.php/Category:Vulnerability>. Acesso em: 07 dez. 2015. PAULI, Josh. Introdução ao Web Hacking: Ferramentas e técnicas para invasão de aplicações web. São Paulo: Novatec, 2014. Tradução: Lúcia Ayako Kinoshita. PCI SECURITY STANDARDS COUNCIL. Information Supplement: Application Reviews and Web Application Firewalls Clarified. 2008. Disponível em: <https://www.pcisecuritystandards.org/documents/information_supplement_6.6.pdf>. Acesso em: 08 nov. 2015. SHEN, Gang; HUANG, Xiong. Advanced Research on Electronic Commerce, Web Application, and Communication: International Conference, ECWAC 2011, Guangzhou, China, April 16-17, 2011. Proceedings, Parte 2. 2. ed. [s. L.]: Springer, 2011. SIQUEIRA, Luciano Antonio. Infraestrutura de Redes: Col. Academy. 2. ed. [s. L.]: Linux, 2011. STUTTARD, Dafydd; PINTO, Marcus. The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws. 2. ed. Hoboken: Wiley, 2011. TANENBAUM, Andrew Stuart. REDES DE COMPUTADORES. 4. ed. [s. L.]: Elsevier Brasil, 2003. TANENBAUM, Andrew Stuart; WETHERALL, David J.. Redes de Computadores. 5. ed. [s. L.]: Pearson Education, 2011. TECHTARGET. Technical guide on: WEB APPLICATION firewalls. Disponível em: <http://viewer.media.bitpipe.com/1127859424_295/1288878967_864/1110_sS_TechGuide_WAF.pdf>. Acesso em: 08 out. 2015. TROST, Ryan. Practical Intrusion Analysis: Prevention and Detection for the Twenty-First Century. [s. L.]: Addison-wesley Professional, 2009.
55
UTO, Nelson. Teste de invasão de aplicações web. Rio de Janeiro: RNP/ESR, 2013. ZANINI, Fábio. Itamaraty sofre onda de ataques de hackers. 2015. Disponível em: <http://www1.folha.uol.com.br/mundo/2014/05/1460646-itamaraty-sofre-onda-de-ataques-de-hackers.shtml>. Acesso em: 06 dez. 2015. ZWICKY, Elizabeth D.; COOPER, Simon; CHAPMAN, Brent. Building Internet Firewalls. 2. ed. [s. L.]: O'reilly Media, 2000.
56
ANEXO A – Trecho do Relatório da Imperva
Figura 22 - Ataque Shellshock
Fonte: https://www.imperva.com/docs/HII_Web_Application_Attack_Report_Ed6.pdf
