MAL - Memória Auxiliar do Lutieri

quinta-feira, julho 26, 2007

DNS Tips

Recentemente construi dois servidores DNS com views e o diabo a quatro.
Debugando o BIND descobri algumas coisas interessantes as quais não encontrei muita informação na internet.

Os registros DNS são divididos em classes. Olhe esse trecho retirado do livro O'Reillly: DNS and BIND, 4th Edition:

Currently, there are classes for internets (any TCP/IP-based internet), networks based on the Chaosnet protocols, and networks that use Hesiod software. (Chaosnet is an old network of largely historic significance.)

Hoje usa-se apenas a classe internet não se sabe se alguém ainda usa a chaosnet. Porém o BIND carrega essa classe(chaosnet). E dentro dela estão algumas informações, por hora importantes, como a versão do BIND, o hostname da máquina onde ele está rodando e os autores do BIND.

A versão do BIND eu já sabia que podia ser consultada. O hostname do server me surpreendeu e os autores eu não consegui consultar. Mas se você carregar com o seguinte comando:

/usr/local/sbin/named -u named -t /chroot/named -g -c /etc/named.conf -d 10

Você verá todas as informações que são carregadas na inicialização. Entre elas uma linha como isto:

26-Jul-2007 15:19:01.984 zone hostname.bind/CH: starting load

Que é onde ele carrega a zona que armazena as informações que mencionei acima.
Indo diretamente ao que interessa que é fazer esse tipo de consulta à servidores rodando BIND.

  • Ex. de como consultar a versão do BIND usando a ferramenta dig:

dig @servidor version.bind txt chaos

  • O mesmo exemplo usando o nslookup:

nslookup
server servidor
set debug
set class=chaos
set type=txt
version.bind
A opção set debug não é necessária mas, útil para ceder mais informações.

Como essa informação, tanto da versão quanto do hostname do server, expõem o servidor a um certo risco. Podemos corrigir esses valores, facilmente, usando as seguintes diretivas no named.conf:

hostname " are you kidding me? ";
version " are you kidding me? ";

Bom...o nslookup é meio chato pra fazer as pesquisas. E até li em algum lugar que ele já é considerado obsoleto. Portanto vá se acostumando com o dig.

No nslookup você tem várias opções que podem ser setadas em modo interativo como o tipo de registro que deseja ser consultado, a classe que vai ser consultada enfim.... Para ver as opções que estão sendo usadas e quem sabe alterá-las pode-se digitar set all. Serão listadas as opções e os respectivos valores setados no momento.

Como fazer consultas de dns reverso. Ou seja, informar o nome e ser retornado o ip. Esses registros de dns reverso são do tipo PTR enquanto os de dns direto são do tipo A. Por padrão o nslookup busca por registros do tipo A.

  • Para fazer uma consulta de dns reverso usando o dig:

dig @servidor -x 192.168.1.1

  • A mesmo consulta utilizando o nslookup:

nslookup
server servidor
set debug
set type=ptr
192.168.1.1

Novamente o set debug não se faz necessário. É eu que tenho mania de usá-lo.

Os servidores usam um tipo de registro(AXFR) que solicita e transfere a zona inteira para quem solicitou. Hoje em dia é usado o IXFR que ao invés de transferir a zona inteira transfere apenas o que há de diferente entre o servidor que foi consultado e o que consultou.

Usando desse recurso podemos podemos fazer de conta que somos um servidor secundário que solicita uma transferência de zona completa. É um pouco útil quando está querendo conhecer um outro servidor... não me pergunte por qual motivos isso seria necessário mas...

dig @servidordns.com.br axfr empresaxyz.com.br

Isso solicita ao servidor servidordns.com.br uma transferência de zona completa da zona empresaxyz.com.br.

Se o pseudo-administrador da empresaxyz não setou a diretiva allow-transfer é bem possível que você verá uma lista de todos os registros pertencentes a essa zona.
Para evitar isso qualquer ser que se proponha a fazer um servidor deveria saber resolver isso com uma diretiva allow-transfer.

allow-transfer { none; };

Referência sobre DNS e BIND:
http://www.zytrax.com/books/dns/

Brevemente posto um how-to de como montar um servidor dns usando o bind, views, jails e afins...

[]'s

Marcadores: ,

Ferramentas para trabalhar com AD

Não é minha área no momento mas achei que algum dia eu vou precisar. Portanto hoje, estou colocando aqui na minha memória secundária.

http://www.dailycupoftech.com/2007/07/26/server-failure-lesson-10-useful-active-directory-tools/

Marcadores:

quarta-feira, julho 25, 2007

FTP e NAT

Era um pacato dia de inverno na TI da empresa onde presto serviços quando eu estava fazendo a migração do firewall em linux para uma máquina nova(Sun X4100) com FreeBSD.

Havia instalado o squid com autenticação ntlm no AD windows, nessus para dar uma conferida na segurança e estava migrando as regras de firewall de iptables para PF. Quase tudo pronto. Quase! pois havia ainda o velho e conhecido problema em acessar servidores ftp estando atrás de um firewall com NAT.

Segundo consta na documentação do próprio PF é bastante simples ter a solução para o problema de acesso a servidores ftp, principalmente os que trabalham em modo ativo, onde o problema de acesso é do cliente.

Teoricamente usa-se um proxy ftp(ftp-proxy) as conexões dos clientes são redirecionadas para esse proxy, normalmente escuta na porta 8021 através do inetd, faz a requisição para o servidor ftp que o cliente solicitou e retorna os dados para o cliente, enfim.. ele faz o meio campo, o papel de um proxy.

O ftp-proxy também cria regras necessárias no firewall, rodando, para permitir o tráfego para o cliente que solicitou, através de âncoras. Hipoteticamente quando uma sessão ftp é estabelecida deveria ser possível ver as regras que o nosso amigo ftp-proxy criou com o comando:

pfctl -a ftp-proxy -s rules
Mas eu nunca consegui ver(talvez eu esteja fazendo algo errado)... cheguei até a pensar que o tal do ftp-proxy não tava trabalhando, porque por sinal ele não loga nada e não faz debug também. Mas descobri que ele estava funcionado quando parei o serviço inetd. Aí não conectou mais no server ftp.

Mas, porém, contudo, entretanto, todavia seguia as instruções, busquei por ajuda em fóruns e não obtive sucesso.

Fiquei um pouco decepcionado pois o que parecia ser simples me roubou um dia inteiro e no final das contas não funcionava em servidores em modo ativo, somente passivo.
Costumo testar no ftp da pucpr:

ftp ftp.pucpr.br


logo-me como anonymous e quando dou um ls ele entra em modo ativo e é ai que a porca torce o rabo. Para saber mais sobre o funcionamento do protocolo e serviço ftp eu recomendo essa leitura: http://pintday.org/whitepapers/ftp-review.shtml

Buscando por uma solução em alguma lista de discussão encontrei várias pessoas com o mesmo problema e uma das soluções citadas era de usar o pftpx. Um softwarezinho que, olhando pelo manual dele aparenta ser a mesma coisa que o ftp-proxy, também escuta na mesma porta(8021). Faz uso de âncoras também e nesse me parece que funciona.

Pois bem, no firewall foi necessário apenas inserir o seguinte:

In the NAT section:

nat-anchor "pftpx/*"
rdr-anchor "pftpx/*"
rdr pass on $int_if proto tcp from $lan to any port 21 -> 127.0.0.1 port 8021

In the rule section:

anchor "pftpx/*"
Bloco acima retirado do próprio manual.

no /etc/rc.conf adicionei o seguinte:

#proxy ftp
pftpx_enable="YES"
Isso irá carregar o pftpx na inicialização do FreeBSD. Aliás, para se reiniciar os serviços sem reinicializar o freebsd pode-se usar o seguinte:


# shutdown now
(Nota: sem -r ou -h)

# return
# exit
Dica acima retirada daqui.

OU

#sh /etc/rc

OU

"After making the necessary changes to the /etc/* file you should send a SIGHUP (hangup) signal to the init process to force it to re-read its configuration file. For example:"

# kill -HUP 1



Porém o comando acima, re-lê, mas não finaliza os serviços que já estão rodando.

Vejamos se o pftpx foi iniciado com sucesso:

sockstat -l4 | grep 8021
tem que aparecer algo como:

proxy pftpx 4378 3 tcp4 127.0.0.1:8021 *:*

Bom se foram inseridas as regras e âncoras no firewall e o serviço está iniciado tudo indica que os clientes da sua rede já podem acessar servidores FTP sem problemas. Teste.

No momento que estabelecer um conexão, a partir de um cliente, execute o seguinte comando no firewall:

pfctl -s Anchors -v

Serão exibidas todas as âncoras. Haverá uma chamada pftpx e outra como pftpx/pid.x.
Onde pid é o número do processo pftpx e x eu não sei. Mas deve ser algo como instância.

execute então:

pfctl -a "pftpx/pid.x" -s rules
pfctl -a "pftpx/pid.x" -s nat


Serão exibidas as regras criadas para essa conexão ftp. Essa âncora pftpx/pid.x só será criada no momento que o ftp estiver em modo ativo.


Proonto!!!!!

Marcadores: , ,

domingo, julho 01, 2007

[OT] Alguns exercícios de Yoga

Alguns exercícios que podem ser feitos em casa:


http://www.yogasite.com.br/yogasite/asana.htm

Marcadores:



Chat with Lutieri G. B.

Subscribe in a reader