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

Uma Abordagem para Classificação Online de
Tráfego TCP
Silas Santiago Lopes Pereira
José Everardo Bessa Maia
Departamento de Estatı́stica e Computação
UECE - Universidade Estadual do Ceará
Fortaleza - Ceará - Brasil
Email: [email protected]
Departamento de Estatı́stica e Computação
UECE - Universidade Estadual do Ceará
Fortaleza - Ceará - Brasil
Email: [email protected]
Jorge Luiz de Castro e Silva
Departamento de Estatı́stica e Computação
UECE - Universidade Estadual do Ceará
Fortaleza - Ceará - Brasil
Email: [email protected]
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. I NTRODUÇ Ã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 M ONITOR C LASSIFICADOR
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.
A. Captura e Pré-processamento de Pacotes
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 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 6= 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 n . Uma nova instância X = x1 , x2 , ....., xn ,
na qual x1 , x2 , . . . , xn 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 xk e yk denotam respectivamente os valores para
o k-ésimo atributo das instâncias X e Y :
v
u n
uX
(1)
d(X|Y ) = t (x2 k − y 2 k )2
R
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 X1 = x1 ∧ X2 = x2 ∧ . . . Xk = xk 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)p(X = x|C = c)
(2)
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.
p(C = c|X = x) =
III. R ESULTADOS E D ISCUSS Ã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.
Tabela IV
C OMPARAÇ ÃO COM FERRAMENTAS EXTERNAS
Tabela I
C ARACTER ÍSTICAS DOS TRAÇOS UTILIZADOS
Parâmetro
T1
T2
Abordagem
Número de fluxos
Tempo de Execução
Número de pacotes
614282
1579921
Abordagem Proposta
2956
1218.65s
Tamanho da captura
565.62MB
1.88GB
Tcpflow
5894
118.87s
Duração da captura
3516.79s
1355.83s
Tcptrace
3044
612.95s
Tamanho médio do pacote
920.78 bytes
1195.16 bytes
Wireshark
3036
182.69s
Taxa média de captura
1.28 Mbps
11.14 Mbps
Tabela V
C ARACTER ÍSTICAS DOS TRAÇOS UTILIZADOS
Tabela II
C OMPOSIÇ ÃO DOS DADOS DE TR ÁFEGO POR CLASSE DE APLICAÇ ÃO
Classificação
Traço
KNN
NB
T2
T1
90.69%
87.20%
1353
6
T2
73.86%
60.22%
145
34
Descrição
T1
Www
World Wide Web
Https
Http protocol over TLS/SSL
Ftp
File Transfer Protocol
1458
Xvttp
Xvttp Protocol
-
4
Isakmp
Isakmp Protocol
-
44
Total
-
2956
88
Tabela III
D ESEMPENHO DOS PROCESSOS DE MONITORAMENTO E REMONTAGEM
Métrica
T1
Número de conexões TCP
2956
T2
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
M bits/(TCO +TRE ), foi de 13.61 Mbps. A vazão máxima de
remontagem, M bits/TRE , foi de 209.74 Mbps, onde TCO e
TRE 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
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. C ONCLUS Ã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.
R EFER Ê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.