Análise de Tráfego · 7 min read · Dec 14, 2025

Análise de Tráfego Usando Debian Lenny

Análise de Tráfego Usando Debian Lenny

Ao usar meu Aparelho de Monitoramento de Rede, notamos um link no MRTG sempre sob carga pesada. Neste link, muitos tráfegos diferentes se agregam, então decidimos analisar quais quantidades de protocolos e, portanto, aplicações, o tráfego cumulativo consiste.

Como você pode ver facilmente, há muito tráfego em cada dia, exceto nos fins de semana e feriados.

Uma aplicação OSS que poderia fazer isso é o ntop. Trecho de www.ntop.org:

"ntop é uma sonda de tráfego de rede que mostra o uso da rede, semelhante ao que o popular comando top do Unix faz. O ntop é baseado em libpcap e foi escrito de uma maneira portátil para rodar virtualmente em todas as plataformas Unix e também no Win32. Os usuários do ntop podem usar um navegador da web (por exemplo, netscape) para navegar pelas informações de tráfego do ntop (que atua como um servidor web) e obter um dump do status da rede. Neste último caso, o ntop pode ser visto como um simples agente semelhante ao RMON com uma interface web embutida."

Preliminar e Isenção de Responsabilidade

Por favor, esteja ciente de que os direitos legais em alguns países podem proibir a realização de coisas como as mencionadas neste artigo, e que você não deve violar direitos legais. Também esteja ciente de que o seguinte recibo descreve a maneira como implementamos nossa solução, não emito nenhuma garantia de que funcionará para você.

1. O Link

O Link tem 10 MBit/s de velocidade de fio e é um gateway de roteamento entre 2 locais localizados a poucos quilômetros de distância. Um cálculo rápido de quanto dado viaja por este link deu o resultado de que deveria estar na faixa de ~25 GigaByte/Dia. De um lado do link estão aproximadamente 2000 sistemas, do outro lado cerca de 200, e cerca de uma dúzia de relações de comunicação entre ambos os lados de interesse para nós. Mais tarde, notamos que cerca de 40-50 milhões de pacotes viajam por este link todos os dias, das 7h às 17h.

Como o ntop analisa todo o tráfego e mostra relações de comunicação, por exemplo, na forma de principais emissores e semelhantes, presumimos que o ntop usaria muita RAM para construir tabelas sobre todas as relações de comunicação, pensamos que a sonda deveria ter o máximo de RAM possível.

2. A Sonda

Decidimos usar uma caixa antiga não utilizada, fazer uma instalação mínima do Debian Lenny e usá-la como sonda ntop. Fizemos apenas uma instalação mínima porque não queríamos desperdiçar a preciosa RAM com X11 ou outras aplicações inúteis, inúteis para este caso de uso. Decidimos usar o Debian porque é facilmente adaptável às nossas necessidades e é conhecido por sua estabilidade. Mas você pode construir uma sonda como a descrita aqui com qualquer outra distribuição Linux que você conheça, também os *BSDs podem ser uma boa base.

Decidimos colocar esta sonda perto do roteador que gerencia este link e configurar uma porta de espelho para obter acesso a todo o tráfego que passa por este link.

Equipamos a sonda com uma segunda NIC, porque precisamos de uma NIC para captura de tráfego e queríamos ser capazes de administrar a sonda remotamente via SSH. A primeira NIC (eth0) foi configurada sem um endereço IP, porque é usada apenas para capturar o tráfego da porta de espelho do roteador, e não para fazer qualquer comunicação ativa. Além disso, a eth0 deve ser colocada em modo promíscuo (para ver todo o tráfego), o que é feito pelo libpcap. A segunda NIC (eth1), que é usada apenas para administração remota, foi configurada com um endereço IP estático.

Felizmente, a antiga caixa que foi usada como sonda estava equipada com 2GB de RAM (o que era suficiente), um processador AMD Athlon(tm) 64 Processor 3800+, e um disco local de 80GB. O disco foi particionado da seguinte maneira:

# fdisk -l
Disco /dev/sda: 80.0 GB, 80026361856 bytes  
255 cabeçotes, 63 setores/track, 9729 cilindros  
Unidades = cilindros de 16065 * 512 = 8225280 bytes  
Identificador do disco: 0x37aa37aa  
  
   Dispositivo  Boot      Início          Fim       Blocos   Id  Sistema  
/dev/sda1                1            131      1052226   83  Linux  
/dev/sda2               132            162       249007+  82  Linux swap / Solaris  
/dev/sda3               163           9729     76846927+   5  Estendida  
/dev/sda5               163           9729     76846896   83  Linux

/dev/sda1 é uma partição de 1GB para Lenny, /dev/sda2 uma pequena partição swap, e /dev/sda5 a ser usada para arquivos de captura. Os sistemas de arquivos são ext3, mas xfs também pode ser um candidato sólido para arquivos tão grandes.

3. Relatório Offline

O ntop é capaz de analisar tráfego em tempo real, ou também é capaz de ler arquivos pcap para análise e relatórios posteriores.

Decidimos primeiro usar a abordagem offline, para capturar o tráfego no link com tcpdump das 7h às 17h por meio de um pequeno shellscript acionado pelo cron, e fazer a análise em um segundo passo.

O shellscript se parece com um script de inicialização Sys-V:

#!/bin/sh

PATH=/sbin:/usr/sbin:/bin:/usr/bin

do_start() {
        ifconfig eth0 up;
        tcpdump -i eth0 -w /media/capture/`date +%F_%R`_tcpdump.pcap &
}

do_stop() {
        pkill -SIGTERM tcpdump;
        ifconfig eth0 down;
}


case "$1" in
    start)
        do_start 2>&1
        ;;  
    stop)
        do_stop
        ;;  
    *)
        echo "Uso: $0 start|stop" >&2
        exit 3
        ;;  
esac

Capturar tráfego das 7h às 17h produz arquivos com tamanho de ~30GB:

-rw-r--r-- 1 root root 32725662515 Jan 14 17:00 2020-01-14_07:00_tcpdump.pcap

Ler um arquivo de captura é feito por

ntop -m 10.80.192.0/18,10.81.20.0/24 -f /media/capture/2010-01-13_10\:30_tcpdump.pcap -n -4 -w3000 --w3c -p /etc/ntop/protocol.list

Para uma explicação detalhada dos switches e parâmetros da linha de comando do ntop, consulte sua página de manual e ajuste-os às suas necessidades.

Você pode então examinar o relatório do ntop no navegador da web na porta 3000 do sistema onde o ntop está sendo executado.

4. Relatório Online

Outra possibilidade de usar o ntop é que o próprio ntop captura o tráfego na eth0 e faz relatórios online em tempo real, para que você possa ver o que está acontecendo alguns segundos depois, e (com o plugin rrd ativado) obter gráficos realmente bonitos e impressionantes (amigáveis para a gestão!) onde você pode ampliar com o mouse.

5. Primeiras Conclusões

Como esperado, vimos que aproximadamente 70% de todo o tráfego foi induzido por um sistema, o Proxy da Internet. O tráfego associado a aplicações produtivas estava na faixa de 3-5%. Para piorar a situação, esse tráfego produtivo está associado a aplicações interativas, como Citrix, Telnet e SAP. Decidimos que o próximo passo deveria ser priorizar/modelar o tráfego com a ajuda de (por exemplo) diffserv, ou TOS mangling.

6. ngrep

Agora decidimos analisar o tráfego relacionado ao proxy, quais sites seriam os mais visitados. Uma análise mais profunda não é possível com o ntop, mas com o ngrep é fácil capturar apenas o tráfego que (por exemplo) vai para um sistema ou vem/vai para uma porta, ou muito mais. O ngrep também é capaz de buscar expressões na carga útil, então a próxima abordagem foi usar o ngrep para capturar apenas o tráfego relacionado ao Proxy da Internet e analisá-lo mais.

Isso é feito simplesmente por

grep -d eth0 host 10.89.1.17 -O /media/capture/snap.pcap

Desnecessário dizer que esse tipo simples de captura também poderia ser feito com tcpdump.

Quando feito das 7h às 17h, isso poderia produzir um arquivo de ~14GB:

-rw-r--r-- 1 root root 14223354675 Jan 25 16:26 snap.pcap

Agora esse arquivo deve ser analisado. A ideia é

  • ler o arquivo com tcpdump, despejá-lo para stdout,

  • grep por “get http://“,

  • cortar o FQDN dos sites,

  • descartar entradas duplicadas que estão em séries curtas (porque podem pertencer a um clique no navegador resultando em uma linha de gets consecutivos),

  • e contar e classificar esses dados de acordo com sua ocorrência.

Isso poderia ser feito em várias etapas usando arquivos intermediários, ou ser um comando onde várias ferramentas de linha de comando são encadeadas:

tcpdump -r snap.pcap -A | grep -i "get http://" | awk '/http/ { print $2 }' | cut -d/ -f1-3 | grep http | sed '$!N; /^
(.*)
\
\
$/!P; D' | sort | uniq -c | sort -r > urls.txt

Isso leva um tempo e você obtém um arquivo classificado em ordem decrescente de quantas vezes os sites encontrados no arquivo de captura foram visitados. Não estou 100% certo se todas as nossas suposições feitas acima estão corretas, mas os números no arquivo parecem viáveis.

  13418 http://www.gxxxxx.dx
  10184 http://www.gxxxxx-axxxxxxxx.cxx
   8281 http://www.fxxxxxxx.dx
   5470 http://www.bxxx.dx
   4269 http://www.sxxxxxx.dx
   2550 http://www.gxxx.cxx
   2047 http://www.bxxxxxxx-zxxxxxx.dx
   2044 http://www.fxxxxxxx.cxx
   1618 http://www.exxxxxxx.dx
   1410 http://www.lx-bx.dx
   ....

Outra maneira de obter um relatório sobre sites visitados seria interpretar o logfile do Proxy da Internet, talvez com Calamaris (no caso do Squid ou um Proxy que produz logs processáveis pelo Calamaris). Sem um log de proxy, não estou ciente de como tal relatório poderia ser produzido.

Por último, mas não menos importante, gostaríamos de enfatizar fortemente que nenhuma informação relacionada a usuários foi avaliada neste projeto.

7. URLs

Debian

Aparelho de Monitoramento de Rede

MRTG

Ntop

tcpdump + libpcap

RRD

ngrep

Squid

Calamaris

AWK 1 Liners

SED 1 Liners

Share: X/Twitter LinkedIn
#Análise de Tráfego

Receba novas postagens na sua caixa de entrada

Sem spam. Cancele a assinatura a qualquer momento.