CENTRO UNIVERSITÁRIO VILA VELHA
CURSO DE CIÊNCIA DA COMPUTAÇÃO
Maycon Maia Vitali
Halysson Freitas Alves da Silva
Sistema Inteligente de Detecção de Intrusão
VILA VELHA
Maycon Maia Vitali
Halysson Freitas Alves da Silva
Sistema Inteligente de Detecção de Intrusão
Trabalho de Conclusão de Curso apresentado ao Centro Univertário Vila Velha como
requisito parcial para a obtenção do grau
de Bacharel em Ciência da Computação.
Orientador: Erlon Pinheiro
VILA VELHA
Maycon Maia Vitali
Halysson Freitas Alves da Silva
Sistema Inteligente de Detecção de Intrusão
BANCA EXAMINADORA
Prof. Msc. Erlon Pinheiro
Centro Universitário Vila Velha
Orientador
Prof. Msc. Otacílio Pereira
Centro Universitário Vila Velha
Banca Examinadora
Prof. Msc. Leonardo Muniz de Lima
Centro Universitário Vila Velha
Banca Examinadora
Trabalho de Conclusão de Curso
aprovado em 14/10/2008.
A Deus e a nossas familias ...
AGRADECIMENTOS
Agradecemos a nosso orientador Erlon por ter nos guiados durante nossa jornada
para a conclusão deste trabalho.
“Adoraria mudar o mundo, mas não me deram o código-fonte...”
Autor Desconhecido
LISTA DE FIGURAS
1
Arquitetura de um HIDS . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2
Arquitetura de uma rede com NIDS . . . . . . . . . . . . . . . . . . . . .
17
3
Exemplo de código vulnerável a XSS . . . . . . . . . . . . . . . . . . . .
22
4
Exemplo de código vulnerável . . . . . . . . . . . . . . . . . . . . . . . .
23
5
Exemplo de código maléfico utilizado em ataques . . . . . . . . . . . .
23
6
Exemplo de código vulnerável a ataques de SQL Injection . . . . . . . .
24
7
Ataque de SQL Injection (formulário) . . . . . . . . . . . . . . . . . . . .
24
8
Ataque de SQL Injection (url) . . . . . . . . . . . . . . . . . . . . . . . .
25
9
Método HTTP-GET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
10
Método HTTP-POST . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
11
Exemplos de tipos de técnicas de evasão . . . . . . . . . . . . . . . . .
26
12
Função Booleana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
13
Gráfico Booleano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
14
Função Fuzzy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
15
Representação gráfica de um conjunto fuzzy . . . . . . . . . . . . . . .
31
16
Diagrama de Hassi-Euler do conjunto fuzzy B no universo real [-5,5] . .
31
17
Funções de Pertinência . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
18
Gráfico representativo das funções de pertinência . . . . . . . . . . . .
32
19
Função de pertinência da negação . . . . . . . . . . . . . . . . . . . . .
32
20
Representação da função de pertinência de negação de S . . . . . . .
32
21
Função de pertinência da união . . . . . . . . . . . . . . . . . . . . . . .
33
22
Representação da função de pertinência de união ente L e T . . . . . .
33
23
Função de pertinência da intercessão . . . . . . . . . . . . . . . . . . .
33
24
Representação da função de pertinência de interseção entre S e T . . .
34
25
Definição da variável lingüísticas ’temperatura’ . . . . . . . . . . . . . .
35
26
Modelo de Mandani . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
27
Arquitetura do SIDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
28
Exemplo de Base de Conhecimento . . . . . . . . . . . . . . . . . . . .
40
29
Exemplo de Funções de Inferência . . . . . . . . . . . . . . . . . . . . .
41
30
Gráfico do ’select’
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
31
Gráfico do ’union’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
32
Funções BAIXO, MÉDIO e ALTO . . . . . . . . . . . . . . . . . . . . . .
42
33
Regras fuzzy para o exemplo . . . . . . . . . . . . . . . . . . . . . . . .
43
34
Bibliotecas do Snort para o SIDI . . . . . . . . . . . . . . . . . . . . . .
45
35
Biblioteca principal do SIDI . . . . . . . . . . . . . . . . . . . . . . . . .
46
36
Bibliotecas de SPP em plugbase . . . . . . . . . . . . . . . . . . . . . .
46
37
Chamadas de SPP em plugbase . . . . . . . . . . . . . . . . . . . . . .
46
38
Primeira modificação do Makefile . . . . . . . . . . . . . . . . . . . . . .
47
39
Segunda modificação do Makefile . . . . . . . . . . . . . . . . . . . . .
47
40
Makefile SIDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
41
Base de Conhecimento para Testes . . . . . . . . . . . . . . . . . . . .
49
42
Funções de Pertinência para Testes . . . . . . . . . . . . . . . . . . . .
50
43
Regras Fuzzy para Testes . . . . . . . . . . . . . . . . . . . . . . . . . .
51
44
Resultado de Requisição Normal . . . . . . . . . . . . . . . . . . . . . .
52
45
Resultado de Ataque com SELECT
. . . . . . . . . . . . . . . . . . . .
53
46
Resultado de Ataque com execução de comandos . . . . . . . . . . . .
54
SUMÁRIO
RESUMO
1 Introdução
12
2 Objetivo
14
3 Sistemas de Detecção de Intrusão
15
3.1 Tipos de SDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2 SDI Baseado em Host . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.3 SDI Baseado em Rede
. . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.3.1 NIDS Ativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.3.2 NIDS Passivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.4 IDSs Baseado em Kernel . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.5 Exemplo de SDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.5.1 Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4 Vulnerabilidades Web
21
4.1 Cross-Site-Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2 File Include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.3 SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
5 Técnicas de Evasão
26
6 Sistema Especialista
27
6.1 Arquitetura de um SE . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
6.1.1 Base de Conhecimento . . . . . . . . . . . . . . . . . . . . . . .
28
6.1.2 Motor de Inferência
28
. . . . . . . . . . . . . . . . . . . . . . . . .
7 Lógica Fuzzy
30
7.1 Teoria de Conjuntos Fuzzy . . . . . . . . . . . . . . . . . . . . . . . . .
31
7.2 Operações Fuzzy Básicas . . . . . . . . . . . . . . . . . . . . . . . . . .
31
7.2.1 Complemento . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
7.2.2 União . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
7.2.3 Intercessão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
7.3 Representação Fuzzy do Conhecimento . . . . . . . . . . . . . . . . . .
34
7.3.1 Variáveis Lingüísticas . . . . . . . . . . . . . . . . . . . . . . . .
34
7.3.2 Regras de Produção Fuzzy . . . . . . . . . . . . . . . . . . . . .
35
7.4 Modelos de Inferência Fuzzy . . . . . . . . . . . . . . . . . . . . . . . .
35
7.4.1 Modelo de Mandani . . . . . . . . . . . . . . . . . . . . . . . . .
36
8 Sistema Inteligente de Detecção Intrusão
37
8.1 Motivação e Justificativas . . . . . . . . . . . . . . . . . . . . . . . . . .
37
8.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
8.3 Módulo Especialista . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
8.3.1 Linguagem de Representação do Conhecimento . . . . . . . . .
38
8.4 Módulo Fuzzy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
8.4.1 Processo de Fuzificação . . . . . . . . . . . . . . . . . . . . . . .
40
8.5 Construção de um Pré-Processador . . . . . . . . . . . . . . . . . . . .
45
8.6 Testes e Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
9 Trabalhos Futuros
56
10 Conclusão
57
REFERÊNCIAS
59
RESUMO
Com a expansão da Internet, diversas empresas têm migrado suas aplicações de
ambiente Desktop para Web. Com essas mudanças, a informação, o bem mais precioso de uma empresa, fica exposta e mais sujeita a violações. Este tipo de incidente
geralmente é causado por ex-funcionários, funcionários insatisfeitos ou mesmo por
espionagem industrial. De outro lado, especialistas em segurança vêm criando mecanismos e regras para diminuir esses ataques ou simplesmente detectá-los para,
posteriormente, analisar e fazer previsões seguindo suas tendências evolutivas. Porém, com o crescimento da Internet e, conseqüentemente, a facilidade de acesso à
informação, o nível de planejamento de ataques vem aumentando gradativamente, o
que dificulta o trabalho dos analistas de segurança. Este trabalho visa construir um
sistema inteligente híbrido que, através da utilização de lógica fuzzy e sistemas especialistas, objetivará diminuir as ocorrências de falsos-positivos e falsos-negativos
comumente encontrados em Sistemas de Detecção de Intrusão baseado em regras.
Palavras-chave: Inteligência Artificial.Lógica Nebulosa.Sistema de Detecção de Intruso.Sistema Especialistas
12
1
Introdução
Diariamente são constatadas diversas novas vulnerabilidades em portais e aplicações Web, o que confirma a necessidade de uma camada específica para segurança.
Porém, existem diversas técnicas de se evadir um ataque, para que o mesmo passe
despercebido por esta camada extra de segurança, tornando a utilização de Sistemas
de Detecção de Intrusão (IDS1 ) baseado em regras ineficazes.
A grande maioria dos IDSs são baseados em regras e assinaturas. As assinaturas
normalmente são utilizadas para fazer comparação de texto, ou seja, se uma determinado texto estiver contida dentro do pacote é gerado um alerta. Já uma regra consiste
em uma assinatura seguida de algumas características como portas e endereços de
origem e de destino, estado da conexão TCP, etc. O problema está no fato de ataques
planejados utilizarem de técnicas de evasão, que podem ser trabalhada pelo atacante
ou mesmo gerada pela aplicação.
Um exemplo de uma técnica de evasão não criada pelo atacante está no ataque a
aplicações WEB que trafegam sob HTTPS (HyperText Transference Protocol Secure),
que trabalha com criptografia de dados entre as pontas. Neste caso, a detecção deveria estar embutida na aplicação, já que em qualquer outro ponto intermediário da
comunicação impediria a análise da informação por estar criptografada.
Dentre os vários IDS’s disponíveis nos mercado, foi escolhido o Snort2 para a implementação deste projeto. O Snort é um sistema livre e de código aberto bastante
famoso e mais utilizado [1] , sua arquitetura modular permite que se adicione funcionalidades de maneira a expandir seus métodos de detecção.
Durante as sessões seqüentes, será descrito diversas técnicas de ataque utilizadas atualmente na Internet, além do funcionamento e das categorias de IDSs. Será
explicando como funcionam as técnicas de evasão e como através delas é possível
1 Do
inglês Intrusion Detection System
de Detecção de Intrusão mantido pela Sourcefire
2 Sistema
13
burlar IDSs baseados em regras. Existe uma sessão exclusiva para explicar como trabalhar com a lógica Fuzzy e será descrito o modelo de Mandani (selecionado para este
trabalho). Outra sessão descreve como funcionam os Sistemas Especialista e como
essa classe de ferramenta pode auxiliar na identificação de padrões de ataques. Com
toda a base teórica formada, as ultimas sessões descrevem o protótipo de um Sistema
Inteligente de Detecção de Intrusão, ou seja, uma ferramente que auxilia na tomada
de decisão frente a um ataque real.
14
2
Objetivo
O trabalho consiste em estudar conteúdos de Inteligência Artificial como Lógica
Fuzzy e Sistemas Especialista, afim de criar um protótipo de um sistema híbrido
que auxilie na detecção de intrusões. Esse protótipo foi construído como um préprocessador para o Snort, o IDS mais utilizado no mundo, com código-fonte aberto
e com arquitetura de fácil expansão. Com essa implementação, foi possível realizar
alguns testes e concluir situações em que o módulo trabalharia melhor que o motor de
regras padrão do Snort.
15
3
Sistemas de Detecção de
Intrusão
Defini-se IDS de acordo com o [2] como “o processo de monitoramento de eventos
e análise dos sinais/anomalias, de intrusões que ocorrem em um ambiente computacional”, cuja função é detectar estas atividades maliciosas ou anômalas e alertar ao
administrador do sistema de que estes eventos estão ocorrendo. Estas anomalias/intrusões são os resultados de ataques provenientes de diversas fontes como acesso
não autorizados, acesso a arquivos não permitidos, e ainda os diversos softwares
maléficos comumente encontrados como: vírus, cavalos de tróia e “vermes”1 .
3.1 Tipos de SDI
Apresenta-se nas próximas subseções os principais tipos de IDS:
• Sistemas de Detecção de Intrusão Baseados em Servidor
• Sistemas de Detecção de Intrusão Baseados em Rede
– IDS Passivo
– IDS Ativo
• Sistemas de Detecção de Intrusão Baseados em Kernel 2
1 Do
2O
inglês worms
termo técnico Kernel representa o núcleo de um Sistema Operacional
16
3.2 SDI Baseado em Host
Os Sistemas de Detecção de Intrusão baseados em servidor (HIDS3 ) tem como
objetivos principais alertar e identificar ataques e tentativas de acesso indevido a própria máquina sendo geralmente empregados quando a segurança está focada nas
informações contidas no servidor e os usuários não precisam ser monitorados.
Figura 1: Arquitetura de um HIDS
Os HIDS podem monitorar diversas variáveis no ambiente do servidor como por
exemplo alterações de registros, adição de usuários, instalação e ocultação de rootkits4 , acesso a arquivos e verificação de integridade como binários falsos incluídos no
sistema por usuários mal intencionados. Não há necessidade de outro equipamento
para que o ambiente tenha um HIDS em funcionamento, o mesmo pode ser instalado
no próprio servidor, vide Figura 1.
3.3 SDI Baseado em Rede
Os Sistemas de Detecção de Intrusão Baseados em Rede (NIDS5 ), utilizam de um
modo especial de funcionamento da interface de rede denominado de “modo promíscuo” onde a interface passa a capturar o tráfego em tempo real e com isso permite
analisar os pacotes que estão trafegando no segmento de rede em questão. Ao ser
3 Do
inglês Host Intrusion Detection System
rootkit é uma classe de software que busca se esconder do sistema de segurança e do usuário
utilizando diversas técnicas avançadas de programação
5 Do inglês Network Intrusion Detection System
4 Um
17
detectada alguma anomalia, o NIDS envia alertas para o administrador do sistema ou
para o especialista em segurança.
O diferencial entre estes dois primeiros tipos de IDS é que o HIDS possui um
problema quanto aos registros, pois como ele está instalado no próprio servidor o
atacante ao conseguir acesso poderá apagar, ou ainda pior, modificar as evidências
de sua entrada no sistema podendo fazer do alvo um “zumbi” para uma próxima ação
criminosa.
Figura 2: Arquitetura de uma rede com NIDS
Um NIDS pode detectar desde um número excessivo de mensagem, ataques de
negação de serviço (DoS6 ) e ataques que usam pacotes fragmentados. A Figura 2 demonstra a necessidade de outro equipamento para a instalação do IDS, este encontrase em modo promíscuo escutando o tráfego da rede em que está conectado. A forma
com que estes IDS trabalham podem variar mas, geralmente os IDS são encontrados
em duas categorias:
• IDS Baseados em Assinatura: Detectam ataques conhecidos que estão em sua
base de assinaturas;
• IDS Baseados em Anomalias: Registra a atividade normal da rede em um momento chamado de “aprendizagem”, e em seguida alerta quando ocorre um desvio no tráfego da rede do que é considerado como atividade normal.
Os Sistema de Detecção de Intrusão Baseados em Rede podem ser divididos em
duas categorias diferentes: IDS Ativo e IDS Passivo.
6 Do
inglês Denial of Service
18
3.3.1
NIDS Ativo
NIDSs Ativos são aqueles que ao detectarem anomalias ou ataques a um determinado seguimento de rede, tomam ações como finalizar a conexão e/ou trabalhar em
conjunto com o firewall 7 para bloquear o tráfego proveniente de uma fonte suspeita.
NIDSs Ativos tem por característica sua localização lógica na rede, ficando entre o
acesso externo e o servidor interno. Sua principal vantagem está no fato de todos os
pacotes que chegarem a rede precisarem passar pela análise do NIDS. Por outro lado,
sua principal desvantagem está no problema do “gargalo” gerado na rede, perdendo
em desempenho.
3.3.2
NIDS Passivo
NIDSs Passivos são aqueles que ao detectarem uma possível violação da segurança registram o feito em logs8 e enviam alertas para o administrador do sistema
ou o responsável pela segurança da rede. NIDSs Passivos ficam localizados em paralelo ao tráfego da rede, evitando perda de desempenho. Por outro lado, existe a
possibilidade de ataques em massa terem sucesso, visto que os NIDSs Passivos não
conseguiriam analisar todos os pacotes enviados ao servidor interno.
3.4 IDSs Baseado em Kernel
IDSs baseados em Kernel(KIDS9 ) são relativamente novos, onde os mesmos cabem a prevenir buffer overflows10 , abuso de funções com permissões administrativas,
além de aumentar a proteção no sistema de arquivos, melhorar o modelo de controle
de acesso, dentre outros.
7 Ferramenta
de gerenciamento de rede através políticas de segurançã
comumente utilizado para representar registros
9 Do inglês Kernel Intrusion Detection System
10 Classe de vulnerabilidade provinda do mal gerenciamento de memoria de aplicativos
8 Termo
19
3.5 Exemplo de SDI
3.5.1
Snort
Snort[3] é um sistema de NIDS de código-aberto, multiplataforma e multi-arquitetura.
Desenvolvido a principio por Martin Roesch e agora sendo mantido pela comunidade,
trabalha em rede e pode ser executado em modo passivo ou ativo. Capaz de realizar
análise de tráfego em tempo real e registro de pacotes em redes IP, o Snort executa
análise de protocolos, busca e associa padrões de conteúdo e pode ser usado para
detectar inúmeros ataques como por exemplo buffer overflows.
O Snort pode ser usado como um sniffer 11 de pacotes, assim como Wireshark12
ou tcpdump13 por exemplo, como um registrador de pacotes, onde o Snort passa a
registrar os pacotes capturados guardando os registros em disco, ou como um NIDS.
Espelhamento de portas compreende em uma interface do switch14 que recebe
todo o tráfego da rede em forma de espelho, ou seja, mesmo que determinados pacotes não sejam para aquela máquina em questão. Esta função só é recomendável para
análise dos pacotes que estão trafegando pela rede, pois o equipamento que receberá
o tráfego espelhado deverá ter uma alta taxa de transferência.
A principal característica do Snort é a inspeção do conteúdo do pacote no camada
7 do modelo OSI15 (ou camada de aplicação na arquitetura TCP/IP16 ), onde para a
realização da detecção de anomalias a mensagem é decodifica e, através das regras,
pode-se detectar uma tentativa de ataque. A saída decodificada do Snort é compreensível aos usuários, porém determinadas informações como portas e nomes de hosts
não estão inclusas nestas informações, para o não comprometimento do processamento realizado pelo motor do Snort.
A arquitetura padrão do Snort baseia-se em uma arquitetura modular, por plugins,
e de quatro componentes básicos:
• Sniffer
• Pré-processador
11 Classe
de ferramenta responsável por analisar os pacotes que trafegam pela rede
de sniffer
13 Exemplo de sniffer
14 Hardware responsável pela comutação de pacotes na rede
15 Do inglês OpenSource Interconection
16 Padrão da Internet
12 Exemplo
20
• Motor de Detecção
• Saída
O sniffer é o “farejador” de pacotes, ou seja, captura os pacotes da rede por intermédio de uma interface de rede em modo promíscuo. Os pré-processadores são
responsáveis por determinadas tarefas onde a arquitetura de regras atual não consiga
manipular, como por exemplo scanning de portas. O Motor de Detecção é responsável pela verificação dos pacotes junto às regras. Caso a resposta do seja afirmativa,
é enviado um alerta para a saída do IDS, e esta saída pode ir para um arquivo de log
ou para um Banco de Dados.
21
4
Vulnerabilidades Web
Nesta sessão serão descritos algumas das principais ameaças em ataques ocorridos na web. Ela tem por objetivo determinar o motivo pelo qual foi escolhido a classe
de vulnerabilidade de SQL Injection para nosso objetivo e, quais são as outras ameaças no qual a ferramenta poderia ser adaptada.
Todas as falhas descritas nessa sessão se caracterizam pela má filtragem das informações fornecidas pelo usuário. Estas informações podem vir de quaisquer dados
manipuláveis pelo usuário como cookies, campos de formulários, variáveis da URL,
entre outras.
Por não passarem por um filtro de caracteres especiais, os dados enviados durante um ataque são interpretados de maneira errônea pela aplicação, alterando a
lógica e induzindo na geração de condições não previstas pelas regras de negócio da
corporação.
4.1 Cross-Site-Script
A vulnerabilidade de Cross-Site-Script (XSS1 ), se classifica como uma falha de
ataque em clientes, ou seja, tem como alvo os navegadores web, sem comprometer o
servidor em questão.
A exploração de XSS ocorre quando um atacante insere códigos (geralmente javascript) de maneira a executa-los (no caso da vítima). O código pode ser planejado
de modo a alterar informações na página visitada pela vítima, redirecionar a página
para outro endereço falso ou fazer o chamado sequestro de sessão2 , fornecendo ao
atacante as informações que indicam que a vítima está autenticada e, se as mesmas forem copiadas e não houver nenhum outro mecanismo de segurança, é possível
1A
abreviação não é CSS pois esta é utilizada para definir a linguagem de estilização de páginas
Hijacking em inglês
2 Session
22
obter os privilégios da vítima no sistema em questão.
Figura 3: Exemplo de código vulnerável a XSS
Como na Figura 3 não existe nenhum filtros de caracteres especiais antes de enviar o valor da variável nome de volta ao navegador, um atacante poderia forjar uma
URL que contenha algum código javascript maléfico. Poderia ser passado na variável
nome algo como <script>alert(document.cookie)</script>. Dessa maneira, ao acessar o endereço, a vítima visualizaria seu cookie em uma mensagem do navegador.
Um ataque planejado consiste em, usando alguns artifícios de programação para Internet, capturar o valor dessa variável (document.cookie) e enviá-la ao atacante. Em
posse desta, o atacante simula uma requisição ao servidor passando esta variável, de
maneira à executá-la com os privilégios da vítima.
4.2 File Include
A classe de vulnerabilidades denominada File Include3 , se caracteriza por, na maioria dos casos, comprometer o servidor que hospeda a aplicação. Desta maneira, o
atacante pode interferir facilmente em todas as vertentes da segurança da informação4 .
Encontrada em diversas linguagens de programação, a vulnerabilidade de File Include consiste em utilizar de características de divisão de código em diversos arquivos
(como modularização) onde, através da manipulação de variáveis que auxiliam na escolha do módulo a ser adicionado no código, um atacante modifica o resultado dessa
geração, fazendo com que a aplicação execute um código maléfico arbitrário.
Como analisado no código PHP da Figura 4, a variável pagina, passada como
parâmetro pelo método HTTP-GET, pode ser facilmente manipulada por um atacante
diretamente pela URL. De acordo com a documentação5 , a função include() pode
3 Do
inglês inclusão de arquivo
vertentes são disponibilidade, integridade e confidencialidade
5 http://br2.php.net/include/
4 Essas
23
Figura 4: Exemplo de código vulnerável
buscar o arquivo solicitado de uma máquina remota e, se o arquivo remoto possuir
algum código PHP, o mesmo será executado no servidor local. Como a variável não
passa por filtros, um atacante poderia induzir o programa a buscar um código maléfico
em um servidor, de maneira a fazer esse código ser executado no servidor local.
Um código maléfico que poderia ser utilizado em um ataque pode ser visto na
Figura 5.
Figura 5: Exemplo de código maléfico utilizado em ataques
Com isto, um atacante poderia invadir o servidor vulnerável simplesmente acessando o arquivo /index.php?pagina=http://www.hack.com/b4d_c0de.txt?&cmd=id. Desta
maneira, o código no servidor irá incluir o código maléfico em seu ambiente e executálo. Nota-se que na URL existe também uma variável cmd que não existe para o programa do servidor, porém é interpretada pelo código injetado pelo atacante que, através da função passthru(), executa um texto passado como parâmetro como comando
interno do servidor e retorna o resultado para o navegador web.
4.3 SQL Injection
O ataque de SQL Injection consiste em injetar código de SQL (Structure Query
Language) em informações que podem ser manipuladas pelo usuário. Estas informações podem ser campos de formulários, variáveis de URL ou até mesmo valores de
24
controle de sessão dos navegadores. O objetivo é alterar a lógica do comando SQL
para executar comandos arbitrário.
Um exemplo de código vulnerável a SQL Injection está em uma não filtragem dos
parâmetros passados no formulário HTML para um código da linguagem de programação PHP .
Figura 6: Exemplo de código vulnerável a ataques de SQL Injection
Observa-se na Figura 6 que as variáveis “usuario” e “senha” são passadas para o
comando SQL com nenhuma filtragem de caracteres especias. Assim, um atacante
poderia burlar facilmente esse método de validação simplesmente “injetando” código
SQL no formulário de autenticação (onde o campo “Senha” possui o mesmo valor do
campo “Usuário”) como visto na Figura 7.
Figura 7: Ataque de SQL Injection (formulário)
Como visto na Figura 7, a lógica do comando SQL foi alterada, fazendo com que
ele retorne os registros cujo usuário esteja vazio ou vazio seja igual a vazio, e cujo
campo senha esteja vazia ou vazio seja igual a vazio. O comando SQL final retornará
25
todos os registros da tabela de usuários.
O ataque também pode ser efetuado acessando diretamente a URL do código
vulnerável preenchendo os parâmetros necessários como na Figura 8. Isto ocorre
porque os parâmetros são passados e verificados através do método HTTP-GET, onde
as variáveis e seus valores ficam acessível pela URL.
Figura 8: Ataque de SQL Injection (url)
Ao acessar este endereço da Figura 8, o navegador envia basicamente a requisição HTTP indicada na Figura 9 para o servidor, onde os parâmetros são codificados
convertendo seus caracteres especiais em seus respectivos valores ASCII em hexadecimal precedido de um sinal de percentil (%). O cabeçalho HTTP termina com duas
quebras de linha.
Figura 9: Método HTTP-GET
Porém, por convenção não é recomendado passar informações sigilosas como senhas pelo método GET, visto que a mesma seria facilmente visualizada na URL por
outros usuários. Para evitar isto, pode-se utilizar o método HTTP POST, que envia as
informações no final do cabeçalho HTTP e não na URL. Para isto, será necessário modificar o formulário inicial, alterando a propriedade method do formulário de get para
post, e modificar a forma com que as variáveis são obtidas no código PHP, trocando
$_GET por $_POST. Com isto, ao submeter o formulário, o cabeçalho enviado será
semelhante ao apresentado na Figura 10. Neste caso, o método HTTP enviado foi o
POST seguido do caminho no servidor do arquivo que processará a requisição e no
final do cabeçalho é enviado os dados fornecidos pelo usuário.
Figura 10: Método HTTP-POST
26
5
Técnicas de Evasão
Como visto anteriormente, existem diversas classes de vulnerabilidades em ambientes Web. Para essas vulnerabilidades, existem uma vasta base de assinaturas
(regras) que dificultam seu sucesso em ataques padronizados ou por ferramentas automatizas. Porém, em ataques bem definidos utiliza-se de técnicas de evasão, onde
o atacante modifica o ataque de maneira que não se encaixe nas regras previstas.
Isto pode ser feito com a manipulação de espaços, inserindo comentário (sintaxe C),
encoding (hexadecimal, base64, decimal, etc), entre ontros.
Uma comparação entre os modos de ataques de SQL Injection comum e a utilização de técnicas evasivas pode ser visto na Figura 11.
Figura 11: Exemplos de tipos de técnicas de evasão
Quando o atacante obtém sucesso, ocorre o chamado falso-negativo, pois o IDS
marca a entrada como negativa (não consiste em um ataque) quando, na verdade,
consistia em um ataque. Por outro lado, tem-se os chamados falso-positivo, que ocorre
quando o IDS marca uma entrada como tentativa de ataque, quando na verdade não
é.
27
6
Sistema Especialista
Os Sistemas Especialistas(SE) consistem em uma subclasse dos chamados Sistemas Baseados em Conhecimento (SBC), com o objetivo de solucionar problemas de
um domínio específico. Seu funcionamento básico consiste na emulação do raciocínio
de um especialista onde, através de uma seqüência de condições, pode-se obter uma
conclusão para um dado problema.
Uma das áreas que mais demonstra interesse pela implantação de Sistemas Especialista é a área médica, haja visto que em uma consulta médica, através de um
conjunto de perguntas feitas pelo médico, é possível obter um pré-diagnóstico do paciente. Com isto, o SE seria o responsável por transmitir as perguntas e, a partir das
respostas dada pelo paciente, determinar um conjunto de possíveis diagnósticos. Um
exemplo de Sistema Especialista para diagnóstico médico pode ser visto em [6].
Sempre que um problema não puder ser modelado em forma de algoritmo ou,
se possível, for inviável por ter uma grande quantidade de regras específicas, os SEs
podem ser utilizados como mecanismo de solução pois, além de trabalharem com uma
base de conhecimento, possui seu mecanismo baseado em processos heurísticos.
6.1 Arquitetura de um SE
Segundo [19], os SEs são responsáveis por, através de um conjunto de dados de
entrada, determinar um possível conjuntos de soluções. Desta maneira, necessita-se
de transformar o conhecimento tácito de um especialista em um conhecimento explícito. O conhecimento tácito é aquele que se forma pela experiência pessoal, de
maneira que não consiga ser estruturada facilmente pela linguagem, enquanto o conhecimento explícito é facilmente representado em forma de imagem ou texto de forma
que se seja possível armazená-lo e retê-lo. Desta forma, para uma boa modelagem
de um SE, é necessário representar o conhecimento de um especialista de tal forma
28
que uma máquina possa armazená-lo. Com isto, a arquitetura de um SE geralmente
é dividida em uma parte específica para armazenar o conhecimento e um motor de
inferência que é responsável pela busca e avaliação dessas informações.
6.1.1
Base de Conhecimento
A Base de Conhecimento de um SE tem por objetivo armazenar a informação do
especialista de maneira explícita. Este processo geralmente é feito pelo especialista
em conjunto com o chamado Engenheiro de Conhecimento que tem como finalidade
analisar e representar o conhecimento.
A Base de Conhecimento consiste no elemento dinâmico de um SE, ou seja, ele
pode ser variado de acordo com sua utilização de maneira que, quanto maior a Base
de Conhecimento, melhor será os resultados propostos pelo sistema. O preenchimento da base de conhecimento pode ser feito tanto manualmente pelo engenheiro
de conhecimento quanto automaticamente através de um módulo de aprendizagem
que, através das decisões tomadas, se algumas delas não forem compatíveis com o
real, será informado um parâmetro de diferenciação fazendo com que, na ocorrência
do mesmo caso, o SE retorne um resultado mais satisfatório.
Geralmente uma base de conhecimento é formada por um conjunto de regras
que, de acordo com suas execuções, preenche diversos parâmetros que influenciam
na tomada de decisão do SE.
6.1.2
Motor de Inferência
O Motor de Inferência (ou Mecanismo de Inferência) consiste em um elemento
permanente do sistema, ou seja, não precisa ser modificado constantemente e além
disto, pode ser reutilizado em outros SEs. Este elemento da arquitetura dos SEs é
responsável pela leitura dos conjuntos de entradas, análise das entradas com a Base
de Conhecimento e do fornecimento da conclusão. Basicamente o Motor de Inferência
é dividido em tarefas simples que são: Selecionar, buscar e avaliar.
Um exemplo de inferência seria para determinar o grau de parentesco entre duas
pessoas. Seja uma Base de Conhecimento com a seguinte informação:
• SE (mãe(pessoa1) = mãe(pessoa2) E pai(pessoa1) = pai(pessoa2)) ENTAO irmãos(pessoa1,
pessoa2)
29
Suponto que o sistema tenha como entrada o seguinte:
• O pai de Pedro é João
• A mãe de Pedro é Maria
• O pai de Carlos é João
• A mãe de Carlos é Maria
Como se tem o conhecimento da regra de parentes dada, as informações fornecidas pelo sistema inferem diretamente com a regra, logo pode-se concluir que Pedro e
Carlos são irmãos.
30
7
Lógica Fuzzy
A computação convencional baseia-se em operações lógicas, comumente lógica
booleana, onde atribuem-se os estados verdadeiros ou falsos para as condições existentes. A lógica nebulosa1, é usada para tratar estados parciais de verdade, onde o
complemento dessa é um estado parcial de falsidade.
De acordo com [5], a teoria clássica de conjuntos tolera o tratamento de classes de
objetos e suas relações internas em um universo delimitado. Este universo de discurso
pode ser discreto ou contínuo, dependendo da natureza dos objetos que o constituem.
Por exemplo, pode-se definir um universo U discreto que armazena números entre -5 e
5 do conjunto Z e assim definir um conjunto A:1,2,3,4,5, onde sua função característica
é definida por XA : U → {0, 1} onde cada elemento de U recebe um valor binário para
determinar o conjunto A. Esta função é representada na Figura 12 e seu gráfico na
Figura 13.
XA (x) =
0 se
1 se
x 6∈ A
x∈A
Figura 12: Função Booleana
Figura 13: Gráfico Booleano
Já em conjuntos fuzzy podemos ter um conjunto B = A, mas sua função característica é definida por µB : U → [0, 1] onde cada elemento de U recebe um valor no
intervalo fechado [0,1]. Esta função está representada na Figura 14 e seu gráfico na
Figura 15.
31
µB (x) =
0
2x
10
se X ≤ 0
se 0 < x ≤ 5
Figura 14: Função Fuzzy
Figura 15: Representação gráfica de um conjunto fuzzy
7.1 Teoria de Conjuntos Fuzzy
O conjunto B pertence a um universo discreto U e sua função característica é
chamada também de função de pertinência. O suporte de B é um subconjunto de U
que possui µB maior do que zero. Para representar um conjunto contínuo usa-se um
gráfico de pertinência, chamado de diagrama de Hassi-Euler (H-E). Veja a Figura 16.
Figura 16: Diagrama de Hassi-Euler do conjunto fuzzy B no universo real [-5,5]
7.2 Operações Fuzzy Básicas
Considere três conjuntos fuzzy chamados “sólido”, “transição” e “liquido”, cuja suas
funções de pertinência são definidas na Figura 17 e na Figura 18 está a representação
em forma de gráfico.
7.2.1
Complemento
Pode-se denotar por ∼A, a operação de complemento de um conjunto fuzzy A do
universo de discurso U, definida com uma função de pertinência na Figura 19, como
32


µS : U =

se x ≤ −2
se − 2 < x < 0
0
se x ≥ 0
1
x
−2
2−|x|
2
µT : U =
µL : U =

 1
se
0 se
|x| ≤ 2
|x| > 2
se x ≥ 2
se 0 < x < 2

0
se x ≤ 0
x
2
Figura 17: Funções de Pertinência
Figura 18: Gráfico representativo das funções de pertinência
no gráfico da Figura 20.
µ¬A (xi ) = 1 − µA (xi )
Figura 19: Função de pertinência da negação
Figura 20: Representação da função de pertinência de negação de S
7.2.2
União
A representação pode ser A U B ou A + B e sua função de pertinência pode ser
vista na Figura 21.
Esta é uma definição particular da operação de união proposta por [8] na década
de 1960. Na verdade, uma forma mais geral de definir a operação de união entre
33
µA∪B (xi ) = max[µA (xi ), µB (xi )]
Figura 21: Função de pertinência da união
conjuntos fuzzy é por meio das normas S, ou seja, de uma família de funções com as
seguintes propriedades:
• Comutatividade: S(a,b) = S(b,a);
• Associatividade: S(a,S(b,c)) = S(S(a,b),c);
• Monotonicidade: se a <= b e c <= d, então S(a,c) <= S(b,d);
• Coerência nos contornos: S(a,1) = 1 e S(a,0) = a
Veja um exemplo na Figura 22, de µL∪T :
Figura 22: Representação da função de pertinência de união ente L e T
7.2.3
Intercessão
A representação pode ser A ∩ B ou A.B e sua função de pertinência pode ser vista
na Figura 23.
µA∩B (xi ) = min[µA (xi ), µB (xi )]
Figura 23: Função de pertinência da intercessão
Similarmente ao caso da união, a operação de interseção entre conjuntos fuzzy
pode ser generalizada por meio de famílias específicas de funções, chamadas de
normas T, com as seguintes propriedades:
• Comutatividade: T(a,b) = T(b,a);
• Associatividade: T(a,T(b,c)) = T(T(a,b),c);
34
• Monotonicidade: se a <= b e c <= d, então T(a,c) <= T(b,d);
• Coerência nos contornos: S(a,1) = a e S(a,0) = 0.
Veja um exemplo na Figura 24, de µS∩T :
Figura 24: Representação da função de pertinência de interseção entre S e T
7.3 Representação Fuzzy do Conhecimento
Como nos processos de engenharia de software a representação fuzzy de um
determinado problema é feito de forma top-down, ou seja, primeiro faz-se um levantamento geral e superficial do que se deseja resolver, para depois determinar um algoritmo e modelos matemáticos. Desta maneira podemos classificar nossos problemas
com valores qualitativos em vez dos quantitativos, essa maneira imprecisa de pensar
nos leva ao conceito de variáveis lingüísticas. O processo de representação fuzzy de
conhecimento depende desse conceito.
7.3.1
Variáveis Lingüísticas
O conceito de variáveis lingüísticas está relacionado diretamente com um modelo
em sua forma bruta, ou seja, ao natural da visão humana e seus valores possíveis
são qualitativos, gerando assim uma imprecisão. Uma forma muito usada é a variável
lingüística temperatura onde podemos ter valores qualitativos como muito baixa, baixa,
agradável, alta e muito alta. Defini-se temperatura no universo de discurso determinado pelo intervalo [0,50] e seus valores qualitativos são subconjuntos dentro deste,
e cada um dos números reais neste intervalo tem um grau de pertinência dentro de
cada subconjunto, como mostra a Figura 25.
Nota-se, por exemplo, que em a temperatura igual a 20 no universo de discurso
de temperatura, existe um grau de pertinência para cada valor qualitativo, onde Muito
35
Figura 25: Definição da variável lingüísticas ’temperatura’
Baixa = 0, Baixa = 0.5, Agradável = 0.5, Alta = 0 e Muito Alta = 0.
7.3.2
Regras de Produção Fuzzy
As regras de produção fuzzy são formadas por duas partes, um antecedente e um
conseqüente, no seguinte formato: se <antecedente> então <conseqüente>
Um exemplo de regra seguindo as variáveis descritas anteriormente poderia ser:
se (temperatura = muito alta) então (beba_liquido ← muito)
7.4 Modelos de Inferência Fuzzy
Os modelos de inferência fuzzy caracterizam-se sobre a semântica do mecanismo,
modelando como será a avaliação dos antecedentes e como se aplicará os conseqüentes. Para se fazer isso são utilizados modelos de inferência fuzzy específicos,
com propriedades sintáticas definidas, ou seja, o modelo de processamento definido
para o sistema de conhecimento vai depender basicamente da forma de armazenamento de informações escolhida.
36
7.4.1
Modelo de Mandani
De acordo com [5], o método de inferência de mamdani tem como característica
possuir relações fuzzy nos antecedentes e também nos conseqüentes. Normalmente
o conjunto de dados são variáveis quantitativas, para isso, o modelo de mamdani
utiliza duas interfaces, uma de entrada e outra de saída. Elas são responsáveis pela
comunicação do sistema, fazendo uma conversão de quantitativo (variável numérica)
para qualitativo (variável lingüística). Os processos de conversão são chamados de
fuzificação e defuzificação respectivamente para entrada e saída de dados. A Figura
26 exemplifica um modelo de processamento fuzzy de inferência de Mamdani.
Figura 26: Modelo de Mandani
37
8
Sistema Inteligente de Detecção
Intrusão
8.1 Motivação e Justificativas
Várias são as maneiras de evadir um ataque de maneira que os IDSs baseados
em regras não os detectem. Visando o aumento da segurança e a diminuição dos
falso-positivos e falsos-negativos, planejou-se a construção de um Sistema Inteligente
de Detecção de Intrusão (SIDI).
Para vulnerabilidade, foi escolhido a detecção de ataques de SQL Injection, pois
comparado com as demais falhas vistas, possui a maior proporção de ocorrência por
impacto na aplicação.
As vulnerabilidades de XSS são encontradas vastamente pela Internet, porém sem
um bom planejamento e utilização de mecanismos avançados de ataque, fica praticamente inviável a exploração. As vulnerabilidades de File Include possuem um impacto
extremamente forte em sua exploração, porém dificilmente se encontra esse tipo de
falha, pois essa classe de vulnerabilidade já é bastante difundida e existe mecanismos e configurações adicionais para inibi-las. Já as vulnerabilidades de SQL Injection
possúem impacto significante (não tanto quanto File Include) e tem um alto grau de
ocorrência nas diversas aplicações web (não tanto quanto XSS).
Como ferramenta de apoio foi escolhido o NIDS Snort, por possuir código-fonte
aberto, suporte a expansão através de pré-processadores e plugins, possuir mais de
3 milhões de downloads e mais de 100.000 usuários ativos(Referência em [4]).
38
8.2 Arquitetura
Para uma melhor manipulação das informações, foi desenvolvido um arquitetura
híbrida para o SIDI utilizando um módulo especialista para o reconhecimento de características de ataque e um módulo fuzzy para a tomada de decisão. Uma breve
explanação da arquitetura projetada pode ser vista na Figura 27.
Figura 27: Arquitetura do SIDI
8.3 Módulo Especialista
De uma maneira geral, inicialmente, o pacote de rede será transmitido para o SIDI.
Com isto, através de um módulo especialista, será feito o processo de taxonomia, ou
seja, a transformação das informações de entrada em variáveis quantitativas. Cada
uma dessas variáveis representará um grau de ocorrência de um determinado termo
comumente utilizado em ataques tais como comentários, palavras reservadas, divisão
de comandos, etc. Esta transformação é feita pelo motor de inferência do módulo
especialista que, através da base de conhecimento, reconhece tais padrões.
8.3.1
Linguagem de Representação do Conhecimento
Com o objetivo de organizar as informações de maneira aberta e de fácil manipulação, foi planejado representar a base de conhecimento através de arquivos do tipo
XML. Para isto, utilizou-se a biblioteca libxml 1 que está presente em quase todas as
distribuições Linux.
1 http://www.xmlsoft.org
39
A base de conhecimento inicializa com um nó único base_conhecimento. A partir
dela, existem diversos nós filhos onde cada filho representa uma variável de conhecimento específica. Cada nó de variável possui duas propriedades: nome e tipo. O
nome representa o nome da variável. O tipo representa se o objetivo da variável é a
minimização(MIN) ou a maximização(MAX). Esta característica foi implantada visando
melhorar a performance do sistema, já que se uma variável for do tipo maximização e
no decorrer da análise de um pacote ela atingir o valor máximo, não será mais necessário verificar os demais casos. O mesmo vale para variável do tipo minimização. No
exemplo da Figura 28, ao processar a variável SELECT, se o caso com identificação
1 coincidir com o pacote, o peso de ocorrência da variável irá para o valor 5, o que
inviabiliza a necessidade de verificar os demais casos, visto que 5 é o valor máximo
permitido para as variáveis do módulo especialista.
Cada variável possui um conjunto de filhos que representam os casos em que
pode ocorrer a variável seguido de um peso de ocorrência. Cada um dos casos possui
os atributos id, valor e expressão O campo id representa um identificador único de
cada caso da variável. Ele é utilizado em conjunto com a análise de registros de
maneira a identificar o que levou o módulo especialista a tomar determinada decisão.
O atributo expressão contém uma expressão regular que será a representação do
padrão de reconhecimento da variável, a mesma utiliza o formato PCRE2 , amplamente
utilizada e conhecida. O atributo “valor” representa qual o valor deve ser associado a
respectiva variável caso o padrão especificado no atributo “expressao” coincida com o
valor passado para o módulo especialista.
A base de conhecimento vista na Figura 28 consiste em um exemplo simples com
três variáveis. Entretanto, em um sistema de produção, são necessárias dezenas de
variáveis com diversos casos cada uma, de maneira a representar uma amplitude
maior do conhecimento.
8.4 Módulo Fuzzy
O módulo fuzzy é o responsável pela tomada de decisão, ou seja, ele é o módulo
que sabe distinguir se as informações retiradas de um determinado pacote, pelo módulo Especialista, consistem em um ataque ou se era apenas um pacote inofencivo a
rede. A arquitetura deste módulo é baseada no modelo da Máquina de Inferencia de
2 Do
inglês Perl Compatible Regular Expression
40
Figura 28: Exemplo de Base de Conhecimento
Mandani, mas tem somente uma alteração, no lugar de um defuzzificador (dados qualitativos para quantitativos) tem-se um Gerador de Registro (dados qualitativos para
logs).
8.4.1
Processo de Fuzificação
O fuzzificador tem por principal e única finalidade, transformar dados de variáveis
quantitativas para os correspondentes dados em forma qualitativa, dentro do conjunto
de valores lingüísticos com o grau de pertinência de cada uma variável de tipos iguais.
Para melhor entender, defina uma variável quantitativa do tipo ’union’, cujo seu
valor é ’4.5’, quando essa chegar no fuzzificador, ele deverá identificá-la e relacionala com uma variável qualitativa do mesmo tipo ’union’, essa terá o seu conjunto de
valores lingüísticos, que será baixo, medio, alto, cada um desses valores lingüísticos tem uma função relacionada, que recebe como parâmetro o valor quantitativo e
retorna um grau de pertinência do mesmo termo dentro da variável. Como exemplificação, a função e o retorno do grau de pertinência para baixo(4.5)=0, medio(4.5)=0.1
e alto(4.5)=0.7.
Para que o conjunto de variáveis provindas do SE seja identificado e transformado
em um novo conjunto, é preciso uma base de informações que determinem como
esse processo deve ser executado, esta deve conter uma variável qualitativa de tipo
41
correspondente, seus valores lingüísticos e as funções para cada um. Como padrão
do projeto, toda base de dados necessária deve estar contida em arquivos XML, como
o visto na Figura 29:
Figura 29: Exemplo de Funções de Inferência
Passado pelo fuzzificador, agora as informações são entregues a máquina de inferência fuzzy. Esta por sua vez recebe as variáveis qualitativas de entrada com seu
conjunto de valores lingüísticos e os respectivos graus de pertinência. Aplicando-as
na base de regras, serão gerados os graus de pertinência para cada elemento do
conjunto dos valores lingüísticos da variável de saída. Para se calcular a persistência, dado uma regra, é aplicada uma função MIN nos valores lingüísticos usados pelo
conjunto de variáveis da própria regra. Depois de gerado as persistência dos valores
lingüísticos da variável de saída, é aplicado a função de MAX nelas, para com isso,
descobrir qual valor lingüístico possui uma maior pertinência no conjunto de valores
da variável de saída. Em alguns casos, existem dois termos lingüísticos que tem o
mesmo grau de pertinência e são os maiores, então será escolhido o termo lingüístico
mais relevante, para não perder informações que tenham uma influência maior em
42
questão da detecção de um ataque.
Para melhor entendimento veja a analise de dois exemplos, a partir das entradas
quantitativas vindas do Sistema Especialista até o final do processo na máquina de
inferência, as funções são definidas pelo arquivo de base de funções do tipo XML.
Figura 30: Gráfico do ’select’
Figura 31: Gráfico do ’union’
Nas Figuras 30 e 31 (com suas funções na Figura 32) e as regras da Figura 33,
temos duas situações de exemplo.
Obs.: Apesar dos gráficos da Figura 30 e Figura 30 terem as mesmas funções,
isso não significa que é um padrão, pois cada valor lingüístico de uma dada variável
tem sua função determinada por quem a escreveu na base de funções. Outra questão
é que para todo x fora do intervalo determinado, a função retornará “0”.
baixo
− 21 x + 1 se 0 ≤ x ≤ 2
2
2
se 1 ≤ x ≤ 52
3x − 3
− 32 x − 32 se 25 < x ≤ 4
medio
alto
1
3
2x − 2
se 3 ≤ x ≤ 5
Figura 32: Funções BAIXO, MÉDIO e ALTO
Situação 1:
43
Figura 33: Regras fuzzy para o exemplo
Dados qualitativos:
select = 1,2
union = 2,5
Aplica-se os dados qualitativos nas funções de pertinência:
select:
baixo(1,2) = 0,4
medio(1,2) = 0,2
alto (1,2) = 0
union:
baixo(2,5) = 0
medio(2,5) = 1
alto (2,5) = 0
Aplicando os valores lingüístico e os graus de pertinência nas regras
1- nenhum ⇒ min (0.4,0) = 0
2- baixo ⇒ min (0.4,1) = 0.4
3- medio ⇒ min (0.4,0) = 0
4- baixo ⇒ min (0.2,0) = 0
5- medio ⇒ min (0.2,1) = 0.2
6- alto ⇒ min (0.2,0) = 0
7- medio ⇒ min (0,0) = 0
8- alto ⇒ min (0,1) = 0
9- certeza ⇒ min (0,0) = 0
Obs.: Quando um termo for gerado seu grau de pertinência mais de uma vez, é
44
escolhido o maior grau.
Termo relevante da variável de saída:
MAX (nenhum, baixo, medio, alto, certeza)
MAX (0,0.4,0,0,0.2,0,0,0,0)
MAX = 0.4
Termo mais relevante é “baixo” com grau de pertinência ’0.4’.
Situação 2:
Dados qualitativos:
select = 5
union = 3,5
Aplicando os dados qualitativos nas funções de pertinência:
select:
baixo(5,0) = 0
medio(5,0) = 0
alto (5,0) = 1
union:
baixo(3,5) = 0
medio(3,5) = 0.33
alto (3,5) = 0.25
Aplicando-se os valores lingüístico e os graus de pertinência nas regras
1- nenhum ⇒ min (0,0) = 0
2- baixo ⇒ min (0,0.33) = 0
3- medio ⇒ min (0,0.25) = 0
4- baixo ⇒ min (0,0) = 0
5- medio ⇒ min (0,0.33) = 0
6- alto ⇒ min (0,0.25) = 0
7- medio ⇒ min (1,0) = 0
8- alto ⇒ min (1,0.33) = 0.33
9- certeza ⇒ min (1,0.25) = 0.25
Termo relevante da variável de saída:
MAX (nenhum, baixo, medio, alto, certeza)
MAX (0,0,0,0,0,0,0,0.33,0.25)
45
MAX = 0.33
Termo mais relevante é ’alto’ com grau de pertinência ’0.33’.
8.5 Construção de um Pré-Processador
Basicamente, para a integração inicial com o sistema, o SPP3 precisar configurar um ambiente com uma função exportada em uma biblioteca. Esta, por sua vez,
será incluída no sistema base de plugins do Snort e a função adicionada na rotina
de inicialização dos SPPs. Para isto, é necessário fazer a inclusão das bibliotecas
fornecedidas pelo Snort, vistas na Figura 34.
Figura 34: Bibliotecas do Snort para o SIDI
Cada uma das bibliotecas possuem suas funcionalidades. As bibliotecas generators.h e event_wrapper.h são responsáveis pela geração de alertas para o Snort,
as bibliotecas util.h e plugbase.h possuem as principais rotinas que todo SPP deve
possuir e a biblioteca debug.h fornece rotinas de controle, para que se possa fazer
análises do SPP.
Após a inserção das bibliotecas padrões, é necessário criar a própria biblioteca do
SPP. Esta biblioteca necessita ter basicamente uma única função que será chamada
na inicialização do Snort. O exemplo de biblioteca inicial pode ser visto na Figura 35.
Nota-se que na Figura 35 existe apenas uma função chamada SetupSIDI(). Esta
função é a responsável pelo carregamento do SPP do SIDI e, para seu funcionamento,
é necessário efetuar duas pequenas modificações no Snort, ambas no arquivo plugbase.c encontrado no diretório src do código-fonte do Snort.
A primeira modificação deve ser a inserção da biblioteca do novo SPP como biblioteca do arquivo plugbase.h(veja a Figura 36) e a segunda modificação consiste na
inserção da chamada a função de carregamento do SPP. Isso é feito simplesmente
chamando a função criada(no caso SetupSIDI()) dentro da função InitPreprocessors()
como pode-se ver na Figura 37.
3 Do
inglês Snort Pre-Processor
46
Figura 35: Biblioteca principal do SIDI
Figura 36: Bibliotecas de SPP em plugbase
Figura 37: Chamadas de SPP em plugbase
47
Feito isto, o SPP estará pronto para ser carregado com o Snort. Para isto é necessário compilá-lo juntamente com o Snort e isto é possível através de duas modificações no arquivo de definição de compilação(Makefile) do diretório /src/preprocessors/
do Snort.
Figura 38: Primeira modificação do Makefile
Figura 39: Segunda modificação do Makefile
A primeira modificação da Figura 38 indica ao Snort que o novo SPP está em um
diretório a parte e que durante a recompilação do sistema deve-se executar um Makefile existente neste diretório. A segunda modificação da Figura 39 indica o arquivo
objeto gerado pelo novo pré-processador compilado, de maneira a liga-lo ao Snort
durante a compilação final.
Para finalizar, a Figura 40 contém o Makefile necessário para se compilar o SIDI.
A Figura 40 representa um arquivo básico para compilação do sistema, entretanto,
com o crescimento do mesmo e a necessidade de divisão em diversos arquivos e
módulos distintos, foi necessário modificar este arquivo de maneira a adequar-se ao
sistema em questão.
A função SetupSIDI() é unicamente responsável pelo registro do SPP na estrutura
interna do Snort. Desta forma, ele simplesmente faz uma chamada a função RegisterPreprocessor() que possui dois parâmetros. O primeiro consiste em uma palavrachave de identificação do SPP e o segundo consiste em um ponteiro para uma função
de inicialização. É importante ressaltar que todos os SPPs são registrados, porém
a função de inicialização só é executada para aqueles que estão ativos segundo o
arquivo de configuração do Snort.
No caso do SIDI, a função de inicialização é a responsável pelo carregamento da
base de conhecimento, carregamento das funções de inferências e pelo carregamento
48
Figura 40: Makefile SIDI
da base de regras fuzzy, todos armazenados em arquivos XMLs. Feito isto, a função
de inicialização se encarrega de definir para o Snort quais são as funções de controle
do SPP. Estas funções são a de recebimento de pacote (para análise), a de finalização
(para liberação de memória) e de reinicialização (para se necessário recarregar os
arquivos de inicialização).
O Snort reconhece qualquer SPP pela palavra-chave definida em seu registro,
portanto, para se inicializar o SIDI (definir com palavra-chave sidi) foi-se necessário
adicionar a seguinte linha no arquivos de configuração:
preprocessor sidi: /etc/sidi
A primeira palavra indica que a configuração a seguir é de um SPP. Em seguida
tem-se a palavra-chave de identificação do SPP e após o dois-pontos um texto que
é passado como parâmetros para o SIDI na sua função de inicialização. Para este
projeto definiu-se que este parâmetro único seria o diretório onde encontram-se os
arquivos XMLs do SIDI.
49
8.6 Testes e Resultados
Após a implementação foram feitos diversos testes para se adequar uma boa base
de conhecimento, conjuntos de funções de inferência e base de regras Fuzzy. Para os
testes foram utilizados a Base de Conhecimento descrita na Figura 41, as funções de
pertinências descrita na Figura 42 e a Base de Regras Fuzzy descrita na Figura 43.
Figura 41: Base de Conhecimento para Testes
Na Figura 44 é possível observar pelo cabeçalho de chegada que o mesmo não
representa um ataque. Ao passar pelo módulo especialista, somente em algumas
variáveis foi definido um peso e, mesmo assim, estes estão presentes apenas nos
conjuntos baixos com pertinências de 0.33 para ambos, SELECT e UNION. Como
resultado, as variáveis (com seus graus de pertinência) não inferiram em nenhumas
das regras, resultado em possibilidade 0.00% para todas os valores lingüísticos de
saída.
É importante ressaltar que até mesmo o valor lingüístico NENHUM está com pertinência 0 (zero). Isto porque nenhuma das regras fuzzy inferira sobre esse valor. Ele
deve ser muito utilizado quando, em alguma condição, muitas regras preencherem os
50
Figura 42: Funções de Pertinência para Testes
51
Figura 43: Regras Fuzzy para Testes
52
Figura 44: Resultado de Requisição Normal
53
demais valores lingüístico portanto sem ser um ataque. Desta maneira, deve-se criar
regras que inferem no valor lingüístico NENHUM, de maneira que ele tenha maior grau
de pertinência sobre os demais valores.
Figura 45: Resultado de Ataque com SELECT
Na Figura 45 é possível observar uma tentativa de ataque através dos comandos
SQL SELECT e UNION. Com isto, o módulo especialista definiu as variáveis SELECT
e UNION com os valores lingüísticos ALTO com pertinência de 0.50, ou seja, certeza
absoluta de ocorrência no pacote de chegada. Com estas informações, esses valores
coincidem com a ultima das regras, o que faz o valor lingüístico CERTO ter probabilidade de 50%.
Na Figura 46, é possível observar no pacote uma tentativa de ataque através
de execução de comandos. Com isto, o módulo especialista identificou as palavras
chaves para tal ataque e definir o grau de ocorrência para as variáveis SHELL e
CMD_DOS gerando, através das funções de pertinência grau máximo para os va-
54
Figura 46: Resultado de Ataque com execução de comandos
55
lores lingüístico ALTO. Com isto, através da primeira regra fuzzy, definiu-se o valor
lingüístico CERTO de posibilidade de ataque como 100%.
56
9
Trabalhos Futuros
Para trabalhos futuros, propõe-se a criação de um método de aprendizagem onde,
através de outros conceitos de I.A. não descritos neste documento, a ferramenta será
capaz de entrar em um modo de aprendizagem, gerando seus próprios padrões e
preenchendo as bases de dados com informações obtidas, de maneira a inibir a atualização constante da base de conhecimento para uma melhor adequação do sistema
a um ambiente de produção.
Juntamente com isto, pode-se implementar um melhor identificador dos parâmetros do protocolo HTTP, fazendo com que a ferramenta trate as variáveis HTTP de
maneira distintas. Um caso em que a aplicação não é viável seria como mecanismo
de proteção de um servidor web que tem como aplicação um fórum de SQL.
Outra modificação interessante seria planejar um método que consiga definir as
regras também seguindo a ordem de precedência das variáveis, de maneira a definir e
tratar diferentemente quanto a sequência em que as mesmas aparecem no cabeçalho.
Como o sistema consiste em um protótipo, inúmeras modificações e melhorias
podem ser feitas. Uma dessas melhorias seria o trabalho com estrutura de dados em
tabela hash para organização das variáveis, visto que como trabalhamos com busca
sequêncial das variáveis perdemos em desempenho.
57
10
Conclusão
Esta monografia foi desenvolvida em cima do objetivo de criar protótipo de um
pré-processador para o SDI Snort. Este pré-processador tem por finalidade aumentar
a inteligência deste sistema de segurança que é muito utilizado mundialmente para
proteger informações, servidores, host e todos os outros componentes que possam
estar ligados ao sistema de uma rede de computadores. O projeto tem como proposta, uma abordagem de analise dentro do cabeçalho da camada de Aplicação do
TCP/IP, verificando possíveis ataques do tipo SQL Injection. Com esta melhor analise,
podemos diminuir a incidência de falsos-positivos - que acarretam a exclusão de pacotes que não representavam perigo - e falsos-negativos - pacotes que passam como
inofensivos, mas que consistem em um ataque.
Ataques de SQL Injection, são muito comuns quando se fala de páginas Web.
Esse problema acarreta na perda, inconsistência e roubo de informações de uma determinada organização, gerando desde problemas administrativos internos até grandes prejuízos financeiros, que podem até levar à falência.
Para desenvolvimento desta estrutura inteligente de análise, foi preciso à utilização
de duas vertentes da Inteligência Artificial, consistindo então em um sistema híbrido. A
primeira é o Sistema Especialista e a segunda é Lógica Fuzzy. O Sistema Especialista
ficou responsável por um módulo de análise, ou seja, um perito em segurança que faz
um levantamento do que potencializa um ataque, e se há ocorrências explícitas ou
implícitas desses pontecializadores, fazendo um relatório geral. Em segundo passo
fica a Lógica Fuzzy. Nesta etapa é onde o sistema toma a decisão, ou seja, decide
em declarar se um pacote é inofensivo ou um ataque e qual o grau de periculosidade.
Essa decisão se dá atravez de sua base de regras.
Com este Pré-Processador, tem-se uma nova ferramenta para auxiliar o Snort na
identificação de SQL Injection, garantindo assim a confiabilidade da informação e a
garantia de que os dados tenham um grau maior de segurança.
58
Com este trabalho, obtivemos a capacidade de modelar e implementar sistemas
inteligente híbridos. Além disto, tiver a oportunidade de experimentar na prática como
Engenheiros de Conhecimento atuam de maneira a fazer o processo de conversão de
conhecimento tácito provindo de um especialista em conhecimento explícito para que
seja possível armazená-lo e consultá-lo quando necessário para auxílio na tomada de
decisão.
59
REFERÊNCIAS
[1] Snort
Zine
1.0.
Snort
Zine
1.0.
2008.
URL:
http://snort.org.br/index.php?option=com_content&task=view&id=38&Itemid=43.
Last Visited: 22/06/2008.
[2] NIST.
National
Institute
of
Standards
and
Technology
Wikipédia,
a
enciclopédia
livre.
2008.
URL:
http://pt.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology. Last
Visited: 24/06/2008.
[3] Equipe
Snort-BR.
Comunidade
Snort
Brasil.
2008.
URL:http://snort.org.br/index.php?option=com_content&task=view&id=38&Itemid=Last
Visited: 26/05/2008.
[4] Snort. Snort Oficial Page. 2008. URL:http://www.snort.org/community/. Last Visited: 27/11/2008.
[5] SISTEMAS Inteligentes - Fundamentos e Aplicações. [S.l.: s.n.], 2005. Manole.
[6] Sistema Especialista Nebuloso Para Diagnóstico Médico. 1994.
[7] NETWORK Intrusion Detection.1994.
[8] L. A. Zadeh. Fuzzy Sets.1965.
[9] QUALIDADE de Serviço em Rede IP Utilizando Lógica Fuzzy. 2006. São Paulo.
[10] SISTEMA Especialista Nebuloso Para Diagnóstico Médico. 1997. Santa Catarina.
[11] Wikipedia. Sistema de Detecção de Intrusos - Wikipédia. 2008. URL:
http://pt.wikipedia.org/wiki/Sistema_de_detecção_de_intrusos.
Last
Visited:
26/05/2008.
[12] Wikipedia. Intrusion Detection System - Wikipédia. 2008. URL:
http://en.wikipedia.org/wiki/Intrusion-detection_system. Last Visited: 26/05/2008.
[13] Glossário. Cartilha de Segurança ?
Glossário.
http://cartilha.cert.br/glossario/#i. Last Visited: 26/05/2008.
2008.
URL:
[14] MULTI-AGENT Framework for Intrusion Detection Systems. 2006. Penambuco.
[15] Marcelo Almeida. Microsoft Invadida por SQL Injection. 2008. URL: http://br.zoneh.org/content/view/489/11/. Last Visited: 04/06/2008.
[16] SecurityFocus. Últimas Vulnerabilidade de SQL Injection. 2008. URL:
http://search.securityfocus.com/swsearch?query=sql+injection&sbm=bid&metaname=alldoc&s
Last Visited: 23/05/2008.
60
[17] HONEYPOTS - A arte de iludir hackers. [S.l.: s.n.], 2003. Brasport.
[18] Port Scan. Port Scan. 2008. URL: http://wapedia.mobi/pt/Port_scan. Last Visited:
05/06/2008.
[19] Sistemas
Especialistas.
Sistemas
Especialistas.
http://www.din.uem.br/ia/especialistas/. Last Visited: 27/11/2008.
2008.
URL:
[21] FireWalls.com.br.
Técnicas
de
Evasão.
2008.
http://www.firewalls.com.br/files/Evasao_ITA.pdf. Last Visited: 20/05/2008.
URL:
[20] F. Bica R. Verdin e R. M. Vicari. Tutores inteligentes. 2006.