1.1. Compilei o applet
JAVA com o JDK 1.2 ou superior, e instalei-o. Ao correr, o
browser queixa-se que não encontra as
classes.
R: O Internet Explorer (versão 4.0 ou superior) só
suporta a máquina virtual JVM 1.1. Compilando com versões
posteriores do JDK 1.1 da Sun, para um formato binário
v1.2 ou superior, causará este tipo de erros*. As versões
anteriores só suportam a JVM 1.0, pelo que a nossa applet
não correra.
O Netscape Navigator (até a versão 4.xx**) só
suporta a JVM 1.0, pelo que a nossa
applet não correrá neste browser. A versão 6.0 ou
superior é suposta suportar a JVM 1.1.
* Para resolver este
problema use o comando "javac -target 1.1 *.java", para forçar o
formato binário das classes para a JVM 1.1.
** Nós corremos com sucesso na v4.75, no Red Hat Linux
7.0, mas são precisos mais testes.
1.2. Tentei compilar o código UNIX, mas este
queixa-se que lhe faltam bibliotecas.
R: O código do sniffer assenta sobre a biblioteca
libpcap. Na instalação de pacotes das distribuições, esta
normalmente vem dentro da categoria de bibliotecas de desenvolvimento
e necessita de ser instalada. No caso de esta não se encontrar, ou já
não possuir os CD's de instalação, o melhor será proceder à sua
instalação a partir do código fonte.
1.3. Que usaram para compilar o código?
R: Usamos o compilador gcc em Linux (para o
servidor), e para o código JAVA, o Microsoft Visual J++ 6.0
e o Sun JDK 1.3 (em Windows).
1.4. Estive a usar a applet,
e reparo que enquanto no IE 5.x ou 6.0, possuo uns botões do
lado direito do ecrã, estes não aparecem no IE 4.0.
R: A JVM do IE 4.0 original, possui diversos
problemas. Instale a última versão da JVM, ou melhor ainda,
faça um upgrade para a versão 5.x ou
6.0.
2.1. A applet não consegue
comunicar com o servidor TCP. Que se passa?
R: Devido ao desenho da arquitectura de segurança do JAVA,
é necessário o browser realizar o
donwload do mesmo servidor em que o
servidor sniffer/TCP se encontra.
Para ultrapassar esta limitação, no caso de estar a usar o
appletviewer do JDK da Sun, pode adicionar o
conteúdo do ficheiro .java.policy, fornecido com a aplicação,
ao já existente, ou caso não exista, copiá-lo para a raiz do seu
directório pessoal.
Windows NT, 2000 e XP: 'copy .java.policy "%USERPROFILE%"'.
UNIX e Linux: 'cp .java.policy ~/'.
Nota: Isto desliga a segurança do TCP/IP do JAVA
para todos os programas JAVA.
2.2. Preciso de históricos de ocupação de rede. Como
procedo?
R: Os componentes sniffer em UNIX (Linux),
funcionam com compatibilidade MRTG. Neste caso, recomendo esta
instância apenas para uso do MRTG. No entanto, não existe nesse
segmento de colisão de rede um hub ou switch com
capacidade SNMP? Este seria o mais indicado, já que a ocupação
de CPU de um servidor à escuta de trafego de rede é
directamente proporcional ao trafego presente nessa rede.
Se depois destas indicações, ainda quiser, ou precisar de usar o
MRTG, compile o ficheiro mrtg.c e verifique se o ficheiro
mtrg.cfg incluído com as fontes deste programa na pasta
others.
2.3. Instalei o vosso servidor correctamente, mas (quase)
não vejo trafego...
R: Verifique se se encontra ligado a um
switch. Se for esse o caso, necessita de configurar uma
porta para monitorização, de forma a visualizar o trafego deste
segmento. Atenção, que se for este o caso, não se recomenda correr
outros serviços no servidor, devido ao impacto negativo que poderá
existir com uma rede a 100 Mbps com uma carga elevada.
2.4. Quero ter sempre os daemons de escuta de trafego
a correr no meu servidor. Como fazer?
R:
Copie o ficheiro sniffstart.sh para:
/etc/init.d
No directório /etc/rc2.d e no /etc/rc5.d
executa o comando:
#ln -s /etc/init.d/sniffstart.sh S20snifftraf
Copie o ficheiro sniffstart.sh para:
/etc/rc.d/init.d
No directório /etc/rc.d/rc3.d e em /etc/rc.d/rc5.d
executa o comando:
#ln -s /etc/rc.d/init.d/sniffstart.sh S20sniffstart
A partir deste momento, sempre que realizar um
reboot à máquina, esta arranca com o servidor.
2.5. Porque fizeram este software?
O ipfilter/ipchains/ipfwadm devolve as
estatísticas de ocupação de rede. E existe o ntop...
R: As informações devolvidas pelos filtros de
firewall, apenas representam o
trafego directamente enviado para a máquina, ou
broadcasts. Apenas representam o trafego total, quando esta
funciona como firewall ou
bridge.
2.6. Não existe já software/hardware
para este uso?
R: Claro, mas cada qual possui usos diferentes. Nós
necessitava-mos de uma ferramenta que fornecesse
feedback da ocupação da rede em tempo real. E como:
- O ntop é pesado, e como nem sempre é possível (ou
desejável) mostrar todo o output
que esta ferramenta gera aos clientes;
- E como o MTRG está pensado para proceder a uma
instalação e manter-se sempre em funcionamento; é também algo lento
ao obter resultados em tempo real; para mais, está irremediavelmente
condicionado a um intervalo de cinco minutos;
- Nem sempre se encontra um network
analyzer/tester disponível; e quando se encontra também
significa mais "400g" que temos de carregar;
- E por último, temos sempre de andar a carregar um portátil para
fazer instalações em clientes...
Nós desenvolvemos este software
essencialmente para:
- Ser leve;
- Colocar um portátil num ponto, e visualizar noutro local de
rede (i.e. na estação de trabalho pessoal do cliente).
2.7. O vosso software é o
que eu preciso para obter estáticas do meu proxy,
do trafego do meu servidor ou existe algo mais indicado?
R: Para este efeito, recomendamos a instalação de um
servidor SNMP, ou da instalação de estatísticas de
proxy. Ocupa bastante menos CPU
do servidor e realiza o mesmo efeito.
2.8. Em certas circunstâncias costuma aparecer uma linha com
o programa sniffclient e a string <killed> no
comando ps. Que significa isto?
R: Isto significa que na terminologia UNIX, se possui
um zombie no sistema.
O sniffclient executa uma cópia de si mesmo recebendo um
pedido do cliente. Devido à construção do mesmo, é comum ficar um e
apenas um zombie enquanto este se encontra a funcionar. Tem a
ver com timings do bloqueio da função
sockets accept e com a execução da função wait3. Ver
tcppserver.c para mais detalhes.
Qualquer zombie desaparecerá
aquando de um kill ao processo
tcpserver.
A solução é colocar um select no
código antes do accept. Pode ser que
já tenhamos corrigido isto pela altura que estiverer a ler isto.
2.9. Que são essas regras BPF que vocês mencionam?
R: As regras BPF (Berkeley
Packet Filter), foram desenvolvidas para fornecer uma
linguagem de alto nível para filtragem de pacotes de trafego. São
suportadas pela biblioteca libpcap. Para mais detalhes,
consulte:
- man tcpdump;
-
http://www.tcpdump.org;
- o livro de Stevens:
"Network Programming, Volume 1 Second Edition,
Networking APIs: sockets and XTI; ISBN
0-13-490012-X";
- as fontes do libpcap.
3.1. Possuem alguns planos para melhorias?
R: Possuímos planos para um cliente Windows Win32 e
X Windows e um servidor para Windows NT, 2000 e
XP.
3.2. Tenho de compilar o código. Não o posso instalar
directamente?
R: Ainda não tentamos criar packages rpm ou
deb. Mas se nos fornecerem as instruções passo a passo... ;->
3.3. A comunicação de dados entre o servidor e a
applet, não é insegura?
R: Claro que é. No entanto, a segurança apenas se aplica
onde necessário. Na nossa opinião, não se justifica codificar os
valores de ocupação das redes.
Consequentemente, não pretendemos modificar este ponto.
3.4. Não posso correr tudo no meu servidor Windows?
R: Neste momento não, mas temos planeado uma versão da
parte servidor para Windows NT, 2000 e XP, num
futuro próximo. O Windows 9x e ME não serão suportados
devido á falta de estabilidade destes SO's, em especial no suporte de
rede.
