Bloqueando broadcast no rádio Mikrotik

Recentemente, adquirimos dois rádios da Mikrotik para interligar a unidade principal da empresa a um prédio que fica próximo, alguns metros de distância. Os rádios foram instalados nos dois locais e configurados no modo bridge. Desta forma, todos os pacotes são encaminhados entre os rádios, gerando um problema: se tudo é transferido para a outra ponta, o tráfego broadcast também e? A resposta é sim!

Isso gerou vários transtornos, pois eles interligam duas sub-redes com faixa de endereços IP diferentes, porém, com o broadcast viajando pra todo lado, uma estação ao ser ligada, por exemplo, enviava um broadcast solicitando um endereço IP para um servidor DHCP e, às vezes, recebia resposta do que estava instalado em outra sub-rede.

Bem, após várias consultas ao Google, encontrei um fórum onde simplesmente era dito que se deveria "criar um filtro para o tráfego de broacast na bridge". Legal, mas e aí, onde raios fica isso? Bem, resolvi escrever este artigo, pois ele complementa, explicando como realizar a tal configuração.

Outro comentário que gostaria de fazer é que também foi criado um filtro para bloquear os pacotes arp, pois, ele só é utilizado na comunição de computadores em uma mesma sub-rede.

Bem, vamos a obra.

Gostaria de lembrar que na interface web do rádio não há esta opção. É necessário utilizar o winbox.

Após efetuar o logon, na tela inicial, clique em Bridge.

Em seguida, será aberta a tela de configuração da bridge. Vá na aba Filters e clique no botão indicado na figura abaixo.

Primeiramente, vamos criar o filtro que bloqueia os pacotes arp. Assim, nas configurações do novo filtro, deve-se escolher o chain FORWARD, o qual é aplicado aos pacotes que trafegam através do rádio, de uma interface a outra. As configurações devem ficar iguais a exibida na figura abaixo.

Para finalizar, é necessário acessar a aba Action e escolher drop.

Após clicar em OK, o filtro será criado.

Agora, vamos para a criação da regra que bloqueia o broadcast.

Na tela de criação do novo filtro, com exceção da opção MAC Protocol, as demais são iguais a do filtro para o protocolo arp.

Em seguida, deve-se acessar a aba Advanced e em Packet Type selecionar Broadcast.

Para finalizar, escolha drop na aba Action e clique em OK para salvar as alterações.

Após a criação dos filtros, eles serão exibidos conforme abaixo.

Um abraço e até a próxima.

Monitorar "Event Viewer" do Windows no Zabbix através do SNMP

Uma das tarefas que fazem parte da rotina de um administrador de redes é verificar com certa frequência os logs de eventos dos servidores em busca de erros. Dependendo da quantidade de máquinas contidas na empresa, esta atividade pode se tornar tediosa e cansativa.

Na empresa onde trabalho utilizamos o Zabbix para monitorar nossos servidores. Entretanto, as verificações se restringiam a itens como uso de processador, memória, rede, disco, entre outros. Os eventos gerados pelo sistema operacional ainda eram necessários ser visualizados, individualmente, em cada servidor. Em pesquisas pela internet, encontrei o artigo Trapping Windows Events with SNMP, escrito por Eric A. Hall, o qual ele descreve como configurar o serviço SNMP do Windows para enviar traps a uma estação coletora quando ocorrer algum evento no sistema operacional.

Primeiramente, é necessário configurar o agente SNMP do Windows para enviar os traps a uma estação coletora, no nosso caso, o servidor Zabbix. Este procedimento pode ser visto neste artigo da Microsoft.

A ferramenta chama-se Event to trap translator e pode ser acessada acessando o menu Iniciar > Executar > evntwin. Na tela inicial, deve-se selecionar a opção Custom na seção Configuration type. Isso ativará o botão Edit. Ao clicar nele, a janela expandirá um painel abaixo onde iremos selecionar os eventos que desejamos ser alertados através do Zabbix.

É possível selecionar todos os eventos, porém isto acarretaria em sobrecarga do servidor de monitoramento, pois o Windows grava entradas no log, frequentemente, sendo que a maioria é apenas informativa. 

No meu caso, optei por selecionar apenas os erros ou alertas de warning, e dos serviços específicos daquele servidor. Por exemplo, uma máquina que possui Oracle instalado, ativei os traps dos erros deste software.

Para habilitar o envio de traps por algum evento, navegue pelas pastas contidas do lado esquerdo da tela até encontrar a sessão desejada. Desta forma, do lado direito aparecerão os eventos relacionados.

Após decidir quais eventos serão configurados, basta selecioná-los e clicar no botão Add. Após terminar o processo, basta clicar em OK para salvar e encerrar o aplicativo. Este processo pode demorar alguns minutos dependendo da quantidade de eventos selecionados.

É possível também exportar o que foi alterado visando possuir um backup das configurações. Basta selecionar os eventos já configurados e escolher Export.... Será solicitado um caminho para salvar o arquivo gerado, que possui a extensão cnf. É possível importá-lo depois, caso necessário, utilizando o comando evntcmd.

Agora vamos ao Zabbix.

No servidor de monitoramento, primeiro precisamos editar o serviço SNMP (Net-SNMP). As configurações abaixo foram feitas em um servidor com o Ubuntu Server instalado.

Primeiro deve-se editar o arquivo /etc/default/snmpd alterando a linha:

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1'

Para:

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid'

E a opção TRAPDRUN conforme abaixo:

TRAPDRUN=yes

Depois, precisamos alterar o arquivo /etc/snmp/snmptrapd.conf, inserindo as linhas abaixo:

traphandle default /bin/bash /var/zabbix/bin/snmptrap.sh

authCommunity log,execute,net ComunidadeSNMP

O parâmetro ComunidadeSNMP deve possuir o nome da comunidade SNMP utilizada na sua rede. O caminho /var/zabbix/bin/snmptrap.sh no seu ambiente.

Na pasta misc/snmptrap do pacote de instalação do Zabbix, possui o arquivo snmptrap.sh. Ele deve ser copiado para o diretório indicado no parâmetro traphandle default do arquivo /etc/snmp/snmptrapd.conf conforme exibido acima.

Abaixo há um exemplo do arquivo snmptrap.sh.

#!/bin/bash
ZABBIX_SERVER="localhost"; #IP ou hostname do servidor Zabbix
ZABBIX_PORT="10051";   # Igual ao parametro 'Listen Port' do zabbix_server.conf

#No parametro abaixo, verificar o local do executavel zabbix_sender
ZABBIX_SENDER="/usr/local/bin/zabbix_sender";     # insert you path

read hostname
read ip
read uptime
read trapoid
read payload
 

hostname=`echo $hostname|cut -f1 -d' '`

payload1=`echo $payload|cut -f2- -d' '`   

read payload
payload2=`echo $payload|cut -f2- -d' '`
read payload
payload3=`echo $payload|cut -f2- -d' '`
read payload
payload4=`echo $payload|cut -f2- -d' '`
read payload
payload5=`echo $payload|cut -f2- -d' '`

str="[$hostname] - $payload1 $payload2 $payload3 $payload4 $payload5"

KEY="snmptraps";
HOST="TRAPSERVER";

$ZABBIX_SENDER -z $ZABBIX_SERVER -p $ZABBIX_PORT -s $HOST -k $KEY -o "$str"

Em seguida, é necessário reiniciar o daemon snmpd:

# /etc/init.d/snmpd restart

A próxima etapa, corresponde a configuração dos itens na interface web do Zabbix. Primeiramente, é necessário adicionar um novo host.

  

Na criação do item que tratará os traps SNMP, podería-se associá-lo ao host, diretamente, mas, honestamente, prefiro a criação de um novo template e a adição do item e do trigger no mesmo. Desta forma, após a criação do template, adicionar ao mesmo o item conforme a figura abaixo:

Depois, adicionamos um novo trigger ao template.

O trigger permitirá que os eventos sejam exibidos na Dashboard por 60 segundos. Se desejar, pode-se criar uma ação que envia um alerta por e-mail, por exemplo.

Finalmente, associamos o template ao host, que receberá os traps, criado anteriormente.

Pronto! O Zabbix passará a receber eventos gerados pelos servidores Windows. Abaixo a um exemplo de e-mail enviado pelo Zabbix contendo um evento gerado por um servidor Windows.

Um abraço e até a próxima!

Monitorando tráfego de rede no Zabbix utilizando o SNMP.

Após pesquisa na internet visando fontes que mostrassem como verificar o tráfego de rede no Zabbix, utilizando-se o protocolo SNMP, encontrei uma em especial que sugeria a criação de um item apontando para o OID do objeto de octetos transferidos na MIB. Era mostrado que o índice a ser utilizado era 65539, 65540, assim por diante.

Verificando a MIB de todos os servidores aqui da empresa percebi que alguns o índice era 16777219, por exemplo. Como tenho um template associado a todos os servidores para monitorar uma interface conectada a determinada sub-rede, seria necessário criar itens específicos para as exceções.

Decidi contornar isso criando um shell script que pode ser utilizado para monitorar uma interface ligada em qualquer sub-rede da empresa e tanto o tráfego de saída, quanto de entrada.

Por exemplo, supondo que a empresa possua as seguintes sub-redes:

• Rede-local: 172.16.0.0/16.
• Rede-Servidores: 10.1.1.0/24.
• DMZ (Rede de perímetro): 192.168.60.0/24.

Com as informações acima, deve-se criar um arquivo na pasta de scripts externos do Zabbix (verificar parâmetro ExternalScripts do arquivo zabbix_server.conf), para este artigo, utilizarei o nome trafegointerface.sh, com o conteúdo abaixo.

#!/bin/bash
# Criado por Rafael Oliveira
# Primeiro parametro IP do host, segundo SL (Redes dos servidores), L (Rede local), DMZ (Rede de perimetro)
# terceiro I (Incoming) O (Outgoing), quarto versao do SNMP e quinto comunidade.
COMUNIDADE=$5
VERSAOSNMP=$4
declare RESULTADO=0
if [ "$2" = "L" ]; then
        REDE="172.16";
elif [ "$2" = "SL" ]; then
        REDE="10.1.1";
elif [ "$2" = "DMZ" ]; then
        REDE="192.168.50";
else
        REDE=$1
fi
INDEX=`snmpwalk -v $VERSAOSNMP -c $COMUNIDADE $1 IP-MIB::ipAdEntIfIndex | grep $REDE | cut -d : -f 4 | cut -d " " -f 2`
if [ "$3" = "I" ]; then
        RESULTADO=`snmpwalk -v $VERSAOSNMP -c $COMUNIDADE $1 IF-MIB::ifInOctets.$INDEX | cut -d : -f 4 | cut -d " " -f 2`
else
        RESULTADO=`snmpwalk -v $VERSAOSNMP -c $COMUNIDADE $1 IF-MIB::ifOutOctets.$INDEX | cut -d : -f 4 | cut -d " " -f 2`
fi
echo $RESULTADO

Lembrando que o script deve ser alterado de acordo com as sub-redes contidas na empresa e os respectivos endereços IPs.

Após salvá-lo, vamos supor que desejamos monitorar o tráfego de rede entrante de todos os servidores conectados à rede de perímetro. Desta forma, podemos criar um template, que será associados a todos eles no Zabbix, com um item que possui as seguintes configurações.

Alguns pontos devem ser observados. No campo Key, os valores 2c e public, correspondem, respectivamente a versão do protocolo SNMP e comunidade. Desta forma, devem ser ajustados conforme sua necessidade. Além disso, I indica que o tráfego monitorado é o entrante para monitorar a saída, deve ser alterado para O.

Outro ponto interessante é referente a opção Custom Multiplier, que é 8. Isso deve ser feito desta forma pois o valor contido na MIB é o número de octetos trafegados.

Com isso, pode-se criar gráficos no Zabbix para uma melhor visualização dos valores e, assim, determinar se há algum gargalo de rede naquele servidor.

Abaixo temos um exemplo de um gráfico com tráfego de rede em uma interface.

Um abraço e até próxima.

Monitorando espaço em disco no Zabbix através do SNMP

Em outro artigo postado anteriormente, tratei acerca do monitoramento de serviços no Zabbix fazendo uso do protocolo SNMP. Continuando a série, vou tratar agora da verificação dos discos (partições) utilizando o mesmo protocolo. 

Vocês podem ser perguntar porque não utilizo o agente para tais tarefas. Afinal, tudo seria mais fácil. Bem, a resposta para a questão é o fato de no passado ter enfrentado problemas de performance em alguns servidores em razão do mal comportamento do agente da ferramenta que consumia muita CPU, em alguns casos, chegando a 100%.

Como a MIB possui todos os dados que necessito para monitorar os servidores, apesar de dar um pouco mais de trabalho, os recursos consumidos pelo agente SNMP em um computador é mínimo e não prejudica sua performance.

Bem, chega de história e vamos ao que interessa. Como fiz no meu outro artigo, Monitorando serviços no Zabbix através do SNMP, criei um shell script que consulta a MIB do sistema operacional, pois o índice da partição pode variar de um computador para outro.

Assim, crie um arquivo no diretório o qual estão armazenado os scripts externos do Zabbix (parâmetro ExternalScripts do arquivo de configuração zabbix_server.conf), no exemplo colocarei discolivre.sh, com o conteúdo abaixo.

#!/bin/bash

# Criado por Rafael Oliveira

# Parametro 1 - Endereco do host

# Parametro 2 - Letra que indica a particao

# Parametro 3 - Sistema operacional

# Inicializa as variaveis

declare TOTAL=0

declare USADO=0

# Comunidade SNMP

COMUNIDADE=monitora

# Obtem o ID do disco na tabela SNMP contida na MIB

if [ "$3" == "linux" ]; then

ID=`/usr/bin/snmpwalk -v 2c -c $COMUNIDADE $1 HOST-RESOURCES-MIB::hrStorageDescr | grep "STRING: $2$" | cut -d : -f 3 | cut -d " " -f 1 | cut -d . -f 2`

else

ID=`/usr/bin/snmpwalk -v 2c -c $COMUNIDADE $1 HOST-RESOURCES-MIB::hrStorageDescr | grep "STRING: $2" | cut -d : -f 3 | cut -d " " -f 1 | cut -d . -f 2`

fi

# Com o ID, realiza a consulta para obter o valor desejado. Primeiro o tamanho, em seguida, o usado.

TOTAL=`/usr/bin/snmpget -v 2c -c $COMUNIDADE $1 HOST-RESOURCES-MIB::hrStorageSize.$ID | cut -d : -f 4 | cut -d " " -f 2`

USADO=`/usr/bin/snmpget -v 2c -c $COMUNIDADE $1 HOST-RESOURCES-MIB::hrStorageUsed.$ID | cut -d : -f 4 | cut -d " " -f 2`

expr $TOTAL - $USADO

Após salvar o arquivo, lembre-se de conceder permissão de execução e alterar o dono para o usuário zabbix.

# chmod a+x discolivre.sh

# chown zabbix.zabbix discolivre.sh

Depois, no template ou host criados no Zabbix, crie um item conforme a imagem abaixo.

Em relação a figura acima, algumas observações precisam ser feitas. 

Na opção Key, os parâmetros do script precisam ser alterados de acordo com o nome da partição e o sistema operacional. Por exemplo, caso deseja-se verificar o volume /home de um servidor com o sistema operacional Linux, ela ficaria da seguinte forma: discolivre.sh[/home linux].

O parâmetro Custom Multiplier pode variar, pois o valor contido na MIB SNMP para o disco não é em bytes e sim em unidades de alocação. Desta forma, antes de defini-lo, é necessário verificar nela o item HOST-RESOURCES-MIB::hrStorageAllocationUnits.[ÍndiceDaPartição]. Este valor é o tamanho do cluster definido na criação do sistema de arquivos.

Depois criar o item para a coleta dos dados, vamos para a criação do trigger. Na criação dele ao inserir a expressão precisamos selecionar o item criado anteriormente com as opções exibidas na tela abaixo.

O valor N da figura acima é 2400000000, ou seja, 2,4 GB. Na criação do item utilizamos a unidade B (bytes). Como 1 GB equivale a 1000000000 (10^9), o valor da expressão precisa ser definido desta forma.

Lembrando que ele pode ser alterado conforme a necessidade da sua empresa. Além disso, lembre-se de definir um nome sugestivo para o trigger como, por exemplo, "Espaço limitado na partição C:". Assim, fica mais fácil identificar o problema quando o mesmo aparecer na Dashboard ou no recebimento de alguma mensagem. 

Monitorando serviços no Zabbix através do SNMP

Uma forma de monitorar o status de um serviço utilizando uma ferramenta de monitoramento é verificando se porta do mesmo está aberta. Por exemplo, poderíamos verificar se a porta 80 está OK e assim supor que o servidor HTTP está operando. No entanto, esta opção pode se tornar inútil se o serviço não responde utilizando sua porta padrão e, com isso, obter dados errôneos.

Uma forma de contornar isso é verificando se o processo correspondente ao serviço está em execução no servidor. Isso pode ser feito através do protocolo SNMP, pois na MIB do sistema operacional há uma tabela com todos os programas abertos naquele momento. Porém, o índice do mesmo pode ser alterado quando o serviço ou o sistema forem reiniciados. A forma que encontrei para contornar este problema foi a criação de um shell script que recebe o nome do executável do processo e retorna 1 caso o mesmo esteja aberto ou 0 para parado.

Este procedimento se aplica ao Zabbix em execução em um servidor Linux. As configurações e instalação das ferramentas SNMP nos sistemas operacionais podem ser encontradas facilmente na internet.

Antes de iniciar o monitoramento através de scripts próprios, é necessário verificar a opção ExternalScripts no arquivo de configuração do servidor Zabbix, geralmente chamado zabbix_server.conf, pois é neste caminho que o software procura os scripts externos criados pelo administrador.

Em seguida, crie um arquivo no diretório citado acima, aqui eu chamo de checaservico.sh com o seguinte conteúdo:

#!/bin/bash
# Criado por Rafael Oliveira
#Comunidade SNMP
COMUNIDADE=public
#Procura o ID do processo na tabela da MIB
IDPROCESSO=`/usr/bin/snmpwalk -v 2c -c $COMUNIDADE $1 HOST-RESOURCES-MIB::hrSWRunName 2> /dev/null | grep $2 | cut -d : -f 3 | cut -d = -f 1 | cut -d . -f 2`
#Retorna o status do mesmo
STATUS=`/usr/bin/snmpwalk -v 2c -c $COMUNIDADE $1 HOST-RESOURCES-MIB::hrSWRunStatus.$IDPROCESSO 2> /dev/null | cut -d : -f 4 | cut -d "(" -f 2 | cut -d ")" -f 1`
#Para o Windows o status de execucao eh 1 no Linux eh 2
if [ "$STATUS" = 1 ]; then
        echo 1;
elif [ "$STATUS" = 2 ]; then
        echo 1;
else
        echo 0;
fi

Lembrando que a variável COMUNIDADE deve ser alterada para o community SNMP utilizada em sua rede.

Após salvar o arquivo, é necessário conceder permissão de execução ao mesmo e alterar o dono para o usuário zabbix, utilizado na execução da ferramenta. Isto pode ser realizado da seguinte forma:

# chmod a+x checaservico.sh

# chown zabbix.zabbix checaservico.sh

Agora vamos a configuração do Zabbix. 

O item pode ser associado a um host ou template. No exemplo, vamos supor que desejamos monitorar o SQL Server. O executável dele chama-se sqlservr.exe. Devemos criar um item no Zabbix com as configurações exibidas na figura abaixo.

O item acima possui outras opções como, por exemplo, Update interval, que pode ser alterada de acordo com sua necessidade. Onde trabalho, utilizo um tempo de 60 segundos para o monitoramento de qualquer serviço.

Após a criação do item, vamos a criação do trigger, pois, a partir dele, será exibido um alerta na Dashboard ou poderá criar-se uma ação para o envio de alguma mensagem.

Deve acessar a opção Configuration > Triggers e selecionar o mesmo template ou host o qual o item acima foi associado. Em seguida, ao escolher a opção de criação do trigger, na linha Expression, clica-se em Insert e seleciona-se o item criado anteriormente conforme exibido abaixo.

Após clicar em Insert é retorna-se a tela de criação do trigger. É necessário inserir um nome para o mesmo.

Após escolher Save, o trigger será criado e, a partir daí, qualquer verificação que retorne um valor 0, ou seja, serviço interrompido, o Zabbix exibirá um alerta na Dashboard.

O procedimento acima pode ser utilizado, inclusive, foi aplicado em um ambiente de produção, tanto para verificação de processos no Windows quanto no Linux.

Backup automático das configurações do ISA Server

Uma forma de efetuar um backup das configurações do ISA Server é através do console de gerenciamento. Pode clicar com o botão direito do mouse sobre o nome do servidor e escolher a opção Back Up... no menu.

O problema deste método e o fato de exigir que o administrador realize o processo, manualmente, toda vez que alguma alteração for efetuada em alguma configuração. A rotina diária com vários problemas acaba fazendo-nos esquecer de realizar tais tarefas.

Assim, para evitar problemas futuros, podemos automatizar este processo. Vamos lá!

Lembrando que este procedimento foi efetuado na versão 2004 do software. Creio que na versão 2006 também funcione. No ISA 2000 o arquivo de backup gerado possui outro formato. Desta forma, este procedimento não se aplica.

Na mídia do ISA Server, no diretório sdk\samples\Admin há um script chamado ImportExport.vbs. Automatização consistem em criar uma tarefa agendada no Windows que o executa.

Assim, após copiá-lo para algum diretório do servidor, basta criar uma nova tarefa agendada, acessando o Painel de controle (Control Panel) > Tarefas agendadas (Scheduled Tasks). Na segunda tela do assistente de criação da tarefa, deve-se selecionar o programa wscript.exe situado no diretório C:\WINDOWS\System32. Após definir o agendamento desejado, deve-se inserir uma conta de usuário com privilégios administrativos no ISA Server. Na tela final, deve-se marcar a opção para exibir as propriedades avançadas.

Na aba Tarefa (Task) a linha Executar (Run) deve ser alterada. Supomos que o arquivo ImportExport.vbs foi copiado para o diretório raiz do disco C:. Assim, ela precisar ficar da seguinte forma:

C:\WINDOWS\system32\wscript.exe C:\ImportExport.vbs //B e "Caminho onde o arquivo de backup será salvo"

A opção //B informa ao wscript que suprimir os erros a serem exibidos e ignorar qualquer pergunta. Isso é necessário pois a tarefa agendada não é executada de modo interativo. A letra e indica que deve ser efetuada a opção de exportação das configurações. 

Será gerado um arquivo no formato xml e o caminho pode ser um drive local ou um compartilhamento remoto. Lembrando que ele deve possui o nome do arquivo a ser gerado com a extensão xml.