petabi/snifflesSniffles: Gerador de Captura de Pacotes para IDS e Avaliação de Expressões Regulares
Sniffles é uma ferramenta para criar capturas de pacotes que testarão IDS que usam padrões fixos ou expressões regulares para detectar comportamentos suspeitos. Sniffles funciona de forma muito simples. Ele pega um conjunto de expressões regulares ou regras e escolhe aleatoriamente uma expressão regular ou regra. Em seguida, gera conteúdo com base nessa regra ou expressão regular. Para strings fixas, isso significa adicionar a string diretamente aos dados (possivelmente com offsets ou outras opções, conforme as regras do Snort). Para expressões regulares, o processo é um pouco mais complexo. A expressão regular é convertida em um NFA e um caminho aleatório é escolhido através do NFA (do início ao fim). Os dados resultantes corresponderão à expressão regular. Finalmente, Sniffles pode ser configurado para correspondência total ou parcial. Com uma correspondência total, os dados do pacote irão corresponder absolutamente a pelo menos uma regra ou expressão regular (embora algumas opções do Snort não sejam totalmente consideradas). Uma correspondência parcial apagará o último caractere de uma sequência de correspondência para uma sequência que não deve corresponder (pode corresponder a outra regra, no entanto). Regras correspondentes devem causar a maior carga em um IDS. Assim, é possível determinar quão bem o IDS lida com o tráfego no pior caso. O tráfego de correspondência parcial causará quase tanta carga quanto o tráfego correspondente. Finalmente, Sniffles também pode gerar tráfego que possui dados completamente aleatórios. Esses dados aleatórios oferecem um cenário de melhor caso, já que dados aleatórios são muito improváveis de corresponder a qualquer regra. Assim, podem ser processados na velocidade máxima. Dessa forma, Sniffles permite a criação de capturas de pacotes para operação de melhor e pior caso da inspeção profunda de pacotes do IDS.
Além do acima, Sniffles também tem a capacidade de criar capturas de pacotes de avaliação. Existem dois tipos de capturas de pacotes de avaliação. A primeira captura de pacotes de avaliação criará exatamente um pacote para cada regra ou expressão regular, em sequência. Assim, é possível testar e verificar se cada regra corresponde conforme o esperado. A avaliação completa vai um passo além e cria um pacote para cada ramo possível em uma expressão regular. Uma única expressão regular pode ter milhares de ramos possíveis. Isso testa para garantir que todos os ramos possíveis de uma expressão regular sejam tratados adequadamente. Capturas de pacotes de avaliação devem corresponder a todos os pacotes. Quaisquer pacotes não correspondentes provavelmente representam uma falha do IDS e precisam de uma investigação mais aprofundada. É claro, sempre há a possibilidade de que Sniffles não esteja criando o pacote correto para um determinado IDS, ou não reconheça uma opção específica para uma regra. Verifique os recursos de regras suportados para mais informações.
Finalmente, Sniffles também pode fazer muito para gerar tráfego de rede aleatório. Por padrão, o tráfego aleatório é TCP, UDP ou ICMP e unidirecional. No entanto, também pode gerar tráfego TCP com ACKs, handshakes e teardowns para cada fluxo. Ele gerará números de sequência e checksums corretos. Além disso, endereços MAC podem ser definidos de acordo com distribuições desejadas, e endereços de rede IP podem ser definidos pelos espaços de endereço Local e Externo. Além disso, é possível simular varreduras dentro de uma captura de tráfego.
REQUER: Python 3.3+ e o módulo SortedContainers
Sniffles consiste nos seguintes arquivos:
Para instalar:
python3.x setup.py install.Notas de Instalação:
python3.x setup.py build para construir localmente, depois vá para o diretório da biblioteca, encontre a lib e use python3.4 -c "from sniffles import sniffles; sniffles.main()" para executar localmente.Snort: Regras de alerta do Snort (a regra deve começar com a diretiva Alert). Tags de conteúdo são reconhecidas e analisadas corretamente. Tags PCRE são igualmente analisadas corretamente. Tags HTTP são processadas consecutivamente, então podem não criar o pacote desejado. O conteúdo (e conteúdo PCRE ou HTTP) pode ser modificado por distance, within e offset. Uma regra pode usar uma opção de controle de fluxo, embora apenas a direção dos dados seja derivada disso. A opção nocase é ignorada e o caso apresentado é usado. Todas as outras opções são ignoradas. Os valores do cabeçalho são analisados e um pacote será gerado atendendo a esses valores. Se espaços de endereço de rede Local e Externo forem usados, o espaço correto será usado para as variáveis $HOME_NET e $EXTERNAL_NET, respectivamente. Exemplo:
alert tcp $EXTERNAL_NET any -> $HOME_NET 8080 (msg:"SERVER-APACHE Apache Tomcat UNIX platform directory traversal"; flow:to_server; content:"/..|5C|/"; content:"/..|5C|/"; http_raw_uri;
Expressões regulares: Expressões regulares brutas, 1 por linha, escritas como abc ou /abc/i. Atualmente suporta as opções i, s e m. Outras opções são ignoradas. Exemplo:
/ab*c(d|e)f/i
Formato de Regra Sniffles descrito abaixo.
-a TCP Ack: Envia um acknowledgment TCP para cada pacote de dados enviado. Desligado por padrão. Pacotes de acknowledgment não possuem dados por padrão.
-b Bidirectional data: Os dados serão gerados em ambas as direções de um fluxo TCP. ACKs serão ativados. Este recurso está desligado por padrão.
-B [Background Traffic Protocol:Percentage]: Define pelo menos um protocolo com valor entre 1 e 100 para produzir Tráfego de Fundo. Este valor representa a porcentagem da quantidade total de tráfego. Protocolos disponíveis: FTP, HTTP, IMAP, POP e SMTP. Por exemplo: "http:20,ftp:30,smtp:10". Digite apenas um número como valor do argumento para gerar tráfego aleatoriamente. Por exemplo: "80".
-c Count: Número de fluxos a serem criados. Cada fluxo conterá um mínimo de 1 pacote. O pacote estará entre dois endpoints conforme definido pela regra ou escolhidos aleatoriamente. tcp_handshake, tcp_teardown e packets_per_stream aumentarão o número de pacotes por fluxo. Atualmente, os dados em um fluxo fluem em apenas uma direção. Se a opção -b for usada, os dados devem fluir em ambas as direções. Além disso, as regras Sniffles podem designar dados para fluir em ambas as direções.
-C Concurrent Flows: Número de fluxos que estarão abertos de uma vez. Melhor esforço, pois se houver menos fluxos do que o número de fluxos concorrentes designados, todos os fluxos atuais serão usados. Por exemplo, se houver apenas 1000 fluxos restantes, mas o número de fluxos concorrentes foi definido como 10000, ainda apenas 1000 fluxos serão gravados naquele momento. O valor padrão é 1000. Se usado com duração, os fluxos -C serão mantidos durante toda a duração, o que, em última análise, desconsiderará qualquer entrada de -c. Observe que o objetivo disso é criar um pcap diverso onde pacotes do mesmo fluxo sejam espalhados em vez de ficarem próximos uns dos outros e criar a ilusão de muitos fluxos concorrentes. Em nossos testes, conseguimos até 2-3 milhões de fluxos concorrentes antes que a memória se tornasse um problema. Além disso, devemos mencionar que diferentes latências entre fluxos podem fazer com que alguns fluxos terminem mais cedo do que outros.
-d Rules Directory: Caminho para o diretório que contém arquivos de regras. Lerá todas as regras habilitadas em todos os arquivos de regras no diretório. Assume que todos os arquivos de regras terminam com a extensão .rules. Use esta opção ou -f, mas não ambas. O símbolo # é usado para desativar (ou seja, comentar) uma regra.
-D Duration: Gera com base na duração em vez de na contagem. A duração está em segundos. Lembre-se de que a latência padrão entre pacotes é uma média de 1-200 microssegundos. Para latências baixas, uma duração grande pode resultar em milhões de pacotes, o que pode levar muito tempo para construir. Além disso, a duração é de melhor esforço. Essencialmente, novos fluxos não são criados após a duração ser atingida, mas pode haver fluxos que não foram concluídos. Estes ainda são gravados, então a duração real pode ser maior do que a designada, mas não deve ser menor. Finalmente, defina uma latência maior se você desejar que menos fluxos sejam criados durante a geração.
NOTA: todos os exemplos assumem que você instalou o pacote sniffles.
Para gerar um pcap a partir de um único arquivo de expressões regulares com 10 fluxos onde cada pacote corresponde a uma regra
sniffles -c 10 -f myre.re -m
Para gerar um pcap a partir de um único arquivo de regras Snort onde cada pacote corresponde quase a uma regra
sniffles -c 10 -f myrules.rules
Para gerar um pcap a partir de múltiplos arquivos de regras Snort em um único diretório onde cada pacote corresponde a uma regra.
sniffles -c 10 -d myrulesdir -m
Para gerar o mesmo pcap acima, usando as mesmas regras, mas com conteúdo aleatório (o conteúdo é aleatório, os cabeçalhos ainda seguirão as regras—não funciona com regex ou regras Sniffles):
sniffles -c 10 -d myrulesdir -r
Para gerar um pcap com 10 fluxos (1 pacote cada) e com dados aleatórios:
sniffles -c 10
Para gerar um pcap com 10 fluxos onde 50% dos fluxos serão tráfego de fundo e o restante dos fluxos conterá pacotes correspondentes a uma regra:
sniffles -c 10 -B 50 myrules.rules
Para gerar um pcap com 10 fluxos, cada fluxo com 5 pacotes, com ACKs, handshake e teardown, além de um comprimento fixo de 50 para os dados em cada pacote com dados:
sniffles -c 10 -p 5 -l 50 -t -T -a
Para gerar um pcap com 20 fluxos aleatórios com uma rede local de 192.168.1-2.x:
sniffles -c 20 -h 192.168.1,192.168.2
Para gerar um pcap com 20 fluxos aleatórios com uma rede local de 192.168.1.x para IPv4 e 2001:8888:8888 para IPv6 com 50% do tráfego IPv6:
sniffles -c 20 -h 192.168.1 -H 2001:8888:8888 -i 50
Para gerar uma captura de pacotes de 5 segundos de pacotes aleatórios com um intervalo médio entre pacotes de 100 microssegundos:
sniffles -D 5 -L 100
Para gerar um pcap que criará um pacote correspondente a cada regra em um arquivo de regras (ou arquivo de regex) em sequência:
sniffles -f myrules.rules -e
Para gerar um pcap que criará um pacote para cada ramo possível de um regex para cada regex em um conjunto de regex e depois salvar esse arquivo em um pcap chamado everything.pcap é como abaixo. No entanto, esta função pode ser executada em tempo exponencial se o regex tiver uma grande quantidade de contagem min-max, então pode levar muito tempo para executar. Além disso, todas as outras opções, exceto as duas ilustradas abaixo, são ignoradas.
sniffles -f myrules.rules -o everything.pcap -E
Para gerar tráfego aleatório com um ataque de varredura ocorrendo 2 segundos depois e durando 2 segundos com 1000 pacotes de varredura por segundo e com a captura inteira com duração de 5 segundos e tempo de intervalo de 50us e com porta inicial 80 (pesquisando portas sequencialmente a partir de 80):
sniffles -D 5 -O 2 -W 2 -I 1000 -L 50 -s 192.168.1.2 -P 80
Semelhante ao acima, mas criará múltiplos ataques de varredura, cada um com duração de 1 segundo, e um offset médio entre ataques de 2 segundos. Além disso, varre apenas as portas designadas. Também tem como alvo endereços IP no intervalo 192.168.1.0-255 aleatoriamente.
sniffles -D 8 -O 2 -W 1 -I 10 -L 50 -s 192.168.1 -P 80,8080,8000,8001
Sniffles suporta vários formatos de regras. Primeiro, Sniffles pode analisar regras Snort e expressões regulares (uma por linha). Além disso, Sniffles também possui seu próprio formato de regra que pode ser usado para controlar explicitamente o tráfego. Isso é feito através do uso de arquivos xml que descreverão o tráfego. Quando este formato é usado, as outras opções do Sniffles podem ser irrelevantes. Exemplos de arquivos de regras podem ser encontrados no diretório examples. Esses arquivos de regras são usados simplesmente designando o arquivo de regras com a opção -f (ou seja, sniffles -f rules.xml)
O formato de regra Sniffles é o seguinte:```xml
<petabi_rules> <traffic_stream proto="tcp" src="any" dst="any" sport="any" dport="any" handshake="True" teardown="True" synch="True" ip="4"> </traffic_stream> <traffic_stream proto="tcp" src="any" dst="any" sport="any" dport="any" handshake="True" teardown="True" synch="True"> </traffic_stream> </petabi_rules>
Em detalhe, as tags funcionam da seguinte forma:
- `<petabi_rules> </petabi_rules>`: Isto define todas as regras para este
ficheiro de regras. Deve existir apenas um conjunto destas tags a abrir e
fechar todos os fluxos de tráfego designados.
- `<rule > </rule>`: Designa uma única regra. Uma única regra pode gerar
um número arbitrário de fluxos de tráfego ou pacotes. Pode ter qualquer número
de regras num único ficheiro.
- Opções:
- name: O nome desta regra. Serve maioritariamente para documentação, sem
função real.
- `<traffic_stream> </traffic_stream>`: Um fluxo de tráfego define tráfego
entre dois pontos finais. Todos os pacotes designados dentro de um único fluxo
de tráfego partilharão os mesmos pontos finais. Qualquer número de fluxos de tráfego
pode ser designado para uma determinada regra. Diferentes fluxos de tráfego dentro
da mesma regra podem ter pontos finais diferentes ou não, dependendo das
definições abaixo.
- Opções:
- typets: Especifica que tipo de fluxo de tráfego usaremos para
gerar pacotes. Atualmente, temos Standard, ScanAttack e
BackgroundTraffic.
- scantype: 1 == Syn scan (padrão) 2 == Connection scan.
É usado com ScanAttack.
- target: Especifica o endereço IP alvo para Scan Attack.
- targetports: Para um ataque de scan. Fornece uma lista separada por vírgulas de
portas possíveis, ou uma única porta inicial. Caso contrário, as portas
serão escaneadas aleatoriamente. Se for fornecida uma única porta inicial,
então as portas serão escaneadas em ordem a partir desse ponto até 65535,
após o que voltará ao ponto inicial. Esta opção
é usada em conjunto com typets sendo 'ScanAttack'
- srcport: Especifica a porta de origem para Scan Attack. Aleatória por padrão.
- duration: A janela, ou duração, em segundos de um ataque de scan
se typets for 'ScanAttack'
- intensity: Intensidade do ataque de scan se typets for 'ScanAttack'.
- offset: Deslocamento antes de iniciar um ataque de scan. Também usado ao
inserir múltiplos scans no tráfego.
- replychance: Probabilidade de um scan ter uma resposta.
Por outras palavras, probabilidade de a porta alvo estar aberta
(padrão 20%). É usado com ScanAttack.
- proto: Designa o protocolo deste fluxo de tráfego.
Deve ser TCP ou UDP ou ICMP (não testado).
- src: Endereço IP de origem. Pode ser um endereço no formato xxx.xxx.xxx.xxx,
$EXTERNAL_NET (para um endereço externo – assume que uma rede
doméstica foi designada), $HOME_NET, ou any (seleciona
aleatoriamente o endereço IP).
- dst: Endereço IP de destino. Igual ao endereço IP de origem.
- sport: Porta de origem (assume TCP ou UDP). Pode usar formatação de porta
snort que pode ser uma lista separada por vírgulas entre parênteses retos
(ex.: [80,88,89]), um intervalo (ex.: [10:1000]), ou any
(ex.: escolha aleatória de 0-65535).
- dport: Porta de destino conforme sport.
- handshake: Irá gerar um TCP Handshake no início do
fluxo. Se excluído, não haverá handshake. Valores válidos
são true ou false. O padrão é false.
- latency: define a latência média entre pacotes (em microssegundos).
- teardown: Irá fechar o fluxo quando todo o tráfego tiver sido enviado
anexando o teardown TCP no final do fluxo de tráfego.
Valores válidos são true ou false. O padrão é false.
- synch: Os fluxos de tráfego são síncronos ou não. Quando true, um
fluxo de tráfego deve terminar antes do próximo fluxo de tráfego
começar. Quando false, todos os fluxos contíguos que são false
(ou seja, assíncronos) executarão ao mesmo tempo.
- tcp_overlap: O valor padrão é false. Quando true, a partir do
segundo pacote será anexado um conteúdo extra e o número de sequência
tcp será reduzido em um para simular o número de sequência
sobreposto do tcp.
- ipv: Designa IPv4 ou IPv6. Opções válidas são 4, ou 6.
O padrão é 4.
- out_of_order: Aleatoriamente, faz com que pacotes cheguem fora de ordem.
Nota, isto só funciona com pacotes que usam a opção 'times'.
Além disso, esta opção deve ser usada com ack para
que os duplicados de ack adequados apareçam no traço de tráfego.
Valores válidos são true ou false. O padrão é false.
- out_of_order_prob: Define a probabilidade de os pacotes chegarem
fora de ordem. Por exemplo, 10 significaria que há 10%
de chance para cada pacote chegar fora de ordem. Pacotes
fora de ordem chegam depois de todos os pacotes em ordem.
Além disso, são também misturados aleatoriamente. Assim,
se os primeiros pacotes 2 e 5 de 10 pacotes forem determinados como
fora de ordem, chegarão por último dos 10 pacotes
(posições 9 e 10) e estarão numa ordem arbitrária
(ex.: 5 pode vir antes de 2 ou vice-versa). O valor
para isto deve estar entre 1 e 99. O padrão é 50.
- packet_loss: Aleatoriamente, faz com que pacotes sejam descartados (ou seja, não cheguem).
Isto só funciona com a opção 'times'. Além disso, esta opção
deve ser usada com a opção ack definida como true para que
duplicados de ack apareçam no traço de tráfego. Valores válidos
são 1 a 99 representando a probabilidade de um pacote ser descartado.
Nota, a perda de pacotes só acontece em pacotes com dados, não
nos acks.
- ack: Faz com que todos os pacotes de dados neste fluxo sejam seguidos por
um ACK do servidor. Valores válidos são true ou false.
O padrão é false.
- percentage: Isto aplica-se apenas ao BackgroundTraffic e deve haver
apenas uma regra de BackgroundTraffic num ficheiro de regras ou diretório.
A percentagem indica a percentagem de fluxo de tráfego de fundo
a ser criado no fluxo de tráfego total.
- http: Distribuição percentual de protocolos de aplicação http no
fluxo de tráfego de fundo.
- ftp: Distribuição percentual de protocolos de aplicação ftp no
fluxo de tráfego de fundo.
- pop: Distribuição percentual de protocolos de aplicação pop no
fluxo de tráfego de fundo.
- smtp: Distribuição percentual de protocolos de aplicação smtp no
fluxo de tráfego de fundo.
- imap: Distribuição percentual de protocolos de aplicação imap no
fluxo de tráfego de fundo.
- `<pkt > </pkt>`: Esta diretiva designa ou um pacote
individual ou uma série de pacotes. A funcionalidade times pode ser usada para ter
uma diretiva `<pkt> </pkt>` a gerar vários pacotes. Caso contrário, é
necessário designar explicitamente cada pacote em cada direção.
- Opções:
- dir: A direção do pacote. Valores válidos são to server
ou to client. O IP src inicial é considerado o cliente,
e o IP dst inicial o servidor. Assim, 'to server' envia um
pacote do cliente para o servidor e 'to client' envia um pacote
do servidor para o cliente. O padrão é to server.
- content: Expressão regular que designa o conteúdo para este
pacote. O tamanho do pacote dependerá da expressão regular.
- fragment: Se deve ou não fragmentar este pacote.
Funciona apenas com ipv4. Deve ter um valor maior que 2.
Irá criar tantos fragmentos quantos forem válidos ou conforme designado
(o que for menor). O valor padrão é 0, significando sem
fragmentos.
- ack: Enviar um ack para este pacote ou não. Valores válidos são
true ou false. O padrão é false.
- split: Divide o conteúdo pelo número designado de
pacotes. Por padrão, todo o conteúdo é enviado num único
pacote (fragmentos são uma pequena exceção a esta regra).
- times: Envia este pacote x vezes. O valor padrão é 1,
um valor positivo enviará exatamente x pacotes (possivelmente
com acks se ack for true), enquanto um número negativo
enviará um número aleatório de pacotes entre 1 e abs(-x).
- ttl: define o valor de time to live para o pacote. Por padrão,
sniffles irá gerar um valor TTL aleatório.
- ttl_expiry: simula o ataque de expiração TTL dividindo
pacotes em múltiplos pacotes com um pacote malicioso
entre dois pacotes bons. Por padrão, o valor é 0
(sem pacote malicioso). Se o valor for diferente de zero, irá
inserir pacote malicioso com este ttl igual ao valor ttl_expiry.
Se o valor ttl estiver definido, o pacote bom será definido
com o novo valor ttl
Notas Finais: O novo formato de regra é apenas um começo e pode conter problemas.
Por favor, avise-me de quaisquer inconsistências ou erros. Além disso, a intenção é
expandir as opções para fornecer cada vez mais funcionalidade conforme necessário.
Entre em contacto comigo para funcionalidades desejadas. Finalmente, este produto é
fornecido como está. Não há garantia de funcionalidade ou
precisão. Sinta-se à vontade para bifurcar este projeto para atender às suas próprias necessidades.
Créditos:
--------
Esta aplicação foi trazida a si por Petabi, Inc. onde fazemos
soluções de segurança Fiáveis, Realistas e Super-rápidas.
Autores:
- Victor C. Valgenti
- Min Sik Kim
- Tu Le
- Moosuk Pyun
Novas Funcionalidades:
-------------
- 21/11/2014: Versão 1.4.0 Adicionada divisão de tráfego e traffobot para
geração de tráfego bidirecional. Corrigido bug onde era lançada uma exceção
quando a quantidade de tráfego gerado cabia numa única
chamada de escrita de tráfego. Reformatação e ativação da utilização. Finalmente, adicionados
testes unitários para traffobot e análise de XML.
- 03/02/2015: Versão 2.0. Reescrita completa de como os fluxos funcionam para reduzir
requisitos de memória ao gerar grandes fluxos usando regras especiais. Atualmente,
consegue lidar com cerca de 2-3 milhões de fluxos concorrentes antes de o sistema abrandar.
Adicionei algumas funcionalidades para ajudar na criação de grandes fluxos. Primeiro,
gere com algo como uma concorrência de 2-3 milhões de fluxos. Além disso, não use
teardown para estes fluxos. Uma fração dos fluxos durará do início
até ao final da captura, enquanto os restantes serão encerrados a cada
período de lote. Vou trabalhar para tornar isto mais eficiente, mas gerir
todas as opções complexas no Sniffles agora não pode ser feito de forma barata em
memória. A única outra solução é obter uma máquina mais potente com mais RAM.
Esta versão também contém uma variedade de correções.
- 11/02/2015: Adicionada probabilidade a pacotes fora de ordem para permitir que a frequência
de pacotes fora de ordem seja ajustada.
- 05/03/2015: Alterado teardown TCP para sequência de teardown padrão.
Agora permite que o conteúdo seja distribuído por vários pacotes sem usar fragmentos.
- 09/04/2015: Corrigido tráfego de scan, estava parcialmente quebrado durante uma das alterações
anteriores. O timestamp inicial do pcap agora tem como padrão a hora atual e pode
ser definido com a opção -g. Finalmente, o 3º pacote no handshake TCP de 3 vias
agora terá dados se o cliente for enviar dados primeiro.
- 22/05/2015: Reescrita da análise de regras para simplificar a capacidade de estender o
analisador de regras para acomodar mais formatos. Incorporada travessia nfa e
pcre diretamente no sniffles. Código limpo e preparado para o
público.
- 27/05/2015: Documentação atualizada, mescladas bibliotecas pcre e
construção nfa para tornar o sniffles um pacote autónomo.
Adicionados o Gerador de Expressões Regulares e o Gerador de Regras Aleatórias como
parte do pacote Sniffles. Versão atualizada para 3.0.0
e publicada no github.
- 12/08/2015: Implementado um grande número de correções de bugs e novas
funcionalidades. Alterado fundamentalmente como os fluxos são
tratados para permitir uma melhor extensibilidade. Adicionada latência por
fluxo. Documentação atualizada.
Gerador de Expressões Regulares
===============================
Este é um gerador simples de expressões regulares.
Cria expressões regulares ou completamente aleatórias, ou
baseadas numa série de distribuições.
Os controlos que podem ser colocados em como as expressões regulares são
geradas são estruturais, não contextuais. Por outras palavras,
não há esforço para que certos tokens de string apareçam nas
expressões regulares geradas. No entanto, as distribuições de probabilidade
podem ser ajustadas para afetar os tipos de funcionalidades
encontradas nas regras, como classes de caracteres, alternância, repetição, etc.
Instalação
----------
Será instalado automaticamente com o resto do Sniffles.
Opções
-------
regexgen--Gerador Aleatório de Expressões Regulares.
uso: regexgen [-C distribuição de caracteres] [-c número regex]
[-D distribuição de classes] [-f ficheiro de saída re]
[-l lambda para geração de comprimento] [-M comprimento máximo de regex]
[-m comprimento mínimo de regex] [-n probabilidade de negação]
[-o probabilidade de opções] [-R probabilidade de repetição] [-r distribuição de repetição]
[-t distribuição de tipo estrutural re] [-?] [-g]
- -C Distribuição de Caracteres: Isto define a possibilidade de ver
caracteres ou tipos de caracteres particulares. Veja uma breve explicação das
distribuições abaixo para exemplos de como usar isto. Por padrão,
esta distribuição é uma distribuição igual. Esta distribuição
tem cinco slots: Caracteres ASCII, Caracteres binários no formato \x00,
Letras alfabéticas (maiúsculas ou minúsculas), Dígitos, e classes de
substituição (como \w). Um exemplo de entrada para isto seria "10,20,10,40,20"
que significaria 10% de probabilidade de qualquer caractere gerado vir de 10% ASCII,
20% binário, 10% letras, etc. Uma ressalva é que caracteres ASCII que
possam causar problemas com expressões regulares (como `[' ou '{')
são convertidos para representação hexadecimal (\x3b por exemplo).
- -c Número de expressões regulares a gerar. O padrão é uma.
- -D Distribuição de Classes: Existem apenas dois slots na distribuição
de classes. O primeiro slot é a probabilidade de a classe ser
composta por algum número de caracteres gerados aleatoriamente. O
segundo slot é a probabilidade de a classe ser composta por
intervalos (como a-z).
- -f Nome do ficheiro de saída. Isto define o nome do ficheiro onde as
expressões regulares são armazenadas. O padrão é um ficheiro chamado rand.re
no diretório de trabalho atual.
- -g Grupos: Todas as expressões regulares terão um prefixo comum com
pelo menos uma ou mais outras expressões regulares (desde que haja
mais de uma regex.) Um prefixo comum é apenas uma expressão regular
que é a mesma para algum conjunto de expressões regulares. O número total
de prefixos comuns possíveis é de 1 a metade do tamanho total
de expressões regulares a gerar. O valor padrão para esta
opção é false. Esta opção não aceita parâmetros.
- -l Lambda para comprimento: Este é o comprimento médio para uma distribuição
exponencial de comprimentos de expressões regulares. O valor padrão é 10.
- -M Comprimento Máximo de Regex: faz com que as expressões regulares tenham no máximo este
comprimento estrutural ou mais curto. Por padrão, o comprimento máximo não é limitado.
- -m Comprimento Mínimo de Regex: faz com que as expressões regulares tenham pelo menos este comprimento
ou mais. O padrão é 3, e usará automaticamente um valor de 1
se a entrada for zero ou inferior.
- -n Probabilidade de Negação: A probabilidade de uma classe de caracteres ser
uma classe de negação ([^xyz]) em vez de uma classe de caracteres normal ([xyz]).
Probabilidade padrão é 50%.
- -o Probabilidade de Opções: Esta é a probabilidade de uma opção ser anexada
à expressão regular. As opções atuais são 'i', 'm', e 's'.
Um número aleatório de opções é adicionado à lista com essas opções
escolhidas através de uma distribuição uniforme.
- -R Probabilidade de Repetição: A probabilidade de repetição ocorrer após
qualquer componente estrutural ter sido adicionado à expressão regular.
- -r Distribuição de Repetição: A distribuição de estruturas de repetição.
Os slots são: Zero para um (?), Zero para muitos (*), um para muitos (+), e
contagem ({x,y}).
- -t Distribuição de Tipo Estrutural Re: A distribuição para os componentes
estruturais primários da expressão regular. Estes
são compostos por três slots, ou categorias: caracteres, classes,
e alternância. Nota, alternância irá simplesmente gerar uma expressão regular
mais pequena até ao tamanho do comprimento restante para a
re. Por outras palavras, alternância resultará em várias expressões regulares
mais pequenas que são unidas na expressão regular geral.
A alternância usa exatamente a mesma metodologia ao criar essas
expressões regulares mais pequenas.
- -? Imprime esta ajuda.
Este gerador criará expressões regulares aleatórias. É possível
ajustar as estruturas dentro das expressões regulares para uma distribuição
de probabilidade, mas atualmente não o conteúdo. Isto é desejável para
explorar a máxima diversidade em possíveis expressões regulares
(embora não necessariamente expressões regulares realistas).
As distribuições são tratadas criando uma lista de probabilidades para
as várias possibilidades, ou slots, para uma distribuição particular.
Estas são adicionadas como argumentos de linha de comandos usando uma string
simples como: "10,30,40,20". A lista deve ter tantos valores
quantos slots. O total de todos os valores na lista deve ser
100 e não deve haver frações. O valor em cada slot
é a probabilidade de esse slot ser escolhido. Por exemplo,
a distribuição de tipo estrutural base da RE tem três slots. O
primeiro slot é a probabilidade de o próximo tipo de estrutura ser
um caractere (onde um caractere pode ser uma letra, dígito, binário, ASCII,
ou classe de substituição (como \w)). O segundo slot é para classes de caracteres
como [ab@%], [^123], ou [a-z]. O slot final é a probabilidade
de alternância ocorrer como (ab|cd). Com estes três slots pode ajustar
a frequência com que gostaria que as estruturas aparecessem nas suas expressões
regulares. Por exemplo, regexgen -c 10 -t "80,10,10" criaria
10 expressões regulares onde 80% das estruturas usadas seriam
caracteres, 10 por cento seriam classes de caracteres, e 10% alternância.
Gerador de Regras Aleatórias
=============================
O Gerador de Regras Aleatórias fornece um meio para criar um número de regras geradas
aleatoriamente com as quais testar uma plataforma específica. Atualmente,
as regras geradas cumprem o formato de regra Snort ou são apenas linhas
de texto. Para que o Gerador de Regras Aleatórias funcione, deve ter
um conjunto de funcionalidades definidas. Exemplos de funcionalidades podem ser encontrados na
pasta example_features e são descritos em baixo.
Instalação
----------
Instalado automaticamente com o Sniffles
Nota: O Gerador de Regras Aleatórias faz uso do
Random Regex Generator para criar conteúdo de qualquer tipo.Opções
-------
Gerador de Regras Aleatórias
uso: rulegen -c [número de regras] -f [conjunto de features]
-o [arquivo de saída] [-s]
- -c Número de regras: O número de regras a serem geradas.
O padrão é um.
- -f Conjunto de features: O arquivo contendo a descrição do conjunto de features.
Consulte a documentação para mais explicações sobre
conjuntos de features e como descrevê-los.
- -o Arquivo de saída: arquivo de saída no qual as regras serão escritas.
O padrão é rules.txt
- -s Formato de regra Snort: escreve as regras no formato de regra do Snort.
Sem parâmetros, o padrão é desligado. Quando desligado, as regras são apenas
convertidas para um formato de string, seja qual for, baseado no
parser de features.
Conjunto de Features
-----------
Features são usadas para descrever aspectos potenciais de regras usadas em
IDS. Por exemplo, um filtro de pacotes pode usar regras que visam
endereços IP de origem e destino. Nesse caso, seria possível
criar um conjunto de features descrevendo como esses endereços IP de origem e destino
devem ser gerados. Mais especificamente, fazemos a
distinção entre regras simples e regras complexas. A diferença
entre essas duas é a presença de notações ambíguas. Por
exemplo, se possuíssemos uma notação ambígua de * para significar qualquer
endereço IP, então poderíamos dizer que * representa uma notação ambígua.
Além disso, sabemos que uma regra também pode usar uma notação não ambígua,
como 192.168.1.1. Isso representaria um endereço IP simples, pois
é um único endereço IP fixo sem qualquer possível notação ambígua.
Em seguida, definimos ainda o intervalo das features específicas
(ou seja, endereços IP em todos os mais de 4 bilhões de
possíveis endereços IPv4, ou apenas algum subconjunto disso).
As features definem, em última análise, todos os aspectos de uma
regra arbitrária. Dado um conjunto de features e um formato de regra válido,
torna-se possível gerar aleatoriamente um número arbitrário
de regras que usam essas features. Dessa forma, é possível
gerar conjuntos de regras de teste que examinarão o IDS em um
vetor que muitas vezes é negligenciado.
As features são definidas em uma lista separada por ponto e vírgula, uma feature por linha:
tipo=feature; lista de argumentos em pares chave=valor, listas usando formatação
Python (ou seja, [a, ..., z]). Features definem partes específicas de um
formato de regra alvo. Features podem ser estendidas para adicionar mais funcionalidades.
Opcionalmente, pode-se estender a capacidade das features criando um novo
formato de regra.
Tipos de Feature Atuais:
1. Feature -- feature genérica
2. Content -- Feature de Conteúdo
3. IP -- Feature de IP
4. Protocol -- Feature de Protocolo
Listas ambíguas devem ser escritas como listas: [x:y]
para um intervalo, [x,y] para uma lista, {x1,x2,x3} para um conjunto
ou apenas * para um curinga ou opção única similar.
Exemplo sobre lista ambígua:```
ambiguity_list=[[2:9]]
it will generate [3:4], [5:6], etc (any [x:y] such that
x <= y and x >= 2 and y > x and y <= 9).
ambiguity_list=[[3,20]]
it will generate [3,9,10], [3,4,8,12], etc (any list [x1,x2,x3,..]
such that all values falling between 3 and 20.
ambiguity_list=[{5,6,10}]
it will generate a subset of {5,6,10} such as {5,10}, {5}.
ambiguity_list=[[2:9],[3,20],{5,6,11}]
it will pick one of [2:9], [3,20], and {5,6,11} and
generate a corresponding instance (see above)
Exemplo para arquivo de funcionalidade:``` type=protocol; name=proto; proto_list=[TCP,UDP,ICMP]; complexity_prob=0;ambiguity_list=None; type=ip; name=sip; version=4; complexity_prob=100;
o anterior define duas características, uma característica de protocolo e uma característica de IP de origem. O protocolo é nomeado proto, que é importante apenas para o formatador de regras, e os protocolos válidos são: IP, TCP, UDP e ICMP. A característica IP é definida como IPv4 e todas as regras serão complexas. A complexidade IP já faz parte da classe e não precisa ser adicionada na definição da característica. Isso criará endereços IP usando notação CIDR.
Generic Feature Attributes:
- Feature_name: Atributo informacional, potencialmente valioso para
o formatador de regras.
- lower_bound: O limite inferior dos valores possíveis. Pressupõe
que a característica seja um número.
- upper_bound: Oposto de lower_bound.
- complexity_prob: A probabilidade de usar características complexas para uma
regra. De 0 a 100. Padrão é 0.
Quando características complexas são usadas, uma notação ambígua
é selecionada aleatoriamente da lista de ambiguidades, ou
se a característica define uma ambiguidade específica (como
endereços IP) então essa é usada. Quando características
complexas não são usadas, um valor é gerado usando
os limites, ou, no caso de Content,
usando um conjunto de valores de distribuição que
restringirão a string gerada a uma série
de caracteres ASCII.
- ambiguity_list: Uma lista de possíveis notações ambíguas.
Lista separada por vírgulas usando formatação python
(ex.: [a, b, c]).
- toString(): Imprime uma instância de uma regra dado este conjunto particular
de características.
Content Feature -- Herda de Feature:
- regex: Verdadeiro ou Falso. Se Verdadeiro, usará formatação pcre para
regex e também poderá adicionar as opções i, s, ou
m ao regex.
- length: Define o comprimento médio do conteúdo
gerado.
- min_regex_length: Define o comprimento mínimo do regex.
Protocol Feature -- Herda de Feature:
- proto_list: Define a lista de protocolos possíveis,
como uma lista separada por vírgulas (ex.: [TCP,
UDP]).
IP Feature -- Herda de Feature:
- version: 4 para IP versão 4, 6 para IP versão 6.
Padrão é versão 4.
Notação ambígua para intervalos, listas, conjuntos:
Notação de intervalo:
[x:y] significa de x a y (inclusive).
Notação de lista:
[x,y] significa lista de algum número determinado aleatoriamente
de valores, onde cada valor é maior ou igual a x
e menor ou igual a y.
Notação de conjunto:
{x1,x2,x3,x4} significa um conjunto de valores x1, x2, x3, x4.
Gerará um subconjunto do conjunto original.
Por favor, consulte os conjuntos de características de exemplo na
pasta example_features para mais exemplos.
Mais detalhes, bem como a teoria acadêmica
por trás disso, estão programados para serem adicionados posteriormente.
-e eval: Cria apenas um pacote para cada regra no conjunto de regras. Ignora todas as outras entradas, exceto -f. Cada pacote terá conteúdo correspondente à regra selecionada.
-E Full Eval: Cria um pacote para cada caminho viável em uma regra pcre no conjunto de regras. Em outras palavras, ab(c|d)e criaria dois pacotes: abce e abde. Ignora todas as outras entradas, exceto -f.
-f Rule File: Lê um único arquivo de regras conforme o caminho e o nome do arquivo fornecidos.
-F Config: Designa um arquivo de configuração para as opções do Sniffles. O arquivo de configuração é uma forma de fixar os parâmetros usados para uma execução do Sniffles.
-g Timestamp: Define o horário inicial para o timestamp do pcap. Este será o número de segundos desde 31/12/1969. O padrão é o horário atual.
-h IP Home Prefixes: Uma lista de Prefixos de Rede Local IP. Endereços IP destinados a vir de um endereço interno usarão esses prefixos. Prefixos podem designar um endereço IPv4 completo de 4 bytes no formato xxx.xxx. Por exemplo: "10.192.168,172.16".
-H IP v6 Home Prefixes: O mesmo que Prefixos Locais IPv4, apenas para IPv6. Exceções notáveis: o separador é dois pontos com dois bytes representados entre dois pontos.
-i IPv6 percentage: Define este valor entre 1 e 100 para gerar pacotes com IPv6. Isso determinará a porcentagem de fluxos que serão IPv6.
-I Intensity of scan attack (ou seja, pacotes por segundo.)
-l Content Length: Fixa o comprimento do conteúdo no número de bytes designado. Menos que um definirá o comprimento igual ao conteúdo gerado pelo nfa, ou um número aleatório entre 10 e 1410 se os cabeçalhos também forem aleatórios. Truncará ou preencherá o pacote conforme necessário.
-L Latency: Latência média em microssegundos. Se não for definida, uma latência média aleatória entre 1 e 200 usecs é determinada para cada fluxo. Assim, os pacotes para um determinado fluxo terão uma latência média entre cada pacote no fluxo.
-M Permite o uso de uma distribuição MAC para ter endereços MAC personalizados no tráfego. Por padrão, os endereços MAC são gerados aleatoriamente. Mais informações sobre o arquivo de definição MAC podem ser encontradas no examples/mac_definition_file.txt. Nota: Você pode especificar até dois arquivos de definição MAC para definir valores diferentes dependentes do MAC de origem ou destino. Se você especificar apenas um arquivo, ele será usado para qualquer direção. Se você usar a seguinte notação, pode especificar para direções específicas. Por exemplo: 'path1:path2'. Path1 será o arquivo de definição MAC para MACs de origem e path2 será o arquivo de definição MAC para MACs de destino. Você também pode usar um ponto de interrogação (?) para designar um ou outro como aleatório, como em: '?:path2' para ter MACs de origem aleatórios, mas usar o arquivo para.
-n Not Match Completely. Define que o conteúdo gerado a partir de uma regra não corresponda completamente (ou seja, truncará automaticamente os últimos caracteres). O comportamento padrão é corresponder ao conteúdo da regra completamente.
-o output file: Designa o nome do arquivo de saída. Por padrão, o arquivo é nomeado: sniffles.pcap.
-O Offset: Offset antes de iniciar um ataque de varredura. Também usado ao inserir múltiplas varreduras no tráfego. Este é o número de segundos antes do início da varredura. Se usado com -R, este se torna o número médio de segundos antes do início.
-p Packets-per-stream: Designa o número de pacotes com conteúdo para um único fluxo. Se um valor positivo for fornecido como argumento, exatamente x (se x for o inteiro fornecido) pacotes com conteúdo aparecerão para cada fluxo. Se x for negativo, um número aleatório de pacotes aparecerá para cada fluxo (de 1 a abs(x)). Por padrão, este valor é 1.
-P Target Port list: Para um ataque de varredura. Forneça uma lista separada por vírgula de portas possíveis, ou uma única porta inicial. Caso contrário, as portas serão varridas aleatoriamente. Se uma única porta inicial for fornecida, as portas serão varridas em ordem a partir desse ponto até 65535, após o que retornará ao ponto inicial. Se uma lista for fornecida, as portas na lista serão varridas em round-robin.
-r Random: Gera conteúdo aleatório em vez de a partir das regras. Se as regras ainda forem fornecidas, elas são usadas na geração dos cabeçalhos. Nota: muitos recursos nas regras podem substituir certos aspectos da geração aleatória.
-R Random scan Attacks: Usará o Offset para criar ataques de varredura no tráfego, mas usará o offset apenas como mediana. O offset é usado para determinar a quantidade de tempo entre quando uma varredura termina e uma nova varredura começa.
-s Scan Attack: Seguido por uma lista separada por vírgula de endereços IPv4 indicando qual endereço IP será alvo. Cada intervalo de IP criará um ataque de varredura. Os intervalos devem ser como: 192.168.1.1 que teria como alvo exatamente aquele endereço IP, enquanto 192.168.1 teria como alvo um endereço IP aleatório entre 192.168.1.0 e 192.168.1.255.
-S Scan type: 1==Syn scan (padrão) 2 == Connection scan.
-t TCP Handshake: Inclui um handshake TCP em todos os fluxos TCP. Desligado por padrão.
-T TCP Teardown: Inclui um teardown TCP em todos os fluxos TCP. Desligado por padrão.
-v Verbosity: Aumenta o nível de mensagens de saída.
-w write content: Escreve as strings de conteúdo em um arquivo chamado 'all.re'
-W Window: A janela, ou duração, em segundos de um ataque de varredura.
-Z Reply Chance: Chance de uma varredura ter uma resposta. Em outras palavras, chance de a porta alvo estar aberta (padrão 20%).