segunda-feira, 26 de fevereiro de 2007

Simulando roteadores Cisco com Dynagen

Apesar de ser somente uma pequena nota sobre um um software de simulação, o post sobre Dynamips é o mais visitado deste blog. Por isso, achei interessante explicar com maiores detalhes o funcionamento do Dynamips e do Dynagen. Para tornar tudo ainda mais fácil, os exemplos que mostrarei abaixo serão todos baseados no dynamips/dynagen para Windows, mas os mesmos funcionam igualmente no Linux (ou até melhor... quem sabe? Mais adiante discutiremos sobre isso também).

Dynamips é um software de código-aberto escrito por Christophe Fillot para simular um roteador 7200 em um PC comum utilizando um processador MIPS. Com este software é possível simular um IOS diretamente no PC - por este motivo o Dynamips necessita de uma imagem do Cisco IOS para funcionar. Atualmente o Dynamips suporta as plataformas 2600, 3600 e 7200 de roteadores Cisco e ainda vários tipos de módulos para estas plataformas.

Para utilizar o Dynamips, por exemplo, para simular uma rede de 4 roteadores interconectados entre si, era necessário mapear em cada instância do Dynamips as interfaces de interconexão utilizando portas UDP. Para facilitar este trabalho de mapeamento Greg Anuzelli desenvolveu um front-end para o Dynamips chamado Dynagen. Com o Dynagen o mapeamento das interconexões é automático: basta definir em um arquivo de configuração qual interface de um roteador conecta-se a outro roteador. Para saber mais detalhes sobre o Dynagen, consulte este tutorial escrito pelo próprio Greg Anuzelli.

Alguns centros especializados em treinamento para as certificações Cisco já disponibilizam laboratórios pré-configurados - ou seja, um arquivo de configuração do Dynagen - para treinamentos e exercícios em um laboratório virtual. Por exemplo, o arquivo do laboratório virtual do Internetwork Expert pode ser pego aqui e do IE Mentor aqui. Estes dois exemplos anteriores foram especialmente desenvolvidos para provas do CCIE.

Desta vez iremos instalar o laboratório do Internetwork Expert. A primeira medida é ter o Dynagen instalado na máquina. Para isso, você deve fazer o download e instalar o Dynagen e a biblioteca libpcap - como estamos no Windows, iremos baixá-la com o nome de Winpcap. Em seguida será necessário pegar a imagem do IOS e descompactá-la com o PKUNZIP ou Winrar (no windows) ou o unzip do Linux. Neste exemplo, iremos utilizar a imagem c3640-is-mz.123-14.T7.bin e descompactá-la no Linux.

$ unzip c3640-is-mz.123-14.T7.bin && mv image.bin c3640-is-mz.123-14.T7.extracted.bin
Coloque a imagem no diretório C:\Program Files\Dynamips\images. Em seguida, você deve rodar o Dynamips com esta imagem (com qualquer configuração de módulos) para descobrir qual é o valor do idle-pc para esta imagem. Para isso, utilizei o comando "C:\Program Files\Dynamips>dynamips.exe -P 3600 images\c3640-is-mz.123-14.T7.extracted.bin" e aguardei o término do processo de boot da imagem. Note que a CPU do seu PC estará constantemente em 100% pois não carregamos o valor do idle-pc no boot da imagem. Para descobrirmos este valor é necessário entrar com a seqüência de break e em seguida pressionar a tecla "i" durante a execução do simulador. No windows a seqüência de break é "Ctrl+ç"e em seguida "i". Pode ser também a combinação "Ctrl+]" e depois "i".
Router>
Please wait while gathering statistics...
Done. Suggested idling PC:
0x605c057c (count=54)
0x605f1cf0 (count=22)
0x605f1d10 (count=46)
0x605f1ed8 (count=32)
0x605f1f3c (count=27)
0x605f2010 (count=69)
0x606a23fc (count=42)
0x606a2478 (count=21)
0x605f2814 (count=23)
0x605f2850 (count=27)
Restart the emulator with "--idle-pc=0x605c057c" (for example)
Agora podemos testar a imagem com algum dos valores que foram descobertos e verificar que a CPU não está mais constantemente em 100%. Esse procedimento é necessário quando precisamos rodar vários roteadores em um mesmo PC e não queremos esperar vários dias para sair do modo exec e entrar no modo de configuração de um dos roteadores...

Agora ajustamos o arquivo com as configurações do laboratório para refletir o nome da imagem e o valor do idle-pc da imagem que acabamos de testar. Temos que editar o arquivo ie.routing.and.switching.topology.4.00.net e atualizar todas as entradas do nome da imagem e idle-pc.

image = C:\Program Files\Dynamips\images\c3640-is-mz.123-14.T7.extracted.bin
idlepc = 0x605c057c

É importante também ter uma forma de conectar na console de cada um dos equipamentos que serão simulados. Para isso a sugestão para este laboratório é criar uma interface de loopback (para saber como fazer no Windows clique aqui) e atribuir o IP 169.254.0.1/16. Temos que descobrir o endereço de hardware desta interface de loopback com o comando "dynamips -e" - algo como {4065B11C-2A6C-4FD2-8204-A12A9A8328A4} - e atualizar este endereço no arquivo de configuração do laboratório para o último roteador - TermServ - que será nosso servidor de console para todos os outros equipamentos.

Para finalizar, iniciamos duas instâncias do dynamips para suportar todo o laboratório:

C:\Program Files\Dynamips>dynamips.exe -H 7200
C:\Program Files\Dynamips>dynamips.exe -H 7201
E depois iniciamos o Dynagen carregando o arquivo de configuração do latoratório.

C:\Program Files\Dynamips>dynagen.exe sample_labs\internetworkexpert\ie.routing.
and.switching.topology.4.00.net

Reading configuration file...


Network successfully started

Dynagen management console for Dynamips

=> list
Name Type State Server Console
TermServ 3640 stopped localhost:7201 2000
R1 3640 stopped localhost:7200 2001
R2 3640 stopped localhost:7200 2002
R3 3640 stopped localhost:7200 2003
R4 3640 stopped localhost:7200 2004
R5 3640 stopped localhost:7200 2005
R6 3640 stopped localhost:7200 2006
SW1 3640 stopped localhost:7200 2007
SW2 3640 stopped localhost:7201 2008
SW3 3640 stopped localhost:7201 2009
SW4 3640 stopped localhost:7201 2010
BB1 3640 stopped localhost:7201 2011
BB2 3640 stopped localhost:7201 2012
BB3 3640 stopped localhost:7201 2013
FRSW FRSW n/a localhost:7201 n/a
=> start TermServ
100-C3600 'TermServ' started
=>

Agora você poderá iniciar cada um dos equipamentos e conectar nos mesmos para testar as mais diferentes configurações. Depois de iniciar o roteador TermServ, pode-se utilizar o telnet para conectar no TermServ e depois na console de cada um dos equipamentos do laboratório.

C:\telnet 169.254.0.2

TermServ>
Agora temos um laboratório virtual de roteadores para testar e simular os mais diferentes ambientes.

O Dynagen pode trabalhar com instâncias do Dynamips rodando em máquinas diferentes, permitindo simular redes de roteadores ainda maiores distribuindo a carga entre máquinas distintas. Se esta for a sua idéia, então é aconselhável a utilização do Linux, já que o Windows não trabalha muito bem com processos que ocupam mais de 2 GB de memória RAM e sabe-se que tem problemas de desempenho depois de uma certa quantidade de roteadores. Mais informações sobre o Dynamips podem ser encontradas no Forum 7200emu.hacki.at ou ainda no blog do Christophe Fillot, autor do Dynamips.

UPDATE (16-fev-2008): Veja também o post sobre o GNS3.

sexta-feira, 23 de fevereiro de 2007

Configurando Interfaces VLAN no FreeBSD

Quando trabalhamos com vlans, podemos segmentar a rede para diminuir o tráfego broadcast compartilhado e segmentar de forma que por exemplo tenhamos uma vlan por serviço/aplicação. A vantagem de ter um Freebsd com interfaces vlans seria, utilizar a mesma interface física para transportar varios tags (vlan id), excluindo a necessidade de uma placa de rede para cada segmento.

Configurando FreeBSD

Primeiramente necessitamos levantar o módulo if_vlan ou para quem queira deixar este suporte nativamente no kernel.

Para habilitar o suporte a vlans sem ter q recompilar o kernel utilizaremos o comando abaixo:

# kldload if_vlan

Não podemos esquecer de adicionar a entrada if_vlan_load=”YES” no arquivo /boot/loader.conf

Caso você queira compilar o suporte nativamente, adicione a entrada abaixo no seu arquivo de configuração e recompile o seu kernel:

device vlan


Depois do suporte a int vlans estar habilitado, vamos começar a configuração no Freebsd.

Vamos utilizar 4 tags para a nossa configuração, 5, 10, 15 e 20, para facilitar vamos associar o tag ao nome da interface vlan, tag 5 (vlan5), tag 10 (vlan10), tag 15 (vlan15), tag 20 (vlan20).

Criando as interfaces:

# ifconfig vlan5 create
# ifconfig vlan10 create
# ifconfig vlan15 create
# ifconfig vlan20 create


Apenas para conferir se as interfaces foram criadas

# ifconfig

A saída deverá ser algo como mostrado abaixo:

vlan5: flags=8002 mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:

vlan10: flags=8002 mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:

vlan15: flags=8002 mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:

vlan20: flags=8002 mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:


Nossas interfaces ja estão criadas, agora vamos associa-las ao devido tag e a interface física.

OBS: não é necessario a nome da int vlan ter o mesmo tag, por exemplo, pode ser criado a interface vlan0 e associado qualquer tag, criamos a vlan5 associada ao tag 5 para ficar mais fácil de coomprender.

Associando os tags:

# ifconfig vlan5 vlan 5 vlandev em0
# ifconfig vlan10 vlan 10 vlandev em0
# ifconfig vlan15 vlan 15 vlandev em0
# ifconfig vlan20 vlan 20 vlandev em0


Pronto, os tags ja estao devidamente configurados e associados a interface física em0.

Agora, atribua os endereços ips nas interfaces vlans.

# ifconfig vlan5 192.168.5.1 netmask 255.255.255.0 up
# ifconfig vlan10 192.168.10.1 netmask 255.255.255.0 up
# ifconfig vlan15 192.168.15.1 netmask 255.255.255.0 up
# ifconfig vlan20 192.168.20.1 netmask 255.255.255.0 up


A saída do ifconfig ficará como mostrado abaixo:

vlan5: flags=8843 mtu 1500
inet 192.168.5.1 netmask 0xffffff00 broadcast 192.168.5.255
inet6 fe80::203:47ff:fe07:63ff%vlan20 prefixlen 64 scopeid 0xb
ether 00:0a:5e:53:f8:ec
media: Ethernet autoselect (100baseTX )
status: active
vlan: 5 parent interface: em0

vlan10: flags=8843 mtu 1500
inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255
inet6 fe80::203:47ff:fe07:63ff%vlan20 prefixlen 64 scopeid 0xb
ether 00:0a:5e:53:f8:ec
media: Ethernet autoselect (100baseTX )
status: active
vlan: 10 parent interface: em0

vlan15: flags=8843 mtu 1500
inet 192.168.15.1 netmask 0xffffff00 broadcast 192.168.15.255
inet6 fe80::203:47ff:fe07:63ff%vlan20 prefixlen 64 scopeid 0xb
ether 00:0a:5e:53:f8:ec
media: Ethernet autoselect (100baseTX )
status: active
vlan: 15 parent interface: em0

vlan20: flags=8843 mtu 1500
inet 192.168.20.1 netmask 0xffffff00 broadcast 192.168.20.255
inet6 fe80::203:47ff:fe07:63ff%vlan20 prefixlen 64 scopeid 0xb
ether 00:0a:5e:53:f8:ec
media: Ethernet autoselect (100baseTX )
status: active
vlan: 20 parent interface: em0


Nossas configurações já estão prontas, todas as int vlans configuradas com as tags associadas e com a interface física fxp0 devinida.

Agora vamos colocar nossas configurações no rc.conf para nao perde-las quando o FreeBSD for rebootado.

Adicionar no arquivo /etc/rc.conf as entradas abaixo:

cloned_interfaces="vlan5 vlan10 vlan15 vlan20"
ifconfig_vlan5="inet 192.168.5.1 netmask 255.255.255.0 vlan 5 vlandev em0"
ifconfig_vlan10="inet 192.168.10.1 netmask 255.255.255.0 vlan 10 vlandev em0"
ifconfig_vlan15="inet 192.168.15.1 netmask 255.255.255.0 vlan 15 vlandev em0"
ifconfig_vlan20="inet 192.168.20.1 netmask 255.255.255.0 vlan 20 vlandev em0"


Nossa configuração está concluída no lado do FreeBSD, vou colocar a configuração que deve ser realizada switchs Cisco Catalyst 3750.

Logue no switch com seu usuário e senha, entre em modo enable:

Switch# enable


Defina uma porta onde será conectado o FreeBSD com as interfaces vlans, no nosso exemplo vamos escolher a porta Gi1/0/1.

Entre em como de configuração

Switch# configure terminal
Switch (config)# interface Gi1/0/1


Lembrando que a interface pode variar conforme o modelo do switch.

Switch (config-if)# switchport trunk encapsulation dot1q
Switch (config-if)# switchport mode trunk
Switch (config-if)# switchport trunk allowed vlan 5,10,15,20
Switch (config-if)# description “DESCRIÇÃO DA PORTA”


Com estas configurações na porta estamos deixando trafegar apenas as vlans 5, 10, 15 e 20, caso queira adicionar mais uma vlan no trunk do switch, utilize o comando abaixo:

Switch (config-if)# switchport trunk allowed vlan add 25


Adicionamos a vlan 25 na porta Gi1/0/1 do switch.

Configure o restante das portas do switch em mode access conforme mensionado abaixo:

Switch (config-if)# interface Gi1/0/2
Switch (config-if)# switchport mode access
Switch (config-if)# switchport access vlan 5


Com isso a porta dois consequirá conversar com a interface vlan 5 do FreeBSD através da porta 1 do switch que esta configurada em mode trunk. Faça o mesmo com as outras portas definindo a vlan que deve ser acessada pela porta.

Com isto finalizamos nosso how-to, este tipo de configuração normalmente é utilizado em firewalls, faça um cálculo de tráfego para não ter gargalo físico na placa de rede, se o tráfego for grande em cada vlan utilize uma placa Gigabit de boa qualidade.

Performance em conexões tcp

Um problema que muitos administradores de rede encontram é quando há reclamações de performance em conectividade. Escrevi um programinha para realizar testes de conexões em modo paralelo e sequencial, um programa em C muito simples, pode ser baixado neste link
Basta compilar com suporte a pthread com o comando abaixo:

gcc multiconnect.c -o multiconnect -lpthread


Syntax: ./multiconnect hostname port [connections]
Se não for passado o número de conexões, o default é 100.

Ele mede a performance em microsegundos já converte para segundos.

quarta-feira, 14 de fevereiro de 2007

Simulando um roteador com JunOS

Não é de hoje que sabemos que grande parte da arquitetura dos roteadores da Juniper é totalmente baseada no PC: memória RAM, ROM, CPU, placa-mãe, etc. Também sabe-se que o JunOS - sistema operacional que controla uma parte específica destes roteadores: a routing engine ou RE - é também baseado no sistema operacional FreeBSD. Por isso, sempre houve um certo mito sobre a possibilidade de rodar o JunOS em um PC "caseiro". Esta combinação - PC mais o JunOS - foi gentilmente apelidada de Olive. A principal motivação para instalarmos o Olive - além da natural curiosidade - é o aprendizado e a familiarização com o sistema operacional JunOS.

Em linhas gerais, os passos para instalar o Olive são:

- Instalar o FreeBSD
- Instalar o pacote do JunOS (jinstall)
- Reboot

Existem também algumas dicas e observação importantes que podem ajudar neste teste. Para começar é recomendável instalar o FreeBSD 4.x-mini (testado com a versão 4.4-mini) com a seguinte estrutura de diretórios:

ad0s1a     /       100M
ad0s1b swap 1G
ad0s1e /config 12M
ad0s1f /var (maior slice, o resto do disco)

Apesar de ser aconselhável utilizar o modelo de particionamento acima, a instalação do pacote jinstall (JunOS) poderá alterar a estrutura de diretórios caso seja necessário. O próximo passo é copiar o pacote do JunOS - que deve ser um arquivo do tipo jinstall-xxx.tgz - para o diretório /var/tmp e iniciar a instalação. Os passos são:
rm /dev/wd0c
ln -s /dev/ad0c /dev/wd0c
mkdir /var/etc
cd /var/etc
touch master.passwd; touch inetd.conf; touch group
cd /var/tmp; pkg_add jinstall-7.0R1.5-domestic-signed.tgz
reboot
Neste momento você poderá ver o Olive rodando em um PC comum. Para conectar-se e iniciar alguma configuração é necessário possuir um cabo de console e utilizar um programa como o Hyper Terminal ou similar. Se você instalou o Olive em uma máquina virtual VMware (FreeBSD), então você pode utilizar o programa VMware Serial Line Gateway para conectar na porta serial sem a necessidade de um cabo serial - a idéia deste programa é criar um gateway para conexão via telnet e traduzir essa conexão para a porta serial do VMware. No caso do VMware, ainda existe uma dica importante: edite o arquivo *.vmx e adicione a linha descrita abaixo, dessa forma o VMware irá simular uma interface de rede Intel que o JunOS/FreeBSD poderá reconhecer.
ethernet0.virtualDev = "e1000"
É importante saber também que o JunOS/Olive é incompatível com a maioria das placas de rede mais comuns. Para saber mais sobre o Olive, versões testadas de JunOS e placas de rede compatíveis basta acessar a página wiki do Olive ou ainda a página de outras pessoas que também já testaram o Olive como o "Sid Smokes" e o Joel Knight.

segunda-feira, 12 de fevereiro de 2007

DNS e os Ataques de Negação de Serviço

Desde a última semana nós temos ouvido falar de ataques de DoS (ou negação de serviço) e de servidores DNS e, por isso, acho interessante observar o que está acontecendo na rede mundial.

Não é de hoje que sabemos da existência de algumas falhas no protocolo de resolução de nomes na Internet (DNS) que permitem a exploração e a amplificação dos ataques de negação de serviço. Por exemplo, a própria escolha de rodar o DNS sobre o UDP (protocolo não orientado a conexão e que pode ser facilmente forjado para enviar falsas requisições) é uma falha que é muito discutida - veja o draft do Frederico Neves (Registro.br) e do João Damas (ISC) no Working Group dnsop do IETF: "Preventing Use of Recursive Nameservers in Reflector Attacks" e o white paper da Verisign intitulado "Anatomy of Recent DNS Reflector Attacks from the Victim and Reflector Point of View".

A principal questão é: o que eu estou fazendo para me proteger? A resposta desta pergunta pode parecer simples, mas não é. Eu comecei a perceber isso quando me deparei com administradores de DNS que nem ao menos sabiam dizer o que é uma "DNS recursivo". Então, vamos lá:

Um servidor de DNS recursivo está configurado para responder a qualquer requisição de DNS independentemente do IP de origem da requisição ou do tipo da requisição. Esta é uma configuração que permite fazer funcionar qualquer servidor DNS em qualquer rede conectada à Internet - e acredito que muitos servidores estejam configurados desta forma.

O problema começa a ocorrer quando alguém resolve atacar o IP 10.10.10.1 (note: somente como exemplo estamos utilizando endereços inválidos). Este atacante envia uma requisição de DNS com IP de origem 10.10.10.1 para um servidor DNS recursivo qualquer e este servidor responde para o IP 10.10.10.1. Multiplique esta resposta pelo número de servidores que respondem requisições recursivas na Internet e você poderá estimar a quantidade de pacotes (teórica) que pode ser gerada para a vítima do ataque. Mais informações técnicas estão disponíveis no site o CERT.br.

No entanto, adotar políticas de segurança pontuais quando o "burburinho" está acontecendo não é a solução de todos os problemas. Por exemplo, como o endereço IP de requisições de DNS pode ser facilmente falsificado é relativamente fácil fazer um ataque utilizando servidores de DNS recursivos configurados para responder consultas recursivas para um grupo restrito de hosts e atacar um host desse grupo restrito, principalmente se existe um grupo grande de servidores DNS recursivos para este grupo de hosts. Por isso é importante implementar políticas de anti-spoofing no perímetro da rede - ou seja, não é permitido tráfego da parte externa para a parte interna da minha rede com endereço de origem de um host interno.

Apesar da possibilidade remota de fazer um ataque que seja suficientemente grande para prejudicar o funcionamente normal de um servidor vítima, o exemplo acima ilustra perfeitamente como a segurança deve ser implementada em diversas camadas quanto possível e que é absolutamente necessário conhecer todos os aspectos do ambiente que queremos proteger.

Para verificar se o servidor de DNS do seu domínio responde consultas recursivas, basta utilizar um das ferramentas publicamente disponíveis neste site. Destaque para o site DNSreport (ou DNSstuff).

Rancid: Ferramenta para Controle de Configuração de Equipamentos de Redes

Disclaimer: É claro que todos nós fazemos backups regulares dos equipamentos que administramos. Também temos uma ferramenta prática e amigável para controlar as alterações de configuração e, até por isso, eu acho que este post não será tão útil...

Rancid - Really Awesome New Cisco confIg Differ - é um programa que pode ser utilizado para realizar backups e controle de versões de configuração de forma simples e rápida e não somente de equipamentos Cisco (como pode parecer pelo nome). Atualmente o Rancid faz backups de equipamentos Cisco, Extreme, Juniper, Nortel Alteon, etc. e pode rodar em FreeBSD, Linux ou MacOS X.

Esta ferramenta é muito utilizada e já foi comentada em pelo menos duas reuniões da NANOG - uma apresentação e um tutorial. Sabe-se que o Rancid é utilizado como ferramente de backup nas empresas: AOL, Global Crossing, MFN, NTT America, Certainty Solutions Inc.

Em linhas gerais o Rancid realiza os seguintes procedimentos:
- Efetua login nos equipamentos listados no arquivo router.db;
- Roda alguns comandos em busca de informações específicas por tipo de equipamento;
- Formata as saídas dos comandos;
- Envia as diferenças para um e-mail;
- Salva as diferenças em uma base para controle de versões (CVS).

O primeiro passo para ter funcionando o Rancid é fazer um instalação: 1) através do código-fonte ou 2) através do ports do FreeBSD. No caso deste exemplo, estamos utilizando a opção 2 (ports do FreeBSD). Existem também algumas depedências que devem ser instaladas para o correto funcionamento, tais como: gcc, make ;-), cvs, perl, expect e diffutils. Eu ainda precisei instalar para este exemplo o cvsweb e viewcvs (todos disponíveis no ports):

cd /usr/ports/net-mgmt/rancid && make install clean
cd /usr/ports/devel/cvsweb && make install clean
cd /usr/ports/devel/viewcvs && make install clean

O primeiro arquivo que deve ser configurado é o rancid.conf - no exemplo, este arquivo está no diretório /usr/local/etc/rancid. Neste arquivo iremos incluir um grupo de equipamentos, configurar o diretório de trabalho do Rancid (onde armazenaremos as informações de backup) e o diretório raíz do CVS e opcionalmente um e-mail para enviar as diferenças de configuração. As opções que utilizaremos são:

BASEDIR=/usr/local/var/rancid; export BASEDIR
CVSROOT=$BASEDIR/CVS; export CVSROOT
LIST_OF_GROUPS="backbone"

Podemos utilizar diversos grupos e, para isso, basta copiar a mesma configuração que iremos fazer para o grupo backbone para os demais.

É extremamente aconselhável que o Rancid rode a partir de um usuário sem privilégios e dedicado para o rancid. Neste exemplo criamos um usuário rancid que será responsável por rodar o Rancid e armazenar as informações de login no arquivo $HOME/.cloginrc.

O arquivo .cloginrc é o arquivo que armazena as informações de controle de acesso para os equipamentos. Este arquivo deve ser criado no diretório home do usuário que irá rodar o Rancid, sempre lembrando que somente o usuário rancid terá permissão para ler e escrever neste arquivo. A sintaxe do arquivo é a seguinte:

$ more /home/rancid/.cloginrc
add password cisco_router
add password cisco_switch

add password extreme_switch
add autoenable extreme_switch 1
add user extreme_switch

Para mais informações sobre a sintaxe deste arquivo, consulte a documentação oficial do cloginrc.

É importante criar a árvore de diretórios para os backups e para o CVS. Para isso devemos executar o script rancid-cvs que está no diretório /usr/local/bin/rancid-cvs. Em nosso exemplo, este script irá criar uma árvore de diretórios para o grupo backbone dentro do diretório $BASEDIR e $CVSROOT (definido no arquivo rancid.conf).

$ cd /usr/local/var/rancid
$ /usr/local/bin/rancid-cvs

Em seguida, é necessário fornecer informações para que o Rancid inicie o backup dos equipamentos e é importante informar quais equipamentos e de que fabricante estes equipamentos são no arquivo router.db. A sintaxe deste arquivo é muito simples e pode ser consultada aqui. O modelo que iremos utilizar é:

$ cd /usr/local/var/rancid/backbone/
$ more router.db
cisco_router:cisco:up
cisco_switch:cat5:up
extreme_switch:extreme:up

É importante notar que os switches Cisco que roda IOS devem ser cadastrados como tipo "cisco". Para que o Rancid conecte corretamente nos equipamentos é necessário que o nome cisco_switch, extreme_switch, etc resolva para um endereço IP; que pode ser por DNS ou através do arquivo /etc/hosts.

Para testar as configurações basta rodar o script rancid-run. Se os arquivos de log (em /usr/local/var/backbone/log) e os arquivos de configuração (em /usr/local/var/backbone/configs) estiverem OK, então basta incluir uma entrada na crontab do usuário rancid para rodar o script periodicamente. Como exemplo, estamos rodando todos os dias às 3:00 horas da manhã:

$ crontab -l
0 3 * * * /usr/local/bin/rancid-run

Se o apache estiver funcionando corretamente, então será possível acessar as configurações através de um página web (utilizando o cvsweb). Basta incluir o caminho para o diretório $CVSROOT (definido no rancid.conf) no arquivo de configuração do cvsweb (/usr/local/etc/cvsweb/cvsweb.conf) conforme o exemplo abaixo e acessar a URL: http://servidorancid/cgi-bin/cvsweb.cgi.

[ snip! ]
@CVSrepositories = (
'local' => ['My CVS Repository', '/usr/local/var/rancid/CVS'],
[ snip!]

Pode-se obter mais informações sobre o Rancid na página oficial dos desenvolvedores.

Solaris Telnet Exploit

Ontem o diário da ISC/SANS apontou uma nova vulnerabilidade no daemon de telnet (in.telnetd) no Solaris 2.10 e 2.11. Aparentemente esta vulnerabilidade não afeta as versões anteriores do Solaris.

Até aí parece-nos uma notícia "normal" em que é encontrada alguma vulnerabilidade supostamente desconhecida e que foi divulgada através da list Full-Disclosure ou Exploits... No entanto, observamos que existe algo diferente com relação a este exploit, ou melhor, não existe exploit, é simples, fácil, e - se é que podemos dizer isso - trivial.

mycomputer$ telnet -l "-fbin" 10.10.10.1
Trying 10.10.10.1...
Connected to 10.10.10.1
Escape character is '^]'.
Last login: Mon Feb 12 11:47:28 from anothercomputer
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
$

Gadi Evrom, na lista Full-Disclosure, aconselhou a Sun Microsystems a fechar no perímetro da rede todo e qualquer tipo de acesso à porta 23 destinado ao /8 alocado para a Sun. Eu acho que este conselho vale para todos. Outra forma de se proteger deste ataque é desabilitar o serviço de telnet no Solaris (cortesia do CAIS-RNP). Mais informações podem ser encontradas no paper 0day was the case that they gave me ou diretamente na página do diário ISC/SANS sobre a vulnerabilidade.

quinta-feira, 8 de fevereiro de 2007

SFP (Gbic)

Abaixo segue uma tabela que referencia os tipos de SFP (Small Form-factor Pluggable) padrão Cisco e suas capacidades de transmissão.


Click na imagem para ampliar

Abaixo, seguem outras refências sobre GBICs (inclusive outros fabricantes):

Juniper

Extreme

Cisco

Testando o tempo de resposta de páginas web

Frequentemente nos deparamos com um problema de lentidão onde é preciso saber onde esta o problema. Resolução de DNS? Tempo de resposta da rede? Tempo de resposta da aplicação?

Uma excelente ferramenta para realizar testes e descobrir onde está o problema é o curl. Ele consegue nos retornar o tempo gasto em cada uma dos seguintes processos: Tempo de resolução de nomes; tempo de conexão tcp (handshake); tempo total de resposta da página (soma dos demais tempo e aplicação).

Abaixo segue um exemplo de utilização do mesmo:

curl -w "NameLookup: %{time_namelookup}\\nTimeConnect: %{time_connect}\\nTimeTotal %{time_total}\\n" -s http://www.google.com.br -o /dev/null


Este comando deve retornar essa resposta:

NameLookup: 0.002
TimeConnect: 0.152
TimeTotal 0.309

Se preciso, pode-se gerar uma lista com os tempos de resposta para ser colocado em uma planilha ou gráfico:
while true;
do
curl -w %{time_namelookup}-%{time_connect}-%{time_total}\\n -s http://www.teste-site.com.br -o /dev/null >> teste_site.txt;
sleep 1;
done

terça-feira, 6 de fevereiro de 2007

Kernel enxuto no OpenBSD

Uma ferramenta interessante para "enxugar" o seu kernel no OpenBSD é o dmassage, que pode ser baixado em http://www.sentia.org/downloads/dmassage-0.6.tar.gz.

Descompacte o programa:
#cd /root (baixei no diretório do root)
#tar -zxvf dmassage-0.6.tar.gz

Para utilizá-lo, vá para o diretório onde ficam os arquivos do kernel em sua plataforma. Por exemplo:

# cd /usr/src/sys/arch/i386/conf/
# /root/dmassage-0.6/dmassage -s GENERIC > KERNEL


A ferramenta irá analisar os devices carregados através da saída do dmesg e irá comentar no arquivo GENERIC os devices não utilizados. O novo arquivo de kernel estará no arquivo KERNEL, somente com o estritamente necessário.

Após isso, pode continuar o procedimento normal de compilacão e instalacão do seu kernel.