LDAP

Uma autenticação centralizada faz parte do processo de adequação do ambiente as boas práticas de segurança. Esta solução provê recursos que atendem aos principios de autenticidade e não-repúdio. Usando a criptografia juntamente com esta solução pode-se previnir ataques de hijacking, spoofing e man in the middle.
O LDAP (Lightweight Directory Access Protocol) é um protocolo cliente-servidor, utilizado para acessar um serviço de Diretório. Ele foi inicialmente usado como uma interface para o X.500, mas também pode ser usado com autonomia e com outros tipos de servidores de Diretório. Atualmente vem se tornando um padrão, diversos programas já têm suporte a LDAP. Livros de endereços, autenticação, armazenamento de certificados digitais (S/MIME) e de chaves públicas (PGP), são alguns dos exemplos onde o LDAP já é amplamente utilizado.
O Openldap é a solução livre para a implementação do LDAP. Diferentemente das soluções proprietárias ( e.g. Active Directory (tm) ), ele implementa de forma fidedigna as especificações das RFCs deste protocolo.

Uma das principais vantagens do LDAP é a facilidade em localizar informações e arquivos disponibilizados. Pesquisando pelo sobrenome de um funcionário é possível localizar dados sobre ele, como telefone, departamento onde trabalha, projetos em que está envolvido e outras informações incluídas no sistema, além de arquivos criados por ele ou que lhe façam referência. Cada funcionário pode ter uma conta de acesso no servidor LDAP, para que possa cadastrar informações sobre sí e compartilhar arquivos.

O LDAP oferece uma grande escalabilidade. É possível replicar servidores (para backup ou balanceamento de carga) e incluir novos servidores de uma forma hierárquica, interligando departamentos e filiais de uma grande multinacional por exemplo. A organização dos servidores neste caso é similar ao DNS: é especificado um servidor raiz e a partir daí é possível ter vários níveis de sub-servidores, além de mirrors do servidor principal.

Tela do LDAP, um dos passos para se criar um usuário:

Portscanner - Nessus

Um port scanner (scanner de porta) é um aplicativo com o objetivo de testar as portas lógicas de determinado host remoto. Neste teste ele identifica o status das portas, se estão fechadas, escutando ou abertas.

O Nessus é um programa de verificação de falhas/vulnerabilidades de segurança (portas, vulnerabilidades, exploits). Ele é composto por um cliente e servidor, sendo que o scan propriamente dito é feito pelo servidor. O nessusd (servidor Nessus) faz um port scan ao computador alvo, depois disso vários scripts (escritos em NASL, Nessus Attack Scripting Language) ligam-se a cada porta aberta para verificar problemas de segurança. O Nessus ajuda a identificar e resolver alguns problemas de vulnerabilidades. A parte Servidor executa os testes enquanto a parte cliente permite a configuração e emissão de relatórios.

Shorewall

Shorewall (mais apropriadamente como Shoreline Firewall) é uma ferramenta de firewall Linux de código aberto, que se baseia no Netfilter (iptables / ipchains) sistema embutido no kernel do Linux, possibilita uma configuração mais organizada e rápida do seu firewall, tornando mais fácil para gerenciar sistemas de configuração mais complexa.

Usando uma analogia compreensível para programadores: Shorewall é iptables, o C é a linguagem assembly. Ele fornece um nível maior de abstração para descrever regras de uso de arquivos de texto.

Abaixo temos o link para o tutorial passo a passo de como instalar e configurar o Shorewall no Debian: http://www.megaupload.com/?d=OYQZ7PI8

Sniffer

Sniffers ou farejadores são softwares muito úteis. Tão grande é a utilidade deles, que até os sistemas de IDS (como o Snort) são feitos com base em sniffers. Um sniffer é um programa que consegue capturar todo o tráfego que passa em um segmento de uma rede. Para tornar mais fácil o entendimento, observe a imagem abaixo:

Quando ligamos computador no HUB, e enviamos informação de um computador para o outro, na realidade esses dados vão para todas as portas do HUB, e conseqüentemente para todas as máquinas. Acontece que só a máquina na qual a informação foi destinada enviará para o sistema operacional.

Se um sniffer estivesse rodando nos outros computadores, mesmo sem esses sistemas enviarem a informação que trafega ali para o sistema operacional, o farejador intercederá na camada de rede, capturando os dados e mostrando-os para o usuário, de forma pouco amigável. Geralmente os dados são organizados por tipos de protocolo (TCP, UDP, FTP, ICMP, etc...) e cada pacote mostrado pode ter seu conteúdo lido.

Criptografia Convencional

Princípios da Criptografia Convencional

A criptografia convencional possui cinco elementos:
• o texto plano;
• o algoritmo de criptografia;
• a chave secreta;
• o texto cifrado (codificado);
• o algoritmo de decriptografia.

Observação: A segurança da criptografia depende do segredo da chave, e não do algoritmo que, geralmente, é de domínio público.

A criptografia pode ser classificada de acordo com:
• o tipo de operação utilizada para transformar o texto plano em texto cifrado;
• o número de chaves utilizadas:
- simétrica: utiliza uma única chave;
- assimétrica: utiliza duas chaves ou criptografia de chave pública;
• a forma como o texto plano é processado.

Tempo médio necessário para decriptografia utilizando a força bruta:

Configurando Snort e Guardian

Instalando o Snort no Debian



Snort é um "farejador" que analisa todo o tráfego da rede, porém não toma nenhuma atitude. Neste tutorial você verá como integrar o Snort com o Guardian. O Guardian, por sua vez, toma a ação de atualizar o iptables com os alertas gerados pelo Snort, ou seja, ele interpreta o log do Snort e atualiza a regra do iptables.

Antes de iniciar, vamos colocar os seguintes mirrors em nosso sources.list:


Código: Selecionar todos
deb http://ftp.us.debian.org/debian lenny main contrib non-free
deb http://de.debian.org/debian squeeze main

Agora vamos atualizar a lista de pacotes:

# apt-get update

Criar diretório IDS na raiz:

# mkdir /IDS

Criar diretório para instalação do http:

# mkdir /www

Copiar todos os pacotes para /IDS:

# cp snort-xxx.tar.gz /IDS
# cp http-xxx.tar.gz /IDS

Descompactar em /IDS e fazer a compilação:

# tar -zxvf http-xxx.tar.gz
# cd http-xxx

Obs.: Verifique se o pacote build-essential está instalado, pois utilizaremos o compilador GCC e esse pacote já vem o GCC e outros softwares. Caso não esteja devidamente instalado, utilize:

# apt-get -y install build-essential
# ./configure --prefix=/www
# make && make install

Verifique se o iptables está instalado e sua versão utilizando:

# iptables -V

Antes de instalar o Snort, vamos instalar a Libcap, que é necessária para a instalação do Snort:

# apt-cache search libpcap

(assim verificamos o nome e a versão do pacote)

# apt-get -y install libpcap0.8-dev

Foi utilizada a versão 0.8 da libpcap.

Precisamos instalar também o Libpcre:

# apt-get -y install libpcre3-dev

Agora vamos instalar o Snort-xxx:

# tar -zxvf snort-xxx.tar.gz
# cd snort-xxx
# ./configure
# make && make install

Crie os seguintes diretórios:

# mkdir /etc/snort
# mkdir /etc/snort/rules

Ainda no diretório /IDS/snort-xxx faça:

# cd etc/
# cp classification.config gen* threshold.conf unicode.map sid* snort.conf reference.config /etc/snort/

Agora vamos colocar as rules baixadas do site snort.org (lembrando que é necessário ter login no referido site para baixar as rules):

# cd /IDS
# tar -zxvf snortrules-snapshot-CURRENT.tar.gz
# cd rules
# cp * /etc/snort/rules

Obs.: O link direto para download é: snortrules-snapshot-CURRENT.tar.gz

Para isso você precisa ter login, mas para criar seu login no site é FREE, grátis. :)

Crie o arquivo que irá guardar os logs:

# mkdir /var/log/snort
# cd /var/log/snort
# touch alert

Para rodar o Snort, edite o arquivo:

# vim /etc/snort/snort.conf

Altere a linha:

var RULE_PATH ../rules

Para:

var RULE_PATH /etc/snort/rules

E faça assim:

# snort -c /etc/snort/snort.conf -o

Ou melhor:

# snort -c /etc/snort/snort.conf -o -i eth0 -D


Definição do Guardian:


"O Guardian, é uma ferramenta que lê os logs do snort em tempo real e bloqueia algum ataque que esteja vindo de algum lugar na internet, ou melhor, bloqueia alguma coisa que possa vir a ser um problema para seu servidor e/ou você." - Snort + MySQL + Guardian + ACID - ataliba.eti.br

Agora vamos instalar o Guardian:

# cd /IDS
# tar -zxvf guardian-1.7.tar.gz
# cd guardian-1.7/scripts

O programa Guardian utiliza sempre os scripts denominados guardian_block.sh e guardian_unblock.sh. Assim, deverão ser copiados para os arquivos com esses nomes correspondentes ao firewall que pretendemos utilizar. Copie:

# cp iptables_block.sh /usr/bin/guardian_block.sh
# cp iptables_unblock.sh /usr/bin/guardian_unblock.sh
# chmod 755 /usr/bin/guardian_block.sh /usr/bin/guardian_unblock.sh
# cd ..
# cp guardian.pl /usr/bin
# chmod 755 /usr/bin/guardian.pl
# cp guardian.conf /etc/

Vamos configurar alguns parâmetros no guardian.conf:

Interface eth0 #Interface eth0, a que terá os terminais bloqueados
AlertFile /var/adm/secure #Mude para /var/log/snort/alert
TimeLimit 86400 #Mude para um valor em segundos que pretendemos que o endereço IP fique bloqueado pela firewall. O valor 99999999 remove esta opção.

Crie o arquivo de log do guardian:

# touch /var/log/guardian.log

Crie o arquivo guardian.ignore com os endereços IP que se pretende ignorar:

# touch /etc/guardian.ignore

Inicie o Guardian:

# guardian.pl -c /etc/guardian.conf

Caso retorne um erro relacionado a seu IP, ex.:

Warning! HostIpAddr undefined!
Attempting to guess...

Abra o arquivo /etc/guardian.conf, no começo do arquivo, descomente a linha:

# HostIpAddr

Deixando assim:

HostIpAddr SEUIP

Ex.: HostIpAddr 192.168.0.102

Agora, tente de novo iniciar o Guardian...

Para visualizar o log use:

# tail -f /var/log/snort/alert

Uma observação importante é que o Snort, com o pacote básico das regras, gera muitos falsos positivos, porém serve muito bem! Exstem também regras para serem compradas prontas, oque geraria um maior nivel de precisão.


Fonte: VOL

MRTG

O Multi Router Traffic Grapher (MRTG) é uma ferramenta de monitoração que gera páginas HTML com gráficos de dados coletados a partir de SNMP ou scripts externos. É conhecido principalmente pelo seu uso na monitoração de tráfego de rede, mas pode monitorar qualquer coisa desde que o host forneça os dados via SNMP ou script.

Foi desenvolvido por Tobias Oetiker e Dave Rand. Foi escrito em Perl mas utiliza um módulo em C para gerar os gráficos.

Características

• Mede sempre 2 valores, no caso de tráfego, pode ser Entrada e Saída.
• Faz as leituras via SNMP ou através de script que retorne um formato padrão.
• Coleta dados a cada 5 minutos por padrão, mas este tempo pode ser aumentado ou diminuido.
• Cria uma página HTML com 4 gráficos (diário, semanal, mensal e anual). Se algum deles não for necessário pode ser suprimido.
• O MRTG pode avisar caso o valor do gráfico atinja um valor pré-estabelecido. Por exemplo: se determinado servidor atinge 95% do espaço do disco, o MRTG pode mandar um e-mail para o administrador informando o ocorrido.
• Possui uma ferramenta para gerar os arquivos de configuração: o CFGMAKER.
• Possui uma ferramenta para gerar um página de índice para os casos em que muitos ítens são monitorados: o INDEXMAKER.

O MRTG é software livre distribuído nos termos da GNU General Public License.

Instalando e configurando SNMP e MRTG

Neste artigo veremos como instalar e usar o SNMP e MRTG.
Os agentes SNMP devem ser executados no modo SOMENTE-LEITURA (RO) porque o coletor SNMP somente precisa ler os dados nas máquinas remotas. Limitando como tem a permissão de acessar os agentes nos dispositivos remotos aumentando um pouco a segurança.
Nunca esqueça que a comunidade SNMP está cruzando a rede em texto limpo e pode ser facilmente interceptada usando ferramentas como o WireShark, antigo Ethereal.

Serão necessários os pacotes SNMP, MRTG e o Apache rodando. Baixe os fontes de acordo com sua distribuição e instale. Instale e configure o SNMP e o MRTG nesta ordem. Tem que ser feito desta forma, pois é preciso que o SNMP esteja devidamente configurado para que o MRTG possa atuar sem problemas.

Em máquinas debian/Ubuntu Linux:

Instale o serviço SNMP:

#apt-get install snmpd

Instale o apache:
#apt-get install apache2

Depois de instalados, iremos configurar o SNMP. Edite o arquivo snmpd.conf:

# vi /etc/snmp/snmpd.conf

Existem diversos tipos de configuração para monitoramento via MRTG, neste texto trataremos de uma configuração simples e funcional.

Ache o tópico "## sec.name source community" e descomente as linhas:

com2sec     local     localhost        private
com2sec     mynet     192.168.0.0/24   public
com2sec     public    default          public

Observe a segunda linha, onde está definido o nome e o endereço da rede.

Em seguida descomente e defina as seguinte linhas:

group mygroup   v1          mynet
group mygroup   v2c         mynet
group local     v1          local
group local     v2c         local
group public    v1          public
group public    v2c         public

view all    included  .1         80
access mygroup  ""  any    noauth    0    all    none   none
access public   ""  any    noauth    0    all    none   none
access local    ""  any    noauth    0    all    all    all

Essas linhas vêm descomentadas por padrão. Deixe-as:

syslocation Unknown (edit /etc/snmp/snmpd.conf)
syscontact Root  (configure /etc/snmp/snmp.local.conf)

Pronto salve o arquivo e inicie o serviço:

# service snmpd start

Configurando MRTG

Você pode usar o comando apt-get install mrtg e o programa irá baixar e instalar automaticamente. Agora se você quiser baixá-lo, visite a página oficial do MRTG:

• MRTG – http://oss.oetiker.ch/mrtg/

O MRTG requer o seguinte para compilar e funcionar no seu Linux: gcc, perl, gd, libpng, zlib. Provavelmente sua distribuição já veio com esses pacotes, então não os cobrirei neste tutorial. Vamos agora começar a instalação:

# tar zpfx mrtg-2.9.25.tar.gz
# cd mrtg-2.9.25
# ./configure --prefix=/usr --sysconfdir=/etc/mrtg

[...configurando a compilação...]

# make

[...compilando...]

# make install

E pronto. Se tudo ocorrer bem, o MRTG estará instalado corretamente no seu sistema, e pronto para o uso! Mas antes, teremos que criar um arquivo de configuração para o MRTG usar. Para isso utilizaremos um utilitário do MRTG chamado “cfgmaker”. Tenha em mãos o IP do seu roteador e a senha “community” dele… Se você não souber o que diabos é isso, então está precisando mexer um pouco mais com o roteador :) Execute o comando:

cfgmaker --global 'WorkDir: /var/www/html/mrtg' \
--global 'Options[_]: bits,growright' \
--output /etc/mrtg/exemplo.cfg \
community@xxx.xxx.xxx.xxx

Onde “xxx.xxx.xxx.xxx” é o IP do seu roteador. Este comando irá gerar o arquivo “/etc/mrtg/exemplo.cfg” e servirá para alterarmos manualmente, comparando com o resultado. Veja este exemplo de configuração final comentada:

# ---------------------
# Configurações Globais
# ---------------------

# Diretório onde vai ficar a página com os gráficos gerados
# pelo MRTG
WorkDir: /var/www/html/mrtg

# Língua usada pelo MRTG para as mensagens na página
Language: brazilian

# Opções:
# bits = Mostrar a velocidade em bits (bits/bytes)
# growright = O gráfico cresce para a direita
Options[_]: bits,growright

# Rodar como Daemon? Assim não será preciso colocar
# no crontab, só precisará colocar um comando na
# inicialização do Linux.
RunAsDaemon: yes

# --------------------------------
# Configuração do link 1 (256kbps)
# --------------------------------

# Aqui você terá de comparar com o exemplo gerado
# pelo comando 'cfgmaker', coloque o valor igual
# ao que foi mostrado. O primeiro número é essencial
# para saber a ligação que estamos usando no roteador.
Target[EXEMPLO]: 1:community@xxx.xxx.xxx.xxx:

# A quantidade de bytes que o link suporta.
# 64kbps = 8000
# 256kbps = 32000
MaxBytes[EXEMPLO]: 32000
AbsMax[EXEMPLO]: 32000

# Com essa opção, todos os 4 gráficos não serão
# redimensionados de acordo com o uso do link. Eles sempre
# terão a altura do máximo de tráfego que se pode chegar
# (de acordo com os itens acima).
Unscaled[EXEMPLO]: dwmy

# Configurações da página. Título e frase no Topo.
Title[EXEMPLO]: Exemplo de Análise de Tráfego para link de 256kbps
PageTop[EXEMPLO]: Exemplo de Análise de Tráfego para link de 256kbps

Pronto. Já temos uma configuração básica para o MRTG. Agora vamos rodá-lo:

# mrtg

Segurança do Bluetooth

O Bluetooth tem três modos de segurança, variando desde nenhuma segurança até total criptografia de dados e controle de integridade. Se a segurança for destivada, não haverá nenhuma segurança. Grande parte dos usuários mantéma segurança desativada até ocorrer uma séria violação, depois eles a ativam. No mundo agrícola, essa abordagem é conhecida como trancar a porteira depois que o cavalo escapou.

O Bluetooth fornece segurança em várias camadas. Na camada física, os saltos de frequência oferecem um nível mínimo de segurança mas, como qualquer dispositivo Bluetooth que se desloca em uma piconet tem de ser informado da sequência de saltos de frequencia, é óbvio que essa frequência não é um segredo. A segurança real começa quando o escravo recém-chegado solicita um canal ao mestre. Supõe-se que os dois dispositivos compartilham uma chave secreta configurada com antecedência.

Para estabelecer um canal, o escravo e o mestre verificam se a outra máquina conhece a chave de passagem. Nesse caso, eles negociam para ver se esse canal será criptografado, terá sua integridade controlada ou ambos. Em seguida, eles selecionam uma chave de sessão aleatória de 128 bits, na qual alguns bits podem ser públicos. A razão para permitir o enfraquecimento dessa chave é obedecer a algumas restrições do governo de vários países, criadas para impedir a exportação ou o uso de chaves mais longas do que o governo pode violar.

O Bluetooth efetua a autenticação apenas de dispositivos, não de usuários. Desse modo, quando um ladrão rouba um dispositivo Bluetooth ele pode ter acesso às finanças e às contas do usuário. No entento, o Bluetooth também implementa segurança nas camadas superiores do que a do enlace. Assim mesmo se houver violação da segurança no nível de enlace, deve restar alguma segurança, especialmente para aplicações que exigem a digitação de um código PIN em algum tipo de teclado para completar a transação.

Segurança de Rede - Linux

Introdução
A cada dia novos usuários de Linux surgem todos os dias, e graças à facilidade de acesso à Internet nos dias atuais a maior parte deles conecta suas máquinas pessoais a redes abertas sem maiores dificuldades.

Sabendo que o Linux é um sistema capaz de ser administrado remotamente, e que muitas configurações default de distribuições habilitam muitos processos servidores para iniciar automaticamente após a instalação, estes novos usuários acabam se transformando em uma ameaça a si próprios, pois expõem à Internet uma máquina aberta, devido à sua falta de conhecimento técnico.

Para piorar a situação, há abundância de textos sobre "segurança" disponíveis na internet, "ensinando" que para garantir uma configuração segura da sua máquina, tudo o que você tem a fazer é "comentar as linhas do inetd.conf", um conselho enganoso.

Primeiros passos

A segurança começa pela instalação do seu sistema Linux. Se você tem uma máquina sem configurações especiais de segurança e quer torná-la segura, uma opção interessante é reinstalá-la completamente, suprimindo assim qualquer erro que tenha sido cometido no passado; lembre-se que uma máquina invadida e onde estranhos obtiveram privilégios de superusuário jamais poderá ser considerada segura novamente, exceto se totalmente reinstalada a partir de uma mídia original (e se você corrigir as falhas que permitiram a invasão original).

Ao instalar o sistema, lembre-se dos seguintes itens:

*Só exponha o sistema à Internet após completar todos os procedimentos de segurança. Há muitos relatos de máquinas invadidas durante o processo de configuração inicial, graças a administradores que preferem confiar na sorte;
*Se a sua distribuição permitir, opte por uma instalação personalizada, e escolha apenas os pacotes que você sabe que irá usar. É muito fácil adicionar pacotes posteriormente, e será sempre um alívio quando você receber e-mail do seu fornecedor recomendando um upgrade urgente de segurança do servidor de Real Audio, e em seguida perceber que não precisa fazer nada a respeito pois não o instalou;
*Monte seu esquema de partições adequadamente. Se você for rodar algum serviço que gere armazenamento de dados em disco (uma proxy web, um servidor de mail, um servidor de news...), certifique-se de criar uma partição separada para o /var, evitando assim que os arquivos dos seus processos servidores possam lotar o espaço de armazenamento da máquina, tirando-a de operação (coisa que normalmente só pode ocorrer em caso de má configuração dos servidores, mas não há por que não levar a sério esta possibilidade);
*Após instalar todos os pacotes, instale todas as atualizações de segurança disponíveis no web site do seu fornecedor. Assine a lista de divulgação de novas atualizações, se disponível;
*Habitue-se a visitar sites de segurança para saber as novas vulnerabilidades a que você pode estar exposto.

Serviços desnecessários

Uma instalação padronizada de sistema operacional costuma habilitar uma série de serviços dos quais você não precisa, e que podem vir a servir como ponto de acesso para um invasor. Removê-los é relativamente fácil, e um passo essencial.

Editar corretamente o arquivo /etc/inetd.conf é básico. Este arquivo define quais os serviços básicos de internet estarão habilitados na sua máquina, e portanto acessíveis a partir de outras máquinas. Verifique atentamente quais destes serviços estão habilitados, e retire os que você não tiver uma boa justificativa para manter. Na dúvida, retire!

Retirar um serviço do inetd.conf é simples, basta acrescentar um caracter # no início da linha, transformando-a em um comentário. Se posteriormente você precisar habilitar novamente o serviço, basta retirar o #.

Máquinas domésticas em geral não precisam de nenhum serviço habilitado no inetd.conf, e podem até mesmo deixar de carregar o serviço inetd (inetd) na inicialização. Usuários de serviços online (como o irc) podem querer habilitar apenas o serviço auth. Não se deixe enganar pela ilusão de rodar servidores telnet, ftp e finger na sua máquina doméstica, exceto se você realmente tiver uma boa justificativa.

Após definir a sua configuração do inetd.conf, reinicie o processo do inetd, comandando killall -HUP inetd

Em seguida, você precisa verificar os serviços de rede standalone, que não são gerenciados pelo inetd.conf, mas sim pelos init scripts, de modo geral localizados abaixo do diretório /etc/rc.d. Cada distribuição de Linux lida com estes scripts de uma maneira um pouco diferente, então você terá que ler um pouco da documentação da sua preferida. Ferramentas como o ntsysv, o ksysv e o tksysv podem ajudar, e a sua distribuição pode ter oferecido algum outro pacote adicional que permita selecionar os scripts facilmente.

De modo geral, os init scripts definem quais serviços serão inicializados no momento do boot. Alguns serviços são aparentemente inócuos do ponto de vista de uma possível invasão (e.g. sound, random, apmd), enquanto outros claramente oferecem algum raio de ação para o potencial invasor (e.g. portmap, xntpd, netfs, rstatd, rusersd, rwalld, rwhod, bootparamd, squid, yppasswd, ypserv, dhcpd, snmpd, named, routed, lpd, gated, httpd, xfs, linuxconf e muitos outros).

Ao definir quais scripts você executará no boot, use o mesmo critério da seleção dos serviços do inetd; na dúvida, retire - se mais tarde você precisar, adicione novamente (após avaliar o impacto sobre a segurança). Particularmente evite rodar o servidor do linuxconf, rstatd, rusersd, rwalld, rwhod, os serviços do NIS (yp*) e os daemons de roteamento (como o gated). Se você for rodar um servidor web para uso interno, ou para testes, certifique-se de configurá-lo para aceitar requests apenas da sua rede interna, ou de sua máquina pessoal - segurança de servidores não será coberta neste texto.

Cuidado ao mexer nos scripts de inicialização

Leia sempre a documentação antes, e tenha à mão um disquete de inicialização completa, como o tomsrtbt para emergências, já que provavelmente o disquete de boot gerado durante a sua instalação do Linux não resolverá o problema. Outra boa dica é aprender a iniciar o sistema em modo monousuário quando tudo falhar.

Detalhes

*Desenvolva uma estratégia de backups confiável;
*Instale ferramentas de análise e rotação de logs;
*Instale ferramentas de garantia de integridade, como o tripwire (principalmente nos servidores);
*Certifique-se de estar usando shadow passwords (nada de senhas criptografadas visíveis no /etc/passwd - este recurso já vem habilitado como default em algumas das distribuições);
*Se você estiver com o servidor de ftp habilitado, configure-o adequadamente; não permita o acesso de root, restrinja a árvore de diretórios, reveja os direitos de acesso anônimos, considere a possibilidade de as senhas de acesso estarem sendo monitoradas em sua rede local;
*Desabilite o telnet e o ftp. Se você precisar deste tipo de serviço, use o ssh (tanto para login quanto para transferência de arquivos);
*Habilite os tcp wrappers (tcpd) e configure adequadamente os arquivos de restrição e permissão de acesso (em geral, /etc/hosts.deny e /etc/hosts.allow);
*Habilite filtros de pacotes (usando ipfwadm, ipchains ou a ferramenta que estiver disponível na sua versão);
*Não permita que outras máquinas iniciem conexões com a sua, exceto para as portas que você explicitamente definir;
*Bloqueie o acesso às portas dos seus serviços locais (xfs, X, servidor web utilizado para testes...).

Monitoração remota (RMON)

A monitoração emota (RMON) é uma especificação padrão de monitoração, que habilita vários sistemas e console e monitores de rede para o intercâmbio de dados de monitoração de rede. A RMON proporciona aos administradores de rede maior liberdade para seleção de consoles e sondas de monitoração com características que satisfaçam às necessidades específicas de suas redes.

A especificação RMON define um conjunto de estatísticas e funções que podem ser permutadas entre sondas de rede e gerentes de console compatíveis com a RMON. Dessa maneira a RMON, proporciona aos administradores uma diagnose abrangente de falhas na rede, planejamento e informações para o ajuste de desempenho.

Grupos RMON

A RMON fornece informações em nove grupos RMON de elementos de monitoração, cada um oferecendo conjuntos específicos de dados para atender às necessidades de monitoração de rede. Cada grupo é opcional, permitindo que cada fabricante ão precise incluir na MIB (Base de informaçõe de administração) todos os grupos.

Alguns grupos de RMON precisam de suporte de outros grupos RMON para que possam funcionar de maneira correta.

Extraído das páginas 525 e 526 do livro INTERNET WORKING MANUAL DE TECNOLOGIAS - Tradução da Segunda Edição.

IPTables

Iptables é um Firewall.
Um firewall é uma barreira inteligente entre duas redes, através do qual só passa tráfego autorizado.
Este tráfego é examinado pelo firewall em tempo real e a seleção é feita de acordo com a política de segurança estabelecida.
O IPTables composto por 3 tabelas:
¹filter: Tabela de filtros de pacotes;
²NAT (network address translation): Conexão de várias máquinas com endereço falso á internet através de poucos endereços IP ́s válidos;
³mangle: Altera o conteúdo dos pacotes.

O que são regras:

As regras são como comandos passados ao iptables para que ele realize uma determinada ação (como bloquear ou deixar passar um pacote) de acordo com o endereço/porta de origem/destino, interface de origem/destino, etc. As regras são armazenadas dentro dos chains e processadas na ordem que são inseridas.

As regras são armazenadas no kernel, o que significa que quando o computador for reiniciado tudo o que fez será perdido. Por este motivo elas deverão ser gravadas em um arquivo para serem carregadas a cada inicialização.

Um exemplo de regra: iptables -A INPUT -s 123.123.123.1 -j DROP.

O que são chains:

Os Chains são locais onde as regras do firewall definidas pelo usuário são armazenadas para operação do firewall. Existem dois tipos de chains: os embutidos (como os chains INPUT, OUTPUT e FORWARD) e os criados pelo usuário. Os nomes dos chains embutidos devem ser especificados sempre em maiúsculas (note que os nomes dos chains são case-sensitive, ou seja, o chain input é completamente diferente de INPUT).

Quando um pacote chega a uma table é verificado se alguma regra se aplica a ele. Caso não haja, é aplicada a política defaut.
Constituído por 3 chains:

INPUT – Pacote destinado a maquina de firewall.
OUTPUT – Pacote originado da maquina de firewall.
FORWARD – Pacote com destino e origem
separados pela maquina de firewall.

Quando um pacote entra numa interface de rede:
Se o pacote é para a máquina é enviado para o chain INPUT;
Se o destino não é esta máquina e o serviço de routing está ativo, o pacote vai para o chain FORWARD;
Se um processo da máquina envia um pacote para a rede o pacote vai para o chain OUTPUT.

Política Default:
A política default do firewall consiste na regra que será utilizada caso algum pacote não se encaixe em nenhuma das regras estabelecidas.
É altamente recomendado que a política default seja DROP, ou seja, tudo o que não for expressamente permitido será descartado (proibido).

Operações do SNMP

Lista de operações suportadas pelo SNMP:

*Get - Utilizada para ler o valor de uma variável; o gerente solicita que o agente obtenha o valor da variável;

*Set - Utilizada para alterar o valor da variável; o gerente solicita que o agente faça uma alteração no valor de uma variável;

*Trap - Utilizada para comunicar um evento ; o agente comunica ao gerente o acontecimento de um evento previamente determinado.

Diferenças entre as versões SNMP

SNMP v1

O SNMPv1 consiste de três documentos:
RFC 1155 define o Structure of Management Information (SMI). Ou seja, os mecanismos usados para descrever e nomear os objetos que serão gerenciados
>RFC 1212 define um mecanismo de descrição mais conciso mas é inteiramente consistente ao SMI.
>RFC 1157 define o Simple Network Management Protocol (SNMP)

Os dois primeiros documentos definem a linguagem de dados. O terceiro documento define as operações do protocolo SNMPv1 utilizando protocol data units (PDUs). Os operadores definidos no SNMPv1 são: get, get-next, get-response, set-request e trap.

Muitos dos conceitos de segurança e administração encontrados no SNMPv3 são encontrados no modelo do SNMPv1.
O SNMPv1 introduz o conceito serviço de autenticação suportando um ou mais métodos. No SNMPv3 o conceito de autenticação foi expandido para incluir serviços como privacidade.

O modelo SNMPv1 possui o controle de acesso baseado num conceito chamado SNMP MIB view. O SNMPv3 especifica um conceito fundamentalmente similar chamado view-based access control.

Apesar do SNMPv1 ter antecipado um serviço de autenticação suportando vários métodos, não foi criado nenhum método além de uma simples autenticação baseada em community strings. Essa foi a grande deficiência do SNMPv1. Como o conceito de "segurança" pode ser interpretado de modo bastante diferente por cada usuário, o serviço de autenticação do SNMPv1 ficou para ser definido em um outro bloco o qual nunca foi posto em prática. O modelo SNMPv3 já possui uma arquitetura para esse bloco.

SNMPv2

O SNMPv2 está descrito nas RFCs: 1902, 1903,1904, 1905, 1906, and 1907. A relação entre o SNMPv1 e o SNMPv2 está descrita no RFC 1908.

O SNMPv2 possui algumas vantagens sobre o SNMPv1. São elas:
*Mais um tipo de dados: 64 bit counter;
*Melhora na eficiência e na performance: operador get-bulk;
*Notificação de evento confirmado: operador inform;
*Maior detalhamento dos erros;
*Modos facilitados de criação e deleção de linhas na MIB;
*Melhorias na definição da linguagem de dados.

Apesar do modelo SNMPv2 estar descrito no RFCs 1902-1907, alguns objetivos iniciais do projeto não foram implementados. Os objetivos não alcançados incluem o fornecimento de segurança tais como:
*autenticação: identificação da origem, integridade da mensagem;
*privacidade: confidencialidade;
*autorização e controle de acesso.

SNMPv3

Os RFCs do SNMPv3 foram produzidos pelo SNMPv3 Working Group da Internet Engineering Task Force (IETF). Esse Working Group se baseou bastante nos documentos Draft Standard do SNMPv2. Como resultado o SNMPv3 é o SNMPv2 com blocos de segurança e administração.
O modelo SNMPv3 descrito nos RFCs 2570, 2571, 2572, 2573, 2574, e 2575, relaciona as deficiências no SNMPv2 em relação a segurança e admninistração. A co-existência do SNMPv1, SNMPv2 e SNMPv3 está descrita no RFC 2576 .

Novas ferramentas foram adicionadas no SNMPv3. São elas:
*Segurança;
*autenticação e privacidade ;
*autorização e controle de acesso;
*Modelo administrativo;
*nomeação das entidades;
*gerência das chaves;
*notificação dos destinos;
*relação dos proxys configuração remota através de operadores SNMP.

Protocolo de gerenciamento SNMP

Definição

O protocolo SNMP (Simple Network Management Protocol) tem como premissa à flexibilidade e a facilidade de implementação, também em relação aos produtos futuros.
O SNMP é um protocolo de gerência definido a nível de aplicação, é utilizado para obter informações de servidores SNMP - agentes espalhados em uma rede baseada na pilha de
protocolos TCP/IP. Os dados são obtidos através de requisições de um gerente a um ou mais
agentes utilizando os serviços do protocolo de transporte UDP - User Datagram Protocol para
enviar e receber suas mensagens através da rede. Dentre as variáveis que podem ser requisitadas utilizaremos as MIBs podendo fazer parte da MIB II, da experimental ou da privada.
O gerenciamento da rede através do SNMP permite o acompanhamento simples e fácil
do estado, em tempo real, da rede, podendo ser utilizado para gerenciar diferentes tipos de sistemas.
Este gerenciamento é conhecido como modelo de gerenciamento SNMP, ou
simplesmente, gerenciamento SNMP. Portanto, o SNMP é o nome do protocolo no qual as informações são trocadas entre a MIB e a aplicação de gerência como também é o nome deste
modelo de gerência.
Os comandos são limitados e baseados no mecanismo de busca/alteração. No mecanismo de busca/alteração estão disponíveis as operações de alteração de um valor de um objeto, de obtenção dos valores de um objeto e suas variações.
A utilização de um número limitado de operações, baseadas em um mecanismo de
busca/alteração, torna o protocolo de fácil implementação, simples, estável e flexível. Como
conseqüência reduz o tráfego de mensagens de gerenciamento através da rede e permite a
introdução de novas características.
O funcionamento do SNMP é baseado em dois dispositivos o agente e o gerente. Cada
máquina gerenciada é vista como um conjunto de variáveis que representam informações referentes ao seu estado atual, estas informações ficam disponíveis ao gerente através de consulta e podem ser alteradas por ele. Cada máquina gerenciada pelo SNMP deve possuir um agente e uma base de informações MIB.

O Agente

É um processo executado na máquina gerenciada, responsável pela manutenção das
informações de gerência da máquina. As funções principais de um agente são:
* Atender as requisições enviadas pelo gerente;
*Enviar automaticamente informações de gerenciamento ao gerente, quando previamente
programado.

O agente utiliza as chamadas de sistema para realizar o monitoramento das informações
da máquina e utiliza as RPC (Remote Procedure Call) para o controle das informações da máquina.


O Gerente

É um programa executado em uma estação servidora que permite a obtenção e o envio
de informações de gerenciamento junto aos dispositivos gerenciados mediante a comunicação com um ou mais agentes.


Esta figura mostra como funciona o relacionamento de um gerente com o objeto gerenciado


O gerente fica responsável pelo monitoramento, relatórios e decisões na ocorrência de problemas enquanto que o agente fica responsável pelas funções de envio e alteração das informações e também pela notificação da ocorrência de eventos específicos ao gerente.

Esta figura mostra o relacionamento entre gerente e agente baseado no modelo TCP/IP

Listas de Controle de Acesso – ACL’s

Objetivos

Neste tutorial será apresentado os conceitos de ACL’s para controlar o tráfego de rede não desejado, bem como utilizá-las para implementar um recurso mínimo de segurança no ambiente. Será abordado também como e onde posicionar uma ACL para que a rede se torne eficiente.

Pré-requisitos:

Conhecer os modos de configuração de um roteador, salvar um arquivo de configuração, bem como os conceitos básicos do protocolo TCP/IP, tais como, endereços de rede, máscaras de sub-rede, protocolos TCP/UDP e portas de conexão.

Parte 1 – Conceitos de ACL’s

Atualmente, um dos grandes desafios do administrador de redes de uma empresa é sem dúvida alguma manter seu ambiente seguro e principalmente estabelecer um controle de tráfego de pacotes nesta rede, daí a necessidade de utilizarmos as Listas de Controle de Acesso.

Os roteadores fornecem uma filtragem básica de pacotes, como por exemplo, o bloqueio de acesso a determinados recursos na internet. Uma ACL nada mais é que uma seqüência de instruções que permitem ou negam acesso a determinada rede ou recursos disponíveis noutras redes.

Toda Lista de Controle de Acesso é primeiramente criada e depois aplicada a uma determinada interface do roteador, ao processar o pacote o roteador verifica as instruções definidas numa ACL e com base nessas informações aceita ou recusa o pacote.

Podemos criar listas de acesso para vários protocolos da camada de rede,tais como, IPX e IP. Devemos sempre considerar a ordem de aplicação das ACL’s, o Cisco IOS analisa uma seqüência de cima para baixo, ou seja, assim que haja uma correspondência encontrada na lista, existirá uma permissão ou negação do pacote e as demais instruções na ACL não serão verificadas.

Se não existir correspondência em nenhuma das linhas de verificação da Lista de Acesso, automaticamente existirá no final da ACL uma instrução deny any implícita por padrão. Essa instrução tem por objetivo negar todo o trafego que passa por essa interface do roteador.

Vale a pena então lembrar que a partir do momento que criarmos uma linha de instrução, o equipamento passa a verificar essa ACL e logo após estará implícito um deny any no final, por exemplo, digamos que eu queira liberar o tráfego FTP para uma determinada rede, se apenas definir essa instrução o restante do tráfego será negado justamente por causa da negação implícita no final da regra. Para solucionar este problema devemos ter bem definidas todas as condições de tráfego da rede a ser liberado e especificá-los em cada linha da ACL.

Caso não seja definida nenhuma Lista de acesso ao roteador, todo tráfego que passará nas interfaces será devidamente liberado a todas redes, tanto de entrada quanto de saída.

A recomendação é que no início do aprendizado de ACL’s devemos sempre adicionar no final da lista a instrução deny any, isso reforçará a lembrança de que existe sempre um deny implícito no final. À medida que a prática na criação de ACL’s for aumentando automaticamente lembraremos desta negação.

Vejamos então os objetivos de utilizarmos ACL’S:

» Como mencionamos anteriormente para limitar o acesso de pacotes indesejados que entram ou saem da rede;

» Implementação mínima de segurança;

» Definir qual rede será liberada ou bloqueada;

» Controlar o fluxo de pacotes preservando largura de banda da rede;

Máscara Curinga

Outro conceito importante que devemos entender ao estudarmos Listas de Acesso é o que chamamos de máscara curinga.

Uma máscara curinga é composta de 32 bits também divididos em 4 octetos e estes octetos estão emparelhados com os 32 bits do endereço IP. A diferença da máscara curinga para a máscara de sub-rede é que o numero 0 da máscara curinga representa verificar o octeto correspondente e o 1 representa descartar o octeto.

Um exemplo seria:

No endereço 192.168.10.89 com a máscara curinga 0.0.0.255, significa verificarmos os três primeiros octetos e descartarmos o último,

Parte 2– Tipos de ACL’s

Existem especificamente três tipos de Listas de Acesso que são:

» Listas de Acesso IP Padrão

» Listas de Acesso IP Estendidas

» Listas de Acesso com Nome

Listas de Acesso IP Padrão

Este é um tipo de Lista de Acesso baseado no endereço IP de origem. Esta ACL permite ou nega o tráfego de um conjunto inteiro de protocolos a partir dos endereços da rede, sub-rede ou host.

Toda configuração de uma ACL num roteador é seguida de um número que corresponde a um intervalo. Este número indica o tipo de Lista de Acesso definida. Para Listas do tipo Padrão o intervalo vai de 1 a 99.

Na versão 12.0.1 do IOS foi adicionado mais um intervalo que vai de 1300 a 1999. Com esse adicional podemos ter até 798 Listas de Acesso IP Padrão.

Primeiramente devemos definir as instruções de uma ACL e logo em seguida aplicarmos numa interface definindo o seu destino. Conceitualmente as listas de acesso IP Padrão devem ser aplicadas mais próximo do destino.

Obs. Todo o processo de configuração será visto no tutorial “Criando Listas de Acesso”.

Listas de Acesso IP Estendidas

Este é um tipo de Lista de Acesso bem mais utilizado, ele baseia todo o controle em endereços de rede de origem e destino, sub-rede, host, conjunto de protocolos e portas. Isso torna este tipo de ACL bem mais flexível e completa que uma lista padrão.

É possível configurar várias instruções para uma mesma lista de acesso, basta para isso conservar o mesmo número da lista. A quantidade de instruções definidas numa lista de acesso é limitada pela capacidade de memória do roteador.

O intervalo de uma Lista de Acesso Estendida vai de 100 a 199, também existe um intervalo adicional para versões de IOS mais recentes que vai de 2000 a 2699.

No final da ACL estendida temos a opção de definirmos o tipo de porta a ser utilizada. É possível especificar operações lógicas na configuração destas portas, tais como:

eq – igual

neq – diferente

gt - Maior do que

lt – menor do que

Essas operações lógicas são utilizadas em determinados protocolos.

ACL’s com Nome

Este tipo de Lista de Acesso foi introduzido na versão 11.2 do Cisco IOS. Esta lista permite que sejam atribuídos nomes ao invés de números às listas de acesso. A principal vantagem deste tipo de configuração está na identificação da lista, ou seja, podemos atribuir um nome que seja relacionado diretamente a função desta lista. Mas além desta vantagem posso destacar:

» Quantidade ilimitada de listas de acesso, visto que não fica na dependência da quantidade de números disponíveis nos intervalos;

» Permite a inserção de instruções no final da lista;

Devemos, porém considerar que neste tipo de lista não deve existir nome repetido, nem se o tipo de lista for diferente. Por exemplo:

Não é possível existir uma lista de acesso padrão e uma lista de acesso estendida com o nome VENDAS.

Definimos uma lista de acesso com nome através do comando ip Access list.

Obs. Todo o processo de configuração será visto no tutorial “Criando Listas de Acesso”.

Considerações sobre o posicionamento das Listas de Acesso

Para o bom funcionamento de uma lista de acesso devemos saber exatamente como e onde posicioná-las, isso fará com que a rede seja muito mais eficiente.

No geral a documentação da Cisco diz o seguinte:

Para listas de Acesso IP Padrão posicione o mais próximo do destino, pois estas se baseiam nos endereços de origem. Para as Listas de Acesso IP Estendidas posicione mais próximo da origem, pois como esta lista se baseia em endereços de origem, destino, tipo de protocolo e porta, o tráfego é analisado antes de sair da rede.

Extraído de: http://www.juliobattisti.com.br/tutoriais/luisepedroso/acl001.asp

WireShark

A ferramenta de gerência de rede WireShark não é nada mais que uma ferramenta para o administrador da rede monitorar e controlar os dados transmitidos entre qualquer protocolo de transmissão.

Com está ferramenta é possível que o administrador possa ter o controle geral sobre todo o tráfego da rede. Também comentamos as plataformas que tem o suporte para o bom funcionamento da ferramenta, falamos um pouco do desenvolvedor e suas características e como proceder na instalação desta ferramenta de gerência de rede.

Sua licença está registrada pela GNU - General Public License (GPL), usa-se linhas de comandos apenas para instalar e para abrir a ferramenta, todo o uso é por interface gráfica e utiliza PCAP para capturar pacotes, de forma que ele só pode capturar pacotes em redes apoiadas por PCAP.

O WireShark, conhecido como tubarão dos fios, serve para monitorar os pacotes de informações que trafegam através de sua rede, um analisador de protocolos para redes de computadores e, no momento, é considerado um dos mais utilizados para Linux no momento, desenvolvido pela Ethereal.

Está é uma ferramenta totalmente livre (Free), ou seja, você pode baixá-la e não precisa se preocupar com limitações ou prazo de validade, apenas instalar e sair usando.

Software registrado pela GNU General Public License (GPL), o Wireshark, antigo Ethereal, as funcionalidades desta ferramenta são parecidas com o TCPDUMP, mas com uma interface GUI, possui mais informações e com possibilidade de aplicar filtros.

O administrador da rede, ou o responsável pela rede pode ter o controle de tudo o que entra e sai da rede, em diferentes protocolos.

Uma boa opção para quem tem uma grande rede para administrar, porque cuidar de uma rede pequena não é tão complicado, mas quando falamos sobre uma grande empresa, a visão já é diferente.

WireShark utiliza PCAP para capturar pacotes, de forma que ele só pode capturar pacotes em redes apoiadas por PCAP.

As plataformas que o WireShark suporta são:
*UNIX;
*Linux;
*Solaris;
*FreeBSD;
*NetBSD;
*OpenBSD;
*MAC OS X;
*Windows.

Extraído de http://www.vivaolinux.com.br/artigo/Wireshark-Artigo/

Tutorial: Utilização do WireShark.