Testes de funcionamento - Resultados dos testes

4. Framework para deteção de intrusões em IoT

5.3. Resultados dos testes

5.3.1. Testes de funcionamento

Nesta secção será apresentada a reação do protótipo aos testes de funcionamento, cujo plano foi apresentado anteriormente, com o objetivo de validar a eficácia funcional da framework proposta.

Para tal, são mostrados e analisados os ficheiros JSON armazenados no módulo central do IDS e que contêm os registos dos fluxos de tráfego exportados pela sonda IDS. Estes ficheiros mostram a captura de pacotes de rede feito pela sonda IDS que, depois de os agregar em registos de fluxos de tráfego, os exporta para o módulo central do IDS.

Para além desses ficheiros, são também apresentados e analisados os ficheiros PCAP armazenados no encaminhador de periferia e que contêm as capturas dos pacotes de rede pertencente ao tráfego trocado entre a rede interna e a Internet, assim como, as comunicações entre a sonda e o módulo central do IDS.

Adicionalmente, temos os relatórios da aplicação IDS, que se encontram armazenados no módulo central do IDS, e que contêm os resultados das análises efetuadas aos registos dos fluxos de tráfego onde são classificados como normal ou anormal.

Por fim, apresentar-se-á o ficheiro de logs da aplicação IDS, que se encontra armazenado no módulo central do IDS, e que contém as mensagens de alerta de intrusões emitidas e armazenadas pela aplicação IDS através do protocolo syslog.

Para além destes ficheiros serão também utilizados os resultados de análises efetuadas com base em dados recolhidos durante os testes.

Teste de captura de pacotes de rede e consequente agregação e exportação de forma segura dos registos de fluxos de tráfego IP correspondentes

Com o resultado deste teste pretende-se validar o protótipo relativamente ao funcionamento da sonda IDS. Demonstra-se, inicialmente, o início do processo executado pela sonda IDS, isto é, o YAF. A Figura 19 e a Figura 21 apresentam extratos dos ficheiros PCAP resultantes da captura do tráfego efetuada no encaminhador de periferia. Estes extratos referem-se ao tráfego CoAP e dizem respeito à ligação entre o cliente e o servidor CoAP. Para além desses, existem também dados referentes ao processo de exportação dos registos de fluxos de tráfego efetuado pela sonda através do protocolo IPFIX sobre TLS.

Assim, depois de se iniciarem os dispositivos IoT que atuam como cliente e servidor CoAP, podemos constatar, através das capturas de tráfego de rede apresentadas na Figura 19, que estes se encontram a trocar mensagens GET com confirmação embutida.

Figura 19 - Captura de tráfego de mensagens GET CoAP

De seguida, iniciou-se a sonda IDS através da execução do YAF no encaminhador de periferia. O comando e respetiva saída são apresentados na Figura 20.

Figura 20 - Comando e saída do comando YAF executado na sonda IDS

Após os registos de fluxo de tráfego existentes na memória cache do YAF terem atingido os temporizadores (idle ou active) de timeout, estes são exportados para o módulo

#/usr/local/bin/yaf --in ens33 --live pfring --ipfix tcp --out 192.168.111.16 --ipfix-port 4740 --no-stats - -verbose --idle-timeout 60 --active-timeout 180 --flow-stats --mac --tls --tls-ca ca.crt --tls-cert yaf.crt --tls-key yaf.key

[2019-06-23 18:13:23] yaf starting

[2019-06-23 18:13:23] Opened PF_RING version v.7.3.0 [2019-06-23 18:13:23] Device RX channels: 1

[2019-06-23 18:13:23] running as root in --live mode, but not dropping privilege [2019-06-23 18:13:23] yaf: c005 (yaf_flow_stats), 0 (c005) [2019-06-23 18:13:23] yaf: c005 (yaf_flow_stats_rev), 1 (c015) [2019-06-23 18:13:23] yaf: c003 (yaf_tcp), 0 (c003) [2019-06-23 18:13:23] yaf: c003 (yaf_tcp_rev), 1 (c013) [2019-06-23 18:13:23] yaf: c004 (yaf_mac), 0 (c004) [2019-06-23 18:13:23] yaf: c009 (yaf_mptcp), 0 (c009) [2019-06-23 18:13:23] yaf: c008 (yaf_payload), 0 (c008) [2019-06-23 18:13:23] yaf: c008 (yaf_payload_rev), 1 (c018) [2019-06-23 18:13:38] adding new template?!?!!? b311 [2019-06-23 18:13:55] adding new template?!?!!? b341 [2019-06-23 18:16:24] Processed 2737 packets into 58 flows: [2019-06-23 18:16:24] Mean flow rate 0.32/s.

[2019-06-23 18:16:24] Mean packet rate 15.08/s. [2019-06-23 18:16:24] Virtual bandwidth 0.2523 Mbps. [2019-06-23 18:16:24] Maximum flow table size 16. [2019-06-23 18:16:24] 12 flush events.

[2019-06-23 18:16:24] 3 asymmetric/unidirectional flows detected (5.17%) [2019-06-23 18:16:24] YAF read 2781 total packets

[2019-06-23 18:16:24] Assembled 0 fragments into 0 packets:

[2019-06-23 18:16:24] Expired 0 incomplete fragmented packets. (0.00%) [2019-06-23 18:16:24] Maximum fragment table size 0.

[2019-06-23 18:16:24] Rejected 44 packets during decode: (1.58%)

[2019-06-23 18:16:24] 44 due to unsupported/rejected packet type: (1.58%) [2019-06-23 18:16:24] 44 ARP packets. (1.58%)

[2019-06-23 18:16:24] yaf terminating #

central do IDS recorrendo ao protocolo IPFIX sobre TLS, por forma a que sejam recolhidos, armazenados e analisados. Na Figura 21 é exibida a captura de pacotes de rede referentes à troca de mensagens CoAP, entre o cliente e o servidor, assim como os pacotes relativos aos registos de fluxos de tráfego exportados pela sonda para o módulo central do IDS através do protocolo IPFIX.

Figura 21 - Captura de tráfego CoAP e IPFIX sobre TLS

Com base nos resultados apresentados, verifica-se que a sonda IDS consegue capturar e agregar as informações das comunicações em fluxos de tráfego. Tal como esperado, esses registos dos fluxos de tráfego são exportados para o módulo central do IDS utilizando o protocolo IPFIX sobre TLS.

Teste de receção, descodificação e armazenamento, por parte do módulo central do IDS, dos registos de fluxos de tráfego IP transmitidos através do IPFIX

Com o resultado deste teste pretende-se validar o protótipo relativamente ao funcionamento do módulo central do IDS, no que diz respeito ao processo de recolha, descodificação e armazenamento dos registos dos fluxos. Apresenta-se, então, a demonstração do funcionamento do processo de recolha, descodificação e armazenamento dos registos de fluxos de tráfego, isto é, as tarefas executadas pelo super_mediator. A Figura 22 revela extratos dos ficheiros PCAP resultantes da captura do tráfego efetuada no encaminhador de

periferia. Estes extratos dizem respeito ao tráfego CoAP relativo à ligação entre o cliente e o servidor CoAP. A Figura 25 e a Figura 26 mostram printscreens do conteúdo da diretoria onde são armazenados os registos dos fluxos recolhidos pelo módulo central do IDS, assim como do conteúdo de um dos ficheiros JSON contendo registos de fluxos de tráfego, respetivamente.

Portanto, depois de se iniciarem os dispositivos IoT que atuam como cliente e servidor CoAP, podemos verificar através das capturas de tráfego de rede apresentadas na Figura 22 que trocam mensagens GET com confirmação embutida.

Figura 22 - Captura de tráfego de mensagens GET CoAP

De seguida, foi iniciada a sonda IDS através da execução do YAF no encaminhador de periferia. O comando e respetiva saída é apresentada na Figura 23.

Seguidamente, foi iniciado o processo do módulo central do IDS através da execução do

Figura 23 - Comando e saída do comando YAF executado na sonda IDS

Figura 24 - Comando e saída do comando super_mediator executado no módulo central do IDS

#super_mediator --in 192.168.111.16 --ipfix-input tcp --ipfix-port 4740 --out /tmp/idsflows/yaf --rotate 240 --output-mode json --verbose

[2019-06-23 19:11:23] super_mediator starting [2019-06-23 19:11:23] E1: Exporter Active.

[2019-06-23 19:11:23] Initialization Successful, starting...

[2019-06-23 19:11:23] Starting Listener for C1 on 192.168.111.16:4738 [2019-06-23 19:11:23] running as root in --live mode, but not dropping privilege

[2019-06-23 19:11:23] ACTIVE Collector C1: 3468 flows, 0 other flows, 0 stats, 0 filtered, 1 connections [2019-06-23 19:11:23] Exporter E1: 3468 records, 0 stats, 0.0925 Mbps, 1145.12 bytes per record

[2019-06-23 19:13:17] SM: Uptime: 0d:0h:5m:0s, Total Flows: 3468, Filtered: 0, Stats: 0, DNS: 0, Other: 0, UDP-uniflows: 0

[2019-06-23 19:13:17] INACTIVE Collector C1: 3585 flows, 0 other flows, 0 stats, 0 filtered, 1 connections [2019-06-23 19:13:17] Exporter E1: 3585 records, 0 stats, 0.0905 Mbps, 1265.38 bytes per record [2019-06-23 19:13:17] E1: Closing File /home/leo/flows/yaf.20190623191317.json

[2019-06-23 19:13:17] SM: Uptime: 0d:0h:6m:41s, Total Flows: 3585, Filtered: 0, Stats: 0, DNS: 0, Other: 0, UDP-uniflows: 0

[2019-06-23 19:13:17] super_mediator Terminating #

[2019-06-23 18:13:23] yaf starting

[2019-06-23 18:13:23] Opened PF_RING version v.7.3.0 [2019-06-23 18:13:23] Device RX channels: 1

[2019-06-23 18:16:24] Mean packet rate 15.08/s. [2019-06-23 18:16:24] Virtual bandwidth 0.2523 Mbps. [2019-06-23 18:16:24] Maximum flow table size 16. [2019-06-23 18:16:24] 12 flush events.

[2019-06-23 18:16:24] 3 asymmetric/unidirectional flows detected (5.17%) [2019-06-23 18:16:24] YAF read 2781 total packets

[2019-06-23 18:16:24] Assembled 0 fragments into 0 packets:

[2019-06-23 18:16:24] Expired 0 incomplete fragmented packets. (0.00%) [2019-06-23 18:16:24] Maximum fragment table size 0.

[2019-06-23 18:16:24] Rejected 44 packets during decode: (1.58%)

[2019-06-23 18:16:24] 44 due to unsupported/rejected packet type: (1.58%) [2019-06-23 18:16:24] 44 ARP packets. (1.58%)

[2019-06-23 18:16:24] yaf terminating #

Após os registos de fluxo de tráfego terem sido exportados pela sonda para o módulo central do IDS, recorrendo ao protocolo IPFIX, é possível verificar que vão surgir novos ficheiros no formato JSON contendo os registos dos fluxos que foram recebidos, descodificados e armazenados no módulo central do IDS. De modo a demonstrar a criação desses ficheiros, encontra-se ilustrado na Figura 25 o conteúdo da diretoria onde são armazenados os ficheiros JSON com os registos dos fluxos de tráfego recebidos.

Figura 25 - Conteúdo da diretoria de armazenamento dos registos de fluxos recebidos

Os ficheiros recebidos, descodificados e armazenados contêm registos de fluxos de tráfego exportados pela sonda IDS através do processo YAF. Na Figura 26 pode ver-se o conteúdo de um dos ficheiros armazenados.

Figura 26 - Conteúdo de um ficheiro JSON com registos de fluxos recebidos

Tendo em conta os resultados deste teste, verifica-se que o módulo central do IDS consegue receber, descodificar e armazenar os registos de fluxos de tráfego exportados pela sonda IDS. Tal como esperado, e à medida que são recebidos pelo super_mediator, esses registos dos fluxos de tráfego são armazenados em ficheiros no formato JSON e são colocados numa diretoria local do módulo central do IDS para posterior análise de intrusões.

Teste da análise dos registos de fluxos de tráfego IP armazenados no módulo central do IDS, por forma a detetar anomalias nas comunicações IoT

Este conjunto de testes de análise aos registos de fluxos de tráfego tem como objetivo validar e verificar a capacidade de deteção de intrusões do IDS proposto. Estes testes consideraram as especificações, apresentadas no subcapítulo 5.1.2, que assentam em valores, ou gama de valores, que os IE analisados têm que ter para que um fluxo seja considerado normal.

Por conseguinte, após o processo de exportação dos registos de fluxos de tráfego efetuado pela sonda, o módulo central do IDS é responsável pela receção, descodificação e armazenamento desses mesmos registos em ficheiros no formato JSON. Para além disso, o módulo central do IDS tem outras funções, sendo uma delas detetar intrusões recorrendo a uma aplicação IDS. Essa aplicação IDS faz a análise dos registos de fluxos de tráfego armazenados em ficheiros no formato JSON e tem como critérios as especificações enunciadas no subcapítulo 5.1.2.

Tal como definido no plano de testes apresentado anteriormente, este conjunto de testes está dividido em duas situações: (i) análise dos registos de fluxos de tráfego de comunicações IoT normais e (ii) análise dos registos de fluxos de tráfego de comunicações IoT anormais ou maliciosos.

Considerando a primeira situação, o teste pretende demonstrar e validar a capacidade que a solução proposta tem na função de deteção de intrusões, distinguindo os registos dos fluxos de tráfego anormais dos normais.

Para desenvolver testes para a primeira situação, foram utilizados e selecionados registos de fluxos de tráfego armazenados no módulo central do IDS. A seleção desses registos foi efetuada de forma a obter um conjunto de registos de fluxos de tráfego com comportamento normal. A seleção foi efetuada com base nas identificações dos dispositivos IoT que integram o protótipo e que se sabe que efetuam comunicações normais. Depois de selecionados, e independentemente de serem CoAP ou MQTT, esses registos de fluxos de tráfego foram analisados pela aplicação IDS, de modo a que se identifiquem quais os registos de fluxos que são normais e os que, mesmo não sendo, são identificados como anormais.

Tal como foram apresentadas as especificações no subcapítulo 5.1.2, os resultados destes testes são apresentados por protocolo aplicacional, isto é, primeiro são revelados os resultados

para testes ao protocolo CoAP e, de seguida, os referentes ao protocolo MQTT. Em ambos os casos, o procedimento é comum.

Desta feita, primeiro executa-se a aplicação e, de seguida, recolhem-se os resultados da aplicação IDS através do relatório criado pela mesma. Conforme se pode verificar no exemplo mostrado na Figura 27, após a análise de um ficheiro com registos de fluxos de tráfego, a aplicação IDS mostra na saída da aplicação um resumo da análise efetuada.

Figura 27 - Comando e saída da aplicação IDS executado no módulo central

Para além dessa saída para a consola do SO, é criado um ficheiro de texto com um relatório, discriminando os resultados da análise feita aos registos de fluxo de tráfego e terminando com os dados resumidos das análises efetuadas, conforme se pode verificar no exemplo mostrado na Figura 28.

Figura 28 - Conteúdo de um relatório da análise da aplicação IDS

Desta feita, os resultados da análise efetuada pela aplicação IDS aos registos de fluxos de tráfego CoAP normais encontram-se separados em duas fases. Na primeira fase, os resultados estão organizados por tipo de mensagem (GET, POST e GET Observe), devido à utilização de um menor número de amostras para uma verificação das especificações. Em relação à segunda fase, os resultados remetem para a análise dos registos de fluxos de tráfego dos três tipos de mensagem CoAP que se encontram num dataset capaz de resumir o tráfego

$ python3 main.py IS NORMAL IS ATTACK IS NORMAL IS NORMAL … IS NORMAL IS NORMAL IS ATTACK IS NORMAL

gerado pelo protótipo após sete dias em operação, sem qualquer introdução de tráfego anómalo, garantindo, assim, que apenas se validam comunicações normais e também com uma maior diversidade.

De seguida, são apresentados, através do uso de tabelas, os resultados para cada uma das fases dos testes da análise de registos de fluxos de tráfego CoAP. Nelas serão discriminados o tipo de mensagem CoAP a que correspondem os registos de fluxos analisados, o número de registos de fluxos de tráfego que compõem o dataset utilizado, o número de registos de fluxos de tráfego CoAP que existem no dataset utilizado, o número de registos de fluxos de tráfego que foram classificados como normais (RFN), o número de registos de fluxos de tráfego que foram classificados como anormais (RFA), a taxa de deteção (TD) para o teste efetuado, a taxa de falsos positivos (FP) e a taxa de verdadeiros positivos (TP).

Os resultados para a primeira fase dos testes de análise de registos de fluxos de tráfego CoAP normais apresentam-se na Tabela 15.

Tabela 15 - Resultados da deteção de fluxos normais CoAP por mensagem

Tipo de mensagem CoAP

Número de fluxos do dataset

Número de

fluxos CoAP RFN RFA TD FP TP

GET 100 100 100 0 100% 0% 100%

POST 100 100 100 0 100% 0% 100%

GET Observe 100 100 100 0 100% 0% 100%

Por outro lado, os resultados para a segunda fase dos testes de análise de registos de fluxos de tráfego CoAP normais apresentam-se na Tabela 16.

Tabela 16 - Resultados da deteção de fluxos normais CoAP

Tipo de mensagem CoAP

Número de fluxos do dataset

Número de

fluxos CoAP RFN RFA TD FP TP

GET/POST/GET

Obs. 17260 1153 1153 0 100% 0% 100%

Relativamente aos resultados da análise efetuada pela aplicação IDS aos registos de fluxos de tráfego MQTT normais, podemos verificar que se encontram separados em duas fases. Na primeira fase, os resultados estão organizados por tipo de mensagem utilizada pelos anunciantes e subscritores (publish e subscribe), atendendo à utilização de um menor número de amostras para uma verificação das especificações. Em relação à segunda fase, os resultados apresentam o resultado da análise dos registos de fluxos de tráfego dos dois tipos

de mensagem MQTT que se encontram num dataset resumindo o tráfego gerado pelo protótipo após sete dias em operação, sem qualquer introdução de tráfego anómalo, garantindo, assim, que apenas se validam comunicações normais e com maior diversidade. Por conseguinte, demonstrar-se-ão, através de tabelas, os resultados para cada uma das fases dos testes da análise de registos de fluxos de tráfego MQTT normais. Nelas serão retratados o tipo de mensagem MQTT que correspondem os registos de fluxos analisados, o número de registos de fluxos de tráfego que compõem o dataset utilizado, o número de registos de fluxos de tráfego MQTT que existem no dataset utilizado, o número de registos de fluxos de tráfego que foram classificados como normais (RFN), o número de registos de fluxos de tráfego que foram classificados como anormais (RFA), a taxa de deteção (TD) para o teste efetuado, a taxa de falsos positivos (FP) e a taxa de verdadeiros positivos (TP).

Os resultados da primeira fase dos testes de análise de registos de fluxos de tráfego MQTT normais apresentam-se na Tabela 17.

Tabela 17 - Resultados da deteção de fluxos normais MQTT por mensagem

Tipo mensagem MQTT Número de fluxos do dataset Número de fluxos MQTT RFN RFA TD FP TP PUBLISH 100 100 100 0 100% 0% 100% SUBSCRIBE 100 100 100 0 100% 0% 100%

Os resultados para a segunda fase dos testes de análise de registos de fluxos de tráfego MQTT normais apresentam-se na Tabela 18.

Tabela 18 - Resultados da deteção de fluxos normais MQTT

Tipo mensagem MQTT Número de fluxos do dataset Número de fluxos MQTT RFN RFA TD FP TP PUBLISH/ SUBSCRIBE 17260 2321 2321 0 100% 0% 100%

Considerando agora a segunda situação anunciada, o teste pretende demonstrar e validar a capacidade que o solução proposta tem na função de deteção de intrusões, distinguindo os registos dos fluxos de tráfego normais dos anormais.

Por forma a desenvolver os testes para a segunda situação, foram utilizados e selecionados registos de fluxos de tráfego armazenados no módulo central do IDS. A seleção desses registos foi coletada de modo a obter um conjunto de registos de fluxos de tráfego com

comportamento anormal. Foi efetuada com base nas identificações do dispositivo IoT que integram o protótipo e que efetua comunicações anormais. Essas comunicações anormais são originadas através da utilização de ferramentas (nmap e hping) e aplicações (clientes CoAP e MQTT) que pretendem gerar comunicações anormais como net scan, inundação de pedidos válidos e inválidos CoAP e MQTT, DoS e DDoS. Depois de selecionados e, independentemente de serem CoAP ou MQTT, esses registos de fluxos de tráfego foram analisados pela aplicação IDS, para identificar os registos de fluxos anormais e os que, mesmo não o sendo, são identificados como normais.

Tal como foram expostas as especificações no subcapítulo 5.1.2, os resultados destes testes são apresentados por protocolo aplicacional, isto é, primeiro são apresentados os resultados para testes ao protocolo CoAP e, de seguida, os referentes ao protocolo MQTT. De salientar que, em ambos os casos, o procedimento é comum.

Primeiro executa-se a aplicação e, de seguida, recolhem-se os resultados da aplicação IDS através do relatório criado pela mesma. Conforme se pode verificar no exemplo mostrado na Figura 29, após a execução da aplicação IDS, é apresentado na saída da aplicação um resumo da análise efetuada.

Figura 29 - Comando e saída da aplicação IDS executado no módulo central

Para além dessa saída para a consola do SO, é criado um ficheiro de texto com um relatório da análise, discriminando o resultado da análise feita aos registos de fluxo de tráfego e terminando com os dados resumidos das análises, conforme se pode verificar no exemplo mostrado na Figura 30. $ python3 main.py IS ATTACK IS ATTACK IS ATTACK … IS ATTACK IS ATTACK IS ATTACK IS ATTACK IS ATTACK

Figura 30 - Conteúdo de um relatório da análise da aplicação IDS

Posto isto, os resultados da análise efetuada pela aplicação IDS aos registos de fluxos de tráfego CoAP anormais encontram-se separados em duas fases. Na primeira fase, os resultados estão organizados por tipo de anomalia (net scan, inundação de pedidos válidos e inválidos CoAP, DoS e DDoS) devido à utilização de um menor número de amostras para uma verificação das especificações. Em relação à segunda fase, os resultados apresentam o resultado da análise dos registos de fluxos de tráfego dos vários tipos de anomalias CoAP que se encontram num dataset que sintetiza o tráfego gerado pelo protótipo após sete dias em operação com a introdução de tráfego anómalo, garantindo assim que se validam comunicações normais e anormais com maior diversidade.

Abaixo, são exibidos, através do uso de tabelas, os resultados para cada uma das fases dos testes da análise de registos de fluxos de tráfego CoAP. Nelas serão discriminados o tipo de

No documento Sistema de deteção de intrusões para a Internet das Coisas (páginas 153-183)