Packet Sampling for Worm and Botnet Detection in TCP Connections

Amostragem de Pacotes para Detecção de Worms e Botnets em Conexões TCP

Lothar Braun, Gerhard Münz, Georg CarleTechnische Universität München, Germany

NOMS 2010

Apresentado por: Bruno Barcarollo Gauer

Roteiro Introdução / Contextualização Bloom Filter Trabalhos Relacionados Detecção de Worms e Botnets Proposta Avaliação Conclusões Críticas

Introdução Botnets e worms representam uma constante

ameaça a segurança das redes Worm: programa mal-intencionado que se

auto replica pela rede Bot: worm com capacidade de comunicação

a algum atacante (formam botnets) Uso de Signature Based Network Intrusion

Detection Systems (NIDS) Análise de pacotes procurando identificar

padrões (signatures) que são armazenados em uma base

Introdução Detecção pode ser complexa

Aumento no número de ataques Surgimento de novos worms Signatures (padrões) se tornam mais

sofisticados Crescimento das redes gera maior tráfego

para análise Recursos de um sistema de detecção

podem se tornar insuficientes

Introdução Soluções possíveis:

Aumentar capacidade de processamento Hardware específico para detecção Distribuir pacotes entre múltiplos sistemas Solução muito custosa

Analisar partes relevantes do tráfego Maioria do tráfego atual de worms e botnets

pode ser detectada verificando pacotes iniciais

Introdução Objetivo: apresentar um algoritmo de

amostragem que analisa os primeiros N bytes do payload (dados) de cada conexão TCP

Bloom Filters para guardar estado das conexões

Estrutura de dados probabilística usada para testar se um elemento está em um conjunto

Pode gerar falso positivo

Bloom Filter Vetor de bits: m posições (inicializadas com 0) K funções hash Para adicionar elemento, faz hash nas k

funções e seta bits como 1 (ex.: k = 3)

Abordagens Amostragem de Pacotes

Time Machine Armazena tráfego de rede por maior tempo Guarda apenas poucos kilobytes do início de

cada conexão PAYL

Procura por anomalias no payload (dados) de pacotes

Abordagens Bloom Filter Time-out Bloom Filter: salva timestamp

– Analisa o primeiro pacote de cada fluxo unidirecional CMS (Count Min-Sketch): armazena contadores

– Detectar port scans Whitehead et al.:

– Memoriza pacotes TCP SYN para detectar conexões estabelecidas e as analisa sem limitar amostragem

Canini et al.:– Cadeia de filtros para analisar primeiros J pacotes

dos fluxos bidirecionais

Detecção de Worms e Botnets Detecção nos primeiros pacotes

Em geral contém informação para classificar o fluxo total como benigno ou malicioso

Avaliação desta afirmação para worms e botnets usando Snort

Sniffer e logger de pacotes usado como Lightweight IDS (Intrusion Detection System)

Determinar posições no payload de sessões TCP em que signatures são encontrados

Análise dos pacotes em ambas direções

Detecção de Worms e Botnets Análise

93 worms e bots em ambiente controlado Todos executado em horários e dias

variados para analisar comportamentos diferentes em relação aos comandos do botmaster

Utilizados dois rule-sets (conjunto de regras para detectar eventos):

Padrão do Snort Rule-set do emergingthreats.net

Detecção de Worms e Botnets 95 alarmes do rule set padrão do Snort 3416 alarmes do rule set Emergingthreats

Detecção de Worms e Botnets 96% dos alertas encontrados nos primeiros 3kB do

payload do início das conexões

Proposta Algoritmo de amostragem usa primeiros N

bytes de payload de cada conexão TCP Mecanismo para manter trajetória (tracking)

das conexões TCP é complexo e custoso Detectar estabelecimento/término da conexão Conexões interrompidas indevidamente Pacotes duplicados, perdidos, reenviados Para grande número de conexões se torna

inviável Gasto elevado de Processamento/memória

para guardar pacotes e reordená-los

Proposta Solução: Connection Tracking simplificado

Reduzir informações armazenadas Tornar decisão de considerar ou descartar

um pacote mais simples mantendo certa precisão na amostragem

Precisão x Escalabilidade e vazão 1ª simplificação: estabelecimento de conexão

Considera estabelecida com envio de SYN seguido de pacote sem SYN flag

1ª Simplificação Pacotes trocados entre mesmo IP e porta

(direção ignorada) dentro de 3 segundos

2ª Simplificação Pacotes não são reordenados

Serão escolhidos N bytes de payload em ordem de chegada

Pacotes duplicados não são descartados Tarefas deixadas para fase de análise dos

pacotes (no IDS) Pequeno risco de pegar pacotes que não

deveriam ser amostrados

3ª Simplificação Conexão TCP é considerada terminada com

detecção de pacote FIN ou RST Pode haver perda de alguns pacotes

Proposta Necessário considerar chegada do primeiro

SYN e um contador de bytes do payload a serem amostrados

Pacotes armazenados até: o máximo (N) ser amostrado receber FIN/RST conexão sofrer time-out

Nº de conexões pode crescer em ataques Algoritmo com memória fixa usando Bloom

Filters

Proposta Utilizar duas variações do Bloom Filter

Time-out Bloom Filter Armazena timestamp ao invés de bits que são

sobrescrevidos com horários atuais Elemento sofre time-out após tempo definido

Count Min-Sketch (CMS) Posições são contadores Quando elemento é inserido é somado valor

as posições referentes Quando elemento é buscado: posição com

menor valor é a que o representa

Proposta Algoritmo

Mecanismo simplificado de armazenamento de estado de conexões TCP

2 filtros Time-Out e 1 CMS 2 funções hash para os filtros Conexões identificadas pela quadrupla: (SA, DA, SP, DP)

Source Address Destination Address Source Port Destination Port

Proposta Elemento armazenado é resultado da

concatenação:

Ex: 200.11.11.11:8080 → 200.10.10.10:8080 Concatenação:

200.10.10.10:8080 || 200.11.11.11:8080 Ambas as direções são mapeadas para

mesmo elemento

Proposta 1º Time-Out Bloom Filter – Start Filter

Armazena timestamp de pacotes SYN CMS Bloom Filter – Export Filter

Contador dos N bytes de payload que devem ser exportados para uma determinada conexão

2º Time-Out Bloom Filter – Stop Filter Armazena timestamp do horário em que

conexão terminou

Proposta Quando pacote SYN chega:

Timestamp é escrito no start filter e pacote é amostrado

Pacotes que não são SYN, FIN ou RST Caso exista conexão no export filter

decrementa contador com tamanho do payload

Else: compara timestamps do start e stop filter

se start mais recente que stop e start menos de 3 segundos da hora atual

Pacote pertence a nova conexão e deve ser amostrado (decrementado no export filter)

Proposta Pacotes FIN e RST:

Se conexão existe no export filter Pacote é amostrado e conexão deletada

subtraindo valor do elemento nos contadores associados

Timestamp é salvo no stop filter

Senão pacote é ignorado

Proposta Análise do Algoritmo

Conexões no Bloom Filter: memória constante

TCP Scans e ataques de flood de SYN Preenchem start filter e podem gerar falsos

positivos Aumento no número de conexões pode

provocar colisões Pacotes vazios não afetam algoritmo

(apenas payload é analisado)

Avaliação – Tráfego Amostrado Twente: entre 0,5% e 2,1% do tráfego total Munich: entre 0,2% e 0,8% do tráfego total

Avaliação – Bloom x Hash Table Twente: maior tráfego → para amostragem alta hash gera menos erros Munich: menor tráfego → valor da amostragem não influenciou erros

Avaliação – Tipos de Erros Bloom Falsos negativos predominam (não analisar

pacotes que deveriam ser)

Avaliação – Tamanho Bloom Amostragem = 5kB

Críticas – Possíveis brechas Atacante poder burlar amostragem

Posicionar pacotes maliciosos após N primeiros bytes do payload

Enviar pacotes com mesmo endereço IP e porta mas com valores inválidos no campo sequência

TCP Scan: preencher start filter e gerar colisões

Solução possível: variar N de acordo com critérios predefinidos

Críticas / Conclusão Algoritmo seleciona primeiros N bytes do

payload da conexão TCP Maioria das ameaças pode ser detectada no

inicio das conexões Mecanismo simplificado para manter estado

das conexões TCP Bloom Filter (consumo de memória

constante) Eficiente para redes de alta velocidade Número de erros na amostragem foi baixa