Comunicações de Dados Engenharia de Sistemas Informáticos, Pós-laboral Trabalho Prático - 2 Ferramenta de Segurança em Comunicações de Dados ntop Docente: Miguel Pires Discentes: Luís M. F. Barreto; nº 7812 Adélio C. de Miranda, nº 7820 Carlos D. D. Pereira, nº 8140 Ano letivo 2012/13 Barcelos, 27 de Maio de 2013
Ferramenta de Segurança em Comunicações de Dados - ntop Adélio C. de Miranda, Carlos D. D. Pereira, Luís M. F. Barreto ESI-PL, Comunicações de Dados Maio 2013 Resumo - A monitorização de sistemas e redes informáticas tem uma relevância tanto maior, quanto maior a infraestrutura em causa ou a necessidade de disponibilidade e desempenho da mesma. Com o substancial crescimento das redes de computadores, sua heterogeneidade e complexidade, tornou-se necessário criar mecanismos que permitissem a monitorização eficiente e integrada do tráfego em trânsito nas redes informáticas. Esta monitorização tem como objetivo não só proteger os recursos centrais de uma infraestrutura, como também o tráfego que desta transita para o exterior. O ntop é uma aplicação opensource escrita em linguagem C e desenvolvida por Luca Deri e Stefano Suin desde 1998. O nome ntop provém da conjunção do da palavra network (rede) com o comando top, comum nas plataformas *nix e que permite visualizar os processos com maior utilização do processador. Neste trabalho iremos estudar as possibilidades de deteção de falhas de equipamentos de rede, segurança e intrusões facultadas pelo ntop. Palavras-Chave: Monitorização; ntop; tráfego; segurança; deteção de intrusões; TCP; IP; netflow. Este documento foi redigido ao abrigo do novo acordo ortográfico.
Índice I. Introdução... 4 II. Descrição do ntop... 5 A. Arquitetura... 5 B. Funcionalidades... 6 III. Métodos de Captura... 6 A. Utilização de um Hub... 7 B. Port Mirroring... 7 C. NetFlow... 8 IV. Funcionalidades... 10 A. Estatísticas de Utilização... 10 V. Aplicações Práticas... 19 A. Monitorização de tráfego... 19 B. Otimização e planeamento da rede... 19 C. Deteção de falhas de segurança... 19 VI. Plugins... 20 VII. Conclusão... 20 Referências... 21 Índice de Figuras Fig. 1 Captura de dados com HUB... 7 Fig. 2 Captura de dados com Port Mirroring... 8 Fig. 3 Captura de dados com NetFlow... 9 Fig. 4 - Estatísticas globais por interface de rede... 10 Fig. 5 - Distribuição da utilização de protocolos de rede... 11 Fig. 6 - Distribuição da utilização de protocolos de aplicação... 12 Fig. 7 - Carga da rede - 10 min.... 13 Fig. 8 - Carga de Rede - 1 hora... 13 Fig. 9 - Comportamento de rede anómalo... 14 Fig. 10 - Histórico da atividade últimas 24 horas... 14 Fig. 11 - Gráfico Sankey... 15 Fig. 12 - Detalhe Sankey... 16 Fig. 13 - Caraterização de computadores locais... 16 Fig. 14 - Utilização de protocolos na rede local... 17 Fig. 15 - Dados IP enviados e recebidos... 17 Fig. 16 - Utilização de protocolos aplicacionais... 18 Fig. 17 - Destinos no mapa Mundo... 18
I. Introdução A gestão de redes informáticas há muito que é objeto de estudo pela crescente importância e dependência que estas representam para as empresas ou instituições a todos os níveis. Cada vez mais a sociedade está refém de tecnologias, funcionalidades e serviços que dependem diretamente do desempenho de determinadas redes de dados. A sua crescente complexidade e dimensão aliadas à diversidade de tipologias e necessidade de segurança, fazem com que os custos de manutenção e respetivo alinhamento com o negócio, subam constantemente. Partindo deste cenário, Luca Deri e Stefano Suin deram início ao desenvolvimento do ntop em 1997, tendo a primeira versão pública sido disponibilizada em 1998. Numa primeira fase, o objetivo era desenvolver uma aplicação que, de forma simples e automática capturasse, armazenasse e relacionasse o tráfego em trânsito nos vários segmentos da rede do Campus da Universidade de Pisa (UNIPI) em Itália. Responsável pela gestão da rede informática da UNIPI, Luca Deri era muitas vezes confrontado com questões relacionadas com a lentidão e inoperacionalidade da ligação à Internet, ou entre departamentos da própria Universidade. As ferramentas disponíveis até então sniffers como o tcpdump ou o snoop das quais fazia uso, proporcionavam apenas a captura de tráfego específico, a pedido, e normalmente para resolução de problemas pontuais e localizados. Embora sendo ferramentas extremamente úteis e poderosas, não apresentavam formas de análise à posteriori da informação ou mesmo do corelacionamento da mesma identificando a origem e destino de cada comunicação. Por outro lado, ferramentas como o RMON e o NeTraMet facultavam já a possibilidade de, através de linguagens de programação, obter algumas análises baseadas nos dados capturados e por sua vez, criação de estatísticas com base nos mesmos. Estas, haviam no entanto sido desenvolvidas com o objetivo de analisar protocolos ou fluxos de dados específicos pelo que não forneciam a tão almejada visão global do estado da rede. Pelo exposto, é percetível a falta de uma ferramenta que permitisse não só a captura de tráfego de rede como também, e talvez principalmente, permitisse produzir em tempo real uma visão global big picture do tráfego gerado na rede, a cada momento. Este trabalho está estruturado da seguinte forma: I Introdução: neste capítulo fazemos uma breve apresentação da aplicação ntop, em estudo neste documento, assim como as motivações da sua criação; II Descrição do ntop: Neste ponto, abordamos de uma forma mais detalhada o que constitui o ntop e uma visão global sobre a sua finalidade; III Métodos de Captura: Neste capítulo, identificamos os vários métodos de captura de tráfego pelo ntop. A sua correta instalação é determinante para a obtenção de informação relevante a quem tem necessidade de instalar uma ferramenta de monitorização de redes. IV Funcionalidades: Neste capítulo, fazemos uma incursão pelos menus e informação disponibilizada pelo ntop. V Aplicações práticas: Neste capítulo, identificamos algumas aplicações práticas da utilização do ntop. Para a realização deste trabalho foi utilizado o seguinte software e respetivas versões:
SO: Ubuntu 12.04.1 LTS Kernel: 3.2.0-35-generic-pae ntop: v5.0.2 i686-linux (versão em desenvolvimento) Plugins: RRD: v2.9 NetFlow: 4.4 O ntop foi instalado numa máquina virtual na plataforma de virtualização VirtualBox (v4.2.12) e, de forma a permitir a captura de maior quantidade de informação possível, todas as interfaces de rede (WiFi e Ethernet) foram configuradas em modo promíscuo. II. Descrição do ntop Muitas vezes, o primeiro contacto com o ntop surge num momento em que, a necessidade de gestão de uma rede se torna crítica e, em determinado momento é necessário responder à(s) questão(ões): - quem está a consumir a toda a largura de banda instalada; com que propósito (aplicação(ões) usadas) e quais a(s) origem(ns) e destino(s) do tráfego? No âmbito dos sistemas de informação, há muitas vezes a tendência para resolver problemas de performance ou falta de resposta adequada dos sistemas em geral, com mais hardware, mais largura de banda, ou seja, aquisição de mais recursos. Esta é no entanto uma má prática a que qualquer gestor de redes e recursos informáticos deve responder com, em primeiro lugar, uma correta análise e investigação do problema antes de acionar qualquer tentativa de resolução do mesmo. A. Arquitetura O ntop é uma ferramenta open-source desenvolvida essencialmente em linguagem C e está disponível sob licença GPL. Isto representa não só o acesso gratuito à aplicação como também ao seu código fonte que com frequência é melhorado e corrigido por programadores e utilizadores de todo o mundo. O ntop baseia-se numa arquitetura modular que permite não só ser estendido com plugins ou extensões, como ser integrado noutras aplicações ou ferramentas sendo um exemplo disso, o sensor Cisco On100 [1] ou o Cisco Traffic Analyzer [2]. Até 2011, a captura de dados realizada pelo ntop recorria apenas à biblioteca libpcap que além de estar disponível nas diferentes plataformas *nix, fornece um interface único de captura de todo o tipo de pacotes. Graças à sua excelente implementação, os autores decidiram portar a biblioteca libpcap para as plataformas não *nix, recorrendo no caso do Windows, ao controlador NDIS existente no software das placas de rede. Este pormenor permitiu ao ntop ser o primeiro software de monitorização de rede, passível de instalação nas maior parte das plataformas mais comuns. A partir de 2011, começou a ser usado um novo método de captura de pacotes, o PF_RING. Após vários meses de desenvolvimento, o PF_RING veio permitir a captura de dados em redes de 10GBit (ou mais), sem perda de pacotes e, não menos importante, recorrendo computadores e placas de rede comuns. Este novo tipo de captura de sockets
permite atingir performances muito superiores às até então possíveis, usando poucos recursos em termos de ciclos de processamento, mantendo compatibilidade com a biblioteca libpcap amplamente utilizada até então. B. Funcionalidades Para lá da captura do tráfego de rede, o ntop permite a análise dos dados capturados que é no fundo o mecanismo que nos vai permitir visualizar toda a informação recolhida. A informação é analisada através da leitura dos cabeçalhos dos pacotes tendo em conta a interface de rede que estiver ativa para monitorização no momento. Esta informação é então armazenada numa tabela de hash onde para cada máquina identificada, são mantidos contadores do tráfego enviado/recebido e respetivos protocolos usados. Os dados analisados são armazenados mantidos em Round Robin Database (RRD). As bases de dados RRD têm por base o conceito de armazenamento de dados numéricos em períodos de tempo pré determinados. A sua estrutura simples que prevê o armazenamento de dados e criação de gráficos a partir destes, é extremamente leve e por isso adequada para armazenar e gerar gráficos a partir de grandes quantidades de informação. Além dos gráficos baseados em RRD que apresentam normalmente quantidades de dados, velocidades ou número de pacotes, a partir da versão 5.0 foram introduzidos os diagramas Sankey [3] que melhoram substancialmente a apresentação de dados transferidos entre entidades. Como veremos mais à frente, recorrendo a diagramas Sankey é possível percebermos visualmente a quantidade de informação transferida entre emissor e recetor, bem como a quantidade afeta a cada uma das partes nessa comunicação. Pelo fato de ser usado um armazenamento baseado em RRD, percebe-se que não é objetivo do ntop fazer a persistência de dados durante longos períodos de tempo (> 1 ano). Mesmo assim, o ntop permite exportar os dados capturados em intervalos de tempo configuráveis, sendo estes passíveis de importação em bases de dados relacionais de terceiros para armazenamento de longo termo. III. Métodos de Captura A monitorização de qualquer rede informática requer, antes de mais, que se conheça o objetivo da monitorização. Ou seja, não podemos esperar que, qualquer que seja a aplicação de monitorização com que iremos trabalhar, esta nos permita obter a informação que queremos, independentemente da forma ou local onde a ligamos à rede ou subrede a monitorizar. O ntop, tal como qualquer outra aplicação de monitorização, apenas monitoriza aquilo que efetivamente vê, resultante da sua ligação à rede ou em alternativa, da informação que lhe fazemos chegar através da utilização de protocolos como o NetFlow 1 ou sflow 2. Por este motivo, passamos a enumerar as formas mais comuns de ligação do ntop à rede. 1 O NetFlow é um protocolo desenvolvido pela Cisco Systems que recolhe informação relativa ao tráfego que transita pela rede (Switches e Routers) que suportam esta tecnologia proprietária. Recolhe toda a informação processada pelo(s) dispositivo(s) onde está instalado. 2 O sflow é uma tecnologia que permite a monitorização de trafego de redes. Os dados são capturados por amostragem o que permite bom desempenho mesmo em redes com débitos elevados. É suportado por um grande número de fabricantes de produtos de rede.
A. Utilização de um Hub Hoje em dia já se torna difícil encontrar HUB s instalados em redes informáticas. Mesmo assim, em determinadas condições podem ser utilizados quando o objetivo é capturar todo o tráfego que percorre uma rede. A principal diferença entre um HUB e um Switch, mais comum nos dias de hoje, é que num HUB quando um pacote entra em determinada porta, este é automaticamente reenviado para todas as outras portas. Assim, se conectarmos a um HUB o router de acesso à Internet, a rede interna e o ntop, este será capaz de escutar todas as comunicações que tiverem lugar entre a rede interna e a Internet. Com esta abordagem, não serão necessárias alterações à configuração de qualquer equipamento e o ntop conseguirá capturar todo o tráfego. Nos dias de hoje, à exceção de casos em que não exista na rede nenhum Switch com a funcionalidade de port mirroring, a utilização de um HUB será talvez remota pelo desuso que estes equipamentos têm registado devido ao menor desempenho relativamente a um Switch. Rede Local Internet Switch Router Hub Fig. 1 Captura de dados com HUB B. Port Mirroring Ao contrário dos HUB s, cada porta de um Switch tem o seu próprio domínio de colisão. Isto significa que à exceção de pacotes unicast, broadcast ou multicast, cada pacote que entre no Switch apenas será enviado para a porta onde está ligada a máquina de destino (determinada pelo endereço MAC). Se considerarmos o cenário que apresentamos anteriormente em que recorremos a um HUB, caso substituíssemos o HUB por um Switch, a única coisa que o ntop iria receber eram broadcasts, multicasts e unicasts e comunicações direcionadas a si próprio. Desta forma não seria capturada qualquer informação relativa à globalidade do tráfego que circula na rede, sendo impossível obter qualquer tipo de relatório de comunicações, do ntop. Embora não seja uma característica intrínseca de todos os Switches, uma grande parte destes a partir de determinado nível de qualidade, possui uma funcionalidade que permite mitigar esta limitação. Resumidamente é possível, em alguns equipamentos, configurar uma porta para a qual será copiada todos os dados que forem
transferidos (enviados/recebidos) pela totalidade ou um conjunto das restantes portas do Switch. Esta funcionalidade é normalmente conhecida com Port Mirroring (portas espelho). Neste cenário, tendo em conta a captura de tráfego de / para a internet, a melhor abordagem é configurar o switch de forma a espelhar a porta 2 (ligada ao router de Internet) na porta 3, onde está ligado o ntop. Rede Local Porta 1 Porta 3 Switch Port Mirroring Porta 2 Router Internet Fig. 2 Captura de dados com Port Mirroring Para este cenário é necessário referir que, quando configuramos uma porta como espelho de outra(s) num switch, a porta para onde forem encaminhados os dados do tráfego espelhado não permite nenhum outro tráfego à exceção deste. Por este motivo, é necessário termos duas placas de rede no computador/servidor onde estiver a ser executado o ntop para que, na segunda placa de rede seja possível atribuir um endereço IP e aceder-lhe remotamente para consulta dos dados recolhidos. C. NetFlow O NetFlow é uma tecnologia proprietária da Cisco que pela sua relevância ao nível da monitorização de tráfego de rede é considerado um standard neste âmbito. Os sensores NetFlow, existentes individualmente ou embebidos em routers ou switches, recolhem informação sobre fluxos de dados, agregam-na e enviam-na para um coletor/analisador, como no nosso caso, o ntop. De modo a recolher toda a informação relevante, é importante colocar sensores NetFlow nos pontos de agregação de rede. Por exemplo no router de ligação à internet, no router de cada sub-rede interna, ou seja, em cada ponto que interesse monitorizar e onde normalmente exista confluência de dados. Um coletor NetFlow que no nosso caso é o ntop, recebe as ligações do tipo NetFlow por norma, na porta 2055. No entanto, esta pode ser alterada consoante as necessidade de cada instalação. Existe ainda o sflow que é um protocolo alternativo compatível com um maior número de equipamentos de rede relativamente ao NetFlow e que é capaz de monitorizar ligações de rede na ordem do GBit/s. O ntop permite
igualmente capturar e analisar os dados que lhe sejam submetidos pelo protocolo sflow. Não está no âmbito do presente documento a análise dos protocolos NetFlow ou sflow, pelo que iremos escusar-nos da sua análise em detalhe, limitando-nos apenas à sua referência e utilização a título demonstrativo. Com recurso ao NetFlow e/ou ao sflow é necessário garantir que existe ligação de rede entre o ntop e o(s) sensor(es) NetFlow/sFlow, de forma a garantir que os dados NetFlow ou sflow cheguem ao ntop. Dados NetFlow Rede Local Internet Switch Router com NetFlow / sflow Fig. 3 Captura de dados com NetFlow Conforme vimos, cada metodologia de monitorização deve respeitar determinados pressupostas em termos de instalação e localização que nos permitam obter os resultados que pretendemos. É importante salientar ainda que, nos casos em que seja usado um HUB ou o port mirroring, a placa de rede que esteja a efetuar a captura de tráfego, deve ser configurada em modo promíscuo. O modo promíscuo permite a uma placa de rede ouvir todo o tráfego que por ela passa e não apenas aquele que lhe é especificamente destinado. De todos os métodos abordados, o port mirroring será o que permite resultados mais fidedignos uma vez que todo o tráfego que flui na rede será disponibilizado ao ntop. Os protocolos NetFlow ou sflow, apenas trabalham com amostras retiradas de todo o tráfego que efetivamente passou no sensor que recolheu os dados e por este motivo é omitida alguma informação passível de coleta recorrendo a port mirroring (deteção de tráfego por endereço MAC, tráfego P2P).
IV. Funcionalidades O ntop usa vários métodos para detetar a informação que trafega na rede e posteriormente gerar os gráficos e tabelas que irão facilitar a sua análise e segmentação de acordo com critérios estabelecidos por políticas de utilização correta da rede, utilização da largura de banda, etc. A. Estatísticas de Utilização A estatística de utilização de tráfego advém da captura de todo o tráfego que passa na rede ou é enviado por NetFlow/sFlow e na contabilização do mesmo. Após a recolha de dados, o ntop passa a relacionar a informação e posteriormente gera gráficos e tabelas que permitem uma rápida identificação do que se passa em termos de comunicações em tempo real. Toda a informação é correlacionada através de um par emissor-recetor que, desta forma, permite rastrear todas as atividades relacionadas com determinado computador/servidor ou outro equipamento que realize comunicações na rede monitorizada pelo ntop. Na Fig. 4 apresentamos o ecrã inicial do ntop. Sendo este o primeiro ecrã visível quando acedemos ao ntop pelo interface web, é possível neste e nos vários menus desta primeira página, aceder ao resumo global no momento. Fig. 4 - Estatísticas globais por interface de rede Os nomes pf_ring_ethx são meramente identificativos e podem ser personalizados. Neste caso usamos o método de captura dos dados através de PF_RING a que acrescentamos o nome (Linux) de cada interface. Neste caso, a interface eth1 é a que apresenta a maior quantidade de comunicações.
Da visualização global, passamos para o gráfico da distribuição dos protocolos de rede usados, na Fig. 5. Neste gráfico percebe-se que, na rede em que estes dados foram obtidos, a esmagadora maioria das comunicações ainda se faz sobre o protocolo rede IPv4. Todos os restantes protocolos de rede têm uma utilização muito reduzida. Fig. 5 - Distribuição da utilização de protocolos de rede Conhecendo o histórico dos protocolos usados e configurados na rede, a visualização da estatística de utilização de cada protocolo é, por si só, identificativa de alguma situação anormal.
Na Fig. 6 podemos observar a distribuição da percentagem de utilização dos protocolos ao nível da camada de aplicação. Neste gráfico facilmente se percebe se há protocolos em utilização a consumir recursos de forma exagerada ou eventualmente não autorizados, em utilização. Fig. 6 - Distribuição da utilização de protocolos de aplicação A Fig. 7 mostra-nos a carga de tráfego na rede. Além deste, estão disponíveis separadores na barra superior ao gráfico para os dados relativos aos períodos: última hora, dia e mês.
Fig. 7 - Carga da rede - 10 min. Fig. 8 - Carga de Rede - 1 hora Estes gráficos são indicados para uma monitorização constante não pelo fato de apresentarem a tendência de utilização da largura de banda como também permitem obter a informação sobre alguma anomalia quando o ntop,
através de métodos estatísticos, identifica a amarelo os momentos em que o tráfego apresenta um comportamento anómalo ao que seria expectável. Podemos ver essa indicação na Fig. 9. Fig. 9 - Comportamento de rede anómalo É possível obter um gráfico com o histórico do peso que cada máquina teve na utilização da largura de banda ao longo das últimas 24 horas através do gráfico da Atividade da Rede (dados enviados / recebidos) por máquinas remotas, ou seja fora da nossa rede, como se mostra na Fig. 10. Fig. 10 - Histórico da atividade últimas 24 horas
Um aspeto muito interessante e que torna o ntop extremamente útil e intuitivo é o fato de em quase todos os gráficos, ser possível interagir com os mesmos diretamente. Se tomarmos como exemplo o gráfico da Fig. 10, é possível clicar com o rato num qualquer computador nele identificado e, a partir daí, passar para a visualização de um gráfico do tipo Sankey [3]. Os gráficos Sankey foram introduzidos na versão 5 do ntop e permitem uma identificação visual de fácil interpretação da transferência de dados entre máquinas. Fig. 11 - Gráfico Sankey Com uma breve leitura da Fig. 11, é percetível que o computador Ubuntu-ntop, identificado a azul-claro transferiu a maior parte da informação com a máquina www.google.com, a azul-escuro. Uma vez que a percentagem de azulclaro e azul-escuro nas barras horizontais é idêntica, sabemos que a transferência de informação foi equitativa. Se analisarmos por exemplo a máquina lis01s05-in-fl.1e100.net, alaranja, verificamos que houve mais transferência de dados entre esta e a máquina Ubuntu-ntop do que o contrário. Partindo do gráfico da Fig. 11, podemos ainda aprofundar mais a análise se carregarmos numa das listas coloridas. Na Fig. 12, podemos ver o detalhe caso selecionemos a cor da máquina 202.67.222.222 que, tal como é identificado pelo ntop representa um servidor de nomes e por isso, as comunicações são identificadas como sendo relativas ao protocolo DNS.
Fig. 12 - Detalhe Sankey O ntop fornece ainda dados em tabelas por desta forma serem mais fáceis de interpretar. Uma tabela com informação relevante fornecida pelo ntop, é a tabela de caracterização dos computadores detetados na rede local. Na Fig. 13 é possível visualizar uma tabela com inventário dos computadores e funcionalidades/caraterísticas de cada um. Fig. 13 - Caraterização de computadores locais
Na Fig. 14, temos a representação da utilização dos protocolos na rede local e os respetivos clientes e servidores. Esta tabela é muito importante uma vez que permite identificar os protocolos em utilização, as portas em uso e as máquinas que os usam. Com esta informação é possível validar se todos cumprem as regras definidas em políticas de utilização dos recursos de rede ou não. Fig. 14 - Utilização de protocolos na rede local Um pouco mais detalhada é a tabela que sumariza a distribuição de tráfego IP. Na Fig. 15, podemos ver os protocolos usados, as máquinas que os usaram e a quantidade numérica de dados transferidos. Fig. 15 - Dados IP enviados e recebidos
Não menos importante é a identificação dos protocolos da camada de aplicação e respetivo peso em termos de dados transferidos. Na Fig. 16, é possível observar se as aplicações usadas estão dentro do âmbito do que é permitido, ou se é necessário proceder a alguma alteração em termos de políticas de proxy e/ou firewall. Fig. 16 - Utilização de protocolos aplicacionais Por fim, na Fig. 15, é possível identificar geograficamente no mundo, a localização das máquinas com quem a rede monitorizada tem sessões ativas. Fig. 17 - Destinos no mapa Mundo
V. Aplicações Práticas A. Monitorização de tráfego Os dados obtidos pela monitorização levada a cabo pelo ntop, permitem identificar os momentos em que o débito da rede, não está de acordo com os parâmetros contratados ou a tecnologia e equipamentos instalados. Além disto pode significar que há políticas de utilização que não estão a ser cumpridas. Normalmente, em redes com alguma dimensão ou requisitos de desempenho há políticas de utilização implementadas ou mesmo acordos de serviço com fornecedores (Service Level Agreement). As razões para que ocorram anomalias podem ser de várias ordens, podendo ir desde má configuração de Sistemas Operativos, placas de rede, aplicações, etc. Caso pela observação dos gráficos seja detetada alguma anomalia, o ntop permite a deteção de alguns problemas de rede, entre os quais podemos referir: - utilização de endereços IP duplicados ou fora do âmbito disponível internamente; - identificação de placas de rede em modo promíscuo; - configuração incorreta de aplicações; - utilização de aplicações não permitidas; - identificação de computadores que não usam os servidores proxy requeridos pelas políticas internas; - identificação de routers; - identificação de computadores configurados como routers; - utilização excessiva de tráfego; B. Otimização e planeamento da rede No seguimento do que já vimos anteriormente, a configuração incorreta de computadores ligados à rede pode influenciar de uma forma negativa o desempenho da rede. O ntop permite-nos identificar potenciais fontes de utilização de largura de banda desnecessárias ou mesmo a utilização de rotas de encaminhamento menos eficazes. Pela observação ao longo do tempo do fluxo de tráfego e sua caracterização, é possível adotar medidas de otimização dos recursos de rede e com isto levar a cabo manutenção e planeamento devidamente fundamentado que de outra forma seriam sempre empíricas. C. Deteção de falhas de segurança Não obstante ser uma premissa já antiga, cada vez mais se verifica que uma grande parte das falhas e problemas de segurança é proveniente do interior da rede [4]. Tendo isto em conta, o ntop mostra-se uma ferramenta útil na identificação de ataques à medida que estes surgem e na identificação de potenciais riscos internos causados por falhas de segurança em computadores ou software. É possível monitorizar ataques do tipo denial of service ou cavalos de tróia.
Tendo por base vários critérios, como sejam falhas de segurança, utilização de largura de banda excessiva, ou outros, é possível a partir do interface do ntop, gerar alertas por e-mail, Short Message Service (SMS) ou Simple Network Management Protocol (SNMP), no momento em que se verificarem as condições definidas pelo gestor da rede. VI. Plugins Uma das vantagens de aplicações baseadas em código aberto é a possibilidade de qualquer utilizador poder analisar o código, melhorá-lo e incrementá-lo com novas funcionalidades. O ntop é também exemplo disto. Ao longo deste documento referimos os gráficos RRD e a captura de dados por NetFlow. Ambos são de fato plugins que, embora sejam distribuídos com o ntop, não fazem parte do mesmo e sim aplicações com fins específicos que acrescentam funcionalidades ao ntop. VII. Conclusão Da realização do presente trabalho, concluímos que o ntop é uma aplicação extremamente útil quando o objetivo é obter resultados imediatamente após a instalação. Esta decorre com facilidade e sem problemas tanto em Linux como em Windows. Embora a versão que utilizamos (v 5.0.2) seja a última versão em desenvolvimento e portanto não estável, causou talvez por este motivo, o não funcionamento dos alertas e a criação de mapas por região. A utilização de recursos pelo ntop é substancialmente baixa tanto em termos de memória, espaço de armazenamento e de processamento, sendo assim uma boa solução para reutilizar por exemplo, um computador antigo que esteja sem utilização. A captura e de informação inicia-se a partir do momento em que o serviço ntop é iniciado e a interação com o utilizador fica disponível à distância de um comum navegador de internet no endereço http://localhost:3000. O estudo e conhecimentos adquiridos no estudo da aplicação ntop, revelaram-se de elevado valor e contribuíram para uma consolidação dos conhecimentos relacionados com a comunicação de dados em redes informáticas.
Referências [1] Packet Monitoring using ntop and Cisco ON100, 15 Fevereiro 2012. [Online]. Available: http://www.ntop.org/ntop/packet-monitoring-using-ntop-and-cisco-on100/. [Acedido em 2013 Maio 19]. [2] Cisco Traffic Analyzer, [Online]. Available: http://www.cisco.com/en/us/docs/switches/datacenter/mds9000/sw/4_1/configuration/guides/fm_4_1/traffic.h tml. [Acedido em 19 Maio 2013]. [3] L. Deri, Sankey Diagrams, 17 Julho 2012. [Online]. Available: http://www.ntop.org/ntop/ntop-5-0-released/. [Acedido em 17 Maio 2013]. [4] T. Teller, The Biggest Cybersecurity Threats of 2013, 12 Maio 2013. [Online]. Available: http://www.forbes.com/sites/ciocentral/2012/12/05/the-biggest-cybersecurity-threats-of-2013-2/. [Acedido em 20 Maio 2013]. [5] NetFlow, 14 Março 2013. [Online]. Available: http://en.wikipedia.org/wiki/sflow. [Acedido em 19 Maio 2013]. [6] sflow, 24 Abril 2013. [Online]. Available: http://en.wikipedia.org/wiki/netflow. [Acedido em 19 Maio 2013]. [7] T. Oetiker, RRDTool, 17 Janeiro 2011. [Online]. Available: http://oss.oetiker.ch/rrdtool/index.en.html. [Acedido em 18 Maio 2013]. [8] MySQL/Oracle, DNS and HTTP Plugins, [Online]. Available: MySQL/Oracle, DNS and HTTP. [Acedido em 22 Maio 2013]. [9] L. Deri, Open Source in Network Administratio, 2008. [Online]. Available: http://luca.ntop.org/opensourceconf_athens2008.pdf. [Acedido em 17 Maio 2013]. [10] Top Software, Wikipedia, 13 Março 2013. [Online]. Available: http://en.wikipedia.org/wiki/top_(software). [Acedido em 16 Março 2013]. [11] L. M. Garcia, tcpdump e libpcap, tcpdump, 2010. [Online]. Available: http://www.tcpdump.org/. [Acedido em 23 Maio 2013]. [12] Systems Administration Commands, Oracle, 10 Janeiro 2007. [Online]. Available: http://docs.oracle.com/cd/e19253-01/816-5166/snoop-1m/index.html. [Acedido em 22 Maio 2013]. [13] Wikipedia, Wikipedia, 17 Maio 2013. [Online]. Available: http://en.wikipedia.org/wiki/rmon. [Acedido em 24 Maio 2013]. [14] NeTraMet - a Network Traffic Flow Measurement Tool, CAAIDA, 7 Março 2012. [Online]. Available: http://www.caida.org/tools/measurement/netramet/. [Acedido em 23 Maio 2013].