terça-feira, 23 de janeiro de 2007

Looking Glass

Looking glass é uma ferramenta que permite efetuar consultas sobre tabelas de roteamento (protocolo BGP) e testes de ping e traceroute. Ela é muito útil para que os administradores de rede possam obter uma visão externa de como estão sendo propagados os anúncios dos seus blocos CIDR na Internet.

A grande maioria dos looking glasses são de acesso gratuito e são implementados através de uma interface web, mas também é possível encontrar quem disponibilize o acesso direto a um roteador (real ou virtual) em que se pode conectar através de telnet. Em ambos os casos os comandos que podem ser efetuados são limitados para evitar problemas de segurança.

Segue a lista de looking glasses que costumo consultar:


GlobalCrossing - telnet://route-server.gblx.net
GlobalCrossing - http://www.globalcrossing.com/network/network_looking_glass.aspx

Host.net - telnet://route-server.host.net
Hurricane Electric - http://lg.he.net/
iPivot - http://lg.ipivot.net.br/
iVeloz - http://lg.iveloz.net.br/
Maxiweb - http://lg.maxiweb.com.br/cgi-local/lg.cgi
NetBotanic - http://lg.netbotanic.com.br/lg.php
NTT - http://www.us.ntt.net/support/looking-glass/
PCH - https://prefix.pch.net/applications/lg/

PTTMetro-RJ - telnet://lg.rj.ptt.br
PTTMetro-SP - telnet://lg.sp.ptt.br
RedIRIS - http://www.rediris.es/red/lg/
RNP - https://memoria.rnp.br/ip/lg.php
Savvis - http://as3561lg.savvis.net/lg.html
Seabone - https://gambadilegno.noc.seabone.net/lg/
SUNET - http://stats.sunet.se/looking-glass/lg.cgi
SouthTech Telecom - http://bgp.stech.net.br/lg
Sprint - https://www.sprint.net/lg/lg_start.php
Telefônica TIWS https://www.globalsolutions.telefonica.com/en/wholesale/looking-glass/
Unifique - http://asn28343.net.br/
Zayo - http://lg.zayo.com/lg.cgi

sábado, 20 de janeiro de 2007

Whois centralizado

O time da Cymru (http://www.cymru.com/) está disponibilizando gratuitamente no link abaixo uma ferramenta de whois centralizado que vai facilitar em muito as identificações de AS numbers de origem. As informações são atualizadas de 4 em 4 horas o que confere grande credibilidade as informações divulgadas e o mais interessante é que ele permite mostrar também as informações das entidades que um determinado AS faz peering.

https://asn.cymru.com/cgi-bin/whois.cgi

Maiores informações de como utilizar as ferramentas podem ser encontradas em:

http://www.cymru.com/BGP/asnlookup.html

Gerenciando a alocação de endereços IP

Para quem procura uma ferramenta free para o gerenciamento e alocação de blocos IP, recomendo o NorthStar. Ele é bem simples de utilizar e é escrito em PERL, o que indica que pode ser portado sem maiores problemas para a grande maioria das plataformas.

Para quem se interessar existe um demo online para avaliação da ferramenta (mas infelizmente nem sempre está no ar :P ). Por isso, instalem!

quarta-feira, 17 de janeiro de 2007

Does my FreeBSD speak brazilian portuguese?

Com o título descaradamente larapiado de um post de um interessante blog de um Mac/Applemaníaco (http://macbucks.blogspot.com/), compartilho como ensinei meu Gnome que estou utilizando um teclado americano e que no Brasil existe acentuação, utilizando o sistema operacional FreeBSD.

Advertisement: Isto foi feito em um PC arquitetura i386. Apenas o título tem a ver com um blog de um Mac/Applemaníaco. Apesar de existir Mac com processador Intel e ser possível instalar o FreeBSD, isso foi feito no ambiente supracitado. Não confunda as coisas! Preste atenção, ou então vá ler o Pato Donald! :P

No /etc/X11/xorg.conf , adicionei/configurei o seguinte:

Option "XkbRules" "xorg"
Option "XkbModel" "pc101"
Option "XkbLayout" "us"
Option "XkbVariant" "intl"


Depois, foi necessário carregar algumas variáveis de ambiente. Caso use sh ou bash, no /etc/profile adicione o seguinte:

export LC_ALL=pt_BR.ISO8859-1
export LANG=pt_BR.ISO8859-1
export LC_CTYPE=ISO-8859-1
export LESSCHARSET=latin1
export GTK_IM_MODULE=xim
export GDK_USE_XFT=1
export GDM_LANG=pt_BR.ISO8859-1


Caso use o shell padrão do FreeBSD csh, adicione no /etc/csh.cshrc :
setenv LC_ALL pt_BR.ISO8859-1
setenv LANG pt_BR.ISO8859-1
setenv LC_CTYPE ISO-8859-1
setenv LESSCHARSET latin1
setenv GTK_IM_MODULE xim
setenv GDK_USE_XFT 1
setenv GDM_LANG pt_BR.ISO8859-1


Agora, é necessário configurar algumas fontes e teclado no /etc/rc.conf . Adicione no arquivo:

font8x14="iso-8x14"
font8x16="iso-8x16"
font8x8="iso-8x8"
keymap="us.iso.acc"


Alguns lembretes:
- no console (fora do modo gráfico) a acentuação não funciona.
- testei essa configuração apenas no meu computador e funcionou corretamente, portanto, novos relatos sobre o funcionamento dessas configurações são bem vindos.

HyperTerminal para Linux

O HyperTerminal é um programa que você pode utilizar para conectar-se a computadores e/ou dispositivos de rede usando um modem, um cabo null modem ou uma conexão TCP/IP. Este aplicativo é geralmente utilizado por administradores de rede para fazer a configuração de roteadores e/ou switches através da interface de console.

Apesar do HyperTerminal ser uma excelente ferramenta ele só existe para ambiente Windows, ou seja, o HyperTerminal acaba por amarrar o usuário ao sistema operacional (o que nem sempre é produtivo). Uma alternativa ao HyperTerminal é utilizar o C-Kermit.

C-Kermit é um programa que combina softwares para comunicação serial e de rede. Ele já é instalado por default na grande maioria das distribuições Linux, mas pode ser instalado e portado para outros ambientes (FreeBSD, NetBSD, OpenBSD, Solaris, etc) sem maiores problemas.

Ao contrário do HyperTerminal, o C-Kermit (ou somente Kermit) não possui uma interface gráfica que torne a sua utilização intuitiva. Além disso, também não é tão fácil encontrar documentação clara a respeito de como devem ser efetuadas as configurações e tão pouco scripts de exemplo na Internet. Por isso, estou publicando no blog alguns dos scripts que utilizo para o trabalho do dia-a-dia e que são extremamente úteis.

Para executar os scripts basta executar:

# kermit nome_do_arquivo


1. Utilizando a interface serial do seu micro para se conectar a console de um roteador ou switch (salvar comandos abaixo no arquivo serial.txt).

log session serial.log
set line /dev/ttyS0
set speed 9600
set serial 8N1
set carrier-watch off
connect
close connection
quit



2. Utilizando a interface serial do seu micro para se conectar a um modem externo (salvar comandos abaixo no arquivo modem.txt).

log session modem.log
set line /dev/ttyS0
set modem type generic
set modem data-compression off
set modem error-correction off
set flow-control /modem rts/cts
set modem speed-matching on
set serial 8N1
set carrier-watch off
dial número_do_telefone
connect
close connection
quit


3. Utilizando o Kermit para efetuar um telnet para um equipamento. Utilizado para acessar equipamentos remotos onde não se possui acesso a console (salvar comandos abaixo no arquivo telnet.txt)

log session telnet.log
set input echo off
set host /nowait
IP PORTA /telnet
connect
close connection
quit


4. Utilizando o Kermit para abrir um raw socket para um equipamento. Muito utilizado para se conectar a servidores de console (veja artigo em http://www.networkcomputing.com/showitem.jhtml?docid=1519f3) (salvar comandos abaixo no arquivo raw.txt)

log session raw.log
set input echo off
set host IP PORTA /raw-socket
connect
close connection
quit


Dicas importantes!

1. Sempre que for finalizar uma conexão a sequência de escape a ser utilizada é a seguinte: "Ctrl+\ , c". Este item é muito importante para não deixar as sessões presas.
2. Caso precise enviar um Ctrl+Break para o equipamento a sequência de escape é "Ctrl+\ , b".

segunda-feira, 15 de janeiro de 2007

Greylisting usando spamd (OpenBSD) em modo bridge - Parte 2

E então? Foi complicada a instalação do OpenBSD?
A princípio, pode assustar (principalmente o particionamento :) ), mas, prometo que agora será mais leve!

Vamos à configuração do nosso greylisting.

Primeiramente, precisamos habilitar o sistema operacional a repassar pacotes de uma interface para a outra, e, além disso, habilitar a ativação do packet filter no boot.
Edite o /etc/sysctl.conf e descomente a seguinte linha:

net.inet.ip.forwarding=1 #1=Permit forwarding (routing) of packets


Edite também o arquivo /etc/rc.conf e adicione a seguinte linha:

pf=YES #Enable PF


Agora, partiremos para a configuração da Bridge.
Para cada interface de rede, é necessário criar um arquivo de configuração. Para a interface xl0, que será ligada à Internet, crie o arquivo /etc/hostname.xl0 . Edite o arquivo e adicione o seguinte (lembre-se o que combinamos no post anterior: no lugar dos IPs representados por letras deve ser usado um IP válido na Internet):

inet aaa.bbb.ccc.ddd 255.255.255.0 NONE


O IP usado na interface externa (xl0) deve pertencer à mesma sub-rede dos seus servidores de e-mail.

Agora para a interface xl1, crie o /etc/hostname.xl1 e adicione no arquivo:

inet 192.168.10.10 255.255.255.0 NONE


E, na interface xl2, crie o /etc/hostname.xl2 e adicione no arquivo:

inet 192.168.10.11 255.255.255.0 NONE


Agora, devemos colocar todas estas interfaces como parte da bridge. Para isso, crie o arquivo /etc/bridgename.bridge0 e adicione o seguinte:

add xl0
add xl1
add xl2
up


Agora, é necessário configurar o spamd. Para isso, edite o arquivo /etc/rc.conf e habilite as seguintes configurações:

spamd_flags="-v -G 25:4:864" #para entender esses números, leia o manual do spamd (man spamd)
spamd_grey=YES # use spamd greylisting if YES
spamlogd_flags="" # use eg. "-i interface" and see spamlogd(8)


O spamd pode consultar listas públicas onde são cadastrados domínios que já enviaram Spam. Isso pode ser configurado no arquivo /etc/spamd.conf . Eu nunca testei essas consultas pois faço isso em outro momento no sistema. Minha configuração é a seguinte:

all:\
:blacklist:whitelist:
whitelist:\
:white:\
:method=file:\
:file=/etc/whitelist.conf:
blacklist:\
:black:\
:msg="SPAM. Your address %A is blocked":\
:method=file:\
:file=/etc/blacklist.conf:


É muito importante que você leia o manual do spamd.conf e entenda o que quer dizer cada linha desta, e, principalmente, como estas listas branca e negra se anulam. Basicamente, nesta configuração, estou dizendo em qual arquivo estão os IPs que não precisam ser filtrados (whitelist) e em qual arquivo estão os IPs dos quais não quero receber e-mail de maneira alguma (blacklist). Mesmo que não os utilize, crie os arquivos whitelist.conf e blacklist.conf

touch /etc/whitelist.conf
touch /etc/blacklist.conf


Agora, a parte mais divertida e elaborada desta implementação: a configuração do pf! Adianto que ela não foi desenvolvida por mim, mas sim por Graham Toal, da Universidade do Texas. O link onde ele disponibilizou isso não está mais no ar. Portanto, coloco aqui para prosperar a criação de Graham (que não é o Bell, mas sim o Toal. Thanks Graham! (os dois!) ). Enfim, fiz apenas algumas pequenas adaptações para facilitar o entendimento do arquivo, o qual está a seguir. Edite o /etc/pf.conf e copie para lá a seguinte configuração, adaptando para o seu cenário. Vou configurar o arquivo de acordo com o nosso:

# $OpenBSD: pf.conf,v 1.29 2005/08/23 02:52:58 henning Exp $
#
# See pf.conf(5) and /usr/share/pf for syntax and examples.
# Remember to set net.inet.ip.forwarding=1 and/or net.inet6.ip6.forwarding=1
# in /etc/sysctl.conf if packets are to be forwarded between interfaces.

#variaveis

ext_if="xl0" #ligada a Internet
int_if= "{ xl1, xl2 }" #interfaces da maquina. Temos tres: uma para entrada da internet
# e outras duas para ligar cada um dos dois MX's.

ip_local="aaa.bbb.ccc.ddd" #esse é o ip pelo qual você consegue conectar na bridge
mail_server= "{ eee.fff.ggg.hhh, iii.jjj.kkk.lll }" #IPs dos MXs que estao atrás da brigde

#Maquinas ou redes da sua instituicao permitidas a acessar servicos no $mail_server

ip_snmp= "{ xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx }" #esses IPs podem ter aceso à porta SNMP dos #$mail_server
ip_ssh= "{ xxx.xxx.0/24, xxx.xxx.xxx.0/24, xxx.xxx.xxx.0/24 }" #IPs podem ter acesso à porta SSH #dos $mail_server


#Tabelas usadas em conjunto com o spamd
table < spamd > persist file "/etc/blacklist.conf"
table < spamd-white > persist
table < whitelist > persist file "/etc/whitelist.conf"

set block-policy drop

#Aumentar o limite de entradas nas tabelas (Padrao: 100000)
set limit table-entries 500000

scrub on $ext_if reassemble tcp no-df random-id

# testes de redirecionamento para o spamd

# Está na whitelist? - Então passe sem ser tocado
no rdr on $ext_if \
inet \
proto tcp \
from < whitelist > \
to any

# Se chegou aqui, não está em whitelist. Está na blacklist?
# Redireciono para o spamd, o qual vai "gastar o tempo" do spammer
# e no final da "interação smtp" dirá que ele está na blacklist

rdr on $ext_if \
inet \
proto tcp \
from < spamd >\
to any \
port smtp -> 127.0.0.1 port spamd

# ainda não está na tabela dinâmica spamd-white
# redireciono para o spamd que vai tratar a mensagem

rdr on $ext_if \
inet \
proto tcp \
from !< spamd-white > \
to any \
port smtp -> 127.0.0.1 port spamd

#bloquear tudo por padrão
block in all
block out all

#libera conexao do localhost para porta de configuracao do spamd 8026
pass in quick proto tcp from 127.0.0.1 to 127.0.0.1 port 8026

#liberar ICMP
pass in quick on $ext_if proto icmp from any to any

#liberar SSH para IPs contidos nas variáveis

pass in quick on $ext_if proto tcp from $ip_ssh to $mail_server port 22 keep state
pass in quick on $ext_if proto tcp from $ip_ssh to $ip_local port 22 keep state


#SNMP

pass in quick on $ext_if proto udp from $ip_snmp to $mail_server port 161 keep state
pass in quick on $ext_if proto tcp from $ip_snmp to $mail_server port 161 keep state
pass in quick on $ext_if proto udp from $ip_snmp to $ip_local port 161 keep state
pass in quick on $ext_if proto tcp from $ip_snmp to $ip_local port 161 keep state


# permitir especificamente os pacotes que foram redirecionados acima
pass in quick on $ext_if \
inet \
proto tcp \
from < whitelist > \
to port smtp

# Pacotes permitidos passam diretamente para o mail_server
# ou seja, já estão na tabela dinâmica spamd_white

pass in quick on $ext_if \
inet \
proto tcp \
from < spamd-white > \
to port smtp


pass in on $ext_if \
route-to lo0 \
inet \
proto tcp \
from any \
to 127.0.0.1 \
port spamd

pass out quick on $ext_if \
inet \
proto tcp \
from $ext_if \
to any \
port smtp \
flags S/SA \
keep state

pass out quick on $int_if \
inet \
proto tcp \
from $int_if \
to any \
port smtp \
flags S/SA \
keep state

pass out keep state

pass quick on { lo xl0 xl1 xl2 } #nomes das interfaces. Adapte para sua configuracao.
#Mantenha lo

antispoof log quick for { lo xl0 xl1 xl2 } #nomes das interfaces. Adapte para seu caso.
#Mantenha lo


Agora, é necessário ativar a atualização da tabela do pf pelo spamd, adicionando uma entrada no crontab. Para isso, como root, faça o seguinte:

#crontab -e


E, no arquivo, adicione as linhas:

#atualizacao spamdb
5 * * * * /usr/libexec/spamd-setup



Esta é toda a configuração necessária. Reinicie a máquina para que elas "entrem em vigor"! :D

Agora, antes de colocar em produção, faça testes enviando e-mail de fora da sua rede. Diminua os tempos configurados no /etc/rc.conf para que seu teste não demore muito (ao invés de 25 minutos como coloquei, coloque 1 minuto. Não use o valor de 1 minuto em produção. Será pouco efetivo. Eu utilizo estes valores que mostrei).

Dicas de comandos úteis

Leia os seguintes manuais
- man spamd
- man spamd-setup
- man spamdb
- man spamd.conf

Comandos do pf
- Adicionar endereço IP na tabela spamd-white:
pfctl -t spamd-white -T add xxx.yyy.zzz.www

- Ver as regras carregadas:
pfctl -s rules

- Testar o arquivo pf.conf antes de carregá-lo
pfctl -nf /etc/pf.conf

- Carregar o arquivo de configuração /etc/pf.conf
pfctl -f /etc/pf.conf


Boa sorte nas configurações! Torço para que seja útil!

Greylisting usando spamd (OpenBSD) em modo bridge - Parte 1


Greylistin
g
é uma técnica usada para combater o Spam, que, atualmente, funciona bem para diminuir o número de propagandas não solicitadas, phishings e vírus na caixa de entrada de e-mail dos usuários. Digo atualmente porque, não tenho dúvidas, que os spammers vão se adaptar a esta técnica. Mas não desanime! Essa é apenas mais uma camada das muitas já implementadas na segurança do seu sistema! :D

Esta técnica se aproveita do fato que, geralmente, os spammers utilizam programas para envio de e-mails em massa ou proxies smtp mal configurados que, ao contrário do que prevê o RFC 821 [1], não reenviam os e-mails caso recebam uma mensagem de falha temporária. Assim, o greylisting exige que uma mensagem seja enviada 1 vez, para que entre na greylist, e, após o tempo mínimo de espera para reenvio configurado no software que fará esse controle de greylisting, mais duas vezes, para que então seja entregue. Uma explicação excelente e didática do funcionamento desta técnica pode ser lida em [2] .

A abordagem que será descrita aqui é útil para que você não precise mudar nada em seu servidor de e-mails. Portanto, caso ele não tenha algum suporte para esta técnica, isso não será problema. O que teremos será uma "caixa preta" que fará todo o controle dos e-mails que chegam aos seus MX (mail exchanger). Todo e-mail que chegar ao MX certamente terá passado pela filtragem do Greylist.
Será necessário um computador com tantas placas de rede quanto forem seus MX mais uma, ligada à internet (Exemplo: Tenho 2 MXs, portanto, precisarei de 3 placas de rede).

Antes de tudo, instale as placas no computador e o sistema operacional OpenBSD (isso foge do escopo deste texto. Vide [3]). Feito isto, mais uma pequena explicação sobre como funcionará o greylisting, agora, utilizando esta implementação.

O greylisting funcionará utilizando a interação entre o daemon spamd (que fará o controle dos e-mails) e o pf (packet filter, o firewall do OpenBSD [4]). O spamd fará o controle do banco de dados citado na referência 2 e atualizará a tabela do packet filter segundo o banco de dados. Ou seja, o IP (fictício) 10.1.2.3 já passou pelos testes e está apto a entregar mensagens no MX, portanto, ele adicionará esse IP na tabela do PF que libera a passagem de pacotes originados deste IP à porta 25. Na próxima vez que este IP enviar e-mails para os meus MXs, o PF verá em suas tabelas que o IP está liberado e permitirá que o pacote siga para o MX correto. Caso um IP não esteja liberado em sua tabela ainda, o PF redirecionará o pedido para o daemon spamd. Este irá responder no lugar do MX (utilizando IP do MX para o qual a mensagem está sendo enviada), como se fosse um servidor SMTP. Pegará os dados, gravará na base de dados e retornará uma falha temporária. Quando for reenviado, checará se o tempo mínimo para reenvio foi satisfeito (digamos, depois de 25 minutos) e, se sim, coloca este IP na whitelist e retorna um erro temporário. Avisa o PF que este IP está liberado, e, no próximo reenvio, o pacote passará pela bridge e chegará de fato ao MX. Agora, vamos às configurações.

Consideremos que o computador tenha três placas: xl0, xl1 e xl2. Consideremos ainda que a placa xl0 será ligada à Internet e as outras duas a cada um dos meus MXs (lembre-se que, para ligar um computador diretamente ao outro, deve-se usar um cabo cross UTP, considerando que está usando uma placa Ethernet com conector RJ-45 :) ). O cenário está ilustrado a seguir (considere os IPs representados com letras IPs válidos na Internet):




Gostou? Bacana? Que tal providenciar uma máquina e iniciar a instalação do OpenBSD? :D
Assim que terminar, volte ao blog para começarmos as configurações! Até logo!

[1] http://www.ietf.org/rfc/rfc0821.txt
[2] http://www.antispam.br/admin/greylisting/
[3] http://www.openbsd.org/faq/faq4.html
[4] http://www.openbsd.org/faq/pf/

quarta-feira, 10 de janeiro de 2007

Dynamips - Emulador Cisco

O Dynamips é um emulador de roteadores Cisco. Com ele é possível emular as plataformas Cisco7200 e Cisco3600 (esta url faz referência a utilização do dynamips com outras plataformas) em uma máquina intel (suporte a Linux e Windows).

Ele ajuda os administradores de redes à:

- Realizar treinamento
- Testar funcionalidades
- Testar configurações que serão aplicadas em ambientes reais
Para utilizar o Dynamips é preciso ter um IOS correspondente.

Existe uma interface chamada Dynagen para facilitar a configuração. Este site possui uma boa documentação.

[UPDATE] Veja também o tutorial de como instalar e configurar o Dynamips/Dynagen.

terça-feira, 2 de janeiro de 2007

Traceroute for Dummies

Disclaimer: Os exemplos deste post não refletem a realidade.

A ferramenta traceroute é utilizada para determinar o caminho (ou rota) por onde os pacotes IP trafegam de uma origem A até um destino B na rede. No entanto, a forma como esta ferramenta é utilizada e como são determinadas as rotas na Internet pode confundir o usuário desatento.

O traceroute funciona enviando pacotes com o campo Time To Live (TTL) configurado para 1. O primeiro roteador (primeiro hop) envia então um pacote (ICMP) indicando que o pacote não pode ser roteado (devido ter expirado o TTL) para a origem. Após receber a indicação de erro, um outro pacote é enviado com o TTL configurado para 2 e o segundo roteador (segundo hop) neste momento enviará uma indicação de erro para a origem. Esse processo continua até que se alcance o destino ou um limite pré-determinado. Para mais informações sobre o funcionamento do traceroute consultar o RFC1393.

Uma das desvantagens deste mecanismo é que existem alguns roteadores (ou firewalls de camada 3) que não enviam pacotes ICMP TTL Expiried e, portanto, o traceroute ficará incompleto nestes casos. No entanto, o mecanismo do traceroute continuará funcionando ou mesmo o acesso da origem até o destino independentemente do resultado do traceroute.

Vejamos então o exemplo abaixo:

traceroute to registro.br (200.160.2.3), 30 hops max, 38 byte packets
1 10.13.0.1 (10.13.0.1) 13.016 ms 14.776 ms 20.168
ms
2 c9060002.virtua.com.br (201.6.0.2) 26.941 ms 12.479 ms 47.129 ms
3 c9060005.virtua.com.br (201.6.0.5) 15.636 ms 15.005 ms 13.898 ms
4 embratel-G6-0-gacc05.spo.embratel.net.br (200.178.78.1) 25.453 ms 12.044 ms 12.600 ms
5 ebt-C1-core03.spo.embratel.net.br (200.230.242.18) 166.976 ms 152.516 ms 59.465 ms
MPLS Label=440 CoS=0 TTL=1 S=1
6 200.244.40.185 (200.244.40.185) 25.348 ms 32.426 ms 45.846 ms
MPLS Label=26 CoS=0 TTL=1 S=1
7 ebt-G6-0-gacc02.pae.embratel.net.br (200.230.221.130) 34.828 ms 26.831 ms 40.176 ms
8 brasiltelecom-P4-1-gacc02.pae.embratel.net.br (200.248.240.26) 51.079 ms 40.072 ms 35.036 ms
9 BrT-G7-1-1-pae-core01.brasiltelecom.net.br (201.10.225.29) 173.797 ms 70.255 ms 48.286 ms
MPLS Label=836 CoS=0 TTL=1 S=1
10 BrT-G3-0-bsace-core01.brasiltelecom.net.br (201.10.192.33) 50.676 ms 61.465 ms 49.934 ms
MPLS Label=898 CoS=0 TTL=1 S=1

11 BrT-P2-11-spopa-core01.brasiltelecom.net.br (201.10.192.169) 61.742 ms 54.972 ms 72.244 ms
MPLS Label=35 CoS=0 TTL=1 S=1
12 BrT-G0-1-2-spopa302.brasiltelecom.net.br (201.10.241.150) 47.699 ms 86.113 ms 79.095 ms
13 BRT-RegistroBR.brasiltelecom.net.br (200.169.193.2) 55.980 ms 52.105 ms 71.012 ms
14 registro.br (200.160.2.3) 58.213 ms 49.184 ms 70.845 ms

Este traceroute, feito de um acesso net/virtua para um IP do registro.br, mostra por onde os pacotes devem passar para sair do meu computador até os servidores do Registro.br: net/virtua, embratel, brasiltelecom e finalmente, registro.br. Observe o caminho de ida traçado em verde e o caminho de volta (do registro.br para o meu computador) destacado em vermelho. Este caminho destacado em vermelho é a interconexão entre NET e Registro.br através do PTT-Metro.

Desta figura podemos rapidamente chegar a duas conclusões importantes:

1) O tempo total apresentado nos pacotes de A (net/virtua) até B (registro.br) é o tempo de ida (destacado em verde) adicionado ao tempo de volta (em vermelho).

2) Sabendo que o tempo total é o tempo de ida + volta, então também devemos admitir que, dada a política de roteamento adotada por cada provedor presente na rede, o pacote de resposta para cada um dos hops pode retornar por caminhos diferentes do caminho de ida e, portanto, o tempo apresentado por cada hop pode sofrer influência de outros caminhos que não aquele que podemos visualizar na saída do traceroute (caminho de ida).

Por exemplo, se observarmos atentamente as conexões da figura acima veremos que a embratel possui uma conexão com a globalcrossing (gblx) que, por sua vez, possui uma conexão com a net/virtua. Em um determinado momento os pacotes da embratel até a net/virtua podem (devido a política de roteamento adotada pela embratel) trafegar pela gblx e, portanto, o tempo da net/virtua até a embratel será a soma do tempo de ida (net/virtua até embratel) e do tempo de volta (embratel até net/virtua, passando pela gblx). A observação de um tempo de resposta elevado no hop embratel poderá portanto indicar um problema na net/virtua, embratel ou gblx.

A ferramenta traceroute pode ser facilmente utilizada nos principais sistemas operacionais disponíveis (unix/linux ou windows). No unix/linux o traceroute utiliza geralmente pacotes UDP (utilizar opção "-I" para pacotes ICMP) e no windows o tracert utiliza pacotes ICMP. Além disso, podemos utilizar front-ends disponíveis na web para obter o resultado da ferramenta traceroute - dentre outras ferramentas - para analisar problemas de rede verificando o caminho de diversos provedores e lugares do mundo para um destino específico. Para mais informações acessar o website traceroute.org mantido por Thomas Kernen (thanks Thomas!).

Como gerar um túnel SSH

Muitas vezes precisamos conectar no nosso e-mail a partir de um ambiente onde as portas de SMTP e IMAP estão bloqueadas e restando apenas uma porta SSH aberta. Então poderemos fazer um tunel SSH para comunicação entre cliente e servidor nas portas desejadas.

Exemplo:

$ ssh nexthop.com.br -l jarbas -L 10025:localhost:25 -L 10143:localhost:143

Agora configurar o cliente de e-mail para conectar na conta "apontando" para localhost:
SMTP em localhost na porta 10025
IMAP em localhost na porta 10143

Vale ressaltar que para clientes SSH Windows o conceito de túnel é o mesmo.

Pronto!

Como gerar chaves SSH

Com os constantes ataques de força bruta em servidores SSH muitos são configurados para aceitar somente acessos por autenticação de chaves SSH, elevando assim o nível de confiabilidade do acesso.

No seu host (linux) gerar o par de chaves SSH:

$ ssh-keygen -t dsa -f chave.asc -v

Informe a senha (passfrase). Serão gerados os arquivos chave.asc e chave.asc.pub.
Em seguida faça uma cópia dos arquivos:

$ cp chave.asc $HOME/.ssh/id_dsa
$ cp chave.asc.pub $HOME/.ssh/id_dsa.pub

OBS: Caso você ainda não tenha o par de chaves SSH no $HOME/.ssh/
Proteção para garantir acessos indevidos:

$ chmod 600 $HOME/.ssh/id_dsa
$ chmod 600 $HOME/.ssh/id_dsa.pub

Pronto agora você possui um par de chaves no seu computador que poderá ser exportada para os servidores desejados.

Faça outra cópia de chave.asc.pub para o HOMEDIR da máquina que você quer conectar e adicione o seu conteúdo ao arquivo "authorized_keys":
$ cat chave.asc.pub >> .ssh/authorized_keys

Pronto! Divirta-se! :-)

Variáveis importantes em servidores de alto tráfego utilizando FreeBSD

Se você administra um servidor com alto tráfego e utiliza o excelente FreeBSD, uma boa dica é aumentar o valor da variável maxusers no kernel. Em /usr/src/sys/i386/conf/ (caso utilize arquitetura i386) adicione:

maxusers 1024

Depois compile e instale o kernel. Eu, particularmente, tomei como padrão colocar essa variável como a metade do tamanho de memória RAM. Se tenho 2048MB, coloco 1024. No momento do config , o sistema irá emitir um alerta quanto a isso, mas, nunca tive problemas.

A variável maxusers irá aumentar algumas coisas importantes do sistema, como, por exemplo, o número máximo de threads e o número máximo de arquivos abertos. Muitas outras variáveis de sistema (aquelas que você vê usando sysctl -a ) são calculadas dependendo desse número.

Outra ação importante é aumentar o número de conexões permitidas ao servidor. O padrão é 128. Em servidores que recebem, por exemplo 800 mil mensagens/dia, é bom aumentar esse valor:

# sysctl kern.ipc.somaxconn=65535

Para que esse valor seja carregado no boot, adicione o seguinte no arquivo /etc/sysctl.conf :

kern.ipc.somaxconn=65535

Sempre usei esse valor máximo, e nunca tive problemas. Essas configurações foram utilizadas em um servidor de e-mail que recebe o número de mensagens citadas acima. :)

Se existe alguma restrição para esses valores citados, quero ouvir opiniões. ;)

PIX - Conectar via SSH

Para se conectar ao PIX via SSH, além de habilitar as conexões via o protocolo é preciso criar uma chave RSA no equipamento. Para isso basta seguir os comandos abaixo.
ca generate rsa key 1024
ca save all
write memory

Sem esses comandos, a cada vez que o equipamento é reinicializado será preciso abrir a interface gráfica via HTTPS para que ele gere essa chave.