Conteúdo Open Source e segurança da informação.

Parque tecnológico da Bahia

noreply@blogger.com (Leonardo Couto Conrado) — Tue, 31 Jan 2012 01:33:00 +0000

A Bahia está muito perto de ter seu primeiro Parque Tecnológico.
Este empreendimento surge para abrigar empresas de base tecnológica, centros de pesquisas, universidades e incubadoras de empresas.

Com alto padrão urbanístico, o empreendimento tem um cuidadoso tratamento paisagístico, preservando parte da cobertura da Mata Atlântica e do seu relevo. Localizado na Avenida Paralela, principal eixo de expansão urbana de Salvador, o Parque Tecnológico da Bahia está próximo ao aeroporto de Salvador, centros de tecnologia, instituições de ensino e conta com conexão de fibra ótica.

O Estado da Bahia dispõe de recursos para apoiar empresas inovadoras que se instalem no parque. São 581.000 m² de área, destinados à geração de conhecimento e de negócios de alto valor agregado.

Entenda como vai funcionar:
http://saudeweb.com.br/video/entenda-como-vai-funcionar-o-parque-tecnologico-da-bahia/

Fonte:
http://www.secti.ba.gov.br/parquetecnologico/

Plugin do Nagios para verificar a fila de e-mails do servidor Qmail

noreply@blogger.com (Leonardo Couto Conrado) — Fri, 20 Jan 2012 17:13:00 +0000

OBS.: O plugin é executado através do NRPE na máquina remota, logo, o script deve ser colocado junto aos outros plugins do nagios na máquina cliente, ou seja, no servidor Qmail e não no servidor Nagios.

Este script ajudará a identificar um possível ataque ao seu servidor de e-mails. Onde uma conta de e-mail do seu dominio provavelmente com uma senha frágil esteja sendo utilizada para enviar uma grande massa de e-mails (SPAM) com destino a endereços e-mails da internet, logo, isso acarretará em uma grande quantidade em excesso de mensagens na fila de envio do seu servidor Qmail atrasando o envio de e-mails verdadeiros. O script checará sempre essa quantidade de mensagens na fila e retornará a saída para o Nagios.

Copie o script abaixo, que irá checar a fila de e-mails, para o diretório de plugins do Nagios no seu servidor Qmail:

# vi /usr/local/nagios/libexec/check_qmail_queue

############################################################### 
# Script checar fila de e-mails do Qmail 
# Por Leonardo Couto Conrado 
# Em 20.01.2012
############################################################### 
#!/bin/sh

OK=0
WARNING=1
CRITICAL=2
UNKNOWN=3

criticalMsgsInQueue=90
warningMsgsInQueue=80

mailQueue=$(/usr/local/bin/qmailctl queue | grep "messages in queue:" | awk -F ":" '{print $2}')

if [ $mailQueue -gt $criticalMsgsInQueue ]; then
        echo "NÚMERO DE MENSAGENS NA FILA ULTRAPASSOU O LIMITE DE CRITICAL, $mailQueue MSGS NA FILA!"
        exit $CRITICAL
fi


if [ $mailQueue -gt $warningMsgsInQueue ]; then
        echo "NÚMERO DE MENSAGENS NA FILA ULTRAPASSOU O LIMITE DE WARNING, $mailQueue MSGS NA FILA!!"
        exit $WARNING

        else
                echo "NÚMERO DE MENSAGENS NA FILA ESTÁ OK, IGUAL A $mailQueue MSGS NA FILA."
                exit $OK
fi

exit $UNKNOWN

# chmod +x /usr/local/nagios/libexec/check_qmail_queue

Para ativar o check, devemos inserir o comando e o serviço no servidor do Nagios. Segue procedimento para ser executado no Nagios:

1 - Crie o comando no arquivo commands.cfg (No ambiente usado para esse "how to" o arquivo encontra-se em /usr/local/nagios/etc/objects/commands/commands.cfg no servidor Nagios:

vi /usr/local/nagios/etc/objects/commands/commands.cfg
#'check_nrpe_qmail_queue' command definition
define command{
        command_name    check_nrpe_qmail_queue
        command_line    $USER2$/check_nrpe -H $HOSTADDRESS$ -c check_msgs_qmail_queue
        }

2 - Crie o serviço para o servidor Qmail:

vi /usr/local/nagios/etc/objects/services/linux-services.cfg
define service{
        use                             non-critical-services         ; Name of service template to use
        host_name                       SRVLMSSAMAIL01
        service_description             EMAILS IN QUEUE
        check_command                   check_nrpe_qmail_queue
      }

3 - Configure o check no NRPE no servidor Qmail:

vi /usr/local/nagios/etc/nrpe.cfg

command[check_msgs_qmail_queue]=/usr/local/nagios/libexec/check_qmail_queue

4 - Reinicie o serviço do Nagios no servidor Nagios e o serviço do NRPE no servidor de e-mail Qmail.

Script para atualizar periodicamente blacklists selecionadas do squidGuard

noreply@blogger.com (Leonardo Couto Conrado) — Thu, 12 Jan 2012 01:17:00 +0000

O script abaixo irá baixar os arquivos tar.gz de blacklist dos sites squidguard.mesd.k12.or.us e www.shallalist.de, após isso ele irá descompactar os arquivos e copiar as pastas de blacklists, que estejam listados por você nos arquivos bls_mesd.txt e bls_shalla.txt, para o diretório de blacklists do squidGuard, após isso mudará o dono dos diretórios de blacklists do squidGuard para o usuário squid e por ultimo ele irá recompilar as blacklists transformando-as em arquivo de banco de dados para o squidGuard. O conteúdo da pasta utlizada para baixar e descompactar os tar.gz será limpa no final do processo.

-> PARA AGENDAR A EXECUÇÃO DO SCRIPT UTILIZE O crontab.

#!/bin/bash
############################################################### 
# Atualizando blacklists selecionadas para o squidGuard
# Por Leonardo Couto Conrado 
# Em 11/01/2012 
############################################################### 
# README:
# Crie o diretorio da variavel dirWork
# Crie o arquivo de log da variavel logUpBlackLists
# Crie o arquivo /usr/local/upblacklists/bls_mesd.txt ele deverá conter as blacklists desejadas da mesd squidguard.mesd.k12.or.us para serem copiadas para as blacklists do squidGuard
# Crie o arquivo /usr/local/upblacklists/bls_shalla.txt ele deverá conter as blacklists desejadas da shalla www.shallalist.de para serem copiadas para as blacklists do squidGuard

clockNow=$(date +%d.%m.%Y-%H:%M)
dirBlackListSquidGuard=/usr/local/squidGuard/db/blacklists/
dirWork=/usr/local/upblacklists/work/
dirUpBlackLists=/usr/local/upblacklists/
squidGuardCreateDBs="/usr/local/squidGuard/bin/squidGuard -C all"
 
urlListMesd=http://squidguard.mesd.k12.or.us/blacklists.tgz
urlListShalla=http://www.shallalist.de/Downloads/shallalist.tar.gz
fileTgzMesd=blacklists.tgz
fileTgzShalla=shallalist.tar.gz
fileBlacklistsMesd=blacklists/
fileBlacklistsShalla=BL/
 
logUpBlackLists=/var/log/updatebacklists.log
 
numBlsMesd=$(cat $dirUpBlackLists"bls_mesd.txt" | wc -l)
numBlsShalla=$(cat $dirUpBlackLists"bls_shalla.txt" | wc -l)
 
counter=1
 
# INICIO
 
cd $dirWork
 
wget -c $urlListMesd
wget -c $urlListShalla
 
if [ $? = 0 ]; then
        tar -xzf $dirWork$fileTgzMesd
        tar -xzf $dirWork$fileTgzShalla
 
        cd $dirWork$fileBlacklistsMesd
              echo $clockNow  " - ANDAMENTO COPIA DAS BLS DA MESD: " >> $logUpBlackLists
                while [ $counter -le $numBlsMesd ]; do
                        blMesd=$(cat $dirUpBlackLists"bls_mesd.txt" | awk -v VAR=$counter 'NR == VAR {print $0}')
                        /bin/cp -fv $dirWork$fileBlacklistsMesd$blMesd/domains $dirBlackListSquidGuard$blMesd >> $logUpBlackLists
                        /bin/cp -fv $dirWork$fileBlacklistsMesd$blMesd/urls $dirBlackListSquidGuard$blMesd >> $logUpBlackLists
                        let counter=counter+1
                done
       counter=1
 
        cd $dirWork$fileBlacklistsShalla
                echo $clockNow  " - ANDAMENTO COPIA DAS BLS DA SHALA: " >> $logUpBlackLists
                while [ $counter -le $numBlsShalla ]; do
                        blShalla=$(cat $dirUpBlackLists"bls_shalla.txt" | awk -v VAR=$counter 'NR == VAR {print $0}')
                        /bin/cp -fv $dirWork$fileBlacklistsShalla$blShalla/domains $dirBlackListSquidGuard$blShalla >> $logUpBlackLists
                        /bin/cp -fv $dirWork$fileBlacklistsShalla$blShalla/urls $dirBlackListSquidGuard$blShalla >> $logUpBlackLists
                        let counter=counter+1
                done
      
       echo $clockNow  " - ANDAMENTO DAS PERMISSOES PARA SQUID NAS BLS DO SQUIDGUARD: " >> $logUpBlackLists
        chown squid -R -v $dirBlackListSquidGuard >> $logUpBlackLists
      
       echo $clockNow  " - RECOMPILANDO AS DBS DO SQUIDGUARD: " >> $logUpBlackLists
       echo `$squidGuardCreateDBs` >> $logUpBlackLists
 
       echo $clockNow  " - LIMPANDO DIRETORIO WORKS: " >> $logUpBlackLists
        cd $dirWork && rm -rf ./
else
   echo $clockNow ' - FALHOU DOWNLOAD DE UMA DAS BLS: ' >> $logUpBlackLists
 
fi
 
exit 0

Sessão Fix BUG

noreply@blogger.com (Leonardo Couto Conrado) — Tue, 10 Jan 2012 12:28:00 +0000

BUG: NFS mount: failed, reason given by server: Permission denied
Versão NFS utilizada: nfs-utils-1.0.9-50.el5 e nfs-utils-lib-1.0.8-7.6.el5
Sistema utilizado: Red Hat Enterprise Linux Server release 5.3 Beta (Tikanga)

SINTOMA:

Ao tentar mapear um diretório remoto via NFS no cliente aonde o mesmo possui as devidas permissões para acesso ao diretório no server é apresentada uma mensagem de erro informando:

mount: failed, reason given by server: Permission denied.

PROBLEMA:

Durante a inicialização do cliente o filesystem que controla o NFSD não é montado.

SOLUÇÃO:

É necessário montar manualmente o filesystem especial nfsd.

Adicione no arquivo /etc/fstab:

# vi /etc/fstab


#########################################

# FIX - BUG 692968 PERMISSION DENIED NFS

#########################################

none                    /proc/fs/nfsd   nfsd     defaults 0 0

Reler o arquivo /etc/fstab

# mount -a

Agora tente mapear novamente o diretório remoto.

REFERÊNCIA:

https://bugzilla.redhat.com/show_bug.cgi?id=264661
http://juljas.net/lpt/post/nfs-permission-denied#comment-118

Instalando NRPE no SlackWare

noreply@blogger.com (Leonardo Couto Conrado) — Sat, 07 Jan 2012 13:48:00 +0000

Utilizado os seguintes pacotes do NRPE e Nagios Plugins para serem instalados no Slackware 13.37.0 Kernel 2.6.37.6-smp:

nagios-plugins-1.4.15 http://www.nagios.org/download/plugins
nrpe-2.13 http://sourceforge.net/projects/nagios/files/

Vamos para a instalação:

Descompactando, ajustando, compilando e instalando o nagios plugins:

# tar -xzf nagios-plugins-1.4.15.tar.gz

# cd nagios-plugins-1.4.15>

# ./configure --prefix=/usr/local/nagios

# make

# make install

Descompactando, ajustando, compilando e instalando o NRPE:

# tar -xzf nrpe-2.13.tar.gz

# cd nrpe-2.13/

# ./configure

# make all

# make install

Adicione manualmente o user e group nagios, caso a instalação não tenha criados:

# adduser nagios

# groupadd nagios

# usermod -G nagios nagios

Permissão de proprietário e grupo proprietário nagios no diretório abaixo:

#chown nagios.nagios /usr/local/nagios

Finalizando a instalação do pacote NRPE:

# make install-plugin

# make install-daemon

# make install-daemon-config

Permissão de proprietário e grupo proprietário nagios no diretório abaixo:

# chown -R nagios.nagios /usr/local/nagios/libexec

# vi /etc/services

nrpe 5666/tcp # NRPE

Adicionando o daemon NRPE para ser controlado pelo inetd (tcp wrapper) do Linux:

# vi /etc/inetd.conf

nrpe    stream  tcp     nowait  nagios /usr/sbin/tcpd /usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -i

Editar /usr/local/nagios/etc/nrpe.cfg e dar as permissões de quem pode se conectar a esse host:
EXEMPLO:

# vi /usr/local/nagios/etc/nrpe.cfg

allowed_hosts=127.0.0.1,192.168.9.144,192.168.1.69

Especificar também os serviços serão checados na máquina local:
EXEMPLO:

# vi /usr/local/nagios/etc/nrpe.cfg




command[check_proc_qmail_supervise_pop3d]=/usr/local/nagios/libexec/check_procs -w 1:1 -c 1:1 -a "supervise qmail-pop3d"

command[check_proc_qmail_supervise_smtpd]=/usr/local/nagios/libexec/check_procs -w 1:1 -c 1:1 -a "supervise qmail-smtpd"

command[check_proc_qmail_supervise_imapd]=/usr/local/nagios/libexec/check_procs -w 1:1 -c 1:1 -a "supervise qmail-imapd"

command[check_proc_qmail_supervise_qmqpd]=/usr/local/nagios/libexec/check_procs -w 1:1 -c 1:1 -a "supervise qmail-qmqpd"

command[check_proc_qmail_supervise_send]=/usr/local/nagios/libexec/check_procs -w 1:1 -c 1:1 -a "supervise qmail-send"

A maioria dos checks feitos na máquina local exigem privilégios de root, como o daemon NRPE é inicializado com o usuário nagios muitos checks terão saídas negadas pelo SO então utilizar o sudo como solução de contorno liberando o usuários nagios a executar comandos especificados como root. Para isso:

1 - Editar /usr/local/nagios/etc/nrpe.cfg e tirar o comentário da seguinte linha no arquivo, habilitando o uso do sudo pelo NRPE:

# vi /usr/local/nagios/etc/nrpe.cfg

command_prefix=/usr/bin/sudo

2 - Editar /etc/sudores e colocar os comandos que serão executados pelo usuário nagios como se fossem o root executando-os :

# vi  /etc/sudores

# Nagios

nagios ALL=(ALL) NOPASSWD: /usr/local/nagios/libexec/check_qmail_queue

nagios ALL=(ALL) NOPASSWD: /usr/local/nagios/libexec/check_procs

nagios ALL=(ALL) NOPASSWD: /usr/local/nagios/libexec/check_users

nagios ALL=(ALL) NOPASSWD: /usr/local/nagios/libexec/check_load

nagios ALL=(ALL) NOPASSWD: /usr/local/nagios/libexec/check_disk

nagios ALL=(ALL) NOPASSWD: /usr/local/nagios/libexec/check_swap

nagios ALL=(ALL) NOPASSWD: /usr/local/nagios/libexec/check_mem.pl

Reiniciei o NRPE, para isso execute um restart no daemon inetd que controla o daemon do NRPE:

# /etc/rc.d/rc.inetd restart

NO SERVDIDOR DO NAGIOS TESTE A COMUNICAÇÂO COM O HOST REMOTO:

# /usr/lib64/nagios/plugins/check_nrpe -H 192.168.65.100

PARA HABILITAR E VISUALIZAR O DEBUG DO NRPE UTILIZE O HOW TO ABAIXO:

Editar /usr/local/nagios/etc/nrpe.cfg

# vi  /usr/local/nagios/etc/nrpe.cfg

debug=1

Editar /etc/syslog.conf

# vi /etc/syslog.conf

####################

# LOG PARA O NRPE

####################

daemon.debug                                            /var/log/nrpe

Reiniciei o NRPE:

# /etc/rc.d/rc.inetd restart

Reload do syslog:

# killall -HUP syslogd

Bela homenagem a Jobs e a importância e consistência do O.S *BSD

noreply@blogger.com (Leonardo Couto Conrado) — Tue, 11 Oct 2011 15:04:00 +0000

Steve Jobs

"Nosso marketshare é maior que o da BMW ou da Mercedes ou ainda da Porsche no mercado automobilístico. O que há de errado em ser a BMW ou a Mercedes?" -- Steve Jobs

Obrigado, Steve, obrigado.

A tecnologia de Steve, FreeBSD & 4.2 BSD

Este homem colocou um sistema baseado em FreeBSD no coração de seu tablet, e revolucionou a indústria da tecnologia móvel. (iPad, iOS = Darwin Embedded = Mach + FreeBSD)

Antes disso, ele revolucionou a indústria da telefonia celular, com um sistema baseado em FreeBSD no coração de seu telefone. (iPad, iOS = Darwin Embedded = Mach + FreeBSD)
Antes, criou um novo conceito de televisão on-line, que vem revolucionando este segmento de mercado em regiões do mundo com acesso persistente a banda larga. Em seu coração, um sistema baseado em FreeBSD. (iTV/Apple TV, iOS = Darwin Embedded = Mach + FreeBSD + TinyBSD)
Bem antes, revolucionou a indústria da música, a forma de se consumir e comercializar música, e no coração de seu tocador de música e loja, colocou um sistema baseado em FreeBSD. (iPod, iOS = Darwin Embedded = Mach + FreeBSD)
Antes disso, criou a série de computadores pessoais mais desejado do mundo, e em seu coração, colocou um sistema baseado em FreeBSD. (Mac Book Pro, iMacs, Mac OS X = Darwin + Aqua + Quartz + Mach + FreeBSD)
Ainda antes, revolucionou a indústria do cinema de animações gráficas, e no coração dessa tecnologia colocou um sistema derivado do Mach 2.5 e do 4.2-BSD. (NEXTSTEP = Mach 2.5 + 4.2-BSD + 4.4BSD)
Antes disso, teve seu primeiro contato com 4BSD ao criar uma plataforma computacional superior à que ele mesmo havia criado no passado. (NEXTSTEP = Mach 2.5 + 4.2-BSD + 4.4BSD)

Este homem mudou consideravelmente a forma como o mundo cria e consome música, cinema, comunicação, cultura, livros. Criou a tecnologia e os produtos mais desejados no mercado contemporâneo. Criou a maior empresa de capital aberto do mundo.
E no coração disso tudo... vocês já sabem.
Por isso, nós, das equipes FreeBSD Brasil LTDA & IDS Tecnologia prestamos nossa pequena e sincera homenagem, em reconhecimento a vida e os feitos deste homem. Obrigado, Steve.

E mais uma coisa...

Foi num NeXT Cube, rodando NEXTSTEP, sistema criado a partir de um kernel híbrido do Mach 2.5 e 4.2-BSD + 4.4BSD (incluindo, claro, TCP/IP do 4-BSD) que Tim Berners-Lee criou o primeiro navegador web (WorldWideWeb era o nome), primeiro servidor web (CERN httpd) e criou a web (WWW e o W3C) como conhecemos hoje. Até onde Steve não estava presente, sua obra (e o BSD, claro) fizeram e fazem toda a diferença.
Mac OS X 10.6 (Snow Leopard) é o primeiro sistema a ter instruções de kernel massivamente processada por GPU em complemento a CPU. O OpenCL e processamento GPU, além do Grand Central Dispatch voltam como contribuição da Apple ao FreeBSD em 2011, no FreeBSD 9 (sistema base), quase 4 anos depois de incorporado no Mac. Tardio? Pense da seguinte forma: FreeBSD é o segundo SO a se apoiar em processamento GPU, quase 4 anos depois. O restante do mercado continua correndo atrás, engatinhando. Em mais 2, 3 anos talvez absorvam mais essa influência da tecnologia de Steve.
Steve se foi, mas seu legado continua. E temos orgulho de enxergar que continua fundado em BSD.
Passado, presente, e por muitos anos ainda, o futuro. Obrigado Steve, por subir o nível.

Fonte: http://www.freebsdbrasil.com.br/home.php?area=20&conteudo=53

Google Social Networking

noreply@blogger.com (Leonardo Couto Conrado) — Tue, 28 Jun 2011 23:02:00 +0000

Google já iniciou o desenvolvimento do aplicativo de rede social que irá competir com o Facebook; Ele se chama: Google+. Muito desafiador... Tarefa árdua essa eim? Será possivel colocar um aplicativo para disputar com o maior serviço de rede social do mundo, o Facebook? De qualquer forma estou curioso para conhecer o Google+.

The Google+ project: real life sharing, rethought for the web.
plus.google.com

Trocar UID proprietário de arquivos e pastas em determinados diretórios por um outro UID para ser o novo proprietário desses arquivos encontrados

noreply@blogger.com (Leonardo Couto Conrado) — Fri, 10 Jun 2011 16:54:00 +0000

Pessoal o script abaixo foi feito para alterar o dono de arquivos e pastas em determinados diretórios, o mesmo sairá recursivamente trocando o UID dos arquivos e pastas encontrados, a partir do UID antigo, por um outro UID, definido por você, para que esse seja o novo dono do arquivos e pastas no diretório.

OBS.: UID é uma identificação exclusiva de qualquer usuário no linux, para verificar o id de algum usuário digite:

# id nomeDoUsuário

root@feigt:/# id leonardoconrado
uid=1018(leonardoconrado) gid=100(users) groups=100(users)

Exemplo 01: Mudará o dono de todos arquivos e pastas do diretório / que tenham como UID 502 e irá "setar" ou configurar um novo UID dono desses arquivos que será UID 512 e irá também gerar um arquivo de log em /root/debug.txt, para que possamos ver se aconteceu alguma falha na tentativa de troca desses UIDs nos arquivos encontrados, ele também contará quantos arquivos foram encontrados com o velho UID, abaixo script:

#!/bin/bash

# Mudar UID proprietário de arquivos e pastas
# para um novo UID ser o proprietário em determinados
# diretórios
# Por Leonardo Couto Conrado
# Em 06.10.2011 

counter=0

# Encontre em / os arquivos que tenha UID igual à 502
for i in $( find / -uid 502 2>> /dev/null ); do
        echo $i

# Mude o dono desses arquivos para UID 512
        chown -v 512 $i >> /root/debug.txt

# Conte cada arquivo encontrado
        counter=`echo "$counter+1"|bc`
done
echo $counter

Exemplo 02: Mudará o dono de todos arquivos e pastas do diretório /oracle que tenham como UID 501 e irá "setar" ou configurar um novo UID dono desses arquivos que será UID 511 e irá também gerar um arquivo de log em /root/debug.txt, para que possamos ver se aconteceu alguma falha na tentativa de troca desses UIDs nos arquivos encontrados, ele também contará quantos arquivos foram encontrados com o velho UID, abaixo script:

#!/bin/bash

# Mudar UID proprietário de arquivos e pastas
# para um novo UID ser o proprietário em determinados
# diretórios
# Por Leonardo Couto Conrado
# Em 06.10.2011 

counter=0

# Encontre em / os arquivos que tenha UID igual à 501
for i in $( find /oracle -uid 501 2>> /dev/null ); do
        echo $i

# Mude o dono desses arquivos para UID 511
        chown -v 511 $i >> /root/debug.txt

# Conte cada arquivo encontrado
        counter=`echo "$counter+1"|bc`
done
echo $counter

Já se foram os últimos blocos do velho e bom IPv4, que até hoje nos foi muito útil...

noreply@blogger.com (Leonardo Couto Conrado) — Wed, 04 May 2011 14:19:00 +0000

O competente ancião, protocolo IPv4, atualmente responsável por carregar todas as nossas informações na rede mundial, a internet, está se aposentando e delegando a tarefa para o jovem e aprimorado protocolo IPv6...

Saiba mais: O fim do IPv4

Linux Magazine Community Edition 76 baixe já a sua

noreply@blogger.com (Leonardo Couto Conrado) — Fri, 11 Mar 2011 11:37:00 +0000

Já está no ar a Linux Magazine 76 Community Edition.

Confira nesta edição os principais assuntos da Linux Magazine de março (Monitoramento e segurança) e leia artigos completos sobre ferramentas de backup para auxiliar na prevenção de falhas e perdas de dados e proteção de servidores web Apache com o módulo mod_security.

A Linux Magazine Community Edition surgiu em agosto de 2009. Trata-se de um arquivo em PDF com 30 páginas do conteúdo original da Linux Magazine do mês, disponível para download uma semana antes do lançamento da revista nas bancas – exclusivo para assinantes e cadastrados na newsletter.

O sumário da Community Edition contém a relação de todas as matérias da revista. Algumas são de livre acesso e outras são artigos que podem ser adquiridos pelo site. O material de livre acesso representa 30% do conteúdo da edição do mês, uma prática já adotada pela Linux Magazine. Pode-se navegar pelo documento, acessando o material gratuito ou adquirindo o material exclusivo em nosso site. Basta clicar para ser levado à página do artigo correspondente. Tudo isso antes mesmo de a revista chegar às bancas ou ser publicada no site.

A melhor parte é que você pode baixar o arquivo e enviar para quem você quiser. Por meio da licença Creative Commons, a Community Edition pode ser livremente copiada e distribuída. Assim, baixe, copie, envie para os seus amigos e faça parte de uma comunidade que não para de crescer. Participe de forma ativa na divulgação da tecnologia que mais traz benefícios para as pessoas e para o mercado em geral.

Quando a revista chegar às bancas, a Community Edition será disponibilizada gratuitamente para download para qualquer visitante do site. Mas você, assinante da newsletter, tem a exclusividade de acesso em primeira mão.

Baixe já a sua!

Editando arquivo CGI(status.cgi ) do Nagios realizando custom

noreply@blogger.com (Leonardo Couto Conrado) — Thu, 24 Feb 2011 11:56:00 +0000

Pessoal recentemente surgiu a necessidade de editar um CGI do Nagios, especificamente o arquivo status.cgi, a carência era adicionar mais uma coluna na tabela da página Problems >> Services(http://servidorNagios/nagios/cgi-bin/status.cgi?host=all&servicestatustypes=28) tal coluna deveria conter a descrição/alias dos hosts. A intenção é para torna compreensivel, para o pessoal não técnico, o host que está apresentando problemas já que teremos uma clouna que informa a descrição do host e não somente a sua abreviatura(Hostname). Pois bem, o bom é que vivemos no mundo open source e sabendo-se disso temos acesso aos fontes dos programas, utilizando-se dessa flexibilidade podemos deixar o programa do nosso jeito, que beleza eim?! Nota 1000 para o GNU e viva ao Linux!! Pois bem, vamos meter a mão na massa:

OBS.:

- Utilizado para esse artigo o CentOS 5.5 e o Nagios Core 3.2.3;
- Você deve compilar o código status.c na máquina que realmente roda o Nagios, tentei editar e compilar o status.c em outra máquina com o mesmo S.O e a mesma versão do Nagios e depois copiei o status.cgi já compilado para outra máquina de produção, porém, não rolou dava erro então compile o nagios na máquina que realmente utilizará os CGI;

1 - Primeiramente vá ao site da Nagios e baixe o source do mesmo;

2 - Descompacte-o;

3 - Vá a pasta /nagios-3.2.3/cgi e edite o status.c;

4 - Foi necessário adicionar somente duas linhas no arquivo, abaixo segue trechos do arquivo numerado e com comentários sobre as linhas adicionadas:

# vi /nagios-3.2.3/cgi/status.c

Primeira parte:

Segunda parte:

Após isso será necessário configurar, compilar e instalar o nagios para ele recompilar os .CGIs, para fazer esta tarefa tomei como referência o How to de instalação do Nagios.org, faremos conforme abaixo:

1 - Em /nagios-3.2.3(A pasta que tem os fontes) você executará 3 comandos:

./configure --with-command-group=nagcmd

make all

make install

Pronto!
E agora vamos ver se a nossa coluna apareceu no services.cgi do Nagios, acesse o seu nagios através do browser:

Voilà!! Customizamos o Nagios!! E Viva o mundo open source!

Extendendo partição raiz / (VolGroup00) com LVM

noreply@blogger.com (Leonardo Couto Conrado) — Thu, 10 Feb 2011 11:29:00 +0000

É normal que o seu sistema Linux com o passar do tempo consuma o filesystem, com aplicativos instalados e logs dos aplicativos que são gerados continuamente e vão logicamente consumido o seu disco, e como consequência disso ficamos sem espaço disponivel na partição root ou /. Existe uma maneira rápida, simples e transparente de incrementarmos mais espaço nessa partição, utilizando para isso a ferramenta LVM, onde podemos realizar esse ajuste de espaço se e somente o seu S.O foi instalado com LVM e foi configurado para a partição / utilizar o esquema de VG(Volume Group) da LVM, que geralmente é o VolGroup00, então isso significa que você porderá extender a sua partição.

Para descobrir essas informações no seu S.O utilize o seguinte comando:

#df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
25G  5.6G   18G  25% /
/dev/sda1              99M   13M   82M  13% /boot
tmpfs                 502M     0  502M   0% /dev/shm
/dev/mapper/VolGroupOracle-LogVolOracle
108G   29G   74G  28% /oracle
/dev/hdc              3.3G  3.3G     0 100% /mnt/dvd

Perceba que o filesystem da sua partição / é: /dev/mapper/VolGroup00-LogVol00 onde VolGroup00 é o Grupo de volumes, é ele quem extenderemos primeiramente, pois, o nosso volume lógico LogVol00, que é a partição /, é membro deste grupo. Logo em seguida após extendermos o Grupo lógico VolGroup00 extenderemos nosso Volume lógico LogVol00 que como já foi dito é a nossa partição root.

Então vamos lá:

Resumo da tarefa a ser realizada: Para poder extender um grupo lógico você deverá arranjar espaço de algum lugar, com LVM geralmente colocamos um novo disco rígido no servidor e após isso mudamos a tabela de partição deste novo disco para o tipo 8e(Linux LVM). Em seguida criamos um Phisical Volume a partir deste disco recém adicionado, PV ou phisical volume é um disco lógico utlizado pelo LVM. Criado o PV, extenderemos o nosso VG(Volume Group) que no nosso caso será o VolGroup00. Logo em seguida após extender o VG iremos extender o LV(Logical Volume) desejado ou em outras palavras a partição / e para finalizar iremos passar para o S.O a informação que extendemos um filesystem dele com o comando resize2fs.

Verifique o nome do dispositivo que foi colocado para seu HD recém adicionado:

#fdsik -l
Disk /dev/sdd: 1073 MB, 1073741824 bytes
255 heads, 63 sectors/track, 130 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/sdd doesn't contain a valid partition table

O dispositivo /dev/sdd está sem tabela de partição criada. Então iremos criar e coloca-la como tipo 8e(Linux LVM):

#fdisk /dev/sdd
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): n
Command action
e   extended
p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-130, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-130, default 130):
Using default value 130

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Linux LVM)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Partição criada:

#fdisk -l /dev/sdd
Disk /dev/sdd: 1073 MB, 1073741824 bytes
255 heads, 63 sectors/track, 130 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1         130     1044193+  8e  Linux LVM

Iremos agora para a parte do LVM, primeiramente criaremos um Phisical Volume(PV) com a partição que foi criada:

#pvcreate /dev/sdd1
Physical volume "/dev/sdd1" successfully created

Agora que já temos o PV iremos extender um Volume Group, que no nosso caso é grupo de volumes que contém a partição raiz / normalmente é chamado de VolGroup00, se não saber qual o nome do grupo der o comando abaixo:

#df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
25G  3.7G   20G  17% /
/dev/sda1              99M   13M   82M  13% /boot
tmpfs                1006M     0 1006M   0% /dev/shm
/dev/mapper/VolGroupOracle-LogVolOracle
206G  188M  196G   1% /oracle

Identificado o Volume Group que contém a sua partição /, então, iremos extender esse VG passando para ele o dispositivo que contém o espaço livre, ou seja, o disco rigido recém adicionado na máquina:

#vgextend VolGroup00 /dev/sdd1
Volume group "VolGroup00" successfully extended

Pronto com o grupo já extendido vamos ver quanto de espaço livre este VG possui agora:

#vgdisplay VolGroup00
--- Volume group ---
VG Name VolGroup00
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 2
Act PV 2
VG Size 8.69 GB
PE Size 32.00 MB
Total PE 278
Alloc PE / Size 248 / 7.75 GB
Free PE / Size 30 / 960.00 MB
VG UUID Ll4Bg4-jIFV-lfut-z4Ae-JTfH-0Hzp-Zf9RjM

Agora sim iremos extender a nossa partição ou volume raiz / utilize o parâmetro Free PE do comando dado acima ele é o indice de espaço livre:

#lvextend -l+30 /dev/VolGroup00/LogVol00
Extending logical volume LogVol00 to 8.19 GB
Logical volume LogVol00 successfully resized

Pronto! Agoramos que extendemos o nosso VG do LVM iremos passar esta informação para o S.O, pois, ainda não foi extendido o disco fisico propriamente dito, para extende-lo utilize o comando resize2fs:

#resize2fs /dev/VolGroup00/LogVol00
resize2fs 1.40.2 (12-Jul-2007)
Filesystem at /dev/VolGroup00/LogVol00 is mounted on /; on-line resizing
required
old desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/VolGroup00/LogVol00 to 2146304 (4k)
blocks.
The filesystem on /dev/VolGroup00/LogVol00 is now 2146304 blocks long.

Pronto!!!! Se tudo correu bem você está agora com espaço livre em seu disco e na sua partição raiz /.
Simples!

Linux Magazine Community Edition 75 baixe já a sua Linux Magazine 75 Community Edition!

noreply@blogger.com (Leonardo Couto Conrado) — Thu, 10 Feb 2011 11:28:00 +0000

Já está no ar a Linux Magazine 75 Community Edition.

Confira nesta edição os principais assuntos da Linux Magazine de fevereiro (Android) e leia um artigo completíssimo sobre programação Palm para webOS, poderoso sistema móvel que pretende conquistar posições no mercado. Leia ainda um completo tutorial sobre SystemTap.

Baixe já a sua!

Linux Magazine Community Edition 73 baixe já a sua Linux Magazine 73 Community Edition!

noreply@blogger.com (Leonardo Couto Conrado) — Thu, 13 Jan 2011 11:14:00 +0000

Já está no ar a Linux Magazine 73 Community Edition.

Baixe já a sua!

Baixe já a sua Linux Magazine Community Edition 74

noreply@blogger.com (Leonardo Couto Conrado) — Thu, 13 Jan 2011 11:02:00 +0000

Já está no ar a Linux Magazine 74 Community Edition.

Confira nesta edição os principais assuntos da Linux Magazine de janeiro (Interoperabilidade) e leia a terceira parte do tutorial de Asterisk, um artigo de programação completo sobre trabalhar com pipes em shell scrip e um artigo sobre como monitorar os daemons do seu sistema.

Baixe já a sua!

Baixe já a sua Linux Magazine Community Edition 72

noreply@blogger.com (Leonardo Couto Conrado) — Thu, 11 Nov 2010 14:30:00 +0000

Aí Galera irei começar a disponibilizar aqui no blog link para download da revista Linux Magazine as edições oferecidas para a comunidade Linux quando a mesma for liberada.

Já está no ar a Linux Magazine 72 Community Edition. Confira nesta edição os principais assuntos da Linux Magazine de novembro (Descomplicamos o VoIP) e leia um artigo completo sobre autenticação de usuários com PAM, e uma análise sobre TeamViewer, ferramenta para controle remoto gráfico.

Abaixo segue link da edição 72 oferecida para a community:

Baixe já a sua!

Shell scripting

noreply@blogger.com (Leonardo Couto Conrado) — Wed, 10 Nov 2010 16:52:00 +0000

Shell script

Shell script é uma linguagem de script usada em vários sistemas operacionais derivados do UNIX. O shell script é batizado com este nome devido a ele ser um arquivo em texto plano, ou seja, legível para uma pessoa interpretar as sua linhas de comandos que segue a forma de um script, ou seja, intruções são executadas passo à passo além disso este arquivo é colocado como um tipo de arquivo executável, e o Shell é o interpretador de comandos dos sistemas Unix-Like. O shell é aquele que aparece logo após digitar-se a senha do usuário e entrar na famosa tela preta que espera ansiosamente por algum comando para ele poder executar. Essa é a sua função: esperar e executar. Cada comando digitado é lido, verificado, interpretado e enviado ao sistema operacional para ser de fato executado. Um exemplo de interpretador de comandos é o bash, usado na grande maioria das distribuições GNU/Linux. O shell é a ligação entre o usuário e o kernel. O kernel é quem acessa os equipamentos(hardware) da máquina, como disco rígido, placa de vídeo e modem.

A maior parte dos usuários classificam shell script como uma linguagem de fácil aprendizado. O primeiro passo é saber o que se deseja fazer, então, ver qual o código que executa este comando em shell e aí criar, basta escrever o código em algum editor de texto e salvar. Depois de salvo você deve coloca-lo como arquivo executável fazendo desta forma:


chmod +x "Nome do arquivo, sem aspas"

Depois de coloca-lo como executável, executamos o arquivo, dessa forma:


./"Nome do arquivo, sem aspas"

Para exibir um manual do bash ou mesmo do comando 'chmod', digite na linha de comando

man bash

man chmod

É possível executar o arquivo mesmo sem modificar a permissão de execução, por exemplo, se for um arquivo escrito para ser executado pelo bash, usar:


sh ./"Nome do arquivo, sem aspas"

FONTE: http://pt.wikipedia.org/wiki/Shell_script

Abaixo temos alguns links para o download de livros sobre shell scripting que serão bastante úteis para aqueles que querem aprender ou aprimorar o seu conhecimento sobre shell script:

- http://tips-linux.net/en/content/pro-bash-programming
- http://tips-linux.net/en/content/expert-shell-scripting
- http://tips-linux.net/en/content/beginning-linux-command-line
- http://tips-linux.net/en/content/bash-pocket-reference
- http://tips-linux.net/en/content/linux-command-line-and-shell-scripting-bible

Agradecimento ao tips-linux.net : Compartilhando conhecimento; Neste site você encontrará dicas, e-books, tutoriais, Linux Commands, Softwares, Drivers e muito mais spbre o mundo Linux.

Switch Dell 6024F - TRAPS e SNMP Query funcionar mutuamente

noreply@blogger.com (Leonardo Couto Conrado) — Fri, 22 Oct 2010 13:32:00 +0000

Perdi um bom tempo com o switch Dell 6024F, pois, o mesmo não aceitava as configurações de traps e snmp query para trabalharem mutuamente no switch, pesquisei muito na internet e não achei nada e por esse motivo posto aqui para quem estiver passando pela mesma situação. O problema foi que quando eu tentava configurar o switch, a partir da console WEB, para habilitar os serviços de TRAPS e SNMP o equipamento ficava bugado não funcionava de hipotese alguma essas funções mencionadas acima. O problema foi resolvido quando tentei configura-lo a partir da console CLI(Linha de Comando) do equipamento:
Habilite a SNMP Query através da CLI:


snmp-server community public ro 172.16.0.203 view default type router

Onde:
172.16.0.203 - é o computador que tem permissão para executar query na MIB do switch;

Depois é só habilitar pela console WEB o envio de TRAPS e agora o switch trabalhrá normalmente com ambos os serviços habilitados.

IPFW - Balanceamento de tráfego com dois links WAN usando o IPFW - FreeBSD

noreply@blogger.com (Leonardo Couto Conrado) — Thu, 21 Oct 2010 20:40:00 +0000


#!/bin/sh

###########################################################################
# Delete todas as regras do IPFW, zera toda tabela de regras.
###########################################################################
/sbin/ipfw -f flush                     


###########################################################################
# Carregar duas instâncias do NATD, uma para cada interface WAN.
###########################################################################
/sbin/natd -u -dynamic -interface re0 -p 8668 
/sbin/natd -u -dynamic -interface re1 -p 8669



###########################################################################
# Regra number 0001: De acordo com o pacote que estiver passando no momento pelo
# gateway, o IPFW primeiramente checará a tabela de sessão(que é criada
# dinamicamente se você adicionar o parâmetro keep-state na regra que queira 
# torna-la dinâmica, veremos abaixo) dessa forma ele verifica se já não existe uma
# regra dinâmica que se aplique ao pacote passante, ou seja, aqui estamos utlizando 
# o firewall no modo stateful.
###########################################################################
ipfw add 0001 check-state



###########################################################################
# Regra number 2000 e 2050: Definem as rotas para as intâncias do NATD 
# criadas acima. Ou seja, aqui setamos para que ocorra NAT nos pacotes 
# que passarem tanto pela interface re0 quanto pela interface re1.
###########################################################################
ipfw add 2000 divert 8668 ip from any to any in via re0
ipfw add 2050 divert 8669 ip from any to any in via re1



###########################################################################
# Regra number 2100: A palavra-chave desta regra é o cara que tem maior 
# responsabilidade sobre todo o balanceamento de tráfego, este cara é o parâmetro
# prob, o seu valor varia de 0 a 1 e diz qual a probabilidade de executar tal regra.
# No caso da regra number 2100, informamos que 50%(0.5) do tráfego utilizando 
# qualquer protocolo que seja IP(ip) de origem(from) 192.168.33.0/24 com destino(to) 
# a qualquer lugar saindo (out) por alguma interface do gateway será pulada (skipto)
# para ser executada a partir da regra number 2200 em diante e além disso 
# colocaremos esta regra na tabela de sessão com o parametro keep-state. Resumindo, 
# estaremos colocando 50% do tráfego para ser roteado pelo NAT na interface re0 que 
# corresponde a instância de porta 8668.
############################################################################
ipfw add 2100 prob 0.5 skipto 2200 ip from 192.168.33.0/24 to any out keep-state



###########################################################################
# Regra number 2150: Como 50% do tráfego será jogado para o NAT da interface re0, os 
# outros 50% do tráfego será ignorado pela regra prob, e adivinha aonde o tráfego 
# ignorado irá parar? Ele será executado pela regra number 2150, que diz que:
# Qualquer protocolo que seja IP(ip) de origem(from) 192.168.33.0/24 com destino(to) 
# a qualquer lugar saindo (out) por alguma interface do gateway será pulada (skipto)
# para ser executada a partir da regra number 2300 em diante e além disso 
# colocaremos esta regra na tabela de sessão com o parametro keep-state. Resumindo, 
# estaremos colocando esse tráfego que não foi executado pela regra prob será 
# roteado pelo NAT na interface re1 que corresponde a instância de porta
# 8669.
###########################################################################
ipfw add 2150 skipto 2300 ip from 192.168.33.0/24 to any out keep-state



############################################################################
# Regras utilizadas pelos skipto acima.
############################################################################
ipfw add 2200 divert 8668 ip from 192.168.33.0/24 to any in
ipfw add 2250 divert 8668 ip from 192.168.33.0/24 to any out
ipfw add 2300 divert 8669 ip from 192.168.33.0/24 to any out
ipfw add 2350 divert 8669 ip from 192.168.33.0/24 to any in

############################################################################
# Aqui eu encaminho(fwd) o tráfego que o gateway estar fazendo(192.168.1.222 e
# 192.168.4.222) para os gateways de rede 192.168.1.1 e 192.168.4.1.
############################################################################
ipfw add 2400 fwd 192.168.1.1 ip from 192.168.1.222 to any
ipfw add 2500 fwd 192.168.4.1 ip from 192.168.4.222 to any



############################################################################
# Aqui defina as regras allow e deny de seu firewall. Como este firewall é de
# teste estou permitindo todo tráfego de qualquer canto para qualquer canto
############################################################################
ipfw add 65000 allow ip from any to any

VNC - Configurando o VNC no Linux como módulo do X11 no display 0

noreply@blogger.com (Leonardo Couto Conrado) — Mon, 06 Sep 2010 18:09:00 +0000

Foi utilizado para este artigo o S.O Red Hat Enterprise Linux ES release 4 (Nahant) e o vnc-server-4.0-8.1.

Se você precisar configurar o VNC para ser carregado na inicialização como módulo do X11 no display 0, ou seja, enxergar e acessar a sessão do usuário local para dar um suporte remotamente ao mesmo, ou seja, da mesma forma que acontece no winVNC da plataforma Windows que enxergamos a tela do usuário e os aplicativos que os estão sendo executados pelo mesmo.

Primordialmente instale o vnc-server no Linux, após isso iremos iniciar a configuração.

Procedimento para a configuração:

1 - Editar /etc/X11/xorg.conf:

# vi /etc/X11/xorg.conf

2 - Adicionar na seção "Module" a linha abaixo:

Load  "vnc"

3- Criar senha do acesso ao VNC A senha será gerada em um arquivo no home do usuário current(/home/usuario_current/.vnc/passwd) que estar a executar o comando abaixo, este arquivo deve ser apontado no arquivo xorg.conf como será explicado no passo 4:
Comando para criação do arquivo da senha:

# vncpasswd

Password:
Verify:
4 -Adicionar na seção "Screen" do aquivo xorg.conf

Section "Screen"
...

Option "SecurityTypes" "VncAuth" #Inserir esta linha no arquivo
Option "UserPasswdVerifier" "VncAuth" #Inserir esta linha no arquivo
Option "PasswordFile" "/root/.vnc/passwd" #Inserir esta linha no arquivo

...
EndSection

OBS.: Encontre no arquivo a sessão "Module", se não existir você deve inserir no final do arquivo fora de qualquer outra sessão, insira as seguintes informações:

Section "Module"
        Load  "dbe"
        Load  "extmod"
        Load  "fbdevhw"
        Load  "glx"
        Load  "record"
        Load  "freetype"
        Load  "type1"
        Load  "vnc"
        Load  "dri"
EndSection

Caso não deseje utilizar autenticação, adicionamos a linha abaixo dentro do arquivo xorg.conf ao invés de utilizar as linhas citadas acima:

Section "Screen"
...
Option "SecurityTypes" "None" #Inserir esta linha no arquivo
...
EndSection

5 - Restart o ambiente x11:
Para fazer isto sem a necessidade de restartar todo o servidor, podemos reiniciar somente o serviço x11, conforme abaixo:

Saia do modo gráfico colocando-o em modo CLI(Comand Line Interface, sem ambiente gráfico):

# init 3

Agora volte para o modo gráfico(KDE, Gnome etc):

# init 5

Pronto agora é só esperar o modo gráfico carrega assim como o serviço do VNC e depois testar a conexão com o server VNC.

Nagios - Traps para o Nagios no FreeBSD

noreply@blogger.com (Leonardo Couto Conrado) — Thu, 26 Aug 2010 20:05:00 +0000

Para este artigo foi utilizado o S.O FreeBSD 8.0-RELEASE-p3 e os seguintes softwares:

- Nagios Core Version 3.2.0
- net-snmp-5.5_3
- snmptt_1.3
- Mibs dos switches Dell

Definições dos aplicativos utilizados:

Nagios:

Originalmente escrito sob o nome Netsaint, o Nagios1 foi criado e ainda
e mantido por Ethan Galstad e sua equipe de mais de 150 desenvolvedores
espalhados por todo o mundo, dedicados a desenvolver plugins, corrigir bugs,
desenvolver uma interface web, produzir e traduzir a vasta documentacao, entre
outras atividades. Este software de monitoramento de redes e distribuido
livremente, atraves da lei de copyleft GPL. A habilidade em administrar
ambientes com infra-estrutura de WAN, LAN e MAN, e a interface grafica – GUI
utilizada lhe garantem desempenho comparavel a sistemas comerciais existentes,
como WhatsUp e BigBrother, assim como o Angel Network Monitor, o PIKT, o
Autostatus e outros2.

FONTE: NAGIOS -mono-HettyAndrade.pdf - www.ginux.ufla.br/files/mono-HettyAndrade.pdf

http://www.nagios.org/

Net-SNMP :

Uma extensão da implementação SNMP, ele quem irá escutar os TRAPS enviados pelos dispositivos de rede para o servidor Nagios. Utiliza a porta padrão de TRAP UDP 162 para escutar as notificações TRAPS.

http://net-snmp.sourceforge.net/

SNMPTT :

SNMP Trap Translator é um manipulador de traps escrito em Perl para ser usado com o Net-SNMP / UCD-SNMP. Ele irá se integrar com o Net-Snmp para pegar os Traps que o este software capturou.

http://snmptt.sourceforge.net/

Mibs:

Será necessário baixar a MIB SNMP dos equipamentos de rede que você queira que o Nagios exiba no sistema. Pode ser inserido qualquer equipamento para enviar TRAPS para o Nagios bastando o mesmo possuir em sua MIB informações de suas TRAPS.

Vamos para a configuração:

1 – Com a MIB do seu equipamento em mãos iremos então converter para o formato exigido pelo SNMPTT. Podemos fazer isto manualmente, no README têm explicando como fazer, porém já deixo informado que é um pouco complexo construir este arquivo nas unhas, podemos fazer então com um script Shell que vêm no .tar do SNMPTT. O nome do script shell que vêm com o aplicativo SNMPTT é snmpttconvertmib, e para converter uma MIB para o formato do SNMPTT utilizamos a seguinte linha de comando:


/home/leonardo.conrado/snmptt/snmptt_1.3/snmpttconvertmib --in=/home/leonardo.conrado/switch-6024f.mib --out=/etc/snmptt.dell-6024f.conf --exec='/usr/local/libexec/nagios/eventhandlers/submit_check_result $r TRAP 1'

Onde, os parâmetros:

--in : a mib a qual deseje converter para a formato do SNMPTT.

--out : arquivo gerado pelo script SNMPTT, ele contém os TRAPS extraidos do arquivo .mib original e formatado para a compreensão do SNMPTT.

--exec : comando a ser executado quando chegar um Trap no net-snmp e capturado pelo SNMPTT se existir este Trap no aquivo do SNMPTT será executado este comando. Neste caso o comando colocará um status para o Nagios exibir nos problemas do serviços de rede, ou seja, este arquivo citado no --exec o "submit_check_result", este script irá escrever um comando para o arquivo de comando/status do Nagios, o nagios.cmd. Nota: Este script destina-se a ser executado no mesmo host que está executando o Nagios.

$r : Variavel contendo informações sobre o problema informado pelo TRAP enviado, isto será exibido no Nagios.

TRAP : Serviço configurado no Nagios(Iremos configurar este serviço para o Nagios, mais adiante).

1 : Uma das variáveis reservada do Nagios. Isso irá setar como será exibido no Nagios o problema do Trap.
STATE_OK=0
STATE_WARNING=1
STATE_CRITICAL=2
STATE_UNKNOWN=3
Se tiver muitos arquivos .mib para serem convertidos utilize este script .sh que cirei para converter os meus arquivos .mib de um equipamento:


!/bin/sh

for i in $( ls /home/leonardo.conrado/*.mib ); do
echo $i
/home/leonardo.conrado/snmptt/snmptt_1.3/snmpttconvertmib --in=$i --out=/etc/snmptt.mikrotik.conf --exec='/usr/local/libexec/nagios/eventhandlers/submit_check_result $r TRAP 1'
done

2 - Após converter os seus arquivos .mib vamos descompactar o .tar do aplicativo snmptt, e partirmos agora para a instalação do aplicativo snmptt para se integrar ao Nagios.

3 - Copie o arquivo snmptt para a pasta /usr/local/sbin (Lembrando que estamos configurando o snmptt no sistema FreeBSD), der permissão de execução para este arquivo(chmod +x snmptt);

4 - Copie o snmptt snmptthandler para a pasta /usr/local/sbin (Lembrando que estamos configurando o snmptt no sistema FreeBSD), der permissão de execução para este arquivo(chmod +x snmptthandler);

5 - Copie o arquivo snmptt.ini para /etc/, é neste arquivo que iremos indicar aonde estar o nosso arquivo .mib já convertido, para que a aplicação snmptt saiba as TRAPS
que deve registrar e enviar para o Nagios. No nosso caso devemos inserir no final deste arquivo snmptt.ini a linha: /etc/snmptt.dell-6024f.conf, conforme abaixo:


[TrapFiles]
# A list of snmptt.conf files (this is NOT the snmptrapd.conf file).  The COMPLETE path
# and filename.  Ex: '/etc/snmp/snmptt.conf'

6 - Crie a pasta /var/log/snmptt/ ;

7 - Edite /usr/local/etc/snmptrapd.conf e adicione a linha: traphandle default /usr/local/sbin/snmptthandler no topo do arquivo;

8 - Crie a pasta /var/spool/snmptt/

9 - Vamos colocar a aplicação para iniciar automaticamente no startup do servidor, para os sistemas Linux como: Mandrake, Red Hat e outros distros Linux o tar do snmptt já traz um script para ser colocado na pasta init.d, porém, como estamos instalando no FreeBSD teremos que criar o nosso próprio script ou consegui-lo através dos ports, bem eu decidi faze-lo mesmo:

10 - Então crie um arquivo chamado snmptt dentro da pasta /usr/local/etc/rc.d/ e der permissão executavel para o mesmo(chmod +x /usr/local/etc/rc.d/snmptt), vamos editá-lo:


[root@noc /usr/sbin]# vi /usr/local/etc/rc.d/snmptt


#!/bin/sh
# PROVIDE: snmptt
# REQUIRE: DAEMON
# BY LEONARDO COUTO CONRADO
. /etc/rc.subr

name="snmptt"

rcvar="`set_rcvar`"

load_rc_config $name

: ${snmptt_enable="YES"}

command="/usr/local/sbin/${name}"
command_args="--daemon"
procname=/usr/bin/perl
pidfile="/var/run/${name}.pid"

run_rc_command "$1"

11 - Edite também o arquivo /etc/rc.conf e adicione a seguinte linha: snmptt_enable="YES"

12 - Aproveitando a edição do arquivo /etc/rc.conf coloque ou modifique as linhas referentes aos serviços que trabalham junto com o snmptt, são eles o snmptrapd(Responsável por escutar as TRAPS enviadas pelos seus equipamentos de rede) e o serviço snmp. O arquivo que estar em produção aqui estar dessa forma:


#;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
# Enable of SNMP - Simple Network Management Protocol
#;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
snmpd_enable="YES"
snmpd_flags="-a"
snmpd_conffile="/usr/local/share/snmp/snmpd.conf"

#;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
# Enable of snmptrapd_enable for traps
#;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
snmptrapd_enable="YES"
snmptrapd_flags="-a -On -Lsd -p /var/run/snmptrapd.pid -c /usr/local/etc/snmptrapd.conf"

#;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
# Enable of snmptt_enable for NAGIOS to receiver traps of equipaments of the network
#;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
snmptt_enable="YES"

13 - Você pode também iniciar a aplicação para testa-la, para debug, com o comando:


snmptt --daemon

Para debugar possiveis erros visualize o seu /var/log/messages e também utilize o comando ps auxww | grep snmptt, abaixo mostro que os processos estão rodando de forma correta:


[root@noc /etc]# ps auxww | grep snmptt
root               886  0.0  0.4 23124  2244  ??  Ss   14Sep10   1:27.46 /usr/bin/perl /usr/local/sbin/snmptt --daemon (perl5.8.9)
root               887  0.0  0.7 23124  3448  ??  Ss   14Sep10   5:01.94 /usr/bin/perl /usr/local/sbin/snmptt --daemon (perl5.8.9)
root             25856  0.0  0.2  8060  1108   0  S+    4:34PM   0:00.01 grep snmptt

Vejam que ele inicia duas instâncias do snmptt.

14 - Um possível erro que pode ocorrer durante o startup do daemon snmptt estar relacionado a alguns módulos do perl estarem faltando ou alguns INIFiles. Comigo o erro que aconteceu foi o seguinte abaixo:


9.4. I see following error: Can't locate Config/IniFiles.pm in @INC ...What should I do?

It's likely that you don't have required Perl modules installed. In this case it's Config::IniFiles that is missing. The easiest way to install Perl modules is to use CPAN extension, eg. perl -MCPAN -e 'install Config::IniFiles'.

Para resolver este caso execute a instalação dos INIFiles conforme mostro abaixo:


perl -MCPAN -e 'install Config::IniFiles'

Bem agora iremos para a parte de integração com o Nagios:

1 - Baixe o .tar do Nagios, aqui utilizei o nagios-3.2.0.tar.gz


tar -xzf nagios-3.2.0.tar.gz

2 - Iremos copíar o script submit_check_result da pasta descompactada do Nagios para a pasta /usr/local/libexec/nagios/eventhandlers/, este script é o responsável por pegar a TRAP e colocar no arquivo nagios.cmd que é o arquivo que coloca todos os eventos/status dos equipamentos em fila para que seja exibido no Nagios. Na verdade quem captura a TRAP é daemon snmptrapd ele fica escutando as TRAPS na porta UDP 161 do seu servidor Nagios e então captura qualquer TRAP que for enviada para o seu servidor, quando a trap é capturada o daemon do snmptt pega essas informações registradas pelo snmptrapd e então verifica no arquivo de mib convertido para ver se encontra algum OID com o mesmo valor do OID do TRAP recebido, se encontrar então ele executa o parametro EXEC referente ao OID encontrado, exemplo na prática:

1 - Um cooler do Switch dell 6024F, que estar configurado para enviar TRAPS para o servidor Nagios, parou, nesse momento o switch envia um pacote TRAP com OID .1.3.6.1.4.1.674.10895.3000.2.1.0.1 para o servidor Nagios.

2 - O daemon snmptrapd que estar escutando na porta UDP 161 captura este pacote e registra em seu log;

3 - O daemon snmptt sabendo desse recebimento de TRAP irá verificar para ver se o OID do TRAP recebido é igual algum OID que estar naquele arquivo convertido a partir de algum arquivo .mib, lembra? Nesse caso que estamos descrevendo, houve a conversão de diversos arquivos .mib baixados no site da Dell referentes a seus switches de série 6020F e convertidos para o padrão exigido do snmptt.

4 - Se houver o OID no arquivo .mib convertido ,então, o daemon do snmptt irá para o próximo passo que é executar o EXEC referente a esse OID, no caso como foi um cooler do switch que parou ele dispara o EXEC do OID .1.3.6.1.4.1.674.10895.3000.2.1.0.1, este OID é o que mostro abaixo:


EXEC /usr/local/libexec/nagios/eventhandlers/submit_check_result $r TRAP 2 "Product Global Status Change.: The product global status has changed from $2 to $1 at time $3."

Este EXEC executa o script do Nagios o submit_check_result passando parametros que são as informações necessárias para exibir o status do equipamento no Nagios.

DETALHE! ATENÇÂO!
Devemos fazer uma modificação no script submit_check_result, já que estamos configurando para o FreeBSD, o detalhe estar na variável CommandFile do script esta variável aponta o arquivo nagios.cmd do Nagios, que por sinal fica em um local diferente das instalações realizadas em distros Linux. Você deve trocar:

De:


CommandFile="/usr/local/nagios/var/rw/nagios.cmd"

Para:


CommandFile="/var/spool/nagios/rw/nagios.cmd"

Bom o que devemos fazer agora é a configuração nos arquivos .cfg do Nagios:

1 - Configurar um template para o serviço TRAP, então:


 vi /usr/local/etc/nagios/objects/templates.cfg

Adicione as linhas abaixo:


############################################################################################
# CREATED FOR THE TRAP SERVICE
############################################################################################
# MODELO 01:
#######################################################################
define service{
        name                         generic-trap-service
        register                     0
        is_volatile                  1
        check_period                 24x7
        max_check_attempts           1
        normal_check_interval        1
        retry_check_interval         1
        active_checks_enabled        0
        passive_checks_enabled       1
        retain_status_information    1
        retain_nonstatus_information 1
        notification_interval        31536000
        notification_period          24x7
        notification_options         w,u,c
        notifications_enabled        1
        check_freshness              1          Enable freshness checking
        freshness_threshold          360        Reset trap alert every 6 min
        contact_groups               admins
}

2 - Como estamos monitorando TRAPS vindos de switches irei adicionar mais um serviço para os switches


vi /usr/local/etc/nagios/objects/servicesswitch.cfg

Adiciona para cada switch da minha rede mais um serviço a ser monitorado, o do TRAP:


# Define a service TRAP for switch/equipament
define service{
        use                     generic-trap-service
        host_name               SWHCDB13448P
        service_description     TRAP
        check_command           check-host-alive
        }

OK, após estas configurações iremos dar um reload no Nagios para ele recarregar as configurações:


[root@noc /usr/local/etc/nagios/objects]# /usr/local/etc/rc.d/nagios reload

Pronto, é isso, com este procedimento deveremos ter o Nagios recebendo os TRAPS dos equipamentos habilitados para enviar TRAP para o servidor Nagios.

IPFW - Criação de regras no IPFIREWALL

noreply@blogger.com (Leonardo Couto Conrado) — Wed, 07 Jul 2010 19:55:00 +0000

Para este artigo foi utilizado o FreeBSD 7.2 e o IPFW2.

Se o seu servidor FreeBSD ainda não tem o IPFW compilado no kernel, então acesse o link abaixo e veja como configura-lo e instala-lo em seu kernel:

http://conteudoopensource.blogspot.com/2010/05/ipfw-instalacao-do-ipfw-com-suporte-ao.html

Inicialmente é bom informar as duas formas de funcionamento do firewall IPFW, no que diz respeito ao tratamento que é dado aos pacotes que trafegam por ele.

Os modos em que o IPFIREWALL pode funcionar são:

Modo Filtro de pacotes:

- Restringir o tráfego baseado no endereço IP de origem ou destino, através das portas de comunicação TCP ou UDP.

Modo Firewall stateful:

- Herda as característica do firewall em modo filtro de pacotes e implementa o filtro por estado da sessão; Nesse caso o firewall armazena os estados das conexões e aplica o filtro de bloqueio ou permissão para o pacote passante com base nesses estados. O firewall armazena em uma tabela os detalhes das conexões existentes (IP de origem, IP de destino, porta de origem, porta de destino, tempo restante para essa conexão na tabela stateful) que estão sendo efetuadas no momento e inspeciona o tráfego evitando que pacotes ilegítimos tenham acesso a serviços de rede ganhando mais velocidade e segurança, evitando, por exemplo, técnicas hacker como: ip spoofing.

Construção do conjunto de regras(Ruleset):

Primeiramente será apresentado o conjunto de regras que são pré-definidas para o IPFW, essas são regras que já vem prontas para serem utlizadas no Firewall.

Ruleset pré-definidas:

A variável do /etc/rc.conf que gerencia qual o conjunto de regras pré-definidas será carregada pelo firewall é a firewall_type=" " . Exitem 5 tipos de regras pré-definidas disponíveis:

"OPEN" - O firewall permiti todo tráfego em suas interfaces, ou seja, não bloqueia nenhuma tráfego.

"CLIENT" - Essa definição de tipo de firewall (firewall_type) permite todo o tráfego proveniente da rede local (por exemplo, uma rede interna atrás de NAT) pra ela mesma. Bloqueia pacotes fragmentados, permite que mensagens de email, resoluções de nomes (DNS) e NTP sejam enviadas pra dentro e fora da rede, e não permite nenhuma máquina que esteja fora da rede interna iniciar conexões TCP com máquinas dentro da rede. Se a rede estiver por trás de uma implementação básica de NAT sem nenhuma opção de proxie carregada isso já seria impossível. Esse tipo de firewall funciona com política aberta ou fechada, definida no kernel, ou seja, não faz diferença se você colocou IPFIREWALL_DEFAULT_TO_ACCEPT ou IPFIREWALL_DEFAULT_TO_DENY como padrão.

"SIMPLE" - Esse tipo de firewall é uma contradição. Apesar do nome SIMPLE, ele é muito mais complexo que a definição CLIENT, e requer que o usuário tenha algum conhecimento nos padrões RFC de Internet pra poder entender suas definições de regras de firewall. Essa regra vai evitar spoofing (técnica onde uma máquina se faz passar por outra, alterando seu endereçamento IP) não permitindo a entrada de nenhum pacote que tenha um endereço de retorno igual ao endereço de qualquer host dentro da rede interna. Vai bloquear todos os pacotes endereçados como de redes privadas, conforme definido na RFC 1928, evitando o tráfego pra dentro ou fora da rede, e vai bloquear ainda todas as redes não-roteaveis, conforme definido no Internet-Drafts da IETF (disponível em http://www.ietf.org/internet-drafts/draft-manning-dsua-03.txt). Esse tipo de firewall vai permitir tráfego de e-mail, de WWW, de DNS, e NTP, e vai permitir também pacotes fragmentados, e em relação às conexões TCP iniciadas por hosts fora da rede, o firewall não vai apenas bloquear, como na definição CLIENT, vai também logar todas essas tentativas.

"CLOSED" - Tecnicamente essa definição não é um conjunto de regras de firewall, porque não adiciona nenhuma regra. Na verdade, aqui acontece tudo que nós insistimos que você deve evitar, ou seja, estabelece uma política fechada, negando todo e qualquer tráfego da rede (exceto o tráfego via lo0 que nós vimos anteriormente que é controlado por padrão). Essa definição simplesmente desabilita todos os serviços IP na rede, a não ser que no seu kernel você tenha adicionado a regra de política aberta. Então, ajustar o firewall pra CLOSED vai ser necessário em casos *extremos* onde você prefere (ainda que temporariamente) tirar toda a sua rede de funcionamento. Ou seja, não defina como padrão no rc.conf.

"UNKNOWN" - Desabilita o carregamento de regras do ipfirewall.

Agora iremos abordar a construção do conjuto de regras personalizaveis para o IPFW utilizaremos neste momento o modo filtro de pacotes. Para isso é necessário criar um arquivo onde será colocado as nossas regras, que será onde o IPFW irá ler as mesmas. Para isso iremos criar o arquivo de regras, como mostra abaixo:

# mkdir -p /tools/firewall

# touch /tools/firewall/rules.fw

Iremos editar o arquivo rules.fw:

# vi /tools/firewall/rules.fw

Agora iremos começar a escrever as nossas regras, mas como é a sintaxe para se escrever as regras no IPFIREWALL?
Abaixo uma breve explicação sobre a sintaxe das regras do IPFW:

CMD [número_regra] [prob probalilidade] ação [log [logamount número] ] corpo_regra

CMD =
add, delete(Os mais utilizados)

add: adicionar uma nova regra ao firewall;
delete: deletar uma regra do firewall;

[número_regra] =
Quando um pacote entra no firewall ele é comparado com a primeira regra no conjunto de regras e avança uma regra de cada vez, que se deslocam de cima para baixo do conjunto em ordem crescente do número de seqüência das regras. Quando o pacote se adequa a seleção de parâmetros de uma regra, o campo de ação é executada e a busca do conjunto de regras termina para o pacote. Isto é referido como "o primeiro que se adequa ganha" do metodo de procura. Se o pacote não corresponde a nenhuma das regras, ele é pego pela regra padrão obrigatório IPFW, número 65.535, que nega todos os pacotes e descarta-los sem qualquer resposta de volta para o remetente, a não ser que se coloque na regra para que o IPFW envie uma mensagem de resposta.
O número de regras varia de 1 a 65535 e indica a sequência em que as regras serão processadas, sendo que a regra de número 65535 é a padrão utilizada pelo firewall, ou seja exclusiva do firewall, essa regra padrão pode ser aceitar tudo(tcp, udp e ip) de qualquer lugar para qualquer lugar ou negar tudo(todos os protocolos tcp, udp e ip) de qualquer lugar para qualquer lugar. Essa regra é especificada antes da compilação do firewall é uma linha que você especifica no kernel IPFIREWALL_DEFAULT_TO_ACCEPT ou IPFIREWALL_DEFAULT_TO_DENY.

[prob probabilidade] =
Uso opcional, Define uma probabilidade para aplicar a regra. Varia de 0 a 1.

ação =
"allow, accept, pass e permit"
Tem a mesma função, aceitar pacote que chegam ao firewall e que se adequem a regra. E a leitura das regras termina.

"deny, drop"
Tem a mesmo função, descartar pacotes silenciosamente(sem enviar resposta ao remetente) que correspondem a regra. E a leitura das regras termina.

"check-state"- Checa o pacote contra um conjunto de regras dinâmicas, isto é para modo statefull do firewall que ainda iremos ver.

"count" - Todos os pacotes que combinarem com uma regra cuja ação seja "count", determinará que o ipfirewall incremente o contagem de pacotes, ou seja, a saída de "ipfw show" indicará mais uma ocorrência de pacotes nessa regra. Motivos estatísticos óbvios. O processamento das regras do firewall continuam a buscar por outras regras que combinem com os pacotes.

"divert porta" - Redireciona o pacote para a porta especificada, utilizando um socket "divert". Pode ser especificado número ou nome, veja /etc/services.

"fwd ip[,porta]" - Sinônimo de forward, encaminha o pacote para o ip especificado. Se o ip for local será encaminhado para a porta especificada, se o ip não for local a porta será ignorada. O pacote não é alterado, e isto inclui o ip de destino, então se o pacote for encaminhado para outro host provavelmente será rejeitado. Caso seja encaminhado para um ip local, desta máquina, o socket que irá receber o pacote terá o seu endereço alterado para coincidir com o endereço de destino do pacote, aceitando desta forma o mesmo.

"pipe número" - Passa o pacote através de um "pipe" dummynet, para controle de tráfego.

"queue número" - Passa o pacote para uma "queue" dummynet, para controle de tráfego utilizando WF2Q+.

"reset" - Quando um pacote encontra uma regra com essa ação, o pacote é bloqueado, e o ipfirewall tenta enviar um sinal (flag) de TCP Reset (RST) pro endereço de origem do pacote. O processamento das regras pra esse pacote termina. Como esse tipo de regra apenas se aplica pra pacotes TCP, o protocolo especificado na regra deve ser "tcp", para que apenas tais pacotes sejam processados por essa regra, e não todos (proto "all") os protocolos de pacotes IP.

"skipto " - Todos os pacotes que combinem com uma regra cuja ação seja "skipto " vão fazer com que o ipfirewall(4) continue processando esse pacote e buscando ocorrência nas regras que sejam de ordem maior ou igual ao indicado pela ação.

"reject" - Essa ação é pouco utilizada atualmente. Quando um pacote combina com uma regra cuja ação seja "reject", então o ipfirewall(4) bloqueia esse pacote e responde com uma mensagem ICMP do tipo "host unreachable", dando a impressão que a máquina se encontra fora da rede. Essa é uma forma não silenciosa de negar o tráfego pelo firewall, contudo, assim como a ação "reset", essa ação também aumenta o uso da sua banda de rede.

"tee porta" - Aceita o pacote e envia uma cópia do mesmo para a porta especificada, via socket "divert".

"unreach código" - Descarta o pacote, e tenta enviar uma resposta "ICMP unreachable" com o código especificado. O código deve ser entre 0 e 255, ou alguma destas palavras chave: net, host, protocol, port, needfrag, srcfail, net-unknown, host-unknown, isolated, net-prohib, host-prohib, tosnet, toshost, filter-prohib, host-precedence ou precedence-cutoff.

[log [logamount número]] =
Uso opcional, caso mencionada a palavra log, cada vez que um pacote coincidir com esta regra será feito um log através do syslog.

corpo_regra =
Contém uma ou mais exigências que o pacote precisa coincidir para a regra ser atendida. Essa especificação pode incluir endereço ip de origem, endereço ip de destino, porta de origem, porta de destino, protocolo, interface de rede de entrada, interface de rede de saída etc. O corpo da regra pode possuir uma ou mais opções. Essas opções podem ser precedidas de "not", como negação, ou serem agrupadas em blocos OR, entre chaves, por exemplo: { dst-port 50 or dst-port 51 or not src-port 52 }. Descreveremos cada uma dela abaixo:

"dst-ip endereço" - Endereço IP de destino do pacote.
"dst-port porta" - Porta(s) de destino do pacote. Se for especificada mais de uma porta, separar por vírgula (50, 51, 52), ou em faixa de portas (50-60).
"established"
Se o pacote tiver os bits RST ou ACK.
"frag"
fragmentos de pacotes, não sendo o primeiro fragmento.
"gid grupo"
Pacotes TCP ou UDP enviados ou recebidos pelo grupo. O grupo pode ser especificado pelo nome ou pelo GID.
"icmptypes tipo"
Tipo(s) de pacotes ICMP. Se for mais de um, separar por vírgula. Os tipos podem ser: echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) e address mask reply (18).
"in | out"
Pacotes de entrada ou de saída. Note que isto significa que os pacotes estão entrando ou saindo da máquina, então mesmo que um pacote venha da rede interna, estará entrando na máquina antes de sair.
"keep-state"
Quando um pacote coincidir com uma regra que tiver esta opção, será criada uma regra dinâmica, cujo comportamento será coincidir o tráfego bidirecional entre este ip/porta de origem e ip/porta de destino, no mesmo protocolo. A regra dinâmica expira após um certo tempo. Dessa forma, pode-se definir uma regra "check-state" anterior a esta, liberando este fluxo de pacotes, e teremos um firewall "stateful".
"limit {ip-origem | porta-origem | ip-destino | porta-destino} número"
Serão permitidas apenas o número especificado de conexões com os parâmetros especificados.
"mac mac-destino mac-origem"
Pacotes com o endereço MAC de destino e/ou de origem especificados. Se não for especificado algum deverá ser usada a palavra "any", para coincidir com todos os endereços.
"proto protocolo"
Pacotes com o protocolo (IP) especificado. Veja /etc/protocols.
"recv interface | xmit interface | via interface"
Pacotes recebidos pela interface de rede especificada (recv xl0), pacotes transmitidos pela interface especificada (xmit fxp0), ou pacotes passando pela interface, independentemente de entrar ou sair (via xl0). Quando xmit for utilizado é requerida a opção "out", já que o pacote estará saindo.
"setup"
Pacotes com o bit SYN mas sem o bit ACK.
"src-ip endereço"
Endereço IP de origem do pacote.
"src-port porta"
Porta(s) de origem do pacote.
"tcpflags flags"
Flags dos pacotes TCP, separadas por vírgula. As possíveis são: fin, syn, rst, psh, ack e urg. A negação pode ser feita por um "!".
"uid usuário"
Pacotes TCP ou UDP enviados ou recebidos pelo usuário. O usuário pode ser especificado pelo username ou pelo UID.
"vrrevpath"
Pra pacotes de entrada, é feita uma consulta ao endereço de origem na tabela de roteamento. Se a interface na qual o pacote entrou é a mesma de saída especificada pela rota, então a regra coincide. Isto pode ser utilizado para criar regras anti-spoofing. Os pacotes de saída não são submetidos à verificação.
PARA UMA LEITURA MAIS AVANÇADA ACESSE OS FONTES DO TEXTO ACIMA:
http://www.freebsd-howto.com/HOWTO/Ipfw-HOWTO

http://www2.unijui.tche.br/~heini/freebsd/ipfw2.html

Exemplos práticos:

### Liebrar udp da rede 192.168.0.0/24  para a rede 192.168.1.0/24
add 00100 allow udp from 192.168.0.0/24 to 192.168.1.0/24 in
### Regra para o INPUT do trafego SSH
add 00200 allow tcp from any to 192.168.1.1/32 22 in
### Regras para o INPUT do VNC da rede 192.168.1.0/24 para VNCs na rede 192.168.1.0/24
add 00300 allow tcp from 192.168.1.0/24 to 192.168.0.0/24 5900 in setup
### Bloquear todos os pacotes vindo de qualquer lugar para qualquer lugar e logar os mesmo
add 64534 deny log all from any to any

Resumindo a sintaxe das regras no IPFW:

# O comando entre colchetes é opcional
command   [rule number]   action   proto   from   source[port]   to   destination[port] [Complemento: in,out,via... etc]

Snorby - Instalação do frontend para snort

noreply@blogger.com (Leonardo Couto Conrado) — Mon, 28 Jun 2010 12:30:00 +0000

Utilizei para esta implementação o snorby 1.1.3 , ambos sobre o FreeBSD 7.2, mais detalhes sobre essa aplicação:

- Snorby 1.1.3:

O snorby é um dos frontends utilizados para visualizar os alertas gerados pelo snort, ele também contém gráficos e estatisticas dos alertas coletados pelo snort. Possui uma interface bastante intuitiva e moderna. Conheça-o http://snorby.org/.

Particulamente gostei muito deste frontend, ele ainda esta em fase de desenvolvimento, mas já dar para utiliza-lo em produção. Veja o report bug do mesmo com a identificação de erros e suas devidas correções e ferramentas a serem implementadas: http://github.com/mephux/Snorby/issues.

O Snorby é desenvolvido utilizando a linguagem de programação ruby on rails para plataforma web. Outro ótimo frontend é o BASE(http://base.secureideas.net/) fork do antigo ACID ambos são desenvolvidos utilizando a ligaugem de programação php.

Vamos para a instalação:

- Programas/dependênias para instalação do Snorby(Instalaremos através do ports):

git-1.7.1 Distributed source code management tool
mysql-client-5.5.4 Multithreaded SQL database (client)
mysql-server-5.5.4 Multithreaded SQL database (server)
ruby18-gems-1.3.7 Package management framework for the Ruby language
ruby18-iconv-1.8.7.248,1 An iconv wrapper class for Ruby

- E através do gem(Gerenciador de pacote do ruby) instalaremos outros pacotes:

- prawn
- rake
- rails
- dbd-mysql
- mysql

- E finalmente através do git:

- Snorby

- Vamos a instalação dos programas e dependencias(No configure do make não marque as opções que aparecerão desmarcadas e deixe as que já estão marcadas):

Instalação do mysql:


# cd /usr/ports/databases/mysql55-server/ && make install clean

Instalação do git:


# cd /usr/ports/devel/git/ && make install clean

Instalação do ruby-gems:


# cd /usr/ports/devel/ruby-gems/ && make install clean

Instalação do ruby-iconv:


# cd /usr/ports/converters/ruby-iconv/ && make install clean

- Instalação dos pacotes através do gem:


# gem install prawn


# gem install rake


# gem install rails


# gem install dbd-mysql


# gem install mysql

Vamos instalar o aplicativo Snorby, instale o mesmo na pasta /usr/local/www então siga o passo a passo:
OBS.: O git utiliza uma porta especifica para realizar o download verifique o seu firewall.


# cd /usr/local/www/ && git clone git://github.com/mephux/Snorby.git

Pronto se tudo ocorreu sem problemas o servidor já se encontra com o snorby instalado, iremos para os pré-requisitos de seu funcionamento:

- Primeiro: Configure o seu snort com banco mysql.

- Segundo: O snorby terá um banco, criado automaticamente pelo rake setup(comando que veremos mais adiante);

- Terceiro : O mysql deve estar iniciado e com permissões de acesso para usuário e seu banco de dados snorby, pois, agora será utilizado somente um único banco que armazenará informações tanto do snort quanto do snorby.

- Quarto: O banco snorby/snort é criado automaticamente pelo rake setup(comando que veremos mais adiante) no localhost ou seja na máquina em que foi instalado o snorby. Não consegui descobri onde alterar essa config.

OBS.: Der permissão para o usuário do banco snorny, para o host localhost, exemplo:

na console do mysql:


GRANT ALL PRIVILEGES ON snorby.* TO snorby@'localhost' IDENTIFIED BY 'senhaDoBDSnorby' WITH GRANT OPTION;

- Após estes passos iremos configurar dois arquivos do Snorby que se encontram em /usr/local/www/Snorby/config, são eles o database.yml e email.yml;


# cp /usr/local/www/Snorby/config/database.yml.example /usr/local/www/Snorby/config/database.yml


# cp /usr/local/www/Snorby/config/email.yml.example /usr/local/www/Snorby/config/email.yml

- Configure os mesmos, o database.yml configura aonde será instalado o banco de dados do snorby e o email.yml confgs para enviar alertas para o email.

Vamos ao processo de confguração automatica do Snorby(Instale os requerimentos adicionais do gem, ele irá informa na console quais são os requerimentos, para carregar o Snorby)

ATENÇÂO: Nessa versão do snoby(1.1.3) a instalação automática só é executada com sucesso se for configurado no arquivo database.yml o BD como localhost e dada as devidas permissões para o usuário que você passa neste mesmo arquivo citado. Aqui onde trabalho configurei como localhost depois instalei o snprby e após instalação executei o script mysql do snorby em outro servidor mysql da minha rede e depois fiz os devidos apontamentos database.yml para o servidor mysql remoto da minha rede.


# cd /usr/local/www/Snorby && rake gems:install


# cd /usr/local/www/Snorby && rake snorby:setup RAILS_ENV=production

Se for a primeira instalação execute também:


# cd /usr/local/www/Snorby && rake snorby:update RAILS_ENV=production


# cd /usr/local/www/Snorby && rake snorby:reset RAILS_ENV=production   # ALL DATA WILL BE LOST

Start Snorby:


# ruby18 script/server -e production -b 127.0.0.1 -p 80 -d

-b = bind address [Default: loopback]
-p = port number [Default: 3000]
-e = environment
-d = Run server as daemon

The default User Name and Password for Snorby:

User: snorby
Password: admin

FONTE:

http://github.com/mephux/Snorby

http://wiki.github.com/mephux/Snorby/snorby-recipe-with-barnyard2-unified2-and-apache-jjc

Fiz um script para colocar na inicialização do sistema operacional o snorby, como é FreeBSD este script deve ser colocado em /usr/local/etc/rc.d/:


#!/bin/sh
#
# $FreeBSD: snorby
#

# PROVIDE: snorby
# BY: Leonardo Couto Conrado
# IN: 11.06.2010

. /etc/rc.subr

name="snorby"

rcvar="`set_rcvar`"

load_rc_config $name

: ${snorby_enable="NO"}
: ${snorby_port_listen="80"}
: ${snorby_bind_addr="127.0.0.1"}
: ${snorby_environment="production"}


command="cd /usr/local/www/Snorby && /usr/local/bin/ruby18"
command_args="script/server -e ${snorby_environment} -b ${snorby_bind_addr} -p ${snorby_port_listen} -d"
procname="/usr/local/bin/ruby18"
pidfile="/var/run/${name}.pid"

run_rc_command "$1"

E no /etc/rc.conf colocamos as seguintes linhas:


#;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
# SNORBY
#;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
snorby_enable="YES"
snorby_port_listen="80"
snorby_bind_addr="127.0.0.1"
snorby_environment="production"

Pronto agora já temos o snorby instalado e na inicialização do SO.

Snort - Instalação

noreply@blogger.com (Leonardo Couto Conrado) — Mon, 21 Jun 2010 12:13:00 +0000

Utilizei para esta implementação o snort 2.8.6 , ambos sobre o FreeBSD 7.2, mais detalhes sobre essa aplicação:

- Snort 2.8.6:

http://conteudoopensource.blogspot.com/2010/06/snort-snort-286-em-modo-promiuscuo.html

O snort pode ser utilizado tanto para detectar ataques(IDS colocando-o em modo promiscuo utilizando por exemplo o port mirror no switch) quanto também para detectar e bloquear os ataques(IPS colocando-o no modo in-line no gateway, firewall de sua rede.), neste tutorial estou utilizando o snort em modo promiscuo realizei um port mirror da porta dos gateways da rede e os alertas estão sendo registrados em um banco mysql.

Bem, vamos dar o start-up em nosso assunto principal que é a instalação do snort:

OBS.: Para utilizar o output(alertas e logs) direcionado para banco de dados mysql, vc antes deverá instalar o mysql e suas bibliotecas.

1) Baixe o snort http://www.snort.org/downloads. Descompacte o tallbar(arquivo tar.gz) do snort;

2) Dentro da pasta descompactada, iremos iniciar a configuração, compilção e instalação:

-> Configure com output para DB mysql:


#./configure --with-mysql --with-mysql-includes=/usr/local/include/mysql --with-mysql-libraries=/usr/local/lib/mysql --prefix=/usr/local/snort


# make


# make install

3) Criar estruturas de diretórios do snort


# mkdir /usr/local/etc/snort

Na pasta descompactada do snort, copie os arquivos do diretório conforme abaixo:


# cp /home/leonardo.conrado/snort-2.8.6/etc/* /usr/local/etc/snort/

4) Copiar as rules que deve ser baixados do site snort.org(Vc deve se cadastrar antes) e coloque-as em /usr/local/snort/rules(crie a pasta rules se não existir)


# cp /home/leonardo.conrado/snortrules-snapshot-2860/* /usr/local/snort/rules

5) Configurar o snort, conforme abaixo:


# vi /usr/local/etc/snort/snort.conf

Configure as principais variáveis, veja os exemplos já configurado:


###################################################
# Step #1: Set the network variables.  For more information, see README.variables
###################################################
# Setup the network addresses you are protecting
var HOME_NET [192.168.1.0/24]

# List of DNS servers on your network
var DNS_SERVERS [192.168.0.60/32,187.84.92.1,187.84.92.2/32]

# List of web servers on your network
var HTTP_SERVERS [192.168.0.64/32]

# List of sql servers on your network
var SQL_SERVERS [192.168.0.65/32]

# List of SMTP servers on your network
var SMTP_SERVERS 187.84.92.99

# Path to your rules files (this can be a relative path)
# Note for Windows users:  You are advised to make this an absolute path,
# such as:  c:\snort\rules
var RULE_PATH /usr/local/snort/rules/rules
var SO_RULE_PATH /usr/local/snort/rules/so_rules
var PREPROC_RULE_PATH /usr/local/snort/rules/preproc_rules

###################################################
# Step #6: Configure output plugins
# For more information, see Snort Manual, Configuring Snort - Output Modules
###################################################

# syslog
output alert_syslog: LOG_AUTH LOG_ALERT

# pcap
# output log_tcpdump: tcpdump.log

# database
output database: alert, mysql,user=snort password=senhaBancoSnortmysql dbname=snort host=192.168.0.65

output database: log, mysql,dbname=snort username=snort password=senhaBancoSnortmysql host=192.168.0.65

###################################################
# Step #7: Customize your rule set
# For more information, see Snort Manual, Writing Snort Rules
###################################################
…

Para debugar habilitei também o output dos alertas e logs do snort para o syslog e sua saida esta sendo escrita no /var/log/messages.
6) Para testar inicie o snort, acompanhe a saída e se ocorrer algum erro a inicialização será interrompida e vc poderá verificar qual o motivo para o erro:


# /usr/local/snort/bin/snort -c /usr/local/etc/snort/snort.conf

Para coloca-lo na inicialização do S.O e setar alguns parametros como interface que o snort irá escutar, coloca o seu processo em back ground etc, então criei um script para o rc.d(lembrando que neste caso estou utilizando o FreeBSD). Abaixo o script snort dentro da pasta /usr/local/etc/rc.d:


#!/bin/sh
Exp $

# PROVIDE: snort
# REQUIRE: DAEMON
# BEFORE: LOGIN
# KEYWORD: shutdown

. /etc/rc.subr

name="snort"

rcvar="`set_rcvar`"

load_rc_config $name

: ${snort_enable="YES"}
: ${snort_if_listen="re0"}
: ${snort_config_file="/usr/local/etc/snort/snort.conf"}

command="/usr/local/sbin/snort/${name}"
command_args="-q -D -i ${snort_if_listen} -c ${snort_config_file}"
procname="/usr/local/sbin/snort/snort"
pidfile="/var/run/${name}_${snort_if_listen}.pid"

run_rc_command "$1"

Já no arquivo /etc/rc.conf, ahbilito o mesmo para carregar na inicialização e seto alguns parametros:


#;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
# SNORT
#;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
snort_enable="YES"
snort_if_listen="re1"
snort_config_file="/usr/local/etc/snort/snort.conf"

Pronto! Agora você já possui o snort na inicialização...

Observações:

- No arquivo snort.conf habilite rules/regras que sejam relevantes a sua rede, por exemplo, você não precisa deixar habilitada a regra para serviços mysql se você não possui nenhum servidor mysql em sua rede... Outra coisa importante também, é definir bem as váriaveis do seu arquivo snort.conf, para que se tenha um bom filtro e que se colete alertas que realmente sejam importantes para a segurança de sua rede e também para se evitar logs que sejam falsos positivo.

- Sempre mantenha suas regras atualizadas, para autmatizar essa atualização de regras utilizo o aplicativo oinkmaster pesquise como instala-lo e configura-lo é bastante simples.

- Utilize as regras do Emerging Threats que é uma comunidade de projetos open sources que desenvolve assinaturas/regras para o snort e que também possui outros projetos open sources ligados a segurança da informação. Conheça http://www.emergingthreats.net/index.php/about-et-mainmenu-43.html

- Existe um arquivo na pasta etc do snort chamado threshold.conf lá você poderá colocar limites para alertas que são gerados com muita frequência ocasionando em alto output se preferir você poderá suprimi-los também utilizando este arquivo threshold.conf.

Snort - Introdução ao IDS/IPS Snort

noreply@blogger.com (Leonardo Couto Conrado) — Wed, 16 Jun 2010 17:24:00 +0000

O Snort é um sistema de detecção de invasão baseado em rede (SDIR) de código fonte aberto, possuindo muitos recursos. Ele é sniffer que tem como diferencial a capacidade de inspecionar o payload do pacote, área que contém os dados do mesmo, fazendo o registros dos pacotes, além de detectar as invasões.

O Snort é um sistema avançado capaz de detectar quando um ataque
está sendo realizado e, baseado nas características do ataque, alterar ou remodelar sua configuração de acordo com as necessidades, e até avisar ao administrador do ambiente sobre o ataque.

Considera-se o Snort um SDI ligthweight, ou seja, ele pode ser colocado em funcionamento com muito pouco esforço tanto no sentido computacional quanto no sentido configuração e suporte.
Um característica marcante do Snort é a facilidade de criação de assinaturas de ataques. Profissionais da área de segurança da informação sabem da velocidade que os eventos ocorrem no mundo virtual. A prontidão, exatidão e rapidez são assuntos essenciais em se tratando de segurança. Como o Snort é um sistema de código aberto e apresenta linguagem fácil de criação de assinaturas, permite a pronta criação e adição de uma nova assinatura de ataque por parte do
administrador.

O Snort é uma ótima ferramenta, mas como todo aplicativo deve ser bem implementada. Devem ser aplicadas somente as assinaturas de ataques relevantes a realidade da rede. Por exemplo, não é necessário monitorar ataque a banco de dados MySQL se ele não se encontra em uso, o que ocasionaria apenas alertas irrelevantes. Além disso o banco de assinaturas deve estar constantemente atualizado evitando assim que ataques passem desapercebidos. O administrador tendo esses cuidados evita ou minimiza os falsos positivos e falsos negativos.

O profissional responsável pela rede deve certificar-se que o sistema onde o Snort esta operando é o mais seguro possível, ou seja, deve-se esta atendo a segurança do sistema operacional onde o Snort esta rodando. Uma invasão à máquina SDI invalida qualquer alerta do mesmo.
O Snort é um sistema que não requer grandes recursos de hardware. Os recursos de hardware necessário para o sistema operacional em uso atende ao Snort.

O Snort foi projetado para ser executado em uma grande gama de sistemas entre eles Linux, FreeBSD, NetBSD, OpenBSD, Solaris, MacOS, Windows, entre outros.

Existem alguns programas opcionais que podem ser instalados para melhorar/facilitar a administração do sistema. Cita-se os aplicativos para o mundo Linux. Os softwares são:

http://www.snort.org/downloads/additional-downloads/

FONTE: http://www.ginux.ufla.br/files/mono-BrunoSantos.pdf