Evrensel Çekim Kanunu

As gramáticas livres de contexto foram utilizadas na área de teste de firewall como apresentado em [Hoffman and Yoo, 2005] e [Hoffman et al., 2010].

Em [Hoffman and Yoo, 2005], foi desenvolvida a ferramenta Blowtorch. A Blowtorch é um framework desenvolvido em C++, para geração automática de teste de firewall. Ela

foi projetada para desenvolver testes com conjuntos de regras de firewall em um ambiente de controle de processos [Byres and Savage, 2005].

No trabalho são apresentados quatro tipos de testes para verificar a política de segu- rança de um firewall, são eles:

• Verificar se os pacotes SYN são enviados a uma taxa maior do que o permitido;

• Descartar todos os pacotes TCP com combinações de flag ilegal;

• Repetição do trafégo de produção (capturar o tráfego de PCN/DMZ e BN/DMZ), verificando se o firewall permite que este trafégo seja permitido;

• Histórico de conexão de dados.

No entanto, o foco principal do trabalho é o teste que verifica o comportamento de um firewall diante da inserção de combinações com flags ruins em conexões TCP. Existem seis flags (urg,ack,psh,rst,syn e fin) de controle no cabeçalho TCP, mas nem todas as combinações desses flags são significativas. Das 64 combinações possíveis, apenas 18 são legais e 46 são ilegais [McCarty and Cox, 2002].

O teste deve determinar o comportamento do firewall diante das 46 combinações de flags ruins. O comportamento desejado de um firewall para essa situação, seria derrubar todos os pacotes que contêm estas combinações ilegais. O teste deve verificar quais pacotes com flags ruins são filtrados por um firewall.

Além de verificar o comportamento do firewall, o teste permite determinar se o estado da sessão TCP tem alguma influência sobre os pacotes encaminhados. Para determinar se o estado faz alguma diferença, os pacotes com flags ruins são enviados em momentos diferentes durante uma sessão TCP.

Para realização desses testes, os 46(quarenta e seis) pacotes com flags ruins foram inseridos em 5 (cinco) locais diferentes, o que resultou em 230 casos de testes. Para criar os casos de testes, foi utilizada uma gramática. Parte dessa gramática pode ser visualizada na Figura 11.

Os testes foram executados com dois firewalls: iptables, que é um firewall de código aberto que funciona em Linux e Pix Cisco, que é o padrão da industria.

Foram realizados dois testes. O primeiro enviou 46 (quarenta e seis) pacotes com flags ruins através do firewall e o segundo enviou pacotes com flags ruins em lugares diferentes

Figura 11: Fragmento da gramatica [Hoffman and Yoo, 2005]

dentro de uma sessão TCP. O resultado mostrou que para o primeiro caso, 2 (dois) dos 46 (quarenta e seis) pacotes foram aceitos. Para o segundo teste, mais pacotes foram encaminhados.

Em [Hoffman et al., 2010] foram apresentados dois estudos de caso que mostram a combinação de duas abordagens: geração de testes baseada em gramáticas (GTBG) e cobertura de matrizes. Na técnica de cobertura de matrizes, um template de testes é desenvolvido com N parâmetros, cada um com um domínio finito. O espaço de teste é o produto cartesiano dos domínios. Cada n-tupla em um espaço de teste especifica um caso de teste. Geralmente o espaço de teste é grande para executar todos os casos de testes. Um algoritmo de cobertura de matrizes obtém uma lista de domínios e gera um subconjunto do espaço de teste contendo todas as combinações de parâmetros de um certo tipo. Estas duas abordagens são utilizadas para automatizar o teste de software.

Um dos estudos de caso determina a efetividade de um firewall de rede quando diante de flags ilegais. Um firewall é testado com um grande número de conexões TCP. Alguns dos pacotes são normais, outros contêm pacotes com flags ilegais. Os firewalls são pro- jetados para detectar e derrubar os pacotes com flags ilegais. Os testes determinam as circunstâncias em que pacotes com flags ilegais são detectados e derrubados.

Para a realização dos estudos de caso foi utilizada a ferramenta YouGen, que engloba as duas abordagens. A Yougen é responsável por definir e produzir os casos de testes. A ferramenta recebe uma gramática livre de contexto G como entrada e produz um

subconjunto de L(G), gerando uma derivação para cada elemento de L(G). A ferramenta é apresentada com detalhes em [Hoffman et al., 2011].

Uma sessão TCP vai por vários estados durante a sua vida útil e o estado da sessão é controlado por um conjunto de seis flags booleanas dentro de cada pacote TCP, são elas: SYN, ACK, FIN, PSH, RST, URG. Uma Conexão TCP é estabelecida através de um processo denominado de handshake de três vias [Tanenbaum, 2003]. Para estabelecer uma conexão TCP, o cliente envia um pacote com a flag SYN, logo depois o servidor responde com um pacote com as flags SYN + ACK e por fim o cliente reponde com um pacote ACK. Feito isso, uma conexão TCP está iniciada. O fim de uma conexão TCP ocorre quando um lado envia um pacote com a flag FIN, o outro lado da conexão reconhece a FIN e termina de enviar seus dados e seguir com a FIN correspondente. O segundo FIN é reconhecido e a conexão é terminada. Para melhor entendimento, a figura 12 mostra quando uma conexão TCP está sendo estabelecida.

Figura 12: Conexão TCP sendo estabelecida [Hoffman et al., 2010]

Como algumas implementações TCP são vulneráveis à combinações com flags ile- gais, os hackers, muitas vezes, enviam pacotes TCP com combinações de flags ilegais. O teste deve determinar as circunstâncias em que os pacotes são ilegais. Um fragmento da gramática utilizada nos testes pode ser visualizada na Listagem 4.2. Esta gramática representa uma conexão TCP completa, com flags ruins injectados em sete posições.

Tanto o trabalho apresentado por [Hoffman and Yoo, 2005] quanto este [Hoffman et al., 2010] tem sido utilizado para testar inserção de pacotes com flags ilegais. No entanto, existem diferenças entre eles. No primeiro a conexão TCP continha

S ::= SEPARATOR BadFlags0 SYN BadFlags1 SYNACK BadFlags2 ACK1 BadFlags3 FINACK1 BadFlags4 FINACK2 BadFlags5 ACK2 BadFlags6;

SEPARATOR ::= ‘! ! ! ! ! ! ! ! !’;

SYN ::= ‘\n’ ‘SYN’ ‘SYN’ ‘ack’ ‘fin’ ‘psh’ ‘rst’ ‘urg’ ‘OUT’ ‘ACCEPT’; SYNACK ::= ‘\n’ ‘SYNACK’ ‘SYN’ ‘ACK’ ‘fin’ ‘psh’ ‘rst’ ‘urg’ ‘IN’ ‘

ACCEPT’;

ACK1 ::= ‘\n’ ‘ACK1’ ‘syn’ ‘ACK’ ‘fin’ ‘psh’ ‘rst’ ‘urg’ ‘OUT’ ‘ACCEPT ’;

FINACK1 ::= ‘\n’ ‘FINACK1’ ‘syn’ ‘ACK’ ‘FIN’ ‘psh’ ‘rst’ ‘urg’ ‘IN’ ‘ ACCEPT’;

FINACK2 ::= ‘\n’ ‘FINACK2’ ‘syn’ ‘ACK’ ‘FIN’ ‘psh’ ‘rst’ ‘urg’ ‘OUT’ ‘ ACCEPT’;

ACK2 ::= ‘\n’ ‘ACK2’ ‘syn’ ‘ACK’ ‘fin’ ‘psh’ ‘rst’ ‘urg’ ‘IN’ ‘ACCEPT’; BadFlags0 ::= BadFlag0;

BadFlag0 ::= ‘\n’ ‘badFlag0’ StaticBadFlags() ‘IN’ ‘DROP’; BadFlags1 ::= ‘\n’ ‘badFlag1’ Flag1 ‘IN’ ‘DROP’;

Flag1 ::= StaticBadFlags();

BadFlags2 ::= ‘\n’ ‘badFlag2’ Flag2 ‘IN’ ‘DROP’; Flag2 ::= StaticBadFlags();

BadFlags3 ::= ‘\n’ ‘badFlag3’ Flag3 ‘IN’ ‘DROP’; Flag3 ::= StaticBadFlags();

BadFlags4 ::= ‘\n’ ‘badFlag4’ Flag4 ‘IN’ ‘DROP’; Flag4 ::= StaticBadFlags();

BadFlags5 ::= ‘\n’ ‘badFlag5’ Flag5 ‘IN’ ‘DROP’; Flag5 ::= StaticBadFlags();

BadFlags6 ::= ‘\n’ ‘badFlag6’ Flag6 ‘IN’ ‘DROP’; Flag6 ::= StaticBadFlags();

Listagem 4.2: Gramática utilizada no teste de firewall [Hoffman et al., 2010]

apenas um único pacote com flags ruins, que incluia todas as combinações, produzindo cerca de 200 milhões de testes. Além disso, os testes foram gerados manualmente. No trabalho de [Hoffman et al., 2010] a ferramenta YouGen foi utilizada e as tags usadas para escolher livremente as combinações.