Sistema de monitoramento para redes sem fio com Zabbix e openWRT

Marcelo Santana Camacho
Implantação de um sistema de monitoramento
para redes sem fio Indoor com Zabbix e
openWRT.
Brasil
2013

Implantação de um sistema de monitoramento para redes
sem fio Indoor com Zabbix e openWRT.
Implantação do NMS Zabbix em uma rede
sem fio em produçao no Campus Univer-
sitário, composta de equipamentos com o
firmware openWRT.
Universidade Federal do Pará – UFPA
Instituto de Ciências Exatas e Naturais
Programa de Pós-Graduação em Ciência da Computaçao
Especializaçao em Redes de Computadores
Orientador: Fernando Nazareno Nascimento Farias
Brasil
2013

Implantação de um sistema de monitoramento para redes sem fio Indoor com
Zabbix e openWRT. / Marcelo Santana Camacho. – Brasil, 2013-
Orientador: Fernando Nazareno Nascimento Farias
Monografia (Especialização) – Universidade Federal do Pará – UFPA
Instituto de Ciências Exatas e Naturais
Programa de Pós-Graduação em Ciência da Computaçao
Especializaçao em Redes de Computadores, 2013.
1. Rede sem fio. 2. Zabbix. 3. openWRT. 4. NMS.

Implantação de um sistema de monitoramento para redes
sem fio Indoor com Zabbix e openWRT.
Implantação do NMS Zabbix em uma rede
sem fio em produçao no Campus Univer-
sitário, composta de equipamentos com o
firmware openWRT.
Trabalho aprovado. Brasil, 02 de setembro de 2013:
Fernando Nazareno Nascimento Farias
Orientador
Francisco Edson Rocha
Coordenador
Brasil
2013

Agradecimentos
Os agradecimentos principais são direcionados aos meus pais e professores, bem
como ao meu Diretor Eloi Favero pela ajuda e incentivo e todos aqueles que contribuíram
para que a produção deste trabalho fosse finalizada.
Agradecimentos especiais são direcionados ao Centro de Tecnologia da Informação
e Comunicaçao1
da Universidade Federal do Pará.
1
<http://www.ctic.ufpa.br>

Resumo
O cenário do monitoramento em redes sem fio ainda está muito voltado para soluções
proprietárias, que oferecem ao usuário os equipamentos, software de monitoramento e
controladoras para configuração em massa dos dispositivos. Já as linhas de equipamentos
de uso doméstico, por outro lado, não se preocupam em oferecer recursos avançados,
mesmo quando são suportados pelo hardware.
Este trabalho oferece uma proposta para uso de equipamentos doméstico dentro de um
contexto organizacional de grande porte, pelo uso de tecnologia aberta e livre. Superando
a primeira dificuldade encontrada para criação do ambiente - a de permitir configurações
avançadas disponíveis em um equipamento de baixo custo, esta flexibilidade foi ofere-
cida pelo openWRT, projeto aberto que será comentado adiante. Para superar a segunda
dificuldade seria necessária a implantação de um sistema que monitore e gerencie este
ambiente, pelo uso de tecnologias e protocolos bem difundidos e normalizados, afim de
manter a compatibilidade com outras soluções. Felizmente, todas as tecnologias oriundas
de software livre possuem a característica de serem compatíveis e adotarem orientações
normalizadas pela comunidade acadêmica. Nesse sentido, optou-se pelo uso da ferramenta
Zabbix, mantida por uma grande comunidade, que ainda tem o seu desenvolvedor como
principal mantenedor.
A combinação dessas ferramentas e tecnologias resultou em uma solução escalável e aberta,
mantida por vários usuários. Espera-se que este trabalho motive outras soluções nesse
sentido ou o aperfeiçoamento da mesma.
Palavras-chaves: soluçao. openWRT. zabbix. monitoramento. rede sem fio.

Abstract
The scenario of monitoring in wireless networks is still very much focused on proprietary
solutions, which offer the user equipment, monitoring and controlling software for mass
configuration of devices. Already the lines of household appliances, on the other hand, do
not bother to offer advanced features, even when supported by hardware.
This paper offers a proposal for use of domestic equipment within a large organizational
context, the use of free and open technology. Overcoming the first difficulty for creating the
environment - to allow advanced settings available in a low-cost equipment, this flexibility
was provided by OpenWrt, open project that will be discussed later. To overcome the
second difficulty would be necessary to implement a system to monitor and manage this
environment, the use of technologies and protocols as well widespread and standardized,
in order to maintain compatibility with other solutions. Fortunately, all the technologies
derived free software have the characteristic of being compatible and adopt standard
guidelines for the academic community. Accordingly, it was decided to use the tool Zabbix,
maintained by a large community, which still has its main developer as maintainer.
The combination of these tools and technologies has resulted in a scalable and open,
maintained by multiple users. It is expected that this work motivates other solutions in
this regard or enhancement thereof.
Key-words: solution. openWRT. zabbix. manager. wireless.

Lista de ilustrações
Figura 1 – Rede ethernet projetada por Bob Metcalfe. . . . . . . . . . . . . . . . . 21
Figura 2 – Camada de enlace 802.11. . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figura 3 – Árvore MIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figura 4 – Tela de monitoramento do Nagios. . . . . . . . . . . . . . . . . . . . . 27
Figura 5 – Graficos gerados pelo Cacti. . . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 6 – Linksys WRT-54GL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 7 – Assistente de instalaçao do zabbix. . . . . . . . . . . . . . . . . . . . . 36
Figura 8 – Falha na checagem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 9 – Checagem bem sucedida. . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figura 10 – Configuraçao do banco de dados. . . . . . . . . . . . . . . . . . . . . . 37
Figura 11 – Configurando IP e porta de escuta. . . . . . . . . . . . . . . . . . . . . 38
Figura 12 – Resumo das configuraçoes. . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figura 13 – Falha na gravaçao do arquivo de configuração. . . . . . . . . . . . . . . 39
Figura 14 – Interface de login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figura 15 – Interface de login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 16 – Template openWRT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figura 17 – Inserindo itens no template1. . . . . . . . . . . . . . . . . . . . . . . . 48
Figura 18 – Configurando os itens. . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figura 19 – Inserindo um host. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 20 – Usuários associados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figura 21 – Tráfego entrante. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figura 22 – Monitoramento da disponibilidade. . . . . . . . . . . . . . . . . . . . . 53
Figura 23 – Análise do tempo de resposta com o ping. . . . . . . . . . . . . . . . . 53
Figura 24 – Tráfego outgoing na interface. . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 25 – Uso da CPU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 26 – Uso da memória. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 27 – Coleta de usuarios associados e endereços MAC. . . . . . . . . . . . . . 55

Lista de tabelas
Tabela 1 – Tabela de particionamento do Zabbix Server . . . . . . . . . . . . . . . 32

Lista de abreviaturas e siglas
AP Access Point
UTP Unshielded twisted pair
IEEE Institute of Electrical and Electronic Engineers
ISO International Organization for Standardization
IP Internet Protocol
LAN Local Area Network
NMS Network Manager System
GNU GNU is Not Unix
vlan Virtual LAN
WLAN Wireless LAN
MAC Media Access Control
LLC Logical Link Control
CSMA/CD Carrier Sense Multiple Access/Colision Detect
CSMA/CA Carrier Sense Multiple Access/Avoid Colision
PLCP Physical Layer Convergence Protocol
WGs Workgroups
OFDM Orthogonal Frequency Division Multiplexing
GHz Giga-Hertz
Mbps Megabits per seconds
MB MegaBytes
HR-DSSS Hight Rate Direct Sequence Spread Spectrum
MIMO Multiple-Input Multiple-Output
ISM Industrial, Scientific and Medical radio bands

SNMP Simple Network Management Protocol
MIB Management Informaton Base
SMI Structure of Management Informaton
TI Tecnologia da Informação
RRD Round Robin Database
CLI Command Line Interface
SSID Service Set IDentifier
ssh Secure Shell
DHCP Dynamic Host Configuration Protocol
frontend Modo de apresentação gráfica para interação com o usuário.

Sumário
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1 HISTÓRICO E PRINCIPAIS PROTOCOLOS . . . . . . . . . . . . . 21
1.1 O padrão IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.1.1 A camada física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.1.2 A camada de enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.1.2.1 IEEE 802.11a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.1.2.2 IEEE 802.11b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.1.2.3 IEEE 802.11g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.1.2.4 IEEE 802.11n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.2 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.2.1 SMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.2.2 MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3 Sistema de gerenciamento de redes . . . . . . . . . . . . . . . . . . . 26
1.3.1 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.3.2 Cacti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.3.3 O Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.4 Gerenciamento por script . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.5 O projeto openWRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2 ESTUDO DE CASO . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.1 Requisitos levantados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.2 Ambiente implementado . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.2.1 Servidor Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.2.2 Pontos de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2 Implantação do Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2.1 Instalação do Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.1.1 Configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.1.2 SSH por infraestrutura de chaves públicas . . . . . . . . . . . . . . . . . . . . . 40
2.2.2 Instalação do Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2.2.1 Configuração do Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.2.2.1.1 Canal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.2.2.1.2 Potência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.2.2.1.3 Serviço de NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.2.2.1.4 Reboot remoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.2.2.1.5 Identificação das redes próximas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.2.2.1.6 Usuários associados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.2.3 Gerenciamento de dispositivos . . . . . . . . . . . . . . . . . . . . . . . . 45
2.2.3.1 Criando um template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.2.3.2 Criando itens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.2.3.3 Inserindo um host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2.3.4 Criando um gráfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3 RESULTADOS OBTIDOS . . . . . . . . . . . . . . . . . . . . . . . 53
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

19
Introdução
As redes sem fio tornaram-se tão populares quanto às redes cabeadas. Aeroportos,
livrarias, universidades e agora até pequenas empresas já começam a oferecê-las em seus
espaços. Dentre os benefícios da tecnologia aos usuários estão:
∙ Mobilidade: como possibilidade de deslocamento na área de abrangência da rede em
que se está conectado, valendo-se de handover quando disponível.
∙ Portabilidade: não é uma característica das redes wireless locais, mas está presente
em redes sem fio como Wi-Max, 3G e até GSM (2G). Entende-se por portabilidade
a capacidade de comunicação irrestrita à uma área ou célula de cobertura, e sim,
a uma área geográfica de grandes proporções ou até cobertura mundial, como é o
caso de alguns serviços via satélite.
∙ Segurança: Cada usuário poderá realizar transações de seu próprio dispositivo móvel,
não dependendo de computadores públicos para isso.
∙ Facilidade de acesso: Usuários de redes sem fio, não dependem de instalações físicas,
pontos lógicos e cabos UTP para conectar-se à rede.
Aos administradores de rede, a tecnologia wireless proporcionou a possibilidade
de expansão da infraestrutura sem que hajam gastos com cabos, switchs, reformas no
ambiente etc. Bastando apenas, a escolha de um local apropriado e quiça, uma análise
mais apurada para determinar o canal e a potência de operação do AP (Ponto de Acesso),
assunto que será aprofundado mais adiante.
O monitoramento dos recursos e disponibilidade de uma rede wireless ainda é um
desafio, sobretudo para àqueles que se baseiam em tecnologias de software livre, pois os
fabricantes de equipamentos nem sempre preocupam-se em oferecer todos os recursos em
nível de software, nos equipamentos mais “populares”, reservando esses recursos para suas
soluções empresariais.
Tecnologias de software e hardware podem ser usadas para contornar esses pro-
blemas, mas exigem um bom conhecimento técnico na filosofia GNU/Linux, de onde se
baseiam essas tecnologias, tais como troca de firmware, configuração de vlan, conheci-
mento sobre funcionamento de protocolos e configuração de servidores. Este trabalho se
propõe a mostrar alguns dos resultados obtidos com a implantação desses recursos em
uma rede de grandes proporções .

21
1 Histórico e principais protocolos
1.1 O padrão IEEE 802.11
O IEEE (Institute of Electrical and Electronic Engineers), sociedade técnico-
profissional internacional dedicada ao avanço da teoria e prática da engenharia, padro-
nizou as Redes de Comunicação sem fio no padrão 802, donde várias outras tecnologias
associaram-se, tais como o Bluetooth (IEEE 802.15), WiMAX (802.16) e as WLANs
(802.11).
Historicamente, a aplicação de comunicações wireless na internet antecedeu a pró-
pria ethernet como é conhecida hoje. Ainda em 1970, quando a “internet” havia deixado de
ser tecnologia militar para ser alvo de pesquisas em redes universitárias, Norman Abrason
estava interessado em conectar usuários remotos da Universidade do Hawaii ao computa-
dor central em Honolulu. Certamente, passar cabos coaxiais para conectar as ilhas não era
uma boa alternativa, já que, o próprio sistema telefônico não funcionava; nesse cenário, a
única solução viável seria a utilização de ondas de rádio com dois canais, um para cada
sentido da comunicação. Esse modelo acabou interessando o pesquisador Bob Metcalfe da
Xerox, que em 1976, projetou e implementou a primeira rede local Ethernet utilizando
cabo multiponto para ligação dos terminais.
Figura 1 – Rede ethernet projetada por Bob Metcalfe.

22 Capítulo 1. Histórico e principais protocolos
As WLANs, do termo inglês Wireless LANs, são redes locais sem fio normaliza-
das no padrão IEEE 802.11, sem dúvida, o padrão mais difundido, sendo considerado
por alguns especialistas uma ameaça à redes ethernet (IEEE 802.3), embora as redes
WLANs sejam dependentes das redes ethernet, funcionando na prática como extensão
delas. Os protocolos da família IEEE 802, regulam as camadas física e de enlace em
redes de computadores possibilitando assim a interoperabilidade entre equipamentos de
diferentes fabricantes.
1.1.1 A camada física
A camada física (PHY) é responsável pela transferência de sinais elétricos, nela são
definidos os meios de transmissão, formas de modulação, codificação, controle e correção
de erro. A camada física possui três componentes básicos: o transmissor, cuja função é
transformar dados em sinais elétricos ou eletromagnéticos, para que sejam enviados pelo
canal; o canal é o meio físico pelo qual os sinais serão transmitidos até o receptor, é
importante considerar como parte do canal as interferências que lhe são características;
o receptor fará o procedimento inverso do transmissor, ele receberá sinais e tentará obter
a informação original, normalmente um sinal é degradado pelo canal, por esta razão, , o
receptor normalmente deve implementar técnicas de correção de erros.
1.1.2 A camada de enlace
A camada de enlace de dados (data link layer), age como árbitro entre o trans-
missor e o receptor, controlando o acesso ao meio físico e estabelecendo as negociações
entre as partes envolvidas. Esta camada é particularmente importante no gerenciamento
dessas redes, haja vista que, os recursos de gerenciamento são implementados aqui. A ca-
mada de enlace nas redes wireless 802.11 possuem duas subdivisões principais, conforme
representado na Figura 2.
A subcamada de Controle lógico do enlace (LLC), que tem a responsabilidade
de tornar transparente para as camadas superiores as peculiaridades da camada física.
E a subcamada de Controle de acesso ao meio (MAC), por sua vez, proporciona a en-
trega confiável de dados, controle de acesso ao meio compartilhado e proteção dos dados
transmitidos.
O principal protocolo da camada MAC é o CSMA (carrier sense multiple acesse),
implementado também em redes ethernet, mas com um método de atuação diferente. Na
realidade, a camada MAC do IEEE 802.3 implementa detecção de colisão (CD), enquanto
que, no IEEE 802.11 é implementado com prevenção de colisão (CA).
Com o passar do tempo, o comitê gestor do IEEE responsável pela normalização
do 802.11, criou WGs (Work Groups), afim de experimentar soluções que aumentariam a

1.1. O padrão IEEE 802.11 23
Figura 2 – Camada de enlace 802.11.
taxa de transferência de dados, através de alterações de outras técnicas de modulação e
espalhamento espectral, a seguir, alguns dos WGs e uma descrição sobre seus objetos de
estudos:
1.1.2.1 IEEE 802.11a
Publicado em 2002, utiliza uma técnica chamada Orthogonal Frequency Division
Multiplexing (OFDM) e opera na frequência de 5 GHz. A OFDM utiliza 8 canais de
20 MHz com transmissão multiportadora bidirecional. Com o IEEE 802.11a é possível
alcançar velocidades de até 54 Mbps.
1.1.2.2 IEEE 802.11b
Em Setembro de 1999 o IEEE ratificou o padrão IEEE 802.11b adicionando 2
velocidades ao IEEE 802.11, as velocidades de 5,5 e 11 Mbps [Barretto, 2012], que utiliza
uma técnica diferente para espalhamento de espectro, chamado HR-DSSS (High Rate
Direct Sequence Spread Spectrum), e alcança até 11 Mbps com 2,4GHz.
1.1.2.3 IEEE 802.11g
Em 2001, o IEEE publicou uma versão aperfeiçoada do 802.11b. Utilizando mo-
dulação OFDM do 802.11a e operando na banda de 2,4 GHz.
1.1.2.4 IEEE 802.11n
Essa especificação foi concluída em 2009 e trouxe como novidade um esquema cha-
mado de MIMO (Multiple-Input Multiple-Output), capaz de aumentar consideravelmente
as taxas de transferência. Trabalha com faixas de 2,4 GHz e 5 GHz e sua velocidade de
transmissão alcança até 450 Mbps.
As WLANS são baseadas em radiofrequência e estão sujeitas à regulação de órgãos
de controle nacionais e internacionais e são autorizadas a operar nas faixas de frequência

ISM (Industrial - Científica - Médica), assumindo 900 Mhz, 2.4 Ghz ou 5 Ghz. Quanto
maior a frequência, maior será a capacidade de transmissão de dados em um canal. As
primeiras WLANs operavam na frequência de 900 Mhz e atingiam velocidades de 256 kbps;
o padrão 802.11 aumentou a transmissão para 1 Mbps usando FHSS e posteriormente para
2 Mbps, utilizando DHSSS à frequência de 2.4 Ghz. (GARCIA, 2003) .
1.2 SNMP
O protocolo SNMP foi criado especificamente para monitorar segmentos de rede
remotos, permitindo a avaliação estatística da rede por longos períodos e realizar uma
análise detalha de seu desempenho por curtos períodos de tempo, haja vista que o SNMP
trabalha com comandos ou requisições atômicas. O uso do protocolo SNMP envolve o envio
de solicitações para receber respostas, portanto, é uma arquitetura Cliente/Servidor em
que, cada dispositivo a ser monitorado possui um agente que recebe as requisições, realiza
a coleta e envia a resposta; um gerente que realiza as requisições, recebe as respostas e
as apresenta de forma ordenada. Um gerente deve continuamente pesquisar a rede para
identificar os problemas. Há situações em que o agente pode enviar dados ao gerente sem
que uma requisição tenha sido efetuada, este evento chama-se trap e surgiu com a segunda
versão do protocolo.
O protocolo consiste em uma série de padrões para o gerenciamento de uma rede,
incluindo um protocolo da Camada Aplicação, um programa de banco de dados e um
conjunto de dados (objetos). Basicamente, a ideia do SNMP é tratar os dados de ge-
renciamento como variáveis pelo seu sistema e assim, poder descrever a configuração do
ambiente a ser monitorado. Essas variáveis podem ser lidas e em alguns casos até escritas
pelas aplicações de gerenciamento, possibilitando a modificação de algum dispositivo da
rede.(LIMA; DUARTE, 1993).
As informações são coletadas pelos agentes e armazenadas em uma base de infor-
mação chamada de MIB, que é um conjunto de todos os objetos gerenciados. Os objetos,
bem como a estrutura da MIB é definida por uma entidade chamada de SMI (Structure
of Management Information).
O SNMP fornece uma estrutura quase completa para a atividade gerencial, con-
forme determina os 5 tipos de Gerencia definidos pela ISO:
∙ Gerencia de Configuração: responsável pela documentação e registro de experiên-
cias ótimas da rede, controle de versões, parâmetros de configuração do sistema e
equipamentos.
∙ Gerencia de Falhas: afim de manter a disponibilidade dos serviços oferecidos, a
equipe de TI precisa de informações sobre as falhas, algumas vezes em tempo real,

1.2. SNMP 25
para que possam elencar as possíveis causas de um erro no sistema.
∙ Gerencia de contabilidade: em muitos as organizações terceirizam serviços, enlaces
ou equipamentos para isso é necessário saber o tempo em que o dispositivo fica
down . Além disso, existe a possibilidade de obtenção de estatísticas de utilização
dos recursos da rede, que normalmente é útil para planejamentos de expansão.
∙ Gerencia de desempenho: ajuda a manter a rede em um nível aceitável de desempe-
nho. Consiste basicamente em coletar informações de utilização dos recursos da rede,
tempo de resposta, taxa de erros, indisponibilidade etc.. Outro passo desse processo
consiste na comparação dessas estatísticas à indicadores de condições normais.
∙ Gerencia de Segurança: Controle de acesso e gerenciamento de privilégios do usuário,
monitoramento e controle de parâmetros de interconexão; proteção contra acesso não
autorizado, fatores ambientais e climáticos de áreas críticas de TI.
O SNMP também introduz alguns riscos de segurança, principalmente nas suas
versões 1 e 2. A versão 1 não possui quase nenhuma forma de segurança implementada, já
a versão 2 implementa comunidades privilégios de acesso sobre as informações, é recomen-
dável que os gerentes de rede alterem sempre que possível as comunidades padrões: public
e private. Em redes wireless há o risco de surgirem "gerentes falsos"que passam a coletar
informações dos dispositivos clientes, outro risco associado é o surgimento de "clientes
falsos"que acabem por confundir os administradores ou sistemas de gerenciamento.
1.2.1 SMI
O Structure of Management Information (SMI) é um padrão que estabelece a forma
de apresentação dos objetos, este padrão é definido pela linguagem Abstract Syntax No-
tation One (ASN.1). No SMI, cada objeto é estruturado de forma hierárquica contendo
seu identificador, que é um sequência de inteiros que o identifica na hierarquia, o nome da
OID e o seu valor. A RFC 2578, que especifica a SMIv2, define 11 tipos de dados básicos
que são usados para construir um objeto de monitoramento com a ASN.1, este campo é o
OBJECT TYPE e pode ser: INTEGER, Integer32, OCTET STRING, OBJECT IDEN-
TIFIER, IpAddress, Counter32, Gauge32, Unsigned32, Time Ticks, Opaque, Counter64.
Além desses, outros tipos podem ser usados, tais como SEQUENCE, SEQUENCE OF
type, BITS construct etc.
1.2.2 MIB
Uma MIB, é uma biblioteca de objetos que são definidos e estruturados pelo SMI.
A MIB comporta-se como uma base de dados, onde seus campos sao preenchidos pelos
agentes e ficam disponíveis para consulta do host gerente. Enquanto, o SMI fornece uma

maneira para definir objetos gerenciados, a MIB é uma definição, usando a sintaxe da
SMI, dos próprios objetos. Analogamente, a MIB se comporta em relação ao objeto como
um dicionário se comporta perante uma palavra. Inicialmente, define o nome textual de
um objeto para depois lhe atribuir um significado ou uma definição. (DUARTE, 2010) .
Figura 3 – Árvore MIB.
1.3 Sistema de gerenciamento de redes
Um Network Manage System (NMS), é um software que age como um frontend,
para o protocolo SNMP oferecendo vários tipos de recursos, tais como: abstração dos co-
mandos SNMP e dados “brutos” coletados, facilidade de configuração, geração de gráficos
e relatórios, customização de perfis de monitoramento (templates), alertas programados
etc.
Existem várias boas opções de Sistemas de Monitoramento de rede, desde soluções
comerciais, como as conhecidas “Controladoras” até Projetos OpenSource, deste último,
alguns bem difundidos serão tratados aqui, bem como aquele que foi escolhido para im-
plementação prática deste trabalho.

1.3. Sistema de gerenciamento de redes 27
1.3.1 Nagios
O Nagios é uma aplicação cliente-servidor disponível para a maioria dos sistemas
operacionais “unix-like”, e usa plugins para monitoramento de serviços. È muito flexivel e
permite a customização de comandos e a configuração de alertas. É muito utilizado para
monitorar ping e disponibilidade de serviços web e implementa a criação de mapas.
Mesmo com muitos recursos interessantes para os administradores de rede, o Na-
gios é considerado difícil, até mesmo para usuários habilidosos em linux e com conheci-
mentos em redes de computadores.
Figura 4 – Tela de monitoramento do Nagios.
1.3.2 Cacti
O Cacti é na verdade uma solução gráfica para o RRDTOOL, sistema desenvolvido
por Tobias Oetiker, que armazena dados de coleta em redes de computadores utilizando
entre outros recursos o protocolo SNMP, o algorítimo Roudin Robin as mais conhecidas
bases de dados disponíveis, RRD vem de Roundin Robin Database.
O Cacti, utiliza portanto as bibliotecas PHP para disparar querys e montar os
gráficos, facilitando sobremaneira as atividades de monitoramento de recursos diversos,
tais como temperatura, processamento e tráfego em redes.

Uma grande vantagem do uso da ferramenta, é que já existe uma grande quantidade
de templates prontos com para geração de gráficos customizados, assim o administrador
pode monitorar a maioria dos equipamentos disponíveis no mercado.
Figura 5 – Graficos gerados pelo Cacti.
1.3.3 O Zabbix
"O ZABBIX é uma ferramenta criada para monitorar a perfomance e a disponibi-
lidade dos ativos de uma rede, ele possui funcionalidades herdadas do Nagios e do Cacti
tornando-o uma das mais completas opções para obter informações sobre servidores e
dispositivos de rede."(ANJOS; MOURA; FERREIRA, 2009)
O Zabbix foi desenvolvido em 2001 por Alexei Vladishev e é mantido pela ZABBIX
SIA. O Software foi liberado sob a licença GPL e é mantido por uma grande e participativa
comunidade de colaboradores. O principal objetivo foi criar uma ferramenta que pudesse
monitorar não apenas um parque computacional ou a infra estrutura da rede, mas tambem
serviços e aplicações.
Suas principais vantagens, segundo a comunidade (ZABBIXBRASIL.ORG), 2012)
são:
1. Possui suporte a maioria dos sistemas operacionais: Linux, Solaris, HP-UX, AIX,
FreeBSD, OpenBSD, NetBSD, Mac OS X, Windows, entre outros;
2. Monitora serviços simples (http, pop3, imap, ssh) sem o uso de agentes;

1.4. Gerenciamento por script 29
3. Suporte nativo ao protocolo SNMP;
4. Interface de gerenciamento Web, de fácil utilização;
5. Integração com banco de dados (MySQL, Oracle,PostgreSQL ou SQLite);
6. Geração de gráficos em tempo real;
7. Fácil instalação e customização;
8. Agentes disponíveis para diversas plataformas: Linux,Solaris, HP-UX, AIX, Fre-
eBSD, OpenBSD,SCO-OpenServer, Mac OS X, Windows 2000/XP/2003/Vista;
9. Agentes para plataformas 32 bits e 64 bits;
10. Integração com os Contadores de Performance do Windows;
11. Software Open Source distribuído pela Licença GPL v2;
12. Excelente Manual (Em Inglês) – Possui licenciamento próprio – Não GPL;
13. Envio de alertas para: e-mail, Jabber, SMS;
14. Scripts personalizados.
Esta ferramenta foi escolhida por posuir a vantagem de concentrar diversos recursos
e ser de facil manipulação, além de dispor de uma abundante documentaçao online.
1.4 Gerenciamento por script
Quando equipamentos não possuem suporte ao SNMP ou quando é muito difícil
coletar informações por meio do protocolo, alguns admistradores recorrem à scripts de
gerenciamento. Obviamente, o dispositivo deve ter uma CLI para que os scripts possam ser
inseridos e executados. Felizmente, a maioria dos equipamentos gerenciáveis dão suporte
à scripts.
O uso de scripts para configuração e monitoramento, já é tradicional em sistemas
baseados em Unix e são muito eficientes. No ambiente de rede, é necessário que o admi-
nistrador implemente algum nível de segurança, para tanto, é comum que seja aberto um
canal seguro por SSH entre o gerente e o dispositivo agente, para que os comandos possam
ser executados de modo criptografado e que o retorno dos mesmos não seja alterado ou
ouvido por intrusos.

1.5 O projeto openWRT
Existe um grande esforço da comunidade open source em adequar o linux para uma
grande quantidade de produtos eletrônicos, e pela sua incrível flexibilidade, isso tem sido
possível. Especialistas em hardware embarcado afirmam que é possível instalar o linux em
qualquer dispositivo que ofereça arquitetura de 32 bits e pelo menos 4 MB de memória.
Essa característica é extremamente interessante para os fabricantes de dispositivos eletrô-
nicos, uma vez que o memória e processamento vem sofrendo com um barateamento tão
expressivo, que superou até mesmo as expectativas de Moore (Intel Corporation, 2005).
O openWRT é um firmware, ou seja, um sistema operacional embarcado em um
computador de propósito específico. Ele controla os recursos disponíveis no hardware e
interage com aplicações no nível do usuário. Ele oferece ao utilizador, recursos que não
são disponíveis na interface de acesso e configuração padrão do equipamento, estendendo
o potencial de um linux para um dispositivo. Com ele é possível configurar medir banda
através de um iperf, configurar vlan, definir vários SSIDs, utiliza-lo como um firewall
iptables ou até servidor dhcp. Todas essas funcionalidades podem ser usadas através da
instalação pelo repositório ou compilando os pacotes.
O nome openWRT surgiu, depois que um entusiasta da tecnologia livre resolveu
dar um telnet para o roteador wireless Linksys WRT-54G, percebendo que o comando foi
respondido ele conseguiu acesso ao terminal e descobriu que na realidade tratava-se de um
linux preparado para aquele propósito. À partir daí, iniciou-se um apelo público para que
a Cisco, grupo dono da marca, disponibilizasse o código fonte conforme prevê a licença
GNU GPL (GNU. . . , 2007) . O grupo não só disponibilizou o código fonte, como também
iniciou o projeto openWRT (OPENWRT, 2013) para que pudesse ser aprimorado. Hoje,
o sistema conseguiu ser portado para equipamentos de vários fabricantes.

31
2 Estudo de caso
2.1 Cenário
Inicialmente, a rede sem fio, foi implantada no campi de Belém, afim de atender
a comunidade acadêmica dentro dos institutos e em alguns pavilhões de aula. Posterior-
mente, a Universidade decidiu adquirir equipamentos mais robustos e fornecer uma solu-
ção Out-door para melhor atender os pavilhões de aula e outros espaços onde o fluxo ou
concentração de estudantes era maior. Hoje, já existe rede sem fio em Campis do Interior
e há o interesse na implantação em outras unidades atendidas pela rede metropolitana.
O interesse institucional em implementar uma rede sem fio, fez com que vários
equipamentos fossem adquiridos e instalados, e atualmente já são mais de 150 (cento e
cinquenta), Pontos de Acesso (AP’s) indoor, espalhados por todo Campi de Belém e mais
de 20 equipamentos outdoor.
Outra coisa importante de se destacar, é a organização lógica da rede, que é seg-
mentada por VLAN’s e possui redes específicas para cada instituto/prédio ou serviço.
Assim é possível imaginar que a rede sem fio tem seus serviços de autenticação e DHCP
centralizados, de tal modo que, o usuário pode descolar-se para outro prédio sem perder
sua conectividade – no máximo aguardar uma reassociação com o equipamento, mas sem
que necessite uma nova autenticação.
Procurou-se adquirir equipamentos que suportassem o firmware openWRT, para
que se tivesse maior flexibilidade nas configurações, já que o firmware do fabricante não
possibilita configuração de vlan, múltiplos SSID’s e outras exigências da rede lógica. Por-
tanto, antes de cada instalação, é realizado o survey, onde é definido o canal de operação,
localização e outros parametros, afim de evitar interferência. Uma vez realizada a instala-
ção, não se tinha mais um controle sobre a disponibilidade do equipamento ou qualidade
do serviço oferecido, pois o acesso dava-se exclusivamente por ssh (secure shell), tornando
um serviço reativo, haja vista que, não havia monitoramento sobre a disponibilidade dos
equipamentos e nenhum tipo informação era coletada sobre utilização ou qualidade do
serviço.
2.1.1 Requisitos levantados
O principal objetivo é coletar informações que digam se o equipamento está em bom
estado de funcionamento, se está alcançável pela rede e principalmente coletar informações
sobre utilização. No caso do campus, que sofre constantemente com problemas de energia,
é interessante para equipe de TI saber se a dificuldade de acesso deve-se à falta de energia

32 Capítulo 2. Estudo de caso
Tabela 1 – Tabela de particionamento do Zabbix Server
Capacidade (GB) Ponto de montagem
15 /raiz
284 /home
15 /var
em algum ponto ou se o equipamento está avariado.
Os principais requisitos levantados durante o processo são os seguintes:
1. Informação sobre disponibilidade.
2. Informação sobre consumo de banda/tráfego.
3. Informações sobre quantidade de acessos.
4. Maior facilidade para acesso e configuração dos AP’s.
5. Informações sobre a situação física dos equipamentos.
2.1.2 Ambiente implementado
A implementação do sistema de monitoramento para a rede wireless Indoor foi rea-
lizada sobre uma infraestrutura em produção, com mais de 150 (cento e cinquenta pontos
de acesso). Abaixo, será descrito, os pontos principais da implantação, características dos
hardwares envolvidos e as principais configurações realizadas tanto no Servidor Zabbix,
quanto nos clientes.
Para montar o cenário, será usado dois tipos de hardware: o computador onde o
Zabbix Server será instalado e os Access Point’s (APs), onde serão instalados o Zabbix
Agent.
2.1.2.1 Servidor Zabbix
Para o Servidor, foi utilizada computador Desktop com as seguintes característi-
cas:
Processador: Pentium(R) Dual-Core CPU E5300 @ 2.60GHz
Cache: 2 MB
Memória RAM: 2GB
Capacidade em disco: 320 GB
Placa de rede: 1000BaseT-HD
Sistema Operacional: Debian Squeeze
Particionamento:

2.2. Implantação do Zabbix 33
2.1.2.2 Pontos de Acesso
Os equipamentos clientes são os Access Point Linksys, como o mostrado na figura
06, com a configuração descrita abaixo:
Modelo: WRT54GL (v 1.1)
Processador: Broadcom BCM5352 @ 200 MHz
RAM: 16 MB
Memória flash: 4MB
Figura 6 – Linksys WRT-54GL.
2.2 Implantação do Zabbix
Diversas ferramentas foram estudadas para a gerência e monitoramento da rede
sem fio indoor da Universidade e a melhor opção encontrada foi o sistema de monitora-
mento de rede Zabbix, por ter um agente no repositório do openWRT disponível e pela
facilidade de instalação e flexibilidade para monitorar itens padrões, bem como personali-
zar itens através de comandos remotos e scripts, além disso, o Zabbix possui ferramentas
para geração de relatórios e gráficos.
O Zabbix usa a arquitetura Cliente/Servidor, e faz o monitoramento dos hosts
tanto por recursos dos seus agentes remotos quanto pelo protocolo SNMP. A sua implan-
tação dá-se em três etapas:
1. Instalação e configuração do Servidor.
2. Instalação e configuração dos Agentes

3. Customização do template.
Na primeira etapa, prepara-se a máquina que receberá os dados de monitoramento
pela configuração de banco de dados, instalação do NMS por repositório ou pelo código
fonte e a instalação de servidor web para acesso por meio do frontend. A segunda etapa,
faz-se a instalação dos agentes nos equipamentos à serem monitorados, essa fase envolve
a instalação de dependências e as alterações no arquivo de configuração do agente. A
terceira etapa, refere-se à configuração daquilo que o administrador pretende monitorar,
tais como uso de memória, disco, processamento, tráfego de rede etc. Pode ser pela criação
de um template ou pela alteração de um existente, criando itens, gráficos e os seus alertas
caso haja necessidade. Essas configurações finais são feitas através do frontend web.
2.2.1 Instalação do Servidor
Na instalação do Zabbix Server, optou-se por fazer o download do código fonte da
versão 2.0.4 (atualmente a stable é a versão 2.0.6), e compila-lo de modo a habilitar todos
os recursos disponíveis (snmp, jabber etc.). Também optou-se por utilizar uma base de
dados Mysql, pela maior simplicidade na instalação e manutenção, portanto abaixo serão
listados os requisitos de software para a instalação:
∙ php5
∙ mysql-server-5.1
∙ mysql-client-5.1
∙ apache2
∙ php5-mysql
∙ libapache2-mod-php5
∙ php5-gd
∙ libnet-snmp-perl
∙ build-essential
∙ libphp-jabber libnet-jabber-perl
∙ php5-curl
∙ libcurl4-openssl-dev
∙ libiksemel-dev libiksemel-utils libiksemel3

O processo de compilação é simples, mas demorado. Antes disso é necessário ins-
talar as dependências para evitar erros durante o processo, também é importante que já
tenha a base de dados para a aplicação. A seguir, listarei os passos necessários:
1. Instalação das dependências listadas acima.
2. Criação de um banco de dados, com usuário e senha.
3. Popular a base de dados com os arquivos schema.sql, data.sql e images.sql, contidos
no tarball. Esses arquivos fazem parte do frontend.
4. Entrar no diretório do source code e executar o configure com os seguintes parâme-
tros:
$ ./configure --enable-server --enable-ipv6 --with-mysql --with-net-snmp
--with-jabber --with-libcurl --with-ssh2
5. Compilar e instalar:
# make install
6. Também é recomendado inserir as portas utilizadas pela aplicação no arquivo /etc/services,
caso não estejam.
zabbix-agent 10050/tcp #Zabbix Agent
zabbix-agent 10050/udp #Zabbix Agent
zabbix-trapper 10051/tcp #Zabbix Trapper
zabbix-trapper 10051/udp #Zabbix Trapper
7. Agora basta criar o diretório no apache para o frontend e copiar os arquivos do site:
$ mkdir /var/www/zabbix
$ cd frontends/php
$ cp * -R /var/www/zabbix/
2.2.1.1 Configuração
Feito isso, já é possível acessar a interface web para concluir a instalação por
um assistente, que ajudará à gerar o arquivo de configuração zabbix_server.conf, com as
configurações de banco de dados e outros detalhes.
O acesso web é feito pela URL: http://[ip_do_servidor]/zabbix, na figura 7 é
possível ver o assistente de instalação:

Figura 7 – Assistente de instalaçao do zabbix.
Clicando em Next, serão checados alguns itens de configuração do servidor web
para que a aplicação rode em perfeitas condições. A figura 8, mostra um cenário possível
em que necessita de ajustes.
Figura 8 – Falha na checagem.
Os parâmetros mostrados na figura 8 acima, podem ser ajustados no arquivo
php.ini, na terceira coluna é possível ver o valor requerido e configurá-lo corretamente.
Feito isso, basta clicar em Retry, para uma nova checagem.

Figura 9 – Checagem bem sucedida.
Continuando a configuração pelo assistente, vamos configurar as credenciais de
acesso ao banco de dados criado. Database Type é o tipo de banco de dados usado, neste
caso, optamos pelo MySql. Preencha os campos de acordo com a figura 9 e clique em
Test connection, caso tenha fornecido as credenciais corretas, será exibido um OK em cor
verde, caso contrário, verifique a base de dados criada.
Figura 10 – Configuraçao do banco de dados.
No próximo passo, você deverá confirmar o endereço do Servidor zabbix e a porta
onde ele escultará as conexões e traps snmp. É recomendado que a porta não seja alterada,

para evitar instabilidade no sistema. Neste caso, nada será alterado. Bastando clicar em
Next.
Figura 11 – Configurando IP e porta de escuta.
Em seguida, será exibido um resumo das configurações realizadas. Essas configura-
ções resultarão em um arquivo que será instalado em /var/www/zabbix/config/zabbix.conf.php,
provavelmente, para uso exclusivo do front-end, já que algumas dessas configurações tam-
bém são definidas no arquivo de configuração do daemon do Zabbix.
Figura 12 – Resumo das configuraçoes.
Quando há problemas de permissão no diretório web do zabbix, provavelmente,

aparecerá um alerta, dizendo que não foi possível gravar o arquivo de configuração no
diretório mencionado. Neste caso, você pode realizar o download do arquivo e gravá-
lo como usuário root, alterar as permissões ou ainda a propriedade de todo diretório
/var/www/zabbix e então tentar gravar novamente (Retry), conforme figura 13.
# chown -R www-data:zabbix /var/www/zabbix
Figura 13 – Falha na gravaçao do arquivo de configuração.
Finalmente, basta clicar em Finish e será redirecionado para a interface de login
do zabbix. Por padrão é:
Username: admin
Password: zabbix
No Zabbix Server, os principais parâmetros a seres ajustados são feitos no arquivo
zabbix_server.conf, localizado em /etc/zabbix/ ou em /usr/local/etc/. Nele são definidos
diretórios padrões para armazenamento de log, porta de escuta das traps snmp, arquivo
do PID do processo, scripts externos e o uso do fping para cheque de disponibilidade.
Foi planejado que todos os acessos aos equipamentos clientes se daria a partir
do servidor, portanto, para acessar por ssh ou transferir qualquer arquivo para o AP, o
administrador entraria remotamente no servidor e dispararia o comando para um host
específico. Todos os scripts e pacotes que devem ser instalados nos AP’s estão em um
diretório específico no servidor, para que sejam copiados via protocolo de transferência
seguro. Essas transferências e acessos à diversos equipamentos, são extremamente onerosas

Figura 14 – Interface de login.
para qualquer administrador de redes, por isso, optou-se em realizar a autenticação ssh
por meio de troca de chaves públicas.
2.2.1.2 SSH por infraestrutura de chaves públicas
A criação das chaves pode ser realizada no linux com o comando:
# ssh-keygen -t rsa -f keyfile-ssh
Será pedido uma senha, mas pode ser deixada em branco, e então o comando
gerará 2 arquivos: o keyfile-ssh que será a chave privada e o keyfile-ssh.pub sendo a chave
pública que deverá ser copiada para todos os hosts, cujo acesso usará autenticação de
chaves públicas. No caso dos APs, ela deverá ser transferida para o diretório específico,
conforme mostrado pelo comando abaixo:
# scp keyfile-ssh.pub [ip]:/etc/dropbear/authorized_keys
É importante ressaltar que o openWRT só permite acesso telnet no primeiro login,
onde é definida uma senha, feito isso, outros acessos deverão ser realizados por ssh ou pela
interface web Luci, que optou-se não instalar por conta da pouca quantidade de memória
disponível.
2.2.2 Instalação do Agentes
O openWRT possui suporte ao zabbix oferecendo pacotes em seu repositório para
utilização como proxy, agente e servidor. A inclusão do zabbix pode ser feita durante a
compilação de uma imagem, pela interface web ou pelo utilitário opkg.

Deve-se observar, no entanto, a arquitetura correta do hardware para evitar con-
flitos. Também é necessário a instalação da biblioteca libcurl, pois é uma depedência do
zabbix-agent.
Para o desenvolvimento do projeto e atendimento de todos os requisitos levantados,
foi necessária a instalação dos seguintes pacotes:
∙ libcurl_7.21.7-1_brcm-2.4.ipk
∙ zabbix-agent_1.6-2_brcm-2.4.ipk
∙ sudo_1.7.8p1-1_brcm-2.4.ipk
2.2.2.1 Configuração do Agentes
Nos agentes, o principal arquivo de configuração é o zabbix_agentd.conf, nor-
malmente localizado no diretório/etc/zabbix. Os principais atributos que precisam ser
alterados são:
∙ Server, que é o endereço IP do servidor para o qual serão mandadas requisições e
os dados coletados.
∙ Hostname, é o nome do host e deve ser o mesmo cadastrado no Zabbix Server,
quando incluído o host monitorado pelo frontend.
∙ EnableRemoteCommands, deve ser igual a 1 (um) quando deseja-se executar co-
mandos remotos por algum ítem.
∙ UserParameter, onde são customizados comandos e checagens executadas pelo agente.
Uma das grandes vantagens do Zabbix, é a variedade de recursos que permitem
que a informação seja coletada de várias formas simples.
A principal estratégia adotada para coletar dados importantes que atendessem os
requisitos levantados, foi o de utilizar chamadas remotas de scripts criados no openWRT,
para consolidar os dados que serão enviados para o servidor, essa estratégia é interessante,
pois permite que outras aplicações também façam uso dos resultados retornados. Outra
estratégia usada foi a funcionalidade de geração de script do frontend, esse recurso se difere
do primeiro, pois nesse caso, o script não fica armazenado no AP, e sim no Servidor, que
executa-o remotamente através do agente. Também foi utilizado o ítem específico para
execução de comandos atômicos que é o system.run[“comando”].
Através dessas estratégias, foi possível coletar grande parte dos dados que atendem
os requisitos levantados, assim como outros que ajudarão a equipe no diagnóstico de
problemas na rede, tais como, canal de operação do AP, quantas redes consegue enxergar

em sua vizinhança, o número de usuários associados e a potência do sinal. A seguir será
explicado com mais detalhes o processo para cada um dos requisitos.
2.2.2.1.1 Canal
É sabido que diferentes equipamentos próximos que compartilham o mesmo canal,
criam interferência que aumentam a perda de pacotes. Todos os rádios instalados pela
equipe de TI da universidade, são configurados em canais não conflitantes, entretanto,
não é raro encontrar outros equipamentos instalados dentro de salas, configurados sem
esta preocupação.
Para coletar essa informação, foi desenvolvido um script em shell, que é compatível
com o chipset broadcom usado pelos equipamentos Linksys.
Script get_channel.sh
export PATH=/bin:/sbin:/usr/bin:/usr/sbin;
devname=$(uci get wireless.@wifi-iface[0].device)
iwlist $devname channel | grep Current| cut -d’:’ -f2 > /tmp/channel
O comando iwlist é um utilitário que retorna características de operação da inter-
face, sua saída é tratada para obtenção apenas do canal de operação, o resultado é então
armazenado no arquivo /tmp/channel, que será lido pelo agente e enviado para servidor.
2.2.2.1.2 Potência
A potência é outra característica que pode prejudicar na comunicação entre equi-
pamentos que operam na faixa 2.4GHz. Para evitar ruídos e interferência entre equipa-
mentos, a potência precisa ser controlada. Abaixo, o script usado para obter a potência
de operação.
Script get_powerl.sh
iwlist $devname txpower | grep Current | cut -d’:’ -f2 | awk ’{print $1}’ > /tmp/power
Também aqui é usado o utilitário iwlist e o resultado consolidado é armazenado
no arquivo /tmp/power.
2.2.2.1.3 Serviço de NTP
Para manter um histórico confiável dos eventos e log dos equipamentos, é fun-
damental que os mesmos estejam com seus relógios sincronizados. Para isso, é usado o

protocolo NTP (Network Time Protocol), que usa um servidor de horas para atualizar o
relógio via rede. O openWRT possui o utilitário ntpdate, bastante difundido no cenário do
software livre e foi criado um script com essa aplicação para atualizar os equipamentos.
#!/bin/sh /etc/rc.common
ntpclient -i 5 -s -h 10.15.1.5
2.2.2.1.4 Reboot remoto
Para reiniciar os equipamentos remotamente, é usado o script reboot.sh.
reboot -f
2.2.2.1.5 Identificação das redes próximas
Para obter o número de redes presentes no mesmo espaço e ter um indicativo da
quantidade de equipamentos foi criado o script scan.sh, que coleta de sua interface wireless
as redes alcançáveis no entorno.
iwlist $devname scan > /tmp/scan
exit 0
2.2.2.1.6 Usuários associados
O script coleta o endereço MAC dos usuários nele associados.
rm /tmp/sta.txt
#remover sta linha quando nao houver necessidade da primeira ser em branco
echo " " >> /tmp/sta.txt
iw wlan0 station dump > /tmp/sta_tmp.txt
cat /tmp/sta_tmp.txt | while read LINE ; do
TEST=$(echo $LINE | awk ’{ print $1 }’)
if [ $TEST = "Station" ]
then
TEST=$(echo $LINE | awk ’{ print $2 }’)
echo $TEST >> /tmp/sta.txt
fi

done
rm /tmp/sta_tmp.txt
Além desses scripts, também foram criados outros para alteração de canal e potên-
cia para uso futuro. Todos os scripts estão armazenados dentro do diretório /etc/scripts
criado no openWRT. Para que sejam usados pelo usuário zabbix criado na instalação do
zabbix-agent, os scripts precisam ter permissão de execução concedida pelo comando:
# chmod +x /etc/scripts/*
A instalação do pacote sudo, que possibilita a execução de alguns comandos presen-
tes nos scrips, como reboot e criação de arquivos no diretório /tmp. Portanto, é necessário
adicionar a seguinte linha no arquivo /etc/sudoers, que insere o usuário zabbix no grupo
de super-usuário com todos os privilégios e permite que execute comandos sem que a
senha seja solicitada.
zabbix ALL=(ALL) NOPASSWD: ALL
Antes de passarmos para a próxima fase, em que efetivamente vamos inserir os
AP’s como hosts a serem monitorados pelo zabbix e configurar o itens. Vamos criar
nossas chaves, que são comandos personalizados para coleta de dados diversos. Com as
chaves, é possível executar comandos remotos e scripts, com passagem de parâmetros,
elas são definidas no arquivo /etc/zabbix/zabbix_agentd.conf, na sessão UserParameter.
A seguir, o exemplo das chaves criadas no arquivo:
UserParameter=radio.assoclist,sudo /etc/scripts/sta.sh;cat /tmp/sta|wc -l
UserParameter=radio.channel,sudo /etc/scripts/get_channel.sh;cat /tmp/channel
UserParameter=radio.power,sudo /etc/scripts/get_power.sh;cat /tmp/power
A execução dos comandos acima, devolve resultados núméricos que são enviados
para o servidor. É possível testa-los através do servidor pelo seguinte comando:
$ zabbix_get -s 192.168.14.2 -k “radio.assoclist”
$ 2
Onde -s indica o endereço IP do agente para o qual a requisição será enviada e o
-k indica a chave que será coletada. Na segunda linha é exibida a resposta enviada pelo
agente remoto.

2.2.3 Gerenciamento de dispositivos
A gerência dos dispositivos é iniciada com a customização de um template no
frontend do Zabbix server, onde cada host é associado à um grupo e um perfil de monito-
ramento, que caracterizam os itens monitorados, alertas e gráficos gerados (SIA), 2012).
A interface web do zabbix server pode ser vista abaixo, na tela inicial é mostrada
uma visão geral dos hosts monitorados, com alarmes, número de hosts up e down, esta
tela pode ser acessada pelo menu Dashboard.
O menu é formado por abas e sub-abas na parte superior da tela. As principais
são as abas Monitoramento e Configuração, que serão mais detalhadas neste trabalho.
Na aba Monitoramento, é possível ter acesso às seguintes Sub-Abas:
∙ DashBoard: resumo dos eventos e exibição dos alertas.
∙ Visão Geral: São todos os itens monitorados em todos os hosts de um determinado
grupo.
∙ Web: São cenários customizados para facilitar o acesso ao conteúdo desejado e or-
ganização do frontend.
∙ Dados recentes: São os últimos dados coletados dos hosts, organizados por aplicação.
∙ Triggers: Exibe os alertas e o status dos itens monitorados.
∙ Eventos: Exibe os eventos que dispararam alertas recentes, organizados por data.
∙ Gráficos: Exibe os gráficos dos itens configurados por host.
∙ Telas: Exibe diagramas visuais que podem ser usados para facilitar o monitoramento
de uma determinada topologia.
∙ Mapas: Permitem que o diagrama seja montado sobre um mapa, para facilitar a
visualização do status dos enlaces e depuração de erros nos equipamentos.
∙ Autobusca: é um recurso que facilita a localização e inclusão de hosts no sistema de
monitoramento.
∙ Serviços de TI: Exibe uma espécie de relatório sobre serviços cadastrados e seu
respectivo SLA.
Na aba Configuração, todos os recursos exibidos em Monitoramento são criados e
configurados. As principais configurações realizadas neste menu foram:

Figura 15 – Interface de login.
∙ Grupo de hosts: Aqui são criados grupos de hosts para facilitar na exibição de confi-
guração e associação de templates. Primeiramente, foi criado um grupo temporário
para que o recurso de Auto-busca fosse empregado, depois que os equipamentos fos-
sem localizados, eles seriam inseridos no grupo AP onde herdariam as configurações
e itens desejados.
∙ Template: Os templates são configurações de itens, gráficos e outras características

de monitoramento. Depois de customizado o template, basta adicionar o host ou
um grupo para que ele assuma aquela customização. A seguir, esse processo será
detalhado.
∙ Hosts: Aqui são exibidos os hosts e seu status de monitoramento, bem como a que
template ele está associado, é possível alterar o status de um host e acessar suas
configurações de template.
2.2.3.1 Criando um template
Templates são customizações que combinam itens, alertas e gráficos. Um novo
template pode ser criado no menu Configurações e pode conter outros templates como
forma de poupar trabalho, aproveitando itens e gráficos existentes.
Para atender os objetivos definidos no trabalho, foi utilizado um template criado
pela comunidade openWRT.org1
. Entretanto, o template precisou de ajustes e de que
novos itens e gráficos fossem inseridos. Na figura 16, é possível visualizar a estrutura do
template.
Figura 16 – Template openWRT.
2.2.3.2 Criando itens
Os itens que precisaram ser adicionados são àqueles que referem-se aos requisitos
levantados, e para os quais criaram-se os scripts para coleta. Agora, vamos cadastrar
esses itens para realizar a coleta dos dados e manter na base de dados. Primeiro deve-se
selecionar o template e em seguida, clicar no link itens do respectivo template.
Uma visão geral dos itens cadastrados será exibida e clica-se no botão “Criar ítem”
localizado no canto superior direito da tela.
Uma nova tela será exibida para cadastro de um novo ítem. Deve-se primeiramente
escolher um nome para o ítem, em seguida definir a chave de coleta (configurada no
1
https://dev.openwrt.org/changeset/36740

Figura 17 – Inserindo itens no template1.
UserParameter do agente), feito isso é só definir o tipo de dado coletado, a frequência da
coleta e informar como esse dado será armazenado. Os itens criados e as suas respectivas
chaves foram:
∙ Potência:
– Chave: radio.power
Executa o script get_power.sh instalado nos equipamentos.
∙ Tráfego incoming na interface:
– Chave: net.if.in[interface]
Esta chave já vem implementada pelo zabbix server e coleta o tráfego entrante de
uma determinada interface.
∙ Tráfego outcoming na interface:
– Chave: net.if.in[interface]
Esta chave já vem implementada pelo zabbix server e coleta o tráfego oriundo de
uma determinada interface.
∙ Usuários associados:
– Chave: radio.assoclist
Esta chave utiliza o script sta.sh instalado nos equipamentos.
∙ Canal:
– Chave: radio.channel
Esta chave chama o script get_channel.sh instalado nos equipamentos.

∙ Scan redes:
– Chave: system.run["sudo iwlist wl0 scan | grep -c ESSID"]
Esta chave usa um ítem já implementado por padrão no zabbix, que é o sys-
tem.run[comando] e permite a execução de comandos remotos.
Figura 18 – Configurando os itens.
2.2.3.3 Inserindo um host
O primeiro passo, deve ser a criação de um grupo para organizar os dispositivos.
Cria-se um novo grupo em Configurações > Grupo de hosts, em seguida clicar no botão
superior direto “Criar grupo de hosts”.
Para inserir um novo host, basta ir à aba Configuração > Hosts e clicar em “Criar
host”. Na próxima tela, as principais informações à serem inseridas são:
∙ Nome do host: Deve ser o mesmo nome cadastrado na linha Hostname do arquivo
de configuração zabbix_agentd.conf.
∙ Nome de exibição: Campo de preenchimento não obrigatório, caso vazio é usado o
Nome do host.
∙ Grupos: Selecionar o grupo na coluna à direita e adicionar à coluna esquerda.

∙ Interface do agente: Considerando que o agente já esteja instalado e configurado no
host. Basta inserir o IP e a porta utilizada recomenda-se não alterar.
∙ Interface SNMP: Nesta versão do zabbix, pode-se realizar o monitoramento tanto
pelo agente, quanto pelo protocolo SNMP. Caso deseje-se combinar as duas moda-
lidades, basta adicionar aqui o endereço IP do host.
Na aba Templates, adiciona-se o template Openwrt importado e clicando em “Sal-
var”, o host é inserido.
Figura 19 – Inserindo um host.
2.2.3.4 Criando um gráfico
Para criar gráficos é necessário ter os itens coletando, basicamente ele utilizará a
mesma técnica utilizada pelo NMS Cacti, funcionando como uma interface gráfica para
os dados coletados e armazenados pelo RRDtool. Isso garantirá a persistência dos dados
ao longo de um período definido na criação do ítem e exibirá o resultado no gráfico.
É importante conhecer o tipo de dados que será exibido, caso contrário, o gráfico
pode exibir informações consistentes, sobretudo quanto à unidade de medida e tipo de
dado. No momento da criação, o Zabbix oferece várias opções que podem ser usadas,
assim é possível escolher a que melhor se adeque à informação que será exibida.

Na aba de Configuração e clique em Novo Gráfico. Na caixa de diálogo que será
aberta, dê um nome ao gráfico, defina caso desejável, a forma do gráfico - existem várias
opções disponíveis, tais como: gráfico em pizza, pilha etc. É possível monitorar vários ítens
em um mesmo gráfico, dividindo os itens por cor ou tipo de linha. Também é possível
determinar sobre que base ele gerará o gráfico: AVG, media, máximo, mínimo.
Figura 20 – Usuários associados.
Na figura 20, é possível ver o gráfico criado para monitorar a quantidade de usuários
em um Ponto de Acesso, enquanto que na figura 21, outro tipo de gráfico é usado para
exibir o tráfego de pacotes nas interfaces wireless do AP.
Figura 21 – Tráfego entrante.

53
3 Resultados Obtidos
Dentro daquilo que nos propomos a fazer neste trabalho, desenvolvendo conheci-
mentos adquiridos durante a formação e apoiando as necessidades da equipe de TI foi
possível dar maior garantia aos usuários desse serviço.
Quanto à análise de disponibilidade, que foi o primeiro requisito levantado, a fer-
ramenta atende perfeitamente o administrador somente com seus recursos nativos, entre-
tanto, é possível otimizar essa análise através de implementações outras. Na Figura 22,
observa-se um gráfico de disponibilidade por meio de ping.
Figura 22 – Monitoramento da disponibilidade.
Outro recurso para checagem de disponibilidade, além das trigguers do Dashboard,
que mudam a cor de hosts indisponíveis, é o ping sobre. host. Ainda no Dashboard,
basta clicar sobre um host específico com o botão direito e escolher uma das opções:
ping, traceroute, nmap, usuários conectados etc. Alguns desses foram implementados para
otimizar a análise.
Figura 23 – Análise do tempo de resposta com o ping.
Quanto ao monitoramento de tráfego entrante, é possível obsevar nos gráficos, que

54 Capítulo 3. Resultados Obtidos
a interface eth0.11, referente à rede visitante, possui um uso bem mais expressivo que as
demais (Figura 21), e isso deve-se obviamente à ausência de autenticação. Já no gráfico
de saída, observa-se que a interface de wireless é bem mais usada que as interfaces físicas
ethernet presentes (Figura 24), conforme já é esperado, entretanto, esse monitoramento
é importante para verificar se em algum lugar, existem usuários tentando navegar pelas
portas físicas.
Figura 24 – Tráfego outgoing na interface.
Quanto ao monitoramento dos recursos físicos do rádio, coletamos uso de processa-
mento e memória. A ideia era depurar, porquê certos equipamentos travavam, entretanto,
após análise desses itens descobrimos que o problema não se dava por esgotamento dos
recursos e sim pela fonte de energia AC que lhe era entregue.
Figura 25 – Uso da CPU.

55
Figura 26 – Uso da memória.
Quanto à quantidade de acessos, logrou-se resultado quanto à coleta de endereços
MAC’s simultâneos conectavam-se ao AP, esta coleta resultou em um gráfico de usuários
associados, conforme pode ser visto na Figura 20. Outro recurso implementado foi o
de coleta no dashboard, que permite não só a visualização do número de usuários, mas
também o MAC address dos mesmos
Figura 27 – Coleta de usuarios associados e endereços MAC.
Quanto à proporcionar maior facilidade para acesso e configuração do AP, achamos
que seria possível abrir um terminal ssh como recurso adicional no dashboard, entretanto
essa feature não foi implementada completamente. O que conseguimos nesse sentido foi
implementar autenticação por chave pública, assim o usuário não precisa ficar digitando
senha em cada acesso feito. Também, implementamos comandos remotos para os princi-
pais problemas encontrados no dia-a-dia, para o ajuste de data/hora foi criado um script

56 Capítulo 3. Resultados Obtidos
que atualiza o ntp no rádio e também o recurso para reboot fácil, que antes exigia acesso
ssh e execução do comando
Alguns problemas encontrados, foi principalmente no que diz respeito à geração de
relatórios. O Zabbix mostrou-se excelente para criação de relatórios por hosts, entretanto,
caso necessite ter uma ideia geral por ítens, de todos os hosts não é possível. Por exemplo,
caso se deseje saber o quantitativo total de usuários que acessaram a rede sem fio por um
mês, o administrador teria que coletar o total em cada AP e somar o resultado.

57
Conclusão
Todas as ferramentas ou técnicas de gerenciamento são de algum modo sustenta-
das por protocolos, por esta razão faz-se necessário o conhecimento sobre a normalização
dessas tecnologias. Este trabalho foi fortemente subsidiado pelos documentos oficiais de
institutos internacionais, tais como: IEEE e IETF. Houve também o esforço, no sen-
tido de simplificar a linguagem e enfatizar os aspectos diretamente relacionados com o
tema abordado. Nenhuma ferramenta, obviamente, vem preparada para a atender todos
os anseios de uma organização, o mais importante, é que ela ofereça oportunidade de
adequação e configuração, pois os cenários mudam e deseja-se ferramentas flexíveis que
possam acompanhar essas mudanças.
Espera-se que o leitor consiga absorver essa base teórico-tecnica para que possa
aplicar esse conhecimento em seu ambiente de trabalho.

59
Referências
ANJOS, J.; MOURA, I.; FERREIRA, D. Manual de Utilização do Zabbix 1.6. [S.l.], 6
2009. Disponível em: <http://homepages.dcc.ufmg.br/~gilson/zabbix.pdf>. Acesso em:
11.3.2013. Citado na página 28.
DUARTE, O. C. M. B. Simple Network Management Protocol. 2010. Disponível em:
<http://www.gta.ufrj.br/grad/10_1/snmp/mibs.htm>. Citado na página 26.
GARCIA, L. G. U. Redes 802-11 (Camada de Enlace). 2003. Disponível em:
<http://www.gta.ufrj.br/grad/01_2/802-mac/R802_11-5.htm>. Citado na página 24.
GNU General Public License, version 3. June 2007. <http://www.gnu.org/licenses/gpl.
html>. Last retrieved 2012-05-10. Citado na página 30.
Intel Corporation. Excerpts from A Conversation with Gordon Moore: Moore’s Law. 2005.
Disponível em: <ftp://download.intel.com/museum/Moores_Law/Video-Transcripts/
Excepts_A_Conversation_with_Gordon_Moore.pdf>. Citado na página 30.
LIMA, H. M. de; DUARTE, O. C. Accumulative acknowledgement error recovery
schemes in high speed environments. [S.l.], 1993. Disponível em: <http://opac.inria.fr/
record=b1030775>. Citado na página 24.
OPENWRT. OpenWRT: Wireless Freedom. 2013. Disponível em: <https://openwrt.
org>. Citado na página 30.
SIA), A. V. Z. ZABBIX The Enterprise-class Monitoring Solution for Everyonel. 2012.
Disponível em: <http://www.zabbix.com/documentation.php>. Citado na página 45.
ZABBIXBRASIL.ORG). Conheça o Zabbixl. 2012. Disponível em: <http://zabbixbrasil.
org/?page_id=59>. Citado na página 28.

Sistema de monitoramento para redes sem fio com Zabbix e openWRT

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Sistema de monitoramento para redes sem fio com Zabbix e openWRT

Semelhante a Sistema de monitoramento para redes sem fio com Zabbix e openWRT (20)

Sistema de monitoramento para redes sem fio com Zabbix e openWRT