anotações outros materiais

Existem basicamente três tipos de intrusões para um IDS detectar. Sendo denominados
conhecidos, quando possuem uma estrutura rígida e seu comportamento já é
devidamente conhecido e catalogado, generalizáveis, quando são parecidos com os
conhecidos, no entanto apresentam modificações em seu funcionamento e
desconhecidos são intrusões não muito difundidas ou mesmo uma versão muito
generalizada de uma intrusão conhecida, as quais tornam impossíveis os usos de regras
predefinidas para detecção.
Para detectar as operações ilegais na rede são usadas, nos casos conhecidos e
generalizáveis, a checagem de assinaturas, isto é, procura por padrões já pré-
estabelecidos de atividades de cunho malicioso. Ou, para invasões desconhecidas,
buscando anomalias, que são nada mais do que atividades/dados diferentes do perfil
tradicional da máquina/rede em que o IDS se encontra.
Network-Based

Monitora o tráfego de rede em um seguimento particular da rede ou dispositivo e analisa a

rede e atividade protocolo de aplicação para identificar atividades suspeitas. Sistemas
deste tipo são capazes de identificar vários tipos de eventos de interesse. Normalmente é
empregado como fronteira entre duas redes, como nas proximidades de firewalls ou
roteadores, servidores de redes privadas (VPN), servidores de acesso remoto e redes
sem fio.

Wireless

Empregado no monitoramento do tráfego e na análise de protocolos para identificar

atividades suspeitas envolvendo os próprios protocolos. Sistemas deste tipo são
incapazes de identificar atividades suspeitas em aplicações ou em protocolos das
camadas mais elevadas (como TCP, UDP) que estejam sendo transferidos na rede.
Apesar de ser mais comumente utilizados dentro do alcance de rede sem fio de uma
organização para monitorá-la, pode ser usado em locais onde haja suspeita de tráfego
não autorizado na rede sem fio.

Network Behavior Analysis (NBA)

Examina o trafego de rede em busca de ameaças que gerem padrões incomuns de fluxo
de dados como ataques DDos, alguns tipos de malware, violações de privacidade.
Sistemas NBA são os mais usados para monitorar o tráfego entre uma rede interna de
uma instituição e redes externas.

Host-Based

Monitora características de um único dispositivo e os eventos que acontecem com ele em

busca de atividades suspeitas. Algumas características que podem ser monitoradas por
host-based IDPS: trafego da rede para este dispositivo, logs do sistema, processos em
execução, atividades de aplicações, acesso e alteração em arquivos e modificações em
aplicações e no sistema. São usados apenas para alguns dispositivos cujo funcionamento
é essencial para o sistema como servidores de acesso público e servidores que
contenham informações sigilosas.
Management network

Rede exclusiva para o tráfego de dados do IDPS. Trata-se de uma rede isolada para o
IDPS a fim de protegê-lo e garantir banda suficiente para seu funcionamento.

Virtual management network

Rede virtual dentro da rede monitorada criada para proteger o tráfego relativo ao IDPS,
sem isolá-lo dos possíveis problemas na rede monitorada.

A criptografia, como elemento de segurança do tráfego de informações, acaba por prejudicar outros elementos como os
sistemas de detecção de intrusos (IDS). Uma vez que, em algumas tecnologias, o campo de dados é criptografado, em
outras, o pacote inteiro o é (cabeçalhos e dados). Neste ambiente, uma ferramenta de IDS não será efetiva, pois os
dados de um ataque podem ser encobertos pela criptografia existente no mesmo.

O IPS pode tomar ações como:

- Enviar um alarme,

- Descartar os pacotes maliciosos

- redefinir a conexão e / ou bloquear o tráfego do endereço IP ofensivo.

- Corrigir erros de verificação de redundância cíclica (CRC) ou Cyclic Redundancy

Check − CRC

- Desfragmentar fluxos de pacotes,

- Evitar problemas de seqüência de TCP

- Limpar as opções de transporte e camada de rede indesejadas.

SSL e TLS
O protocolo SSL foi originalmente desenvolvido pela Netscape para garantir a segurança dos
dados transportados através das camadas de aplicação HTTP, LDAP e POP3

Os

principais objetivos do SSL são:

• Autenticar o cliente e o servidor entre si;
• Garantir a integridade dos dados: Durante uma transmissão, dados não podem ser
alterados (seja de forma intencional ou não);
• Assegurar a privacidade dos dados: As informações trocadas entre cliente e servidor
devem ser protegidas de interceptação e devem ser lidas apenas pelo destinatário. Este pré-
requisito é necessário tanto para os dados associados ao protocolo propriamente dito, quanto
para os dados do aplicativo que é enviado durante a sessão.
Enfim, o SSL não é apenas um protocolo único, mas sim um conjunto de protocolos que podem
ser divididos em duas camadas:
• A camada para garantir a segurança e integridade dos dados, composta pelo SSL Record
Protocol;
• A camada que visam estabelecer uma conexão SSL, três protocolos são utilizados aqui. O
SSL Handshake Protocol, o SSL ChangeCipher SpecProtocol e o SSL Alert Protocol.
Abaixo listaremos todas as possíveis mensagens em uma comunicação SSL:
• Alerta – Informa à outra parte de uma possível brecha na segurança ou falha de
comunicação.
• ApplicationData – Informação real que as duas partes irão trocar entre si, que é
criptografada, autenticada e/ou verificada por SSL.
• Certificate – Uma mensagem que carrega o certificado da chave pública do remetente.
• CertificateRequest – Uma solicitação do servidor para que o cliente forneça seu
certificado da chave pública.
• CertificateVerify – Uma mensagem do cliente que verifica que ele conhece a chave
privada correspondente à sua chave pública certificada.
• ChangeCIpherSpec – Um indicador para começar a utilizar serviços de segurança
acordados.
• ClientHello – Uma mensagem do cliente indicando os serviços de segurança que ele
deseja e que ele é suporta.
• ClientKeyExchange – Uma mensagem do cliente carregando as chaves criptográficas para
as comunicações.
• Finished – Uma indicação de que todas as negociações iniciais estão completas e uma
comunicação segura foi estabelecida.
• HelloRequest – Um pedido do servidor para que o cliente inicie (Ou reinicie) o processo de
negociação.
• ServerHello – Uma mensagem do servidor indicando os serviços de segurança que serão
utilizados para a comunicação vigente.
• ServerHelloDone – Uma indicação do servidor de que ele completou todos os seus pedidos
para o cliente para estabelecer a comunicação.
• ServerKeyExchange – Uma mensagem do servidor carregando as chaves criptográficas para
a comunicação.
SSL & TLS – Diferenças
As diferenças entre o SSL e o TLS são muito pequenas e técnicas, porém eles possuem normas
diferentes. O TLS tem a capacidade de trabalhar em portas diferentes e usa algoritmos de
criptografia mais fortes como o keyed-Hashing for Message Authentication Code (HMAC)
enquanto o SSL apenas Message Authentication Code (MAC). Além do que, a versão 1.0 do TLS
não interopera com a versão 3.0 do SSL.
O TLS pode ser utilizado por uma autoridade intermediária, não sendo sempre necessário
recorrer à raiz de uma Autoridade de Certificação.
O protocolo TLS foi criado como o sucessor do SSL. É mais freqüentemente usado como uma
configuração nos programas de e-mail, mas assim como o SSL, o TLS pode ter um papel em
qualquer transação cliente-servidor.

IPSEC
Cada protocolo [ESP e AH7] suporta dois modos de uso: o modo transporte e o modo túnel. No modo transporte, o
protocolo provê proteção primariamente para os protocolos de camada superior; no modo túnel, os protocolos são
empregados como um túnel de pacotes IP." 8

Security Associations(SA)
Um fundamento importante do IPSec são as Security
Associations. Uma Security Association (SA) é um conjunto de parâmetros que
representa uma relação unidirecional entre um emissor e um receptor. Entre
estes parâmetros, estão: algoritmo de criptografia, chave de criptografia,
algoritmo de autenticação e chave de autenticação. As informações de uma SA
são comuns ao receptor e ao emissor. Para uma relação bidirecional, são
necessárias duas Security Associations.
Três parâmetros atuam como identificadores de uma SA:
• Security Parameters Index, um identificador numérico único de 32
bits, presente nos cabeçalhos dos protocolos IPSec;
• endereço IP de destino;

• identificador de protocolo de segurança, que relaciona a SA ao AH

ou ao ESP.
Com esses parâmetros, um receptor pode facilmente associar uma
mensagem segura IPSec a uma SA em sua base de dados de SAs (ou a duas,
caso sejam utilizados tanto o AH quanto o ESP). Ele poderá então desencriptar
a mensagem e/ou verificar as informações de autenticação, de acordo com os
demais parâmetros.

3. Implementação
Com o IPSec, a segurança é implementada na camada do IP. Isto faz com que ele seja
transparente para as aplicações, que não precisam ter seu código-fonte alterado para garantir
segurança. Além disso, pode ser facilmente utilizado em conjunto com o UDP, protocolo muito
usado atualmente em comunicações multimídia.

Diferentemente, as soluções de segurança mais comumente adotadas (SSL, TLS, SSH etc.)
operam nas camadas de transporte ou aplicação. Muitas vezes, estas são utilizadas devido à
complexidade da arquitetura e dos protocolos do IPSec, que exigem que a pilha TCP/IP seja
alterada ou estendida, de acordo com a opção de implementação.
O IPSec pode ser implementado de diversas maneiras, seja num terminal, em um roteador
ou firewall (para criar um gateway de segurança) ou em um dispositivo de segurança
independente. Na RFC 4301 [8], são definidas 3 alternativas de implementação para o IPSec:

Integração no IP

Se baseia na integração dos protocolos do IPSec na implementação nativa do IP, o que é viável
tanto para um terminal quanto para um gateway de segurança. Pode ser considerada a solução
padrão, mais elegante.

Entretanto, é preciso alterar o código-fonte da implementação IP, o que foi feito no Microsoft
Windows 2000 (sendo incluído nas versões posteriores) e no Linux Kernel 2.6. Um tutorial
simples sobre a utilização da pilha IPSec nativa do Ubuntu pode ser encontrado
em https://help.ubuntu.com/community/IPSecHowTo.

Bump-in-the-stack (BITS)

Consiste em implementar os protocolos IPSec entre a implementação nativa IP e os drivers da

rede local. Os pacotes passados adiante pela camada do IP são interceptados por uma camada
extra IPSec, que provê segurança e, depois, encaminha para a interface de rede na camada
seguinte.
 Figura 1: Ilustração da alternativa de implementação BITS.
Os cabeçalhos do IPSec são acrescentados após o cabeçalho IP.
Ilustração adaptada de [3].

Para esta implementação, não é necessário o acesso ao código-fonte da pilha IP. Normalmente,
quando adotada, esta estratégia é aplicada a terminais da Internet.
Bump-in-the-wire (BITW)

Neste método, é utilizado um hardware adicional, que provê os serviços IPSec.

Este hardware atua de maneira semelhante ao software BITS, interceptando pacotes IP,
adicionando segurança e repassando-os na rede.
Quando utilizado em conjunto com um roteador ou firewall, pode-se criar um gateway de
segurança, que permite que diversos computadores numa rede local estabeleçam conexões seguras
com terminais fora da rede, sem implementarem o IPSec. Mais informações poderão ser obtidas
na descrição do modo túnel, na seção Modos de Operação.

Assim como a opção de implementação BITS, o Bump-in-the-wire não requer o acesso ao

código da implementação IP nativa.

Como será visto mais adiante, as três estratégias de implementação (integrada, BITS e BITW)
se relacionam com os dois modos de operação do IPSec.
7. Internet Key Exchange
Motivação

Os serviços de autenticação e encriptação (AH e ESP) dependem da

utilização de chaves secretas (conhecidas apenas pelos comunicantes) para
serem fornecidos pelo IPSec.
Caso uma entidade intercepte uma comunicação IPSec em modo transporte,
por exemplo, esta será incapaz de alterar qualquer parte do pacote sem que
seja notada (se estiver sendo utilizado o AH) ou ter acesso às informações nele
contidas (caso seja utilizado o ESP). Todavia, isto é válido apenas se esta
entidade não possui acesso ao segredo compartilhado pelos comunicantes.
Portanto, é preciso que o acordo quanto às chaves que serão usadas na
comunicação seja feito de maneira segura.
A forma mais trivial de estabelecer uma chave secreta no IPSec é através de
configuração manual. Os comunicantes escolhem as chaves que serão usadas
e registram manualmente as SAs necessárias.
Esta é uma estratégia bastante prática para cenários pequenos, mas não é
escalável, já que seria preciso configurar ao menos duas SAs (entrada e saída)
para cada par de endereços IP. Para resolver este problema e permitir maior
flexibilidade no compartilhamento de chaves, foi criado o IKE (Internet Key
Exchange), um protocolo para gerenciamento automático de chaves que
também faz parte do IPSec.

Funcionamento

Este protocolo, que pode ser considerado o mais complexo do conjunto

IPSec, usa o ISAKMP (Internet Security Association Key Management Protocol)
como base para criar as SAs nos dois lados da comunicação, que serão
utilizadas pelos protocolos AH e ESP.
O primeiro passo para o estabelecimento das SAs para os comunicantes é a
criação de um canal seguro. Este é definido por uma SA bidirecional (ao
contrário das demais) referente ao IKE. Nela, estão contidas informações como
a chave secreta e os algoritmos de criptografia que serão usados nas
negociações subsequentes (para as SAs do AH e do ESP).
Para a escolha da chave secreta, é realizada uma série de procedimentos
baseada no algoritmo de troca de chaves Diffie-Hellman [11].

Diffie-Hellman

Proposto em 1976, este algoritmo permite o estabelecimento de uma chave

secreta compartilhada através de um canal de comunicação inseguro. Esta
chave poderá ser utilizada, por exemplo, em algoritmos de criptografia
simétrica.
Numa troca de chaves entre duas entidades hipotéticas A e B, ocorre
primeiro um acordo quanto a um número primo p e a uma raiz primitiva
de p, r.
O número r será uma raiz primitiva de p se

Os números p e r não são secretos.

Em seguida, A e B escolhem um número secreto entre 1 e p-1 (inclusive)
cada, XA e XB.

Então, A envia para B:

A chave secreta K, calculada por B, será:

Analogamente, A poderá calcular a mesma chave secreta a partir

de YB, fazendo:

Desta forma, a partir da escolha de r e p e da troca (sem segurança)

de YA e YB, o algoritmo de Diffie-Hellman permite o estabelecimento de uma
chave secreta, conhecida apenas por A e B.
Este algoritmo não autentica os usuários que estão realizando a troca de
chaves, o que o torna vulnerável a ataques. Devido a isso, o protocolo IKE
inclui mecanismos adicionais para garantir a autenticação, baseados na troca
de assinaturas digitais. Para mais detalhes, ver [2].

Escolhida a chave secreta e criada a SA para o IKE, ocorre o estabelecimento

das demais SAs através do canal seguro criado.