A Greylist do Turriz é uma lista de endereços IP que foram bloqueados pela firewall dos routers da Turriz que está disponível ao público na Internet.
Após uma primeira análise desta fonte de informação, podemos verificar que: a primeira linha é o cabeçalho e não tem interesse.
cada linha tem um registo que nos interessa;
usando o csv.DictReader, é possível aceder a cada um desses campos individualmente, pois este guarda os dados num dicionário do tipo {nome da coluna : valor da coluna na linha que é lida};
os dados de interesse na página são:
- Address – endereço IP de origem do ataque; -Country – código do país de origem do ataque; -Tags – tipos de classificação do ataque;
- ASN – autonomous system number (identificador único de cada rede na internet que pertence, por norma, ao ISP);
Na posse de todos estes dados, já podemos determinar que a função parse terá como objetivos:
fazer o pedido à pagina para receber a informação de todo o ficheiro CSV;
ler a resposta da página;
dividir a resposta em linhas, pois cada linha é um registo de interesse; para cada linha, chamar a função process.
Página 42 de 99
Por outro lado, podemos, também, verificar que a função process, que processa cada linha que a função parse retorna, terá como objetivo único tratar os dados e guardá-los segundo a Data Harmonization. Como tal, podemos afirmar que:
- o primeiro campo irá ser o “source.ip”; - o segundo campo irá ser o “source.asn”;
- o terceiro campo irá variar, dependendo da informação que o mesmo contém: se o valor do campo terminar em “scan” (por exemplo “http_scan”, o campo terá duas informações de interesse: o classification.type, que será “scanner”, e a protocol.application que, neste caso, seria “http”. No entanto, se o campo tiver o valor “proxy_scan”, este será um caso particular em que o
classification.type será “scanner” e não haverá protocol.application, pois
“proxy” não é um protocolo. Neste haverá o dado event_description.text, que terá o valor “proxy”.
se o valor do campo não terminar em “scan”, poderemos usar um dicionário para facilitar o processamento, associando o tipo de dados aos valores possíveis do campo a ser processado, conforme se apresenta na figura seguinte:
Página 43 de 99
- O quarto campo irá ser o “source.geo_cc”;
Na posse de todos estes dados, já temos condições suficientes para fazer um teste inicial.
Ao construirmos o teste com os passos acima descritos no estudo da fonte, podemos construi-lo com a estrutura da figura 12:
Neste caso, também não há a necessidade de dividir o teste nas funções parse e
process, pois a função parse diz respeito apenas ao pedido, à condição inicial
(r.status_code == 200) e ao ciclo que percorre cada linha do ficheiro CSV.
O restante código do teste diz respeito à função process, pois é apenas aqui que cada linha (o resultado da função parse) será processada em separado.
Após verificarmos que este teste está a funcionar corretamente e nos devolve os dados certos, podemos adaptá-lo à plataforma, ou seja, retirar os dicionários e substituir os mesmos por eventos.
Página 44 de 99
Após o teste ser adaptado à plataforma, procedemos à criação de um caso de teste. Para poder criar o caso de teste, precisamos de recolher alguns dados do ficheiro de teste antes de continuar, sendo essas as entradas e saídas de dados das funções parse e
process que podem ser acedidas através de prints dentro deste teste inicial.
Neste caso, para a função parse, como entrada temos todo o ficheiro CSV, ou seja, a resposta da página quando se faz o primeiro pedido para receber este ficheiro e, como saída, temos cada linha. Por outro lado, para a função process, como entrada temos, por exemplo, a linha de dados que é o resultado da função parse e, como saída, teremos os dados já tratados.
Ao dispor destes dados, podemos fazer o nosso caso de teste em que damos, às funções, os valores de entrada escolhidos e verificamos se os resultados são os esperados.
Página 45 de 99
O caso de teste terá o aspeto das figuras 13 e 14:
Ao ver a figura acima, podemos verificar que na função test_parse é chamada a função parse para uma resposta falsa da página, através do patch da função que irá receber a resposta da página para que, quando o bot correr, não faça um pedido à pagina e, em vez disso, crie um objeto falso que está presente no objeto mock_url. Neste caso, o objeto falso tem que ser construído com dois atributos essenciais: o status code e o valor de retorno da função de que se faz patch.
Página 46 de 99
Ao chamar a função parse com este mock_url, esta irá retornar uma linha e essa linha será comparada com o resultado esperado (presente na variável row): se forem iguais, o teste da função parse irá ser concluído com sucesso.
Para a função process, é usada a variável row como entrada e os dados de saída são comparados com os dados introduzidos pelo autor numa das funções disponíveis no módulo de unittest: a função assertEqual(). Se os resultados introduzidos pelo autor forem iguais aos resultados da função process, o teste da função process irá ser concluído com sucesso.
Após o caso de teste ser validado, o bot está pronto a ser testado numa cópia local, localizada na workstation do autor, das partes essenciais da plataforma, para garantir que o bot se integra e funciona corretamente dentro da mesma e é feito um pedido de
Git Push, ou seja, de submissão do plugin na plataforma, que será posteriormente aceite
pelo gestor do projeto.
Página 47 de 99