Uma Abordagem para Classificação Online de Tráfego TCP

Uma Abordagem para Classificação Online de Tráfego TCP Silas Santiago Lopes Pereira Departamento de Estatística e Computação UECE - Universidade Estadual do Ceará Fortaleza - Ceará - Brasil Email: silas@larces.uece.br José Everardo Bessa Maia Departamento de Estatística e Computação UECE - Universidade Estadual do Ceará Fortaleza - Ceará - Brasil Email: jmaia@larces.uece.br Jorge Luiz de Castro e Silva Departamento de Estatística e Computação UECE - Universidade Estadual do Ceará Fortaleza - Ceará - Brasil Email: jlcs@larces.uece.br Resumo Este trabalho apresenta o projeto e implementação de um monitor classificador de tráfego TCP. O monitor classificador funciona como um pipeline composto de três módulos: captura e pré-processamento, remontagem dos fluxos e classificação. Os módulos são construídos como processos concorrentes com interfaces de dados bem definidas entre eles de forma que qualquer dos módulos pode ser melhorado e atualizado independentemente. O atraso médio de entrega é de 40.23 segundos, aproximadamente. Para o módulo de classificação, são comparados os desempenhos dos classificadores K-Nearest Neighbor (KNN) e Naïve Bayes (NB) para validar nossa abordagem. I. INTRODUÇÃO Em diversas tarefas de administração da rede, é útil conhecer o perfil do tráfego Internet. Aprovisionamento de capacidades, gerenciamento de banda e planejamento podem se beneficiar da classificação off-line por classe de aplicações. Por outro lado, tarefas como detecção de ameaças ou de intrusão são mais eficientes se realizadas em tempo real. O objetivo de várias abordagens baseadas em medição é avaliar e entender o comportamento e características da Internet, tais como projeção de tráfego, inferência de topologia, e identificação e caracterização de aplicações [1]. A função de monitoramento e classificação deve constituir a base de qualquer plataforma de gerenciamento de redes atual. No entanto, o projeto e a construção de um monitor classificador de tráfego é uma tarefa desafiadora por várias razões. O tráfego Internet está em constante mudança, o que contribui para dificultar a caracterização da estrutura e do comportamento da rede. Um exemplo disso é a expansão das redes Peer-to-Peer (P2P) e o crescimento do tráfego de Voz sobre IP (VoIP) [2]. Jogos online, P2P e VoIP aumentam a cada dia sua participação percentual no tráfego total da rede. Este trabalho descreve a implementação de um monitor classificador de tráfego Internet online em tempo quase real para uso em redes corporativas, e avalia diferentes métodos de aprendizado de máquina (AM) para classificação de tráfego de rede. O monitor classificador é baseado no conceito de fluxo bidirecional. Isso quer dizer que o objeto fundamental a ser classificado em um determinado padrão é o fluxo de tráfego. Um fluxo é identificado por um ou mais pacotes entre um par de hosts e é definido pela quíntupla: endereços IP de origem e de destino, portas de origem e de destino, e tipo de protocolo (ICMP, TCP, UDP) [3]. O Restante deste trabalho está organizado da seguinte forma. Os trabalhos relevantes relacionados são revisados em cada seção. A seção II descreve o projeto e a implementação do monitor classificador. A seção III apresenta e discute os resultados da avaliação de desempenho. A seção IV finaliza com algumas conclusões. II. O MONITOR CLASSIFICADOR O monitor funciona como um pipeline de três estágios, sendo um módulo de coleta e pré-processamento dos pacotes, um módulo de remontagem dos fluxos e um módulo de cálculo dos atributos e classificação. Para efeito do pipeline, o tempo é dividido em intervalos de 30s. Após iniciado o processo, três processos paralelos estão em execução em cada intervalo: uma coleta de pacotes, a remontagem dos fluxos referentes à coleta do intervalo anterior, e a classificação dos fluxos referente à coleta ocorrida com dois intervalos de atraso. Um processo auxiliar em paralelo encarrega-se do encerramento de conexões antigas, no intuito de reduzir o consumo de processamento de memória durante a remontagem. Com essa abordagem, o tempo médio de resposta do monitor classificador é de 40.23s. Graças à operação em pipeline, entretanto, o monitor entrega uma atualização a cada 30s. Essa medição de tempo é realizada pela verificação contínua da diferença dos valores de timestamp do primeiro e último pacotes que chegaram em um certo intervalo de coleta. Em resumo, o monitor trabalha com um quantum de 30s de tráfego e com um atraso de 10.23s na remontagem de fluxos, extração de atributos e rotulação. Este foi o menor valor atingido na implementação atual. A figura 1 exibe a estrutura do monitor classificador proposto. As principais tarefas são: coleta online dos pacotes provenientes de algum ponto de rede, pré-processamento para

Além disso, apresentam-se os principais trabalhos relacionados sobre o problema da remontagem e a política de remontagem adotada. Finalmente, as técnicas de aprendizado de máquina supervisionado utilizadas neste trabalho são apresentadas. Figura 1. Diagrama de bloco do monitor classificador remontagem dos fluxos, extração e seleção dos atributos estatísticos, rotulação dos fluxos a partir da análise de payload dos pacotes ou por método baseado em portas, treinamento com alguma técnica de aprendizado supervisionado e classificação das novas instâncias, a partir do modelo de AM construído sobre os dados de treinamento. O monitor classificador realiza continuamente a captura do tráfego de pacotes e possui dois fluxos de processamento de informação. Na fase de treinamento, os pacotes coletados são submetidos a um processo de remontagem, o qual associa cada pacote a seu respectivo fluxo. Outro processo extrai informações estatísticas derivadas a partir do cabeçalho dos pacotes, seleciona os atributos mais relevantes por algum algoritmo de seleção de atributos, e rotula o fluxo a partir do método baseado em portas conhecidas. Então, os fluxos gerados, os quais são dispostos em uma representação espacial (cada stream de dados corresponde a uma instância com um conjunto de características e um atributo classe), são usados para treinar a técnica de classificação supervisionada selecionada. Na fase de avaliação, os fluxos não rotulados obtidos na coleta, remontagem e extração de atributos, são finalmente avaliados pelo classificador. O monitor foi desenvolvido inteiramente em Python, o qual é uma linguagem de programação interpretada e de rápida prototipagem [4]. A simulação de coleta online é realizada a partir da leitura e processamento seqüencial de cada pacote contido em um arquivo de traço. O monitor também adota um dado timeout para coleta e apresentação dos resultados. A justificativa para implementação de um algoritmo de remontagem de fluxo, dado a existência de diversas ferramentas e bibliotecas que alcançam esse objetivo, tais como libnids [5], TcpTrace [6], e WireShark [7], é a possibilidade de avaliar diferentes abordagens para classificação de subfluxos, como mencionado em [8]. Além disso, possibilita-se a avaliação de abordagens distintas para remontagem de streams TCP, como em [9], as quais são fundamentais no desenvolvimento de um sistema de classificação de tráfego em alta velocidade. As subseções seguintes descrevem as características relevantes do monitor classificador. Inicialmente, as fases de captura e pré-processamento de pacotes são introduzidas, as quais constituem as etapas iniciais do monitor. Em seguida, são apresentados os conceitos relacionados à remontagem de stream de dados e o princípio do registro recentemente acessado em primeiro lugar, aplicado em nossa abordagem. A. Captura e Pré-processamento de Pacotes A captura do tráfego em pacotes, seguida do processamento e visualização dos dados é uma demanda comum nas tarefas de monitoramento de volume ou supervisão de tráfego. Em forênsica de rede, esta tarefa é bem mais delicada e requer maior confiabilidade. Em forênsica de rede, pacotes são capturados e analisados em um estágio tardio [10]. Captura de pacotes possui maior granularidade que exportações de dados NetFlow [11]. No que tange a análise de traços de rede, é exigível que se tenha uma ferramenta de trabalho eficiente que seja capaz de reconstruir os traços de rede. Portanto, é essencial que o processo de coleta de pacotes possa capturar pacotes completos de modo que a stream seja remontada corretamente. A biblioteca libpcap [12] provê dois tamanhos de pacotes, os quais são, respectivamente, o tamanho do pacote emitido inicialmente, len, e o tamanho do pacote efetivamente capturado, caplen. Uma vez que len caplen, isto implica que o pacote não foi corretamente capturado. Pacotes incompletos aplicados no processo de remontagem causam erros não corretivos devido a ausência de informação capturada e, por esta razão, não são considerados pelo monitor. Além disso, o monitor apenas considera pacotes TCP com valores de porta menores ou iguais a 1023, relativo a aplicações padrão, para as quais a IANA (Internet Assigned Numbers Authority) [13], ou Autoridade para Atribuição de Números da Internet, determina as portas bem conhecidas de 0 a 1023 [14]. Nós observamos que o tempo total necessário para realização da rotulação e extração de características é da ordem de poucos segundos. Deste modo, o gargalo de desempenho encontrase no processo de remontagem de stream TCP, detalhado na próxima subseção. B. Remontagem de Fluxo Uma função de remontagem associa um pacote TCP com sua respectiva stream. O propósito de tal função é recuperar o estado inicial, emitido pelo remetente, a partir dos pacotes TCP capturados [15]. Dado que, durante a transmissão de pacotes, os mesmos podem ser entregues fora de ordem, perdidos ou corrompidos, a remontagem TCP é um processo não trivial. É primordial que o processo de remontagem, o qual é aplicável a uma diversidade de sistemas de análise de tráfego de rede, tais como detecção e prevenção de intrusão, inspeção de conteúdo e forense de rede, seja executado o mais rápido possível, de modo a suportar altas taxas de tráfego, especialmente em redes de alta velocidade [16]. Em [15], embora a RFC 973 [17] apresente a especificação padrão do protocolo, há diferentes implementações, o que faz da remontagem TCP uma difícil tarefa. Diferentes ferramentas de remontagem detêm suas próprias especificações sobre o conceito de stream. Por exemplo, a ferramenta Tcpflow vincula

uma tupla com uma stream, ao passo que a ferramenta Tcptrace associa uma sessão a uma dada stream. As ferramentas Tcptrace e Tcpflow agrupam os dados enviados em cada sentido da transmissão em streams distintas. Em uma stream gerada pela ferramenta WireShark, os dados oriundos do emissor e do receptor são agrupados na mesma stream. Uma sessão TCP é identificada por um conjunto de pacotes TCP com mesma quádrupla (endereço IP de origem, porta de origem, endereço IP de destino, porta de destino) e delimitada pelos pacotes que caracterizam o início e o término de uma conexão TCP, dado que pode haver recorrências desse conjunto de informações no tráfego de rede. Uma sessão TCP inicia-se com uma fase de estabelecimento de conexão e termina com uma fase de encerramento de conexão, como descrito na RFC 793. Cada sessão TCP está relacionada a uma stream de dados, de modo que pode haver múltiplas sessões por fluxo [15]. C. Rotulação Rotulação de fluxos é um passo necessário para treinamento e posterior avaliação dos classificadores. Embora a utilização de método baseado em portas para rotulação de fluxos de tráfego pode introduzir erros devido à sua crescente ineficácia, dado que fluxos incorretamente rotulados podem aumentar o impacto de overfitting do modelo de classificação, a existência de alguns valores imprecisos no conjuntos de dados é um problema comum de aprendizado de máquina e um bom esquema de AM deve possuir a habilidade de lidar com esta situação [18]. Em [16], os autores apresentam um mecanismo eficiente de remontagem de stream TCP para processamento em tempo real do tráfego de rede em altas velocidades. O mecanismo utiliza o princípio do registro recentemente acessado em primeiro lugar para reduzir o custo da busca de uma conexão para a chegada de cada pacote ao sistema. Além disso, para aprimorar o processo de busca, o sistema mantém as conexões TCP estabelecidas e não estabelecidas em estruturas de dados diferentes. Resultados experimentais baseados em um tráfego de rede capturado em um típico gateway gigabit mostraram que, em comparação com o mecanismo de remontagem tradicional, a política proposta revelou-se eficiente e capaz de atender ao requisito de propriedade de tempo real em sistemas de análise de tráfego em redes de alta velocidade. Em [19], apresenta-se um mecanismo de remontagem de stream TCP projetado e implementado para um sistema de detecção de intrusão baseado em rede. O sistema recebe pacotes individuais da rede e executa a detecção de assinaturas a partir do payload. A abordagem é descrita da seguinte forma: Primeiramente, o sistema associa a cada pacote recebido à sua conexão TCP correspondente, com base na quádrupla formada pelos endereços IP e portas de origem e de destino. Em seguida, a partir da verificação do número de seqüência do pacote, o sistema determina se este é o próximo pacote esperado pela conexão. Caso afirmativo, o pacote é enviado para detecção de assinaturas. Senão, o pacote está fora de ordem e é armazenado em um buffer referente a stream correspondente. Após a detecção de assinaturas inicial, se o pacote não está completo, este é descartado e a conexão inteira correspondente é removida da tabela hash na qual as conexões são mantidas. Caso contrário, este é encaminhado para o host pretendido. Este trabalho utiliza o mesmo conceito de stream TCP apresentado em [15] e o princípio do registro recentemente acessado em primeiro lugar, detalhado em [16]. A estrutura de dados utilizada para armazenamento dos registros de conexões é uma lista simples, sendo que conexões estabelecidas e não estabelecidas são armazenadas em listas separadas. Baseado no mecanismo de buffer de conexões incipientes, detalhado em [16], em que todos os registros de conexão são divididos em duas partes (um conjunto de registros de conexões não estabelecidas e outro que gerencia as conexões estabelecidas), o sistema busca na lista de registros de conexões não iniciadas (LRCNI) para os pacotes com flag SYN ativo, e procura na lista de registros de conexões iniciadas (LRCI) para os outros pacotes. Tal mecanismo pode significativamente reduzir o tempo de busca [16]. A política de remontagem adotada foi baseada no mecanismo proposto em [19] para remontagem de sessão TCP e no princípio do registro recentemente acessado em primeiro lugar [16], validada experimentalmente com as ferramentas Tcptrace,Tcpflow, e WireShark. Para cada pacote TCP recebido, o sistema verifica se este contém o flag SYN ativo. Caso afirmativo, o sistema busca a conexão correspondente na LRCNI. Se o registro é valido, o pacote é inserido na lista de pacotes associados a esta conexão. Senão, uma nova conexão é criada para este pacote. Se o pacote não contém o flag SYN, o sistema busca na LRCI pela conexão associada. Se o registro é válido, o pacote é associado a essa conexão. Caso seja inválido, verifica-se a existência da conexão na LRCNI. Caso negativo, o pacote é descartado. Senão, a conexão é removida da LRCNI, inserida em LRCI e por fim, o pacote é adicionado. Se o pacote contém os flags FIN ou RST, a conexão é encerrada. D. Classificação Classificação de tráfego Internet em tempo real possibilita a solução de difíceis problemas de gerência de rede por provedores de serviço de Internet e seus fornecedores de equipamentos. Operadores de rede, especialmente em redes de alta velocidade, precisam ter conhecimento sobre o tráfego fluindo na rede a fim de reagir rapidamente em apoio a diferentes metas de negócio [20]. Em [18], avalia-se a efetividade de técnicas de AM para o problema de classificação de tráfego em tempo real usando atributos estatísticos derivados dos pacotes iniciais de cada fluxo. Os autores utilizaram o método baseado em portas para rotulação dos fluxos em classes de aplicação. Os traços de tráfego utilizados são anonimizados por questão de privacidade, o que impossibilita a inferência das aplicações que geraram os fluxos. Embora tal abordagem possa conseqüentemente introduzir fluxos incorretamente rotulados, os autores argumentam que, para as portas estudadas, a percentagem de instâncias de fluxo não rotuladas é baixa e a maior parte do tráfego pertence a aplicações padrão. Os resultados obtidos

mostraram que a classificação com árvores de decisão obteve maior precisão e desempenho em relação aos outros classificadores comparados. Além disso, classificadores baseados em subfluxos podem atingir altos valores de precisão enquanto reduzem a complexidade computacional. A abordagem apresentada em nosso trabalho usa traços reais na avaliação dos métodos de aprendizado de máquina (AM) supervisionado MLP e KNN para classificação de tráfego Internet a partir das informações estatísticas derivadas unicamente do cabeçalho dos pacotes. Os recursos providos pela ferramenta Weka (Waikato Environment for Knowledge Analysis) [21], esta dispõe de uma coleção de algoritmos de aprendizagem de máquina para resolução de problemas de Data Mining, foram utilizados para treinamento e avaliação dos classificadores. 1) KNN: Dentre os diversos métodos estatísticos supervisionados para reconhecimento de padrões, a técnica Nearest Neighbor (NN) é a que obtém melhores resultados, sem a necessidade de suposições à priori sobre as distribuições dos exemplos de treinamento [22]. O algoritmo parte do princípio que todas as instâncias correspondem a pontos em um espaço n-dimensional R n. Uma nova instância X = x 1, x 2,..., x n, na qual x 1, x 2,..., x n são os atributos correspondentes, é classificada calculando-se sua distância euclidiana às instâncias de treinamento, e então categorizada com o rótulo da instância de treinamento mais próxima [23]. O classificador KNN estende essa ideia através da seleção dos k vizinhos mais próximos e classificação da nova instância com a classe mais frequente entre eles [22]. A distância euclidiana entre duas instâncias X e Y é definida na expressão abaixo, onde x k e y k denotam respectivamente os valores para o k-ésimo atributo das instâncias X e Y : d(x Y ) = n (x 2 k y 2 k) 2 (1) k Para a execução do classificador KNN, o monitor gera um arquivo contendo as instâncias de fluxo de tráfego em formato compatível com o Weka. Em seguida, o sistema executa a rotina weka.classifiers.lazy.ibk, passando como parâmetros o número K de vizinhos mais próximos e o arquivo com os dados de treinamento e avaliação. 2) Naïve Bayes: O classificador NB é uma técnica simples que pode ser aplicada ao problema de classificação de tráfego Internet [24]. Uma descrição mais detalhada desse método pode ser encontrada em [25]. Assuma C uma variável aleatória que denota a classe de uma instância e X um vetor de variáveis aleatórias representando os valores observados dos atributos. Além disso, assuma c um rótulo de uma determinada classe e x um vetor de valores de atributo. Considere uma instância de teste x a ser classificada. A classe mais provável será aquela com maior valor para P (C = c X = x). ou seja, a probabilidade da classe c dada a instância x. A expressão seguinte apresenta a regra de Bayes, aplicada para calcular esta probabilidade, onde X = x corresponde ao evento X 1 = x 1 X 2 = x 2... X k = x k e P (C = c) representa a probabilidade a priori de c, ou seja, a probabilidade de obtenção da classe c sem levar em conta os dados de treinamento: p(c = c X = x) = p(c = c)p(x = x C = c) p(x = x) Uma suposição comum a qual não é inerente à abordagem Naïve Bayesiana, todavia frequentemente usada é que para cada classe os valores dos atributos numéricos são normalmente distribuídos. Segundo [25], embora essa suposição não reflita a realidade no que se refere ao contexto de tráfego Internet,tal abordagem supera em desempenho alguns modelos mais complexos. De acordo com [26], no caso da técnica Naïve Bayes envolver atributos quantitativos, a discretização fornece uma opção para estimação de densidade de probabilidade. Uma descrição detalhada da abordagem de discretização pode ser encontrada em [27]. Neste trabalho, nós utilizamos a técnica Naïve Bayes com discretização fornecida no Weka. A execução da técnica NB é similar a realizada para o método KNN, sendo que se executa o comando weka.classifiers.bayes.naivebayes, passando como parâmetros a opção de discretização e o arquivo com os dados de treinamento e avaliação. III. RESULTADOS E DISCUSSÃO O desempenho dos módulos de coleta e remontagem foi avaliado para verificação de capacidade, sob condições de carga variável. Para este propósito, utilizou-se traços de tráfego coletados em um host conectado a uma rede Ethernet banda larga 100Mbps. O monitor foi executado em um PC Core i5 com CPU 2.30 GHz e 4GB de memória. A simulação de coleta online a partir de traços de tráfego previamente coletados permite flexibilidade na avaliação de diferentes classificadores e abordagens de remontagem, desde que execuções diferentes do sistema para o mesmo traço de pacotes geram o mesmo conjunto de fluxo. Sem este determinismo, seria extremamente dificultosa a tarefa de reproduzir os mesmos resultados em uma coleta online, dado a possibilidade de atraso e perda de pacotes, por exemplo. O monitor é configurado com um timeout de 60 segundos. Isso significa que, para os fluxos TCP com duração maior que este valor, estes são periodicamente encerrados pelo processo coletor. Tal esquema é necessário para evitar que conexões antigas ou ociosas continuem armazenadas no buffer, desperdiçando recursos de memória e processamento do monitor. As características dos traços de tráfego utilizados, referenciados como T1 e T2, são apresentadas na tabela I. A tabela II apresenta as aplicações identificadas nos respectivos traços a partir do método baseado em portas. Para o traço T1, a maior parte do tráfego considerado refere-se a aplicações Www e Ftp, e para T2, as classes Https e Isakmp possuem maior número de instâncias. Em nosso estudo, as etapas de avaliação e treinamento das técnicas de classificação são realizadas ao final da captura de pacotes e remontagem dos fluxos. (2)

Tabela I CARACTERÍSTICAS DOS TRAÇOS UTILIZADOS Parâmetro T1 T2 Número de pacotes 614282 1579921 Tamanho da captura 565.62MB 1.88GB Duração da captura 3516.79s 1355.83s Tamanho médio do pacote 920.78 bytes 1195.16 bytes Taxa média de captura 1.28 Mbps 11.14 Mbps Tabela II COMPOSIÇÃO DOS DADOS DE TRÁFEGO POR CLASSE DE APLICAÇÃO Classificação Descrição T1 T2 Www World Wide Web 1353 6 Https Http protocol over TLS/SSL 145 34 Ftp File Transfer Protocol 1458 Xvttp Xvttp Protocol - 4 Isakmp Isakmp Protocol - 44 Total - 2956 88 Tabela III DESEMPENHO DOS PROCESSOS DE MONITORAMENTO E REMONTAGEM Métrica T1 T2 Número de conexões TCP 2956 88 Duração da remontagem 48.21s 228.14s Duração da leitura do traço 1218.65s 4895.20s Throughput da captura e remontagem 3.08 fps 0.12 fps Throughput da remontagem 4750.06 fps 1.24 fps Vazão máxima da captura e remontagem 1.22 Mbps 17.64 Mbps Vazão máxima de remontagem 209.74 Mbps 95.39 Mbps A tabela III apresenta alguns dados de desempenho obtidos após a execução do monitor classificador em uma simulação baseada em traços. Nós observamos que, para T1, o maior throughput atingido pelos módulos de coleta e remontagem foi 3.08 fluxos por segundo (fps), aproximadamente. Isso significa que, a cada segundo, 3.08 streams são entregues pelo processo de remontagem para o próximo processo. Embora este valor seja baixo, dado que o tráfego referente ao traço T1 possui um throughput médio de apenas 1.28 Mbps, o processo de remontagem atingiu o throughput de 4750.06 fps em um dos intervalos de coleta. A maior taxa atingida pelo monitor para coleta e remontagem, expressa por Mbits/(T CO +T RE ), foi de 13.61 Mbps. A vazão máxima de remontagem, Mbits/T RE, foi de 209.74 Mbps, onde T CO e T RE são os tempos de duração de coleta e remontagem em um dado intervalo, respectivamente. Analogamente, as mesmas medidas de desempenho são apresentadas para o traço T2. Devido ao gargalo de desempenho no processo de remontagem e leitura dos pacotes, o monitor não é efetivo em tempo real. Na tabela IV, com base em T1, o sistema é comparado com as ferramentas Tcpflow, Tcptrace e Wireshark. Como pode ser observado, o número de fluxos não é o mesmo entre as ferramentas, devido a divergência do conceito de fluxo empregado, conforme explicado previamente. Pode-se verificar Tabela IV COMPARAÇÃO COM FERRAMENTAS EXTERNAS Abordagem Número de fluxos Tempo de Execução Abordagem Proposta 2956 1218.65s Tcpflow 5894 118.87s Tcptrace 3044 612.95s Wireshark 3036 182.69s Tabela V CARACTERÍSTICAS DOS TRAÇOS UTILIZADOS Traço KNN NB T1 90.69% 87.20% T2 73.86% 60.22% que o tempo de execução da abordagem proposta é superior as outras ferramentas. Supõe-se que isso seja devido o sistema ser desenvolvido em uma linguagem de programação interpretada para fins de prototipagem. No intuito de avaliar o processo de classificação, consideram-se os seguintes atributos para cada fluxo de tráfego: Tempo decorrido entre primeiro e último pacote, número de pacotes, total de bytes, número de pacotes com ao menos um byte de payload de dados TCP, número de pacotes com bit PUSH ativo no cabeçalho TCP, e mediana e variância do total de bytes no pacote IP. Desde que cada atributo é calculado para ambas as direções do fluxo, cada instância de fluxo possui 14 discriminantes estatísticos além do atributo classe. Não houver propriamente uma seleção de atributos neste trabalho. Escolheram-se os atributos mais freqüentemente encontrados em trabalhos anteriores publicados e que possam ser calculados a partir dos dados contidos no cabeçalho dos pacotes sem examinar o payload. A partir da utilização dos recursos do Weka, foi utilizada validação cruzada para avaliar a precisão dos modelos de classificação. Além disso, o valor da constante k para a técnica KNN foi arbitrariamente definido como 10. Pode-se observar, na tabela V,que a técnica KNN foi capaz de categorizar corretamente em média 90.69% e 73.86% do tráfego avaliado, contra 87.20% e 60.22% para o classificador Naïve Bayes, para os traços T1 e T2, respectivamente. IV. CONCLUSÃO O trabalho apresentou a arquitetura, implementação e desempenho de um monitor classificador de tráfego TCP. A implementação do monitor classificador é composta de três módulos implementados como processos concorrentes: captura e pré-processamento, remontagem dos fluxos e classificação. Para o traço T1, o throughput dos módulos de captura e remontagem da implementação atual é de 3.08 fluxos por segundo. O atraso médio de entrega é de 40.23s. Para o módulo de classificação, os desempenhos dos classificadores K-Nearest Neighbor e Naïve Bayes são comparados. KNN mostrou-se superior ao NB com taxas de acerto de 94.89% contra 85.72%.

Atualmente, este trabalho está evoluindo em quatro direções. Primeiro, o estudo da implementação do sistema em uma máquina com quatro núcleos (core 2 quad) com o processo referente a cada módulo alocado em um núcleo exclusivo [28]. Espera-se com isso aumentar a vazão do sistema. Segundo, estuda-se a classificação baseada em subfluxos [29] com vistas a reduzir o tempo de resposta. Terceiro, a implementação da solução apresentada com tecnologia NetFPGA [30], dado que a implementação em hardware é essencial para dar suporte a qualquer aplicação em tempo real, sobretudo em redes de alta velocidade [31]. Por fim, estuda-se a utilização de amostragem de pacotes para o monitoramento em altas taxas de tráfego. REFERÊNCIAS [1] A. Ziviani and O. Duarte, Metrologia na Internet, Minicursos do XXIII Simpósio Brasileiro de Redes de Computadores, SBRC, pp. 285 329, 2005. [2] T. Karagiannis, A. Broido, and M. Faloutsos, Transport layer identification of P2P traffic, in Proceedings of the 4th ACM SIGCOMM conference on Internet measurement. ACM, 2004, pp. 121 134. [3] A. Moore and D. Zuev, Internet traffic classification using bayesian analysis techniques, in Proceedings of the 2005 ACM SIGMETRICS international conference on Measurement and modeling of computer systems. ACM, 2005, p. 60. [4] A. Moore, J. Hall, C. Kreibich, E. Harris, and I. Pratt, Architecture of a network monitor, in Passive & Active Measurement Workshop 2003 (PAM2003). Citeseer, 2003. [5] R. Wojtczuk, libnids homepage, 2005, 2005. [6] S. Ostermann, Tcptrace, 2005. [7] A. Orebaugh, G. Ramirez, and J. Burke, Wireshark and Ethereal network protocol analyzer toolkit. Syngress Media Inc, 2007. [8] G. Maiolini, A. Baiocchi, A. Rizzi, and C. Di Iollo, Statistical classification of services tunneled into ssh connections by a k-means based learning algorithm, in Proceedings of the 6th International Wireless Communications and Mobile Computing Conference. ACM, 2010, pp. 742 746. [9] S. Nor, Near Real Time Online Flow-Based Internet Traffic Classification Using Machine Learning (C4. 5), International Journal of Engineering (IJE), vol. 3, no. 4, p. 370, 2009. [10] M. Cohen, Pyflag-an advanced network forensic framework, digital investigation, vol. 5, pp. S112 S120, 2008. [11] R. Bejtlich, The Tao of network security monitoring: beyond intrusion detection. Addison-Wesley Professional, 2004. [12] V. Jacobson and S. McCanne, libpcap: Packet capture library, Lawrence Berkeley Laboratory, Berkeley, CA, 2009. [13] G. Camarillo, The internet assigned number authority (iana) uniform resource identifier (uri) parameter registry for the session initiation protocol (sip), 2004. [14] S. Zander, T. Nguyen, and G. Armitage, Automated traffic classification and application identification using machine learning, in Local Computer Networks, 2005. 30th Anniversary. The IEEE Conference on. IEEE, 2005, pp. 250 257. [15] G. Wagener, A. Dulaunoy, and T. Engel, Towards an estimation of the accuracy of tcp reassembly in network forensics, in Future Generation Communication and Networking, 2008. FGCN 08. Second International Conference on, vol. 2. IEEE, 2008, pp. 273 278. [16] B. XIONG, C. Xiao-su, and C. Ning, A Real-Time TCP Stream Reassembly Mechanism in High-Speed Network, JOURNAL OF SOUTHWEST JIAOTONG UNIVERSITY, vol. 17, no. 3, 2009. [17] J. Postel, Rfc 793: Transmision control protocol, DARPA Internet Program Protocol Specification, 1981. [18] Y. Wang and S. Yu, Machine Learned Real-Time Traffic Classifiers, in Intelligent Information Technology Application, 2008. IITA 08. Second International Symposium on, vol. 3. IEEE, 2009, pp. 449 454. [19] P. Agarwal, TCP Stream Reassembly and Web based GUI for Sachet IDS, Master s thesis, Indian Institute of Technology Kanpur, Kanpur, India, 2007. [20] T. Nguyen and G. Armitage, A survey of techniques for internet traffic classification using machine learning, Communications Surveys & Tutorials, IEEE, vol. 10, no. 4, pp. 56 76, 2008. [21] E. Frank, M. Hall, and L. Trigg, Weka 3-Data Mining with Open Source Machine Learning Software in Java, The University of Waikato, 2000. [22] M. J. Islam, Q. M. J. Wu, M. Ahmadi, and M. A. Sid-Ahmed, Investigating the performance of naive- bayes classifiers and k- nearest neighbor classifiers, Convergence Information Technology, International Conference on, vol. 0, pp. 1541 1546, 2007. [23] L. Jun, Z. Shunyi, L. Yanqing, and Z. Zailong, Internet traffic classification using machine learning, in Second International Conference on Communications and Networking in China, 2007. CHINACOM 07, 2007, pp. 239 243. [24] D. Zuev and A. Moore, Traffic classification using a statistical approach, Passive and Active Network Measurement, pp. 321 324, 2005. [25] I. Witten and E. Frank, Data Mining: Practical machine learning tools and techniques. Morgan Kaufmann Pub, 2005. [26] Y. Liu, Z. Li, S. Guo, and T. Feng, Efficient, Accurate Internet Traffic Classification using Discretization in Naive Bayes, Networking, Sensing and Control,ICNSC 2008. IEEE International Conference on, vol. 0, pp. 1589 1592, 2008. [27] Y. Yang and G. Webb, On why discretization works for naive-bayes classifiers, AI 2003: Advances in Artificial Intelligence, pp. 440 452, 2003. [28] A. Marowka, Towards high-level parallel programming models for multicore systems, in Advanced Software Engineering and Its Applications, 2008. ASEA 2008, dec. 2008, pp. 226 229. [29] L. Bernaille, R. Teixeira, I. Akodkenou, A. Soule, and K. Salamatian, Traffic classification on the fly, ACM SIGCOMM Computer Communication Review, vol. 36, no. 2, pp. 23 26, 2006. [30] J. Lockwood, N. McKeown, G. Watson, G. Gibb, P. Hartke, J. Naous, R. Raghuraman, and J. Luo, Netfpga an open platform for gigabit-rate network switching and routing, in Microelectronic Systems Education, 2007. MSE 07. IEEE International Conference on. IEEE, 2007, pp. 160 161. [31] J. Naous, D. Erickson, G. Covington, G. Appenzeller, and N. McKeown, Implementing an openflow switch on the netfpga platform, in Proceedings of the 4th ACM/IEEE Symposium on Architectures for Networking and Communications Systems. ACM, 2008, pp. 1 9.