Apache PHP Postgresql no CentOS e Fedora

Nesse pequeno tutorial vamos aprender a instalar e configurar de maneira básica um servidor Web na plataforma Linux (baseado no CentOS 5). Note que trata-se de material inédito, que será de grande valia para muitos que, como eu, precisam fazer isso e não encontram materiais disponíveis na web. Mãos à obra!

1) Abra o shell e logue como root:
No CentOS e Fedora o pacote chama-se httpd;

2) Instalando o Apache:
# yum install httpd

Após a instalação, é necessário rodar o comando chkconfig para que ele seja ativado no boot:
# chkconfig httpd on

3) Para iniciar o serviço temos duas opções de comandos:
# service httpd start
OU
# /etc/init.d/httpd start

start: Inicia o serviço
stop: Para o serviço
restart: Para e inicia o serviço
reload: Apenas atualiza a configuração, sem para o serviço.

Após iniciar o serviço, abra o navegador e digite, para testar o serviço:
http://127.0.0.1
Se for carregada a página inicial do APACHE, significa que a instalação foi concluída com sucesso!

Todas as configurações do Apache no CentOS e Fedora ficam no arquivo:
/etc/httpd/conf/httpd.conf

Os sites ficam concentrados dentro do diretório:
/var/www/html/

4) Instalando o suporte a PHP:
# yum install php

5) Instalando o módulo PHP para fazer a junção com Postgresql:
# yum install php-pgsql

Para que as alterações entrem em vigor, reinicie o Apache:
# service httpd restart

Para verificar se o suporte a PHP esta ativo, crie um arquivo com o nome teste.php dentro da pasta /var/www/html/
que contenha a seguinte linha:
<?php phpinfo( ); ?>

Abra o seu navegador e digite o endereço:
http://127.0.0.1/teste.php

6) Instalando o Postgresql com todas as suas dependências:
# yum install postgresql*.*

Iniciando o serviço e ativando-o no boot:
# service postgresql start
# chkconfig postgresql on

Os arquivos de configuração do Postgresql se encontram dentro da pasta:
/var/lib/pgsql/data/

Acesse esse diretório e vamos editar os arquivos de configuração:
# cd /var/lib/pgsql/data
# vi pg_hba.conf

No final do arquivo deixe as linhas conforme o exemplo abaixo:
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:

Libera o acesso para a máquina local sem senha:
host all all 127.0.0.1/32 trust

Libera o acesso para a rede local sem senha:
host all all 192.168.0.0/24 trust

# Libera o acesso externo sem senha
host all all 0,0,0,0 0,0,0,0 trust

# IPv6 local connections:

#host all all ::1/128 ident sameuser

Para que as alterações entrem em vigor reinicie o serviço:
# service postgresql restart

Agora vamos editar o arquivo postgresql.conf:
# vi postgresql.conf

Descomente e modifique as linhas abaixo conforme o exemplo:

#—————————————————————————
# CONNECTIONS AND AUTHENTICATION #—————————————————————————

# – Connection Settings -

# Descomente, essa linha faz com que o Postgresql aceite conexões de qualquer ip.
listen_addresses = ‘*’ # what IP address(es) to listen on;

# comma-separated list of addresses;

# defaults to ‘localhost’, ‘*’ = all

# Descomente as linha abaixo,
port = 5432
max_connections = 500

Para que as alterações entrem em vigor reinicie o serviço:
# service postgresql restart

Alguns comandos básicos de Postgresql:

Criando uma base de dados chamada microcamp
# createdb -U postgres microcamp

Listando as bases de dados dentro do banco:
# psql -U postgres -l

Entrando dentro da base de dados microcamp
# psql -U postgres microcamp

# Listando o conteúdo da base de dados:
frigo2=# \d

# Atribuindo uma senha para a base de dados
frigo2=# alter user postgres with encrypted password ’senha’;

Para sair da base de dados use as teclas CTRL + D simultaneamente.

Após atribuido a senha a base de dados é necessário editar novamente o arquivo pg_hba.conf, trocando os métodos trust por md5 para que a senha seja requisitada ao tentar a conexão, lembrando que o arquivo se encontra dentro do diretório /var/lib/pgsql/data.
# cd /var/lib/pgsql/data
# vi pg_hba.conf

# TYPE DATABASE USER CIDR-ADDRESS METHOD

# “local” is for Unix domain socket connections only

local all all md5

# IPv4 local connections:

# Libera o acesso para a máquina local sem senha
host all all 127.0.0.1/32 md5

# Libera o acesso para a rede local sem senha
host all all 192.168.0.0/24 md5

# Libera o acesso externo sem senha
host all all 0,0,0,0 0,0,0,0 md5

# IPv6 local connections:

#host all all ::1/128 ident sameuser

Para que as alterações entrem em vigor reinicie o serviço:
# service postgresql restart

Agora vamos testar a conexão com o Postgresql, crie um arquivo chamado conexao.inc.php dentro do diretório /var/www/html e adicione as linhas abaixo:

<?php

$strConexao=”host=localhost user=postgres dbname=frigo2 password=frigo13579 port=5432″;

$conexao=pg_connect($strConexao);

if(!$conexao){

echo “Erro na conexcao: ” . pg_last_error($conexao);

}

?>

Agora crie um arquivo chamado consultar_todos.php e adicione as linhas abaixo:

<?php

$strConexao=”host=localhost user=postgres dbname=frigo2 password=frigo13579 port=5432″;

$conexao=pg_connect($strConexao);

if(!$conexao){

echo “Erro na conexcao: ” . pg_last_error($conexao);

}

?>

Agora uma dica muito importante, para que a conexão possa ser estabelecida no CentOS é necessário desativar o SELinux, que por padrão na instalação fica ativado, para desativa-lo vá na área de trabalho e no menu Sistema -> Administração -> Nível de Segurança e Firewall e selecione Desativado

Pronto sua configuração básica já vai estar funcionando.

Fonte: www.microcampnews.com.br

Firewall

O Linux, de uma forma geral, é relativamente imune a vírus, worms e trojans, que são a principal causa de invasões e dores de cabeça em geral no Windows. Isso não ocorre apenas porque o Windows é usado em mais máquinas e por isso um alvo maior, mas também porque os aplicativos disponíveis no Linux são, pela média, bem mais seguros.

Veja o caso do Apache, por exemplo. Ele é usado em uma percentagem muito maior de servidores que o IIS. Mesmo assim, o número de falhas críticas de segurança e invasões bem-sucedidas registradas contra servidores web rodando o IIS é bem maior do que nos mais numerosos servidores Apache.

Mesmo assim, brechas de segurança podem surgir onde menos se espera. Por exemplo, em 2004 foi descoberto um buffer overflow no servidor SSH, que poderia ser usado para desenvolver um exploit. Esta brecha não chegou a ser explorada, pois, assim que a possível vulnerabilidade foi descoberta, uma correção foi rapidamente disponibilizada e a notícia se espalhou pela web. Antes que alguém tivesse tempo de escrever um exploit, a maior parte dos servidores do mundo já estavam seguros.

A moral da história: é sempre muito melhor prevenir do que remediar, e a melhor forma de se proteger contra brechas deste tipo é manter um firewall ativo, permitindo apenas acesso aos serviços que você realmente deseja disponibilizar. Reduzindo os pontos vulneráveis, fica mais fácil cuidar da atualização dos serviços expostos e, assim, manter seu servidor seguro.

Imagine o firewall como a muralha que cercava muitas cidades na idade média. Mesmo que as casas não sejam muito seguras, uma muralha forte em torno da cidade garante a segurança. Se ninguém consegue passar pela muralha, não é possível chegar até as casas vulneráveis. Se, por acaso, as casas já são seguras, então a muralha aumenta ainda mais a segurança.

A idéia mais comum de firewall é como um dispositivo que fica entre o switch (ou hub) em que estão ligados os micros da rede e a internet. Nesta posição é usado um PC com duas placas de rede (eth0 e eth1, por exemplo), onde uma é ligada à internet e outra à rede local.

O firewall aceita as conexões vindas dos micros da rede local e roteia os acessos à internet. De dentro da rede você consegue acessar quase tudo, mas todas as tentativas de conexão vindas de fora são bloqueadas antes de chegarem aos clientes.

Imagine um micro com o Windows XP, onde o sistema acabou de ser instalado, sem nenhuma atualização de segurança e com o firewall inativo. Conectando este micro na internet diretamente, será questão de minutos até que ele comece a ser infectado por worms e se transforme em um zumbi a atacar outras máquinas ligadas a ele.

Entretanto, se houver um firewall no caminho, os pacotes nocivos não chegam até ele, de forma que ele fica em uma posição relativamente segura. Ele ainda pode ser infectado de formas indiretas, como ao acessar uma página que explore uma vulnerabilidade do IE ou ao receber um e-mail infectado através do Outlook, mas não mais diretamente, simplesmente por estar conectado à internet.

Opcionalmente, o servidor rodando o firewall pode ser equipado com um servidor Squid configurado para remover arquivos executáveis das páginas acessadas e um servidor Postfix, encarregado de bloquear mensagens infectadas, o que adiciona mais um nível de proteção.

Note que o firewall em si não protege contra vírus e trojans, mas apenas contra tentativas diretas de conexão. Ele cria uma barreira entre os micros da rede local e a internet, fazendo com que os recursos compartilhados na rede não sejam acessíveis de fora. No Linux, o firewall é incluído no próprio Kernel do sistema, na forma do Iptables, encontrado no Kernel 2.4 em diante. Isso garante um excelente desempenho e segurança em relação à maioria dos firewalls for Windows, que rodam em nível de aplicação.

Embora seja sempre mais seguro ter um servidor dedicado, você pode ter um nível de segurança muito bom simplesmente habilitando o firewall localmente. Todos os pacotes provenientes da internet passam primeiro pelo Iptables antes de serem encaminhados para os aplicativos. Por isso, um firewall local, bem configurado, garante uma segurança muito próxima à de um firewall dedicado.

Escrevendo um Script de Firewall

Existem muitos firewalls gráficos for Linux, como o GuardDog, o Shorewall e o Firestarter (que comento adiante). Eles variam em nível de facilidade e recursos, oferecendo uma interface amigável e gerando as regras do Iptables de acordo com a configuração feita. Você pode escolher entre usar o programa que melhor atenda suas necessidades ou configurar diretamente o Iptables com as regras desejadas. Neste caso, você pode formular as regras diretamente, definindo condições onde os pacotes serão aceitos ou recusados, como em:

# iptables -A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT

Estes comandos seguem uma sintaxe comum: tudo começa com o comando “iptables“, que é quem executará as opções incluídas no comando. Em seguida vem uma condição, indicada pela opção “-A”. Neste exemplo usei “INPUT -p tcp -s 192.168.0.0/255.255.255.0″, que se aplica a qualquer pacote de entrada (INPUT), utilizando o protocolo TCP (-p tcp), proveniente dos micros da rede local (192.168.0.0/255.255.255.0). Note que aqui estou especificando uma faixa de endereços e a máscara de sub-rede. No final, é preciso dizer o que fazer com os pacotes que se enquadrarem nesta situação, indicando uma ação. O “-j ACCEPT” diz que estes pacotes devem ser aceitos.

À primeira vista, isso parece bem complicado, assim como o arquivo de configuração original do Squid, com suas 3.000 e tantas linhas. Mas, as coisas ficam bem mais simples se começarmos com um script simples e formos incluindo novas regras aos poucos.

Este é um exemplo de script que pode ser usado em um desktop que simplesmente acessa a internet como cliente, sem rodar nenhum servidor, nem compartilhar a conexão com outros micros:

# iptables -A INPUT -i lo -j ACCEPT
# iptables -A INPUT -p tcp –syn -j DROP

A idéia aqui é que o micro possa acessar a internet sem que ninguém de fora possa invadi-lo de forma alguma. Esses dois comandos fazem isso da forma mais simples possível.

A primeira linha orienta o firewall a deixar passar os pacotes enviados através da interface de loopback (-i lo -j ACCEPT). É importante que esta linha (ou outra com o mesmo efeito) sempre seja usada, em qualquer script de firewall que termine bloqueando todas as conexões, pois no Linux a interface de loopback é usada para comunicação entre diversos programas. Para ter uma idéia, todos os programas gráficos a utilizam para se comunicarem com o X, os programas do KDE a utilizam para trocar mensagens entre si. Sem esta regra, muita coisa deixa de funcionar corretamente.

Depois de abrir o firewall para as mensagens locais, usamos a segunda regra para bloquear todas as novas conexões vindas de fora. O “–syn” faz com que o firewall aplique a regra apenas para tentativas de abrir novas conexões (alguém tentando acessar o servidor SSH que você esqueceu aberto, por exemplo), mas sem impedir que servidores remotos respondam a conexões iniciadas por você. Isso permite que você continue navegando e acessando compartilhamentos em outros micros da rede local, com poucas limitações.

Para não precisar ficar digitando os comandos cada vez que precisar reiniciar o micro, você pode incluí-los em um dos arquivos de inicialização do sistema. Nas distribuições derivadas do Debian, você pode colocá-los no final do arquivo “/etc/init.d/bootmisc.sh” e, nas derivadas do Red Hat, no arquivo “/etc/rc.d/rc.local“.

Essas duas regras podem ser usadas como base para criar o que chamo de firewall de bloqueio. Ele segue uma idéia bastante simples: você diz as portas que gostaria de abrir e ele fecha todas as demais. Ou seja, o firewall fecha por padrão todas as portas, com exceção das que você disser explicitamente que deseja manter abertas. Isso garante uma configuração de firewall bastante segura com um mínimo de dor de cabeça.

Você pode adicionar novas regras, abrindo portas, direcionando faixas de portas para micros da rede interna, fechando portas de saída, de forma a bloquear o uso de programas como o ICQ e o MSN e assim por diante.

Imagine que você está configurando o firewall do servidor da rede. Ele tem duas placas de rede, uma para a rede local e outra para a internet. Você precisa que ele fique acessível sem limitações dentro da rede local, mas quer manter tudo fechado para quem vem da internet.

Nesse caso, você poderia usar a regra que mostrei há pouco no seu script de firewall:

# Abre para uma faixa de endereços da rede local
iptables -A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT

O “192.168.0.0″ indica a faixa de endereços da rede local. A máscara “255.255.255.0″ indica que a última parte do endereço muda, ou seja, os micros da rede local usam endereços entre 192.168.0.1 e 192.168.0.254. Tudo o que vier deles (tanto TCP, quanto UDP, já que não indicamos o protocolo) é aceito.

Note que esta faixa de endereços não é roteável, ela simplesmente não existe na internet. Não existe a possibilidade de algum engraçadinho de outro estado tentar configurar seu micro para usar esta faixa de endereços e enganar a regra do firewall.

Como uma proteção adicional, as versões recentes do Iptables são capazes de ignorar pacotes aparentemente destinados a uma interface quando eles chegam em outra. Com duas placas, onde uma está ligada à rede local (usando a faixa 192.168.0.x) e outra à Internet, o firewall não aceitará que um pacote falseado, proveniente da Internet, com endereço de emissor “192.168.0.3″ (por exemplo), seja encaminhado a um micro da rede local, pois ele sabe que pacotes com este endereço de emissor devem chegar apenas pela placa ligada à rede local.

Essa mesma regra pode ser usada também para abrir o firewall para endereços ou faixas de endereços da internet. Imagine que você queira dar acesso aos micros da filial da sua empresa em Macapá, onde usam um link com o IP fixo 200.220.234.12. Você poderia abrir a faixa 200.220.234.0 ou apenas o IP 200.220.234.12, de forma que o firewall permitisse acessos vindos de lá, mas continuasse bloqueando o restante. Você pode abrir para várias faixas de endereços distintas, basta repetir a linha adicionando cada uma das faixas desejadas.

Imagine agora que este servidor foi instalado na sede de uma empresa para a qual você presta serviços. Você precisa acessá-lo de vez em quando para corrigir problemas, mas naturalmente quer fazer isso via internet, sem precisar se deslocar até lá. Você pode configurar o firewall para abrir a porta 22 usada pelo SSH adicionando a regra:

# Abre uma porta (inclusive para a internet)
iptables -A INPUT -p tcp –dport 22 -j ACCEPT

Note que esta regra abre a porta 22 para todo mundo. Lembre-se do exemplo do SSH: todo servidor disponível para a internet é um risco potencial de segurança, por isso só abra as portas para os servidores que você realmente for utilizar. O ideal seria usar um par de chaves, protegidas por uma passphrase para acessar o servidor e configurá-lo para não aceitar logins com senha (apenas com chaves), como vimos no capítulo sobre SSH.

Ao abrir várias portas, você pode utilizar o parâmetro “-m multiport” para especificar todas de uma vez, separadas por vírgula, sem precisar colocar uma em cada linha. Para abrir as portas 21, 22 e 6881 (bittorrent), por exemplo, você usaria a regra abaixo:

# Abre um conjunto de portas
iptables -A INPUT -m multiport -p tcp –dport 21,22,6881 -j ACCEPT

Se você presta suporte a partir de uma empresa que possui um link dedicado, com IP fixo, você pode tornar a regra mais específica, permitindo apenas o IP de onde você acessa:

# Abre uma porta para um IP específico
iptables -A INPUT -p tcp -s 200.231.14.16 –dport 22 -j ACCEPT

Em um micro doméstico, você pode abrir também as portas usadas pelo bittorrent (6881 a 6889) ou portas usadas por jogos multiplayer, por exemplo. Para abrir um intervalo de portas, use a regra:

# Abre um intervalo de portas
iptables -A INPUT -p tcp –dport 6881:6889 -j ACCEPT

Além de trabalhar com endereços IP, é possível criar regras baseadas também em endereços MAC. Isso permite adicionar uma camada extra de proteção ao criar regras para a rede local. Para isso, usamos o parâmetro “-m mac –mac-source”, seguido pelo endereço MAC da placa do host desejado. Para permitir que o host “192.168.1.100″ tenha acesso ao servidor, mas apenas se o endereço MAC da interface bater, você usaria uma regra como:

iptables -A INPUT -s 192.168.1.100 -m mac –mac-source 00:11:D8:76:59:2E -j ACCEPT

Note que agora, além do IP, especificamos o endereço MAC da placa. As duas regras são usadas em conjunto, de forma que o acesso é permitido apenas caso as duas informações estejam corretas. Isso dificulta as coisas para alguém que queira acessar o servidor trocando o IP de sua máquina. Você pode descobrir o MAC das máquinas da rede usando o próprio ifconfig ou o comando “arp -a”.

Note que limitar o acesso com base no endereço MAC adiciona uma camada extra de proteção, mas não é infalível. O endereço MAC pode ser trocado de forma quase tão simples quanto o endereço IP e, sniffando a rede, é possível descobrir os endereços IP e MAC dos micros com uma certa facilidade.

No Linux, você pode trocar o endereço MAC da placa de rede usando os comandos:

# ifconfig eth0 down
# ifconfig eth0 hw ether 00:11:D8:76:59:2E
# ifconfig eth0 up

Como vê, basta especificar o endereço desejado. O Iptables não é capaz de diferenciar máquinas com os endereços MAC falseados das reais, pois, se alguém desconectasse o micro 192.168.1.100 da rede e configurasse o seu para usar o mesmo IP e MAC, poderia acessar o servidor bipassando a regra de firewall. A única forma de ter uma segurança completa seria utilizar o SSH ou outro protocolo que utilize um algoritmo robusto de encriptação para o login e a transmissão dos dados.

Lembre-se de que o firewall é uma primeira barreira de proteção, mas não é uma garantia por sí só. É preciso combiná-lo com outras camadas de segurança para ter um servidor completamente seguro.

Outra limitação é que as regras baseadas em endereços MAC podem ser usadas apenas dentro da rede local. O endereço MAC é descartado do pacote quando ele é roteado para a Internet, ficando apenas o endereço IP. Ao acessar através de uma conexão compartilhada, todos os pacotes provenientes da Internet chegam com o endereço MAC do gateway da rede.

Este é um exemplo de script completo, incluindo algumas regras adicionais para evitar ataques comuns:

#!/bin/bash

iniciar(){

# Abre para uma faixa de endereços da rede local
iptables -A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT

# Abre uma porta (inclusive para a internet)
iptables -A INPUT -p tcp –dport 22 -j ACCEPT

# Ignora pings
iptables -A INPUT -p icmp –icmp-type echo-request -j DROP

# Protege contra IP spoofing (esta opção já vem ativada por padrão na
# maioria das distribuições atuais, mas não custa ter certeza)
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter

# Descarta pacotes malformados, protegendo contra ataques diversos
iptables -A INPUT -m state –state INVALID -j DROP

# Abre para a interface de loopback. Esta regra é essencial para que
# o KDE e outros programas gráficos funcionem adequadamente.
iptables -A INPUT -i lo -j ACCEPT

# Impede a abertura de novas conexões, efetivamente bloqueando o acesso
# externo ao seu servidor, com exceção das portas e faixas de endereços
# manualmente especificadas anteriormente. Bloqueia tudo.
iptables -A INPUT -p tcp –syn -j DROP

}

parar(){
iptables -F
echo “Regras de firewall desativadas”
}

case “$1″ in
“start”) iniciar ;;
“stop”) parar ;;
“restart”) parar; iniciar ;;
*) echo “Use os parâmetros start ou stop”
esac

A receber qualquer conexão, vinda de qualquer endereço, o firewall primeiro verifica todas estas regras, seqüencialmente, para decidir se o pacote passa ou não. Usando esse script de exemplo, teríamos o seguinte:

- Se o pacote vier da rede local, ele é aceito.
- Se o pacote for para porta 22 (do SSH), ele é aceito.
- Se for um ping, ele é recusado (de forma a dificultar um pouco para outros descobrirem que você está online).
- Pacotes danificados ou forjados (unclean) são recusados, protegendo os micros da rede interna.
- Se o pacote vier da sua própria máquina (um programa tentando mostrar alguma coisa na tela, por exemplo), ele é aceito.
- Se o pacote for uma resposta a uma conexão que você iniciou, como, por exemplo, o servidor do guiadohardware.net enviando a página do site que você está acessando, ele é aceito.
- Tentativas de conexão (toda conexão TCP é iniciada por um pacote syn) fora das condições especificadas acima são descartadas pelo firewall. A conexão nem sequer chega a ser estabelecida e o emissor não recebe qualquer resposta (DROP). Ele não sabe se o pacote foi recebido ou não, fica no vácuo, o que dá a impressão de que o seu micro nem está online.

Da forma como escrevi, o script suporta as funções “start”, “stop” e “restart”, e pode ser usado como um serviço de sistema. Salve-o dentro da pasta “/etc/init.d”, como em “/etc/init.d/firewall”, e marque a permissão de execução:

# chmod +x /etc/init.d/firewall

A partir daí, você pode ativar as regras usando o comando “/etc/init.d/firewall start” e fazer com que alterações dentro do script entrem em vigor com um “/etc/init.d/firewall restart”.

Se você está configurando um servidor dedicado remotamente, é importante que você teste o script antes de configurar o sistema para executá-lo automaticamente durante o boot. O motivo é simples: se houver alguma regra incorreta no script, que bloqueie seu acesso ao servidor, você poderá solicitar um reboot do servidor para que a configuração seja removida e você recupere o acesso. Entretanto, se o sistema for configurado para carregar o script durante o boot, o reboot não resolverá e você precisará abrir uma chamada de suporte, solicitando que um técnico se logue localmente no servidor e desative seu script (o que provavelmente resultará em uma taxa adicional).

Uma opção mais relaxada seria simplesmente colocar os comandos com as regras desejadas no final do arquivo “/etc/init.d/bootmisc.sh” ou “/etc/rc.d/rc.local”, mas isso não é tão recomendável, pois você perde a possibilidade de reiniciar o firewall rapidamente depois de alterar as regras.

Assim como nas regras do Squid, cada pacote que chega pela rede precisa passar por todas as regras, para que o firewall possa decidir o que fazer com ele. Quando aceito por uma das regras, ele é imediatamente encaminhado ao aplicativo, sem passar pelas demais. Por isso é necessário sempre colocar as regras mais restritivas por último, de preferência concluindo o script com uma regra que bloqueia todos os pacotes de entrada.

Outra dica é que você pode incluir os comandos para compartilhar a conexão e ativar o proxy transparente (que também são regras de firewall) no script, fazendo que ele desempenhe simultaneamente as duas funções. Nesse caso, tome o cuidado de sempre colocar as regras que compartilham a conexão e ativam o proxy transparente antes das regras que bloqueiam conexões.

Este é um exemplo de script de firewall que inclui as regras para compartilhar a conexão e ativar o proxy transparente. Ao usá-lo, comente as linhas que não se aplicam à sua instalação:

#!/bin/bash

iniciar(){

# Compartilha a conexão
modprobe iptable_nat
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -p tcp –tcp-flags SYN,RST SYN -m tcpmss –mss 1400:1536 \
-j TCPMSS –clamp-mss-to-pmtu
echo “Compartilhamento ativado”

# Proxy transparente
iptables -t nat -A PREROUTING -i eth1 -p tcp –dport 80 -j REDIRECT –to-port 3128
echo “Proxy transparente ativado”

# As regras de firewall que vimos há pouco:
iptables -A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT
iptables -A INPUT -p tcp –dport 22 -j ACCEPT
iptables -A INPUT -p icmp –icmp-type echo-request -j DROP
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp –syn -j DROP

}

parar(){
iptables -F
iptables -t nat -F
echo “Regras de firewall e compartilhamento desativados”
}

case “$1″ in
“start”) iniciar ;;
“stop”) parar ;;
“restart”) parar; iniciar ;;
*) echo “Use os parâmetros start ou stop”
esac

Outra dica importante são os comandos usados para limpar as regras do Iptables. É necessário executá-los sempre que você fizer alterações no seu script de firewall e quiser executá-lo novamente para que as novas regras entrem em vigor. No primeiro script de exemplo, por exemplo, uso o comando “iptables -F” como parte da função “stop”, que desativa o firewall. No segundo script, incluí também o “iptables -t nat -F”.

iptables -F: Limpa a tabela principal do iptables, onde vão os comandos para abrir e fechar portas, que vimos até aqui.

iptables -t nat -F: Limpa a tabela nat, que é usada por regras que compartilham a conexão e fazem forwarding de portas, como por exemplo:

iptables -t nat -A PREROUTING -i eth0 –dport 22 -j DNAT –to-dest 192.168.1.2

Todas as regras do Iptables que levam “-t nat” são armazenadas nesta segunda tabela, que precisa ser zerada separadamente. A idéia é que você pode limpar as regras principais do firewall sem desabilitar o compartilhamento da conexão e vice-versa.

iptables -L: Este comando lista a configuração atual, sem alterar nada. É interessante executá-lo depois de fazer alterações na configuração do firewall, para ter certeza que as regras surtiram o efeito esperado. Para ver as regras de forwarding e compartilhamento, use também o “iptables -t nat -L“

Forwarding de Portas

Você deve lembrar que, ao compartilhar uma conexão entre vários micros, apenas o servidor que está com a conexão recebe conexões vindas da internet. Os micros da rede local acessam via NAT e apenas recebem respostas para conexões iniciadas por eles.

Mas, imagine que você queira que um servidor web, escutando na porta 80 do micro 192.168.0.3 da rede local, fique disponível para a internet. Como o servidor é o único com um IP válido na internet, a única forma de fazer com que o 192.168.0.3 fique acessível é fazer com que o servidor “passe a bola” para ele ao receber conexões na porta 80. É justamente isso que fazemos ao configurar o forwarding de portas.

Uma vez feita a configuração, sempre que o servidor receber uma conexão qualquer na porta 80 (ou qualquer outra definida por você), ele a repassará para o micro 192.168.0.3. Isso é feito de forma completamente transparente, forma que o emissor nem percebe que quem respondeu à solicitação foi outro servidor.

Essa opção pode ser usada também para permitir que os micros da rede local fiquem com as portas do bittorrent abertas (de forma a baixar arquivos com um melhor desempenho), rodem servidores de games online ou qualquer outra tarefa onde seja necessária manter determinadas portas TCP ou UDP abertas. A limitação é que continua existindo uma única porta 80, uma única porta 21, etc. de forma que apenas um micro da rede interna pode receber cada porta de cada vez.

Veja um exemplo de como redirecionar as portas 6881 a 6889 usadas pelo Bittorrent para o micro 192.168.0.10 da rede local:

# Redireciona uma faixa de portas para um micro da rede local.
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p tcp -i eth0 –dport 6881:6889 -j DNAT \
–to 192.168.0.10
iptables -t nat -A POSTROUTING -d 192.168.0.10 -j SNAT –to 192.168.0.1

Esta regra é um pouco mais complexa, pois trabalha em duas fases. A primeira faz com que o servidor encaminhe todas as conexões que receber na interface e porta especificada para o micro da rede local e a segunda faz com que os pacotes de resposta enviados por ele posam ser encaminhados de volta. Para que ambas funcionem, é necessário usar o comando “echo 1 > /proc/sys/net/ipv4/ip_forward”, que ativa o forwarding de portas. É o mesmo comando que usamos ao compartilhar a conexão.

Nos parâmetros que coloquei em negrito, a “eth0″ é a placa de internet, onde chegam os pacotes, a “6881:6889″ é a faixa de portas que estão sendo redirecionadas e o “192.168.0.10″ é o IP do micro dentro da rede local que passa a receber as conexões destinadas a ela. Na segunda regra, temos repetido o IP do micro na rede local e, em seguida, o “192.168.0.1″ que indica o IP do servidor, dentro da rede local.

Para redirecionar uma única porta, ao invés de uma faixa, basta citar a porta sem usar os “:”, como em:

# Redireciona uma única porta para um micro da rede local.
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p tcp -i eth0 –dport 22 -j DNAT –to 192.168.0.10
iptables -t nat -A POSTROUTING -d 192.168.0.10 -j SNAT –to 192.168.0.1

É possível ainda indicar uma lista de portas (usando a opção -m multiport), como em:

# Redireciona um conjunto de portas
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p tcp -i eth0 -m multiport –dport 21,22,80 -j DNAT \
–to-dest 192.168.0.10
iptables -t nat -A POSTROUTING -d 192.168.0.10 -j SNAT –to 192.168.0.1

Note que nos três exemplos usei o parâmetro “-p tcp”. Ele é necessário, mas faz com que a regra se aplique apenas a portas TCP. Caso você precise fazer forwarding de portas UDP, deve alterar o protocolo dentro da regra, como em:

# Redireciona uma porta UDP
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p udp -i eth0 –dport 53 -j DNAT –to 192.168.0.10
iptables -t nat -A POSTROUTING -d 192.168.0.10 -j SNAT –to 192.168.0.1

Bloquiando Portas de Saída

Mais um uso importante para o firewall é bloquear portas de saída, ou seja, bloquear portas no sentido rede local > internet. Isso permite bloquear o uso de determinados programas que utilizem estas portas.

O MSN, por exemplo, utiliza originalmente a porta 1863. Nas versões recentes ele é capaz de se conectar também através da porta 80 (ou através de sites como o meebo.com, que permitem acessar o MSN diretamente através do navegador). Por isso, ao bloquear a porta 1863, os clientes podem continuar conseguindo se conectar, porém, você obriga o tráfego a passar pela porta 80, onde tem a chance de fazê-lo passar por um servidor Squid, configurado como proxy transparente. Isso permite logar os acessos ou sabotar o sistema de autenticação do MSN, bloqueando os domínios “messenger.hotmail.com” e “webmessenger.msn.com”, além de outros sites que ofereçam clientes via web.

Hoje em dia, cada vez mais programas são capazes de acessar a Web através da porta 80, 443 (https) ou via proxy, o que torna difícil bloqueá-los. Em muitos casos, é preciso usar uma combinação de portas fechadas no firewall, bloqueio a endereços IPs específicos e bloqueio de determinados domínios no Squid.

Ao criar as regras do Iptables, existem duas opções. Bloqueando a porta para “FORWARD”, você impede o acesso a partir dos micros da rede local, que acessam através da conexão compartilhada pelo servidor. Bloqueando para “OUTPUT”, a porta é bloqueada no próprio micro onde o firewall está ativo. Você pode bloquear as duas situações, duplicando a regra:

iptables -A OUTPUT -p tcp –dport 1863 -j REJECT
iptables -A FORWARD -p tcp –dport 1863 -j REJECT

Você pode ainda bloquear intervalos de portas, separando-as por “:”, como em:

iptables -A FORWARD -p tcp –dport 1025:65536 -j REJECT

Como estamos criando regras para os micros da rede local e não para possíveis invasores provenientes da Internet, é aconselhável usar a regra “REJECT” ao invés de “DROP”. Caso contrário, os programas nos clientes sempre ficarão muito tempo parados ao tentar acessar portas bloqueadas, o que vai gerar reclamações e um certo overhead de suporte.

Você pode descobrir facilmente quais portas de saída são utilizados por cada programa fazendo buscas no Google, mas tentar bloquear um a um todos os programas indesejados acaba sendo tedioso. Ao invés disso, você pode experimentar um solução mais radical: inverter a lógica da regra, bloqueando todas as portas de saída e abrindo apenas algumas portas “permitidas”.

O mínimo que você precisa abrir neste caso são as portas 80 e 53 (dns). A partir daí, você pode abrir mais portas, como a 21 (ftp), 25 (smtp), 110 (pop3) e assim por diante. Um exemplo de configuração neste caso seria:

iptables -A FORWARD -p udp -i eth1 –dport 53 -j ACCEPT
iptables -A FORWARD -p tcp -i eth1 –dport 80 -j ACCEPT
iptables -A FORWARD -p tcp -i eth1 –dport 21 -j ACCEPT
iptables -A FORWARD -p tcp -i eth1 -j LOG
iptables -A FORWARD -p tcp -i eth1 -j REJECT

Veja que todas as regras especificam a interface da rede local (eth1 no exemplo), de onde serão recebidas as conexões dos clientes. Note que não incluí nenhum bloqueio para forwarding de pacotes provenientes da interface eth0 (da internet), pois a idéia é bloquear diretamente as requisições dos clientes e não as respostas. Em uma conexão TCP típica, o cliente envia a requisição na porta TCP usada pelo serviço, mas recebe a resposta em uma porta aleatória. Este é um exemplo de entrada no log do Iptables que mostra a resposta a uma conexão http normal. Veja que ela está endereçada à porta 45159 do cliente:

IN=eth0 OUT=eth1 SRC=64.233.169.99 DST=192.168.0.10 LEN=40 TOS=0×00 PREC=0×00 TTL=239 ID=36813 PROTO=TCP SPT=80 DPT=45159 WINDOW=8190 RES=0×00 ACK FIN URGP=0

No caso da porta 53 (DNS) estou especificando o protocolo UDP, ao invés de TCP, pois as requisições são feitas usando portas UDP para ganhar tempo. Embora os servidores DNS escutem tanto na porta 53 TCP, quanto UDP, na prática quase sempre é usada a porta 53 UDP, pois o tempo de resposta é menor. No UDP a requisição é simplesmente respondida da forma mais rápida possível, enquanto que no TCP é necessário abrir e encerrar a conexão.

A regra “iptables -A FORWARD -j LOG” é uma boa opção durante a fase de testes, pois ela faz com que o Iptables logue todos os pacotes que forem encaminhados (tanto envio, quanto resposta), permitindo que você verifique o que está ocorrendo quando algo não estiver funcionando. Você pode acompanhar o log usando o comando “dmesg”.

Colocado nesta posição (depois das regras que autorizam as conexões nas portas 53 e 80), ele vai mostrar apenas as requisições bloqueadas pelo firewall, dando-lhe a chance de acompanhar os acessos dos clientes e permitir portas adicionais sempre que necessário.

Por exemplo, esta estrada (no log) mostra uma tentativa de conexão de um cliente MSN rodando no micro “192.168.0.10″ que foi bloqueada pelo firewall:

IN=eth1 OUT=eth0 SRC=192.168.0.10 DST=207.46.28.77 LEN=60 TOS=0×00 PREC=0×00 TTL=63 ID=21328 DF PROTO=TCP SPT=38119 DPT=1863 WINDOW=5840 RES=0×00 SYN URGP=0

A opção “DTP” indica a porta usada. Se quisesse autorizar o uso do programa, você adicionaria a regra “iptables -A FORWARD -p tcp -i eth1 –dport 1863 -j ACCEPT” em seu script.

Outra opção, para não precisar abrir tantas portas e ter um melhor controle sobre o tráfego de saída é usar um servidor Squid configurado como proxy transparente (interceptando o tráfego da porta 80) e rodar servidores locais para DNS e e-mail (você pode configurar um servidor Postfix como sistema satélite, de forma que ele envie os e-mails dos usuários da rede usando o SMTP do provedor), de forma que qualquer acesso precise necessariamente passar por algum dos serviços ativos no servidor, sujeito a log e aos bloqueios que configurar.

Neste caso, desabilite o compartilhamento da conexão (ou bloqueie o forward de todas as portas) e configure os clientes para utilizarem o IP do servidor como DNS, servidor SMTP, POP e outros serviços que tenha ativado. Mesmo ao ser configurado como proxy transparente, o Squid continua funcionando como um proxy tradicional, através da porta 3128. Você pode configurar clientes de FTP e outros programas com suporte a proxy para acessarem através dele. A vantagem sobre o acesso direto é que ao passar pelo proxy, tudo fica registrado e todo acesso precisa passar pelos filtros de domínios, formatos de arquivos, limitação de banda, etc. definidos por você.

Complementando o bloqueio de portas, você pode também bloquear o acesso de determinados endereços IP, como em:

# Bloqueia o acesso à web a partir de um determinado IP
iptables -A FORWARD -p tcp -s 192.168.0.67 -j REJECT

Esta regra deve ir logo no início do script, antes das regras que abrem portas de saída, caso contrário não surtirá efeito. Lembre-se de que o Iptables processa as regras seqüencialmente: se uma compartilha a conexão com todos os micros da rede, não adianta tentar bloquear para determinados endereços depois. As regras com as exceções devem sempre vir antes da regra mais geral.

Bloquiando Domínios

É possível ainda bloquear ou permitir com base no domínio, tanto para entrada quanto saída. Isso permite bloquear sites e programas diretamente a partir do firewall, sem precisar instalar um servidor Squid e configurá-lo como proxy transparente. Nesse caso, usamos o parâmetro “-d” (destiny) do Iptables, seguido do domínio desejado.

Para bloquear os acessos ao Orkut, por exemplo, você usaria as regras:

iptables -A OUTPUT -d orkut.com -j DROP
iptables -A FORWARD -d orkut.com -j DROP

A primeira linha bloqueia pacotes de saída destinados ao domínio, ou seja, impede que ele seja acessado a partir da própria máquina local. A segunda linha bloqueia o forward de pacotes destinados a ele (domínio), ou seja, impede que outras máquinas da rede local, que acessam através de uma conexão compartilhada acessem-no.

Se for paranóico, você pode usar também a regra:

iptables -A INPUT -s orkut.com -j DROP

Esta regra impede também que qualquer pacote proveniente do orkut.com chegue até a sua máquina. Como disse, é apenas para paranóicos .

Originalmente, o Iptables sabia trabalhar apenas com endereços IP. A possibilidade de criar regras baseadas em domínios são um recurso um pouco mais recente, onde o firewall faz um lookup do domínio, para descobrir qual é o IP atual e assim poder bloqueá-lo. Você pode verificar o IP usado pelo servidor de um determinado domínio usando o comando “dig” (que no Debian faz parte do pacote “dnsutiuls”), como em:

$ dig orkut.com

A vantagem de criar as regras do firewall baseado em domínios é que a regras são automaticamente atualizadas caso o servidor do site mude de endereço.

Ao bloquear o “orkut.com” no Iptables, você automaticamente bloqueia o “www.orkut.com” ou qualquer outra variante ou outros domínios que levem ao mesmo servidor. A principal limitação é que a regra não se aplica a subdomínios hospedados em diferentes servidores. Por exemplo, você pode bloquear o domínio “uol.com.br”, mas isso não bloqueará o “tvuol.uol.com.br”, que é hospedado em um servidor separado. Em casos como este, a única solução é bloquear ambos.

Resumo das Regras de Iptables

Depois desta rodada inicial de exemplos, nada melhor do que um guia mais detalhado dos parâmetros suportados pelo Iptables. Escrever regras de firewall é quase como aprender um novo dialeto. Existem muitas combinações possíveis entre os parâmetros disponíveis e “regras de concordância” que determinam o que funciona e o que não. Imagine que ao escrever uma nova regra, você está explicando uma idéia. Tente ser claro para que seja entendido .

Parâmetros do Iptables:

-A INPUT: Especifica que a regra se aplica a pacotes de entrada, ou seja, pacotes recebidos pelo servidor, em qualquer interface.

-A OUTPUT: A regra se aplica a pacotes de saída, transmitidos pelo próprio servidor.

-A FORWARD: Este parâmetro é usado ao compartilhar a conexão com a internet, permitindo que os micros da rede local acessem através do servidor. Os pacotes de outros micros, encaminhados pelo servidor, são tratados como “FORWARD”, diferentemente dos pacotes transmitidos pelo próprio servidor, que são tratados como “OUTPUT”. Você pode definir regras diferentes para cada situação.

-p tcp: Especifica que a regra se aplica a pacotes TCP, o que é o mais comum.

-p udp: Alguns serviços usam também portas UDP. Um bom exemplo são os servidores DNS, que escutam tanto na porta 53 TCP, quanto na 53 UDP. Este parâmetro permite definir regras que se aplicam a estes casos, abrindo ou fechando as portas UDP, como em:

iptables -A INPUT -p udp –dport 53 -j ACCEPT

A maioria das regras do Iptables exigem que você especifique o protocolo, fazendo com que você tenha que repetir a regra caso queira abrir uma porta simultaneamente para TCP e UDP. Ao executar algo como “iptables -A INPUT –dport 53 -j ACCEPT” (sem especificar o protocolo), você receberá um erro como:

iptables v1.3.3: Unknown arg `–dport’
Try `iptables -h’ or ‘iptables –help’ for more information.

Como as portas UDP também são usadas por alguns serviços, é muito comum bloquear as portas de 1 a 1024 UDP, autorizando apenas as portas que realmente devem ficar abertas, como em:

iptables -A INPUT -p udp –dport 53 -j ACCEPT
iptables -A INPUT -p udp –dport 1:1024 -j DROP

Note que você nunca deve fechar todas as portas UDP, pois as portas altas são usadas aleatoriamente para pacotes de resposta para DNS e diversos outros protocolos. Você pode fazer o teste: use a regra “iptables -A INPUT -p udp -j DROP” e você não conseguirá mais navegar até desativar o firewall usando o comando “iptables -F”.

Alguns administradores mais paranóicos fecham todas as portas UDP até a 32000, por exemplo. Não existem muitos problemas em fechar uma faixa maior de portas, desde que você sempre deixe uma larga faixa de portas altas abertas, de forma a receber os pacotes de resposta.

Ao contrário do TCP, não é possível criar uma regra genérica para permitir todos os pacotes de resposta UDP (como a “iptables -A INPUT -p tcp –syn -j DROP”), pois no UDP não são abertas conexões. Os pacotes são simplesmente transmitidos diretamente, sem aviso prévio.

-p icmp: Além do TCP e UDP, existe o protocolo ICMP, usado para pacotes de controle, pings e envio de mensagens. Um exemplo de uso é a regra para desativar a resposta a pings que vimos há pouco. Na verdade ela atua bloqueando o pedido de ping antes que ele seja repassado ao sistema:

iptables -A INPUT -p icmp –icmp-type echo-request -j DROP

-i eth0: A opção “-i” permite definir a interface onde os pacotes devem ser recebidos ou enviados. Por exemplo, usar uma regra como:

iptables -A INPUT -p tcp -j REJECT

… simplesmente desconectaria seu micro da rede, pois bloquearia comunicações em qualquer interface. Porém, se você especificasse a interface, ele bloquearia apenas pacotes recebidos através dela, como em:

iptables -A INPUT -i eth2 -p tcp -j REJECT

O mesmo se aplica quando você quer permitir conexões em determinadas portas, mas apenas a partir da placa de rede local. Para permitir conexões via SSH apenas a partir da placa eth1, você poderia usar:

iptables -A INPUT -i eth1 -p tcp –dport 22 -j ACCEPT

-o eth0: É similar ao parâmetro “-i”, mas especifica uma interface de saída. Este parâmetro é menos usado, pois normalmente nos preocupamos em impedir que o firewall aceite conexões em determinadas portas, ao invés de tentar interceptar as respostas. Mas esta opção pode ser útil em casos em que você precisa fechar uma porta de saída apenas para determinada interface. Este é um exemplo de uso, onde bloqueio pacotes de saída na porta 1863 apenas para a placa eth1:

iptables -A OUTPUT -p tcp -o eth1 –dport 1863 -j DROP

–dport ou –destination-port: Especifica uma porta. O uso mais comum para esta opção é para abrir portas de entrada (e depois aplicar uma regra que fecha as demais), como na regra que abre para conexões na porta 22, que mostrei no exemplo anterior.

-s (source): O parâmetro “-s” permite especificar um endereço IP ou domínio de origem, de forma a aceitar ou recusar as conexões. Embora seja muito fácil forjar endereços IP dentro da rede local, as coisas são muito mais complicadas na Internet. Permitir o acesso a determinadas portas (como a do SSH) apenas para determinados endereços, ou faixas de endereços, é uma medida de segurança interessante em muitas situações.

Este é um exemplo de regra, que abre a porta 631 apenas para hosts dentro da faixa e máscara especificada:

iptables -A INPUT -p tcp -s 72.232.35.0/255.255.255.248 -j ACCEPT

-d (destiny): Destinado ao endereço IP ou domínio citado. É muito usado ao bloquear o acesso a determinados sites a partir dos micros da rede local, como, por exemplo:

iptables -A FORWARD -d torrentreactor.net -j REJECT

-m mac –mac-source 00:11:D8:76:59:2E: Esta é a regra que permite especificar endereços MAC dentro de regras do Iptables que vimos há pouco. Ela é uma forma de dificultar o uso de endereços IP falseados para ganhar acesso ao servidor, pois permite relacionar o IP ao endereço MAC da placa instalada. Lembre-se, porém, que ela só pode ser usada em rede local e que os endereços MAC são quase tão fáceis de falsear quanto os endereços IP. Um exemplo de uso seria:

iptables -A INPUT –dport 22 -m mac –mac-source 00:11:D8:76:59:2E -j ACCEPT

–syn: Cria uma regra válida apenas para novas conexões, não impedindo que o outro micro responda a conexões iniciadas pelo servidor, como em:

iptables -A INPUT -p tcp –syn -j DROP

-j: É usado no final de cada regra, especificando uma ação, que pode ser:

-j ACCEPT : Aceita o pacote. Ele é encaminhado ao destino sem passar pelas demais regras.

-j REJECT : Rejeita educadamente o pacote, enviando um pacote de resposta ao emissor. Quando uma porta está fechada em modo reject, o emissor recebe rapidamente uma resposta como “connect to host 192.168.1.1 port 22: Connection refused”.

-j DROP: O DROP é mais enfático. O pacote é simplesmente descartado, sem aviso. O emissor fica um longo tempo esperando, até que eventualmente recebe um erro de time-out.

-j LOG: Este último parâmetro permite logar conexões. É interessante usar esta regra principalmente em portas muito visadas, como a do SSH, pois assim você tem uma lista de todos os endereços que acessaram seu servidor na porta especificada. Para ativar o log, você deve duplicar a regra que abre a porta, usando a opção “-j LOG” na primeira e “-j ACCEPT” na segunda, como em:

iptables -A INPUT -p tcp –dport 22 -j LOG
iptables -A INPUT -p tcp –dport 22 -j ACCEPT

As mensagens são gravadas no arquivo “/var/log/messages” de forma bastante detalhada, incluindo a data e hora da conexão, o IP e MAC do micro que fez a conexão (SRC), além da porta (DPT). Você pode ver o mesmo log, porém com as entradas escritas de forma resumida, usando o comando “dmesg”.

Jun 29 15:49:46 spartacus kernel: IN=eth0 OUT= MAC=00:e0:7d:9b:f8:01:00:15:00:4b:68:db:08:00 SRC=192.168.0.2 DST=192.168.0.1 LEN=52 TOS=0×00 PREC=0×00 TTL=64 ID=32704 DF PROTO=TCP SPT=56848 DPT=22 WINDOW=2164 RES=0×00 ACK URGP=0

Não se assuste com o volume, pois o log inclui todas as tentativas de conexão. O fato de um determinado IP ter aberto uma conexão com a porta 22 do seu servidor, não significa que o usuário realmente obteve acesso ao SSH. Ele pode ter recebido o prompt para digitar a senha, mas isso não significa que ele realmente conseguiu fazer login.

Note que alterar a ordem das regras altera o resultado. Em caso de duas regras conflitantes, vale a que vem primeiro. Por exemplo, ao usar:

iptables -A INPUT -p tcp -j REJECT
iptables -A INPUT -p tcp –dport 22 -j ACCEPT

… a porta 22 permanecerá fechada, pois os pacotes serão descartados pela primeira regra, sem terem chance de serem autorizados pela segunda. É justamente por isso que é sempre necessário colocar as regras menos restritivas primeiro, declarando as portas autorizadas, para só então fechar as demais.

O mesmo se aplica ao logar transmissões. Se você usar algo como:

iptables -A INPUT -p tcp –dport 22 -j ACCEPT
iptables -A INPUT -p tcp –dport 22 -j LOG

… o log não funcionará, pois os pacotes destinados à porta 22 serão aceitos pela primeira regra e não passarão pela segunda, que faz o log. As regras que fazem log devem sempre vir antes das regras que autorizam as conexões.

Testando com o Nmap

Depois de terminar, você pode testar o firewall usando o Nmap, a partir de outro micro da rede local ou da internet, para procurar vulnerabilidades. O Nmap é um pacote bastante popular. No Debian você pode instalá-lo pelo apt-get.

Caso a regra que bloqueia tudo esteja ativa, você vai ter o seguinte como resultado:

# nmap -sS -v 192.168.0.33

Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-04-03 10:12 BRT
Host 192.168.0.33 appears to be down, skipping it.
Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
Nmap run completed — 1 IP address (0 hosts up) scanned in 12.053 seconds

Ou seja, o Nmap não consegue sequer perceber que o PC está realmente lá, e avisa: “Se você realmente tem certeza que ele está online, experimente usar a opção -P0″, o que não vai mudar muita coisa:

# nmap -P0 -v 192.168.0.33

Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-04-03 10:14 BRT
Host 192.168.0.33 appears to be up … good.
Initiating SYN Stealth Scan against 192.168.0.33 at 10:14
The SYN Stealth Scan took 1361 seconds to scan 1659 ports.
All 1659 scanned ports on 192.168.0.33 are: filtered
Nmap run completed — 1 IP address (1 host up) scanned in 1360.579 seconds

Como todas as portas estão em modo drop, onde o firewall simplesmente descarta os pacotes sem confirmar o recebimento, o teste demora muito tempo, quase 27 minutos para escanear apenas as primeiras 1659 portas. Uma varredura completa, em todas as 65 mil portas, levaria 17 horas e meia, isso executando o teste via rede local. Via internet, a varredura levaria vários dias e, mesmo assim, só apareceriam as portas manualmente abertas no seu script.

Fonte: Livro Redes e Servidores Linux do Carlos Morimoto

Usando o VMware Server

Em versões anteriores, o VMware era um produto caro. Com a concorrência de outros produtos, a VMware passou a disponibilizar gratuitamente o VMware Player, seguido do VMware Server. O VMware Server é tão completo e flexível que atende não apenas a quem quer usá-lo em um servidor, mas também aos usuários normais, que querem rodar diversos sistemas operacionais no mesmo micro. Se você já é usuário do VMware Workstion, ou do VMware Player, pode muito bem migrar para ele.

Com o lançamento de processadores cada vez mais rápidos e o uso de volumes cada vez maiores de memória RAM, passou a fazer cada vez mais sentido agrupar diversos servidores em uma única máquina, utilizando algum sistema de virtualização.

A virtualização é obtida inserindo uma camada intermediária entre o sistema rodando dentro da máquina virtual e o hardware da máquina, simulando uma máquina completa. O software de virtualização fica então responsável por gerenciar todos os recursos do hardware, incluindo interrupções e endereços de memória, de forma que os sistemas dentro das máquinas virtuais possam trabalhar como se cada um tivesse uma máquina inteira reservada para si.

O sistema principal neste caso passa a ser chamado de host (hospedeiro) e os sistemas que estão rodando dentro da máquina virtual são chamados de “guests” (convidados). Cada um deles acha que tem um PC completo para si, enquanto na verdade está rodando dentro de uma “matrix”, na máquina virtual:

Um sistema de virtualização permite dividir um único PC em diversas máquinas virtuais independentes, sendo que cada uma pode rodar um sistema operacional diferente. As máquinas virtuais compartilham os recursos da máquina real, dentro dos limites de uso de memória e de espaço em disco estabelecidos por você.

Em versões anteriores, o VMware era um produto caro. A versão destinada a estações de trabalho (o VMware Workstation) custava US$ 79 e o VMware GSX (a versão para servidores) custava algumas centenas de dólares.

Com a concorrência de outros produtos, a VMware passou a disponibilizar gratuitamente o VMware Player, uma versão reduzida do VMware Workstation. Em 2006 foi disponibilizado o VMware Server, uma versão surpreendentemente completa, que permite não apenas executar as máquinas virtuais, mas também criá-las, configurá-las e fazer toda a administração, sem limitações.

O VMware Server é tão completo e flexível que atende não apenas a quem quer usá-lo em um servidor, mas também aos usuários normais, que querem rodar diversos sistemas operacionais no mesmo micro. Se você já é usuário do VMware Workstion, ou do VMware Player, pode muito bem migrar para ele.

Você pode encontrar as dicas gerais de como instalá-lo e criar as máquinas virtuais no meu tutorial anterior: http://www.guiadohardware.net/tutoriais/vmware-server/

A dica de hoje é sobre o VMware Server 2.0, que já está na versão Beta 2. Embora ainda esteja em desenvolvimento, ele já é bastante estável.

A principal novidade é uma nova interface de administração, batizada de VMware Infrastructure (VI). Ela permite que todas as funções das máquinas virtuais, incluindo a configuração das máquinas virtuais e o acesso ao console sejam acessadas através do próprio navegador, combinando as funções do VMware Mui e do VMware Server Console, usados nas versões anteriores:

A interface pode ser tanto acessada via HTTP quanto via HTTPS, usando o próprio navegador. Se você está usando o VMware Server em sua máquina local, acesse através do “http://127.0.0.1“, caso contrário use o HTTPS para ativar o uso da encriptação, como em “https://gdhn.com.br“. Assim como na versão 1.4, o login pode ser feito usando qualquer conta no servidor que tenha acesso às máquinas virtuais. Para ter acesso irrestrito, use o root:

Para acessar o console usando o navegador é necessário instalar um plugin, que é oferecido da primeira vez que você tenta acessá-lo. Diferente dos antigos plug-ins em Active-X, que foram tão usados na época do IE 6, o plug-in do VMware está disponível também na forma de uma extensão para o Firefox, que pode ser usada também em clientes Linux.

O plug-in é na verdade uma versão completa do Server Console, modificada de forma a facilitar a instalação. Clicando sobre a janela dentro da interface de gerenciamento, o console é aberto em uma nova janela. Como ele continua utilizando a mesma interface de acesso a vídeo do VMware Server Console, o desempenho é similar:

O acesso via navegador pode não fazer muito sentido se você usa o VMware Server localmente, mas é uma grande melhoria para quem o instala em um servidor central e acessa as máquinas virtuais remotamente. Em vez de precisar instalar o VMware Server Console em cada máquina de onde for acessar o servidor, você precisa apenas instalar o plug-in.

Como de praxe, você pode utilizar diversas máquinas virtuais simultaneamente, limitado apenas aos recursos da máquina e ao limite “físico” de 64 VMs simultâneas do VMware Server.

Se você está utilizando o VMware Server 1.4, pode remover a versão antiga usando o comado “vmware-uninstall.pl”, que se encarrega de parar o serviço e remover os componentes:

# vmware-uninstall.pl

Os arquivos do VMware Server 2.0 Beta estão disponíveis no: http://www.vmware.com/beta/server/. Quando a versão final estiver disponível, a página será movida para o http://www.vmware.com/download/server/. Na página estão disponíveis tanto a versão para sistemas de 32 bits quanto a de 64 bits:

Em vez de três pacotes separados, temos agora apenas dois componentes. O pacote “VMware-server”, que é o componente principal e o “VMware-vix”, que contém a engine da interface de administração.

Estão disponíveis também versões para o Windows quanto para Linux, atendendo a usuários de ambos os sistemas. A versão Windows é instalada da forma tradicional, no estilo “next, next, finish”, mas a versão Linux exige alguns passos adicionais, já que é desenvolvida de forma a ser instalável em qualquer distribuição e para permitir o uso em servidores sem interface gráfica instalada, daí o instalador em modo texto e o processo de instalação relativamente manual.

Baixe os dois arquivos para a mesma pasta e descompacte-os, como em:

# tar -zxvf VMware-server-e.x.p-84186.i386.tar.gz
# tar -zxvf VMware-vix-e.x.p-84186.i386.tar.gz

Acesse a pasta “vmware-server-distrib/” e rode o script “vmware-install.pl”. Desde que você tenha descompactado os dois arquivos no mesmo diretório, o script de encarregará de instalar também o VMware-vix automaticamente.

# vmware-server-distrib/
# ./vmware-install.pl

Uma das preocupações dos desenvolvedores foi ampliar o volume de módulos pré-compilados incluídos no pacotes principal, que correspondem à maior parte dos 400 MB do download. Mesmo assim, ainda é necessário ter os headers do Kernel e os compiladores para conseguir instalá-lo nas distribuições não atendidas pelos módulos pré-compilados. Além do vmmon, o instalador agora gera dois novos módulos, o vmci e o vsock.

Perto do final da instalação, o instalador pergunta sobre as portas que serão usadas para o acesso web, via HTTP e HTTPS. Se você está instalando o VMware Server em sua máquina de trabalho, pode simplesmente usar as portas padrão (80 e 443) para facilitar o acesso, mas se você o está instalando em um servidor dedicado, que já possui um servidor web ativo, é importante alterar as portas usadas, caso contrário o servidor web usado pelo VMware irá conflitar com o servidor web já existente, com resultados variados:

Please specify a port for standard http connections to use [80]: 8080
Please specify a port for secure http (https) connections to use [443]: 40443

Como de praxe, ao especificar portas diferentes do padrão, você deve incluir a porta no endereço de acesso ao servidor, como em “https://gdhn.com.br:404433“

Uma observação é que as versões beta do VMware Server 2.0 vem com as extensões de debug ativadas. Elas permitem gerar relatórios detalhados sobre o status do software, que podem ser incluídos em bug reports, mas reduzem substancialmente o desempenho das máquinas virtuais (a perda chega a mais de 50% em diversas operações).

O debug pode ser desativado dentro das configurações de cada máquina virtual (você precisa desativá-lo uma por uma), desmarcando a opção “Record runtime information”, dentro da seção “Summay > Commands > Configure VM > Advanced”:

Os betas possuem também um sistema de expiração, que bloqueia o uso das versões antigas conforme atualizações vão sendo disponibilizadas, de forma a evitar que os usuários continuem a utilizar versões beta antigas, cujos problemas já foram solucionados.

Concluindo, temos a questão da compatibilidade entre as máquinas virtuais criadas em outras versões do VMware. Por ser a versão mais recente, o VMware Server é compatível com máquinas virtuais criadas em qualquer versão anterior. Entretanto, elas não se beneficiam das melhorias introduzidas na nova versão, como o suporte a mais memória RAM e suporte a dispositivos USB 2.0. Para tirar proveito das melhorias, você tem a opção de atualizar as máquinas virtuais, usando a opção “Upgrade Virtual Machine”, disponível na aba “Summary”:

Note que ao fazer isso a máquina virtual deixa de ser compatível com as versões anteriores (o upgrade é de mão única), mas nada impede que você mantenha uma cópia de backup da máquina virtual original, antes de atualização.

Ao atualizar uma máquina virtual com o Windows, use também a opção “Upgrade VMware Tools”. Os novos drivers virtuais oferecem pequenos ganhos de desempenho em diversas áreas, além de serem necessários para que o sistema guest tenha acesso aos novos recursos.

Fonte: www.guiadohardware.net

O VMware Server

Usando o VMware Server, você pode transformar um único servidor dedicado em vários servidores virtuais, cada um se comportando como se fosse uma máquina separada. Além da possibilidade de combinar os diversos servidores da sua rede local em uma única máquina, ele permite dividir um único servidor dedicado em diversos servidores virtuais, que podem desempenhar funções secundárias ou até mesmo serem sublocados. Você pode também utilizá-lo no seu desktop, pois ele substitui o VMware Player e o VMware Workstation com vantagens. O melhor de tudo é que ele é gratuito.

Quase tudo pode ser simulado via software. É possível até mesmo simular um computador de arquitetura diferente, para que os softwares escritos pare ele rodem da mesma forma que rodam dentro do seu sistema nativo.

Um dos exemplos mais conhecidos são os emuladores de videogames antigos, que permitem rodar jogos de Atari, Nintendo 8 bits, Mega-Drive, Super-Nes, Playstation e outros.

Assim como é possível emular um videogame para rodar os jogos escritos para ele, é possível simular um PC completo dentro de uma máquina virtual e até mesmo executar diversos sistemas operacionais simultaneamente.

O sistema principal neste caso passa a ser chamado de host (hospedeiro) e o sistema operacional que está rodando dentro da máquina virtual é chamado de “guest” (convidado). Ele acha que tem um PC completo para si, enquanto na verdade está rodando dentro de uma “matrix”, na máquina virtual.

Naturalmente, este trabalho de simular um PC completo e ainda por cima com um bom desempenho não é simples, veja o caso dos emuladores de videogame, que, de uma forma geral, precisam de um PC muito mais poderoso do que o sistema original. É preciso um Pentium 200 para emular um Super Nes (que usa um processador de 3.5 MHz e 128 KB de RAM) com qualidade.

Existem atualmente três softwares que se destacam nesta categoria, o VMware, Qemu e o Xen, que trabalham de forma ligeiramente diferente, mas com grandes diferenças práticas.

O VMware usa um conceito de virtualização. Ele tenta sempre que possível converter os comandos usados pelo sistema dentro da máquina virtual em comandos que o sistema host entenda e execute diretamente. Isso se aplica quando é necessário transmitir dados através da placa de rede, tocar sons na placa de som, ou executar instruções do processador. O VMware interpreta e converte instruções o mínimo possível, o que faz com que o sistema dentro da máquina virtual rode com um desempenho muito similar ao desempenho real da máquina.

O Qemu, por sua vez, é um emulador. Ele tenta processar todas as instruções, o que acaba demorando mais tempo e fazendo com que a performance seja menor. Em geral, o VMware (nas versões recentes) consegue fazer com que o sistema guest rode com de 70 a 90% do desempenho que teria se estivesse rodando diretamente, enquanto que o Qemu obtém de 5 a 10%. O Qemu possui um módulo adicional, o Kqemu, que faz com que ele passe a funcionar de forma mais similar ao VMware, virtualizando as instruções básicas do processador, ao invés de emular tudo. O Kqemu melhora consideravelmente o desempenho do Qemu, mas ainda assim o deixa bem atrás do VMware em questão de desempenho. Inicialmente, o Qemu era apenas um projeto menor, mas recentemente ele passou a ganhar mais destaque, com o desenvolvimento do KVM, um sistema de virtualização incluído diretamente no Kernel, disponível a partir do 2.6.20, que trabalha em conjunto com ele.

Temos ainda o Xen, que embora relativamente desconhecido entre os usuários de desktops, já é bastante utilizado nos servidores. Ele utiliza uma idéia diferente, a paravirtualização, que consiste em dividir de forma transparente os recursos do hardware, permitindo que o sistema guest rode com uma redução de performance muito pequena (menos de 5%, na maioria dos casos). O maior problema é que para rodar dentro do Xen é necessário que o sistema guest seja modificado. Não é possível rodar qualquer sistema diretamente, como no caso do VMware e do Qemu. Isto não é um grande problema no caso das distribuições Linux, mas é no caso do Windows e outros sistemas de código fechado.

O Xen é muito mais complicado de configurar que o VMware, o que limita um pouco seu público-alvo, mesmo quando falamos em servidores. Mesmo assim, é possível que o Xen evolua em termos de facilidade de uso e, graças ao bom desempenho, comece a disputar diretamente com o VMware. A página do Xen é a http://www.xensource.com/.

Por enquanto, o vamos estudar sobre o uso do VMware Server, que é atualmente a solução que melhor combina desempenho e facilidade de uso.

O VMware Player, VMware Workstation e o Qemu são os mais usados nos desktops, onde o uso mais comum é usar uma máquina virtual para rodar o Windows dentro do Linux, ou vice-versa. A principal utilidade da máquina virtual é rodar programas gráficos, de forma que você fica com a janela aberta continuamente.

Entretanto, num servidor dedicado as coisas são um pouco diferentes. Ao invés de você ficar o tempo todo na frente da máquina, como faria num desktop, espera-se que o servidor funcione continuamente, sem precisar de muita manutenção. Embora (com um pouco de malabarismo), seja até possível instalar o VMware Player no servidor e deixá-lo ativo, rodando outro sistema numa máquina virtual, ele não é a solução mais prática para a tarefa, sem falar que não é possível usá-lo em servidores sem o ambiente gráfico instalado.

Entendendo o VMware Server

Em um PC desktop, o uso mais comum de um software de virtualização é rodar um segundo sistema operacional, de forma a fazer testes ou rodar algum software específico. Muita gente usa o VMware Player ou o Virtual Box para rodar uma cópia do Windows dentro do Linux ou vice-versa. A principal utilidade da máquina virtual é rodar programas gráficos, de forma que você fica com a janela aberta continuamente:

Entretanto, em um servidor dedicado as coisas são um pouco diferentes. Ao invés de você ficar o tempo todo na frente da máquina, como faria num desktop, espera-se que o servidor funcione continuamente, sem precisar de muita manutenção. Embora (com um pouco de malabarismo), seja até possível instalar o VMware Player no servidor e deixá-lo ativo, rodando outro sistema numa máquina virtual, ele não é a solução mais prática para a tarefa, sem falar que não é possível usá-lo em servidores sem o ambiente gráfico instalado.

Chegamos então ao VMware Server, que vamos ver em detalhes ao longo deste tutorial. Ele é uma versão adaptada e otimizada para uso em servidores dedicados, sem monitor nem ambiente gráfico. A principal diferença é que o VMware Server roda remotamente, e é acessado através de uma interface de administração via web (chamada de VMware Management Interface, ou MUI), onde você pode ativar, desativar e monitorar o status das máquinas virtuais remotamente. A idéia é que cada máquina virtual seja configurada como um novo servidor dedicado, que você administra usando o SSH ou outro software de acesso remoto.

Usando o VMware Server, você pode transformar um único servidor dedicado em vários servidores virtuais, cada um se comportando como se fosse uma máquina separada. Em geral, ao locar um servidor dedicado você recebe uma faixa de IPs com máscara 255.255.255.248, com 5 endereços IPs utilizáveis. Isso significa que você pode usar um endereço para o servidor principal e ainda ficar com mais 4 endereços para as máquinas virtuais (sendo que uma delas pode acumular a função de servidor DNS secundário).

Para emergências, onde você precise ver as mensagens de inicialização ou quando precisar alterar as configurações da máquina virtual (quantidade de memória RAM reservada, CD-ROM ou imagem ISO de boot, etc.) você pode usar o VMware Server Console, uma interface de administração, através da qual você pode se conectar remotamente a qualquer uma das máquinas virtuais disponíveis, obtendo a imagem que seria enviada para o monitor. Ele pode também ser usado para criar novas VMs e instalar ou reinstalar o sistema:

Como um servidor dedicado pode custar menos de US$ 100 por mês, dependendo do datacenter escolhido, existe até mesmo uma boa possibilidade de ganhar algum dinheiro alugando os servidores virtuais e, ainda assim (embora com menos recursos de hardware disponíveis), continuar dispondo do sistema principal.

Até junho de 2006, a VMware oferecia o VMware GSX Server, que era um produto caro, assim como o VMware Workstation. Ele vinha perdendo terreno devido à concorrência do Xen, do Virtuozzo e do Virtual PC (da Microsoft), de forma que a VMware decidiu disponibilizá-lo gratuitamente, como uma solução “entry-level” para a virtualização de servidores. Nasceu assim o VMware Server. O resultado é que temos disponível uma solução de virtualização para servidores muito prática, ao custo de um download.

As limitações do VMware Server são o suporte a até 3.6 GB de memória RAM (na versão 2.0 o limite foi ampliado para 8 GB, desde que você o utilize sobre um sistema operacional de 64 bits) e o suporte a um máximo de 64 máquinas virtuais ativas simultaneamente. Ou seja, embora existam, as limitações não afetam a grande maioria dos usuários.

A VMware ganha dinheiro vendendo o ESX Server, uma solução de virtualização para grandes empresas, que suporta o uso de servidores muito mais robustos e oferece mais opções de gerenciamento e integração entre diversos servidores. Diferente do VMware Server, que é instalado sobre um sistema operacional já existente, o ESX Server roda diretamente sobre o hardware, substituindo o sistema operacional inteiramente.

Preparando o terreno

O VMware Server possui versões para Linux e Windows. No caso da versão Linux, é necessário instalar dois módulos de Kernel (vmmon e vmnet), que permitem que o VMware tenha acesso direto ao hardware. O pacote de instalação inclui módulos pré-compilados para diversas distribuições, mas em muitos casos os módulos precisam ser compilados durante a instalação, o que torna necessário ter instalados os headers do Kernel e um conjunto de compiladores. Eles não são instalados por padrão na maioria das distribuições, o que demanda uma preparação adicional.

O primeiro passo é baixar os arquivos de instalação do VMware Server, disponíveis no:
http://www.vmware.com/download/server/

É necessário fazer um cadastro gratuito para receber o código de registro solicitado durante a instalação. O procedimento é bastante amigável e é possível inclusive solicitar vários números de registro (gratuitamente), caso pretenda instalar em vários servidores.

Estão disponíveis três componentes, o VMware Server propriamente dito, a interface de gerenciamento via web (Management Interface) e o “VMware Server Linux client package”, um arquivo compactado contendo o VMware Server Console. Os dois primeiros são instalados no servidor, enquanto o último (o Server Console) é instalado no seu desktop, a partir de onde você administrará o servidor:

Tanto as versões em .rpm quanto em .tar.gz contém os mesmos componentes, o que muda é apenas o formato do pacote. Nos exemplos vou utilizar as versões .tar.gz, que podem ser usadas em qualquer distribuição.

Enquanto baixa os pacotes, aproveite para ir adiantando o serviço, verificando a instalação dos headers, compiladores e das bibliotecas do X.

Comece verificando a versão do Kernel instalada, usando o comando “uname -a”, como em:

# uname -a

Linux server 2.6.18-4 #1 Tue Aug 16 12:46:35 UTC 2005 i686 GNU/Linux

Em seguida, instale a versão correspondente dos headers do Kernel, usando o gerenciador de pacotes. Procure pelo pacote “linux-headers”, seguido pela versão do Kernel usada. No caso do Debian ou do Ubuntu você pode fazer a instalação usando o apt-get, como em:

# apt-get install linux-headers-2.6.18-4

Além dos headers, é necessário instalar um conjunto básico de compiladores, incluindo o gcc, make, libc6-dev e o binutils. No Debian e no Ubuntu você pode instalá-los através do pacote “build-essential”, um metapacote que instala toda a turma:

# apt-get install build-essential

No OpenSuSE, abra o Yast e, na seção Software Management, instale os pacotes “gcc” e o pacote “kernel-source” da mesma versão do Kernel instalado.

No Fedora, você precisa instalar também o pacote “xinetd”, que é necessário para que os scripts de inicialização utilizados pelo VMware Server funcionem corretamente.

No Mandriva a lista de pacotes é um pouco maior, similar ao que precisamos instalar no Debian. Abra o mcc e instale os pacotes autoconf, automake, gcc, gcc-cpp, xinetd, perl-devel e kernel-source, lembrando de instalar a versão do pacote kernels-source correspondente à versão do kernel atualmente instalada.

Muitas distribuições incluem estes componentes por padrão, dispensando estes passos. No caso do Ubuntu, você pode precisar criar manualmente o link “/usr/src/linux”, apontando para a pasta referente à versão instalada. Para isso, acesse a pasta “/usr/src” e rode o comando “sudo ln -sf linux-headers-2.6.*-* linux”, como em:

# sudo ln -sf linux-headers-2.6.20-15-server linux

Se mesmo depois de criar o link o instalador do VMware continuar parando na pergunta sobre a localização dos headers do Kernel, significa que você não instalou a versão correta do pacote “linux-headers”. Verifique e tente novamente.

Embora o VMware Server não precise da interface gráfica para funcionar, ele precisa que um conjunto básico de bibliotecas esteja disponível. Quando você faz uma instalação em modo servidor do Ubuntu, ou uma instalação mínima do Debian, estas bibliotecas precisam ser instaladas manualmente:

# apt-get install libx11-6 libxtst-dev libxt-dev libxrender-dev libxtst6 libxt6 libxrender1 libxi6 libdb3

Note que a instalação destas bibliotecas não implica na instalação do ambiente gráfico propriamente dito. Somados, os pacotes totalizam pouco mais de 14 MB, enquanto uma instalação completa do ambiente gráfico, incluindo o KDE (ou o Gnome) e alguns aplicativos somaria mais de 300 MB em pacotes.

Sem as bibliotecas do X, você receberá um erro similar a esse no final da instalação, quando o instalador pedir o serial. Ele surge justamente quando o instalador tenta carregar as bibliotecas utilizadas pelo programa a fim de concluir a instalação e se repete indefinidamente até que elas sejam instaladas:

Type XXXXX-XXXXX-XXXXX-XXXXX or ‘Enter’ to cancel: xxxxx-xxxxx-xxxxx-xxxxx
/usr/lib/vmware/bin/vmware-vmx: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory

Uma dica é que você pode fazer a instalação dos pacotes usando um segundo terminal, sem precisar abortar a instalação do VMware. Depois que os pacotes forem instalados, o instalador aceita o serial e a instalação é concluída.

Como comentei no início, o pacote do VMware-Server inclui um grande conjunto de módulos pré-compilados, de forma que em muitos casos você sequer precisará se preocupar com os headers do Kernel ou com ferramentas de compilação. De qualquer forma, é interessante ter esses componentes instalados, já que eles são necessários para instalar diversos softwares e drivers. Mesmo em um servidor, mais cedo ou mais tarde você acaba precisando instalar alguma coisa que precisa deles.

Instalando

Para instalar o pacote principal do VMware Server, descompacte o arquivo .tar.gz e execute o arquivo “vmware-install.pl” dentro da pasta criada, como em:

$ tar -zxvf VMware-server-1.0.5-80187.tar.gz
$ cd vmware-server-distrib
# ./vmware-install.pl

O instalador é um script perl que roda em modo texto, o que permite a instalação em servidores sem o ambiente gráfico instalado. Não existe muito mistério, desde que os headers e os compiladores estejam em ordem, você vai acabar com uma instalação utilizável mesmo que simplesmente pressione Enter em todas as opções. Algumas perguntas que precisam de um pouco mais de atenção são:

Trying to find a suitable vmmon module for your running kernel.

None of the pre-built vmmon modules for VMware Server is suitable for your
running kernel. Do you want this program to try to build the vmmon module for
your system (you need to have a C compiler installed on your system)? [yes]

Using compiler “/usr/bin/gcc”. Use environment variable CC to override.

What is the location of the directory of C header files that match your running
kernel? [/lib/modules/2.6.8-2-386/build/include]

Aqui ele pergunta sobre o os módulos do Kernel, confirmando a localização dos headers. Este arquivo “/lib/modules/2.6.8-2-386/build/include” é, na verdade, um link para a pasta “/usr/src/kernel-headers-2.6.8-2-386″, onde estão os headers do kernel. Em caso de erros neste ponto, verifique a instalação dos headers e a presença do link. Outra dica é que você precisa ter instalados os pacotes “gcc” e “g++” da mesma versão usada para compilar o Kernel.

As próximas perguntas são sobre as interfaces de rede virtuais:

Do you want networking for your virtual machines? (yes/no/help) [yes]

Do you want to be able to use NAT networking in your virtual machines? (yes/no) [no]

Do you want to be able to use host-only networking in your virtual machines? [no]

Naturalmente, você deve responder sempre “yes” na primeira pergunta, caso contrário as máquinas virtuais ficarão desconectadas da rede, mas as duas seguintes precisam de uma inspeção mais cuidadosa. Por padrão, o VMware oferece uma rede virtual em modo bridge (bridged network), onde as máquinas virtuais simplesmente acessam a rede, como se fossem máquinas separadas. Cada uma tem seu próprio IP, como se fossem vários servidores distintos.

As opções para criar uma rede NAT e host-only permitem que as máquinas virtuais sejam configuradas com endereços internos, e acessem a rede através do host. Esta configuração é útil no VMware Player (onde você geralmente quer que o sistema dentro da máquina virtual apenas acesse a internet, sem compartilhar nada), mas não é tão interessante no VMware Server, onde a idéia é justamente criar servidores virtuais. Veja que no exemplo anterior desativei ambas as opções.

Caso seu servidor tenha mais de uma placa de rede, o instalador pergunta:

Your computer has multiple ethernet network interfaces available: eth0, eth1.

Which one do you want to bridge to vmnet0? [eth0]

Ou seja, ao detectar que existe mais de uma placa de rede disponível, ele pergunta a qual delas as máquinas virtuais devem ser ligadas. É importante indicar a placa correta, referente à rede onde as máquinas virtuais ficarão disponíveis, seja a placa da rede local, ou seja a placa com o link de internet.

Embora a mesma placa física seja compartilhada por todas as máquinas virtuais, o VMware se encarrega de encaminhar corretamente os pacotes recebidos. Ele simula inclusive a existência de diversos endereços MAC, um para cada placa de rede virtual. Imagine que ele cria uma espécie de “hub virtual”, onde as máquinas virtuais são conectadas.

Em seguida, temos:

Please specify a port for remote console connections to use [902]

Esta é a porta que será usada para a conexão do cliente, o vmware-server-console. Você pode alterar a porta por outra menos visada (e indicá-la manualmente ao conectar). O ponto principal é que a porta precisa ficar aberta no firewall. Se você é paranóico e prefere não correr o risco de manter a porta 902 aberta, pode ainda utilizar um túnel para se conectar a ela através da porta utilizada pelo SSH. Veja a dica mais adiante.

Em seguida, você deve definir a pasta onde as máquinas virtuais serão armazenadas. Aqui escolhi a pasta “/var/vms” (a pasta “/var” é usada por padrão para armazenar os sites do apache, bases de dados do MySQL, etc.), mas a escolha fica por sua conta. Naturalmente, as máquinas virtuais podem ocupar bastante espaço, por isso é importante checar o espaço livre dentro da partição destino.

In which directory do you want to keep your virtual machine files?
[/var/lib/vmware/Virtual Machines] /var/vms/

Depois de fornecer o código de registro, que você recebe via e-mail, a instalação está completa:

The configuration of VMware Server 1.0.5 build-80187 for Linux for this running
kernel completed successfully.

Depois de instalado, o VMware pode ser iniciado e parado através do serviço “vmware”, como em “/etc/init.d/vmware start” ou “/etc/init.d/vmware stop”. Sempre que tiver problemas, experimente, antes de mais nada, reiniciar o serviço.

O próximo passo é instalar o VMware Server Console, na sua estação de trabalho. A instalação é bem similar à do servidor, com a diferença de não serem necessários os headers e os compiladores. Basta descompactar o arquivo (ele usa uma dupla compactação, em .tar.gz e depois em .zip), acessar a pasta que será criada e executar o script “vmware-install.pl”, como em:

$ unzip VMware-server-linux-client-1.0.5-80187.zip
$ tar -zxvf VMware-server-console-1.0.5-80187.tar.gz
$ cd vmware-server-console-distrib
# ./vmware-install.pl

Depois de instalado, chame-o usando o comando:

$ vmware-server-console

Ao abrir a conexão com o servidor, você pode logar usando qualquer conta de usuário. De início, você pode se logar como root, para testar e fazer a configuração, mas depois é interessante criar uma conta de usuário separada, que tenha acesso à pasta das VMs. O VMware utiliza SSL de 128 bits para garantir a segurança da conexão, mas sempre é bom evitar utilizar o root para tarefas rotineiras.

O vmware-server-console possui uma interface muito similar à do VMware Workstation, onde você pode criar e editar as configurações das máquinas virtuais. Como disse, o VMware Server é uma versão adaptada para uso em servidores, onde a interface é separada do restante do software, permitindo que você faça tudo remotamente.

Ele utiliza um protocolo próprio para comprimir e transmitir a imagem da tela via rede, exibindo-a no seu desktop. O maior problema é que o VMware utiliza um protocolo de atualização de tela sem perda, que acaba sendo bastante ineficiente para uso via rede.

Ao acessar uma máquina virtual que está rodando num servidor remoto, o desempenho de atualização da tela é bastante inferior ao que você teria acessando a máquina remota usando o NX Server ou o VNC, por exemplo. Mesmo acessando via banda larga, usar aplicativos gráficos acaba sendo desconfortável. Isso faz o sistema dentro da VM parecer lento enquanto está sendo acessado (remotamente) através do Console, mas, na verdade, o desempenho não é muito diferente do obtido nas outras versões do VMware. Em geral, você obtém de 70 a 90% do processamento real do servidor dentro das máquinas virtuais.

Uma dica é que você pode utilizar o vmware-server-console para se conectar a uma cópia local do VMware Server. Neste caso, a atualização de tela é tão rápida quanto ao usar o VMware Workstation ou o VMware Player, de forma que muita gente prefere utilizar o VMware Server mesmo ao rodar máquinas virtuais localmente. Para isso, basta usar a opção “Local host” na tela inicial. Você pode aproveitar para ir treinando na sua máquina, antes de começar a criar VMs para servidores importantes.

É possível (e bastante simples) fazer a instalação do sistema dentro da máquina virtual usando sua máquina local e depois transferir o sistema já instalado para o servidor remoto. Desta forma, você não perde tempo tentando realizar todo o processo de instalação do sistema remotamente. Você pode inclusive criar várias cópias independentes da mesma máquina virtual, aproveitando a instalação inicial.

Vamos começar do básico, vendo os detalhes sobre a criação e configuração das máquinas virtuais. Uma vez conectado (seja a um servidor remoto, seja localmente), use a opção “Create a new virtual machine” na tela inicial:

A primeira opção determina as opções que serão mostradas daqui em diante. Na opção “Typical” são mostradas apenas as opções mais simples, deixando o wizard definir os detalhes. No nosso caso, estamos mesmo interessados em decifrar as opções mais avançadas, então vamos de “Custom”:

O VMware inclui uma série de otimizações que melhoram o desempenho e a compatibilidade do sistema dentro da máquina virtual. São melhorias relacionadas à operação interna do programa, de forma que não temos muitos detalhes sobre elas, mas a diferença é realmente mensurável. Para que elas entrem em ação, é importante indicar corretamente o sistema operacional que você irá instalar dentro da VM. Dentro da opção “Linux”, você encontra versões do Red Hat, SuSE, Mandriva e Ubuntu, que são suportadas oficialmente pela equipe do VMware. Para as demais distribuições, use as opções “Other Linux 2.6.x kernel”, ou “Other Linux 2.6.x kernel 64-bit” (ao instalar as versões de 64 bits das distribuições). Existe também a opção “Other Linux 2.4.x kernel”, que pode ser usada ao instalar distribuições antigas, que ainda utilizam Kernels da série 2.4:

Em seguida, chegamos à fase das apresentações, onde você define um nome para a máquina virtual e (mais importante), define a pasta onde os arquivos referentes a ela ficarão armazenados.

As máquinas virtuais nada mais são do que um conjunto de arquivos dentro de uma pasta. O mais importante deles é o disco virtual, onde são armazenados todos os dados salvos no “HD” da máquina virtual. Ao escolher a pasta, é importante verificar o espaço disponível, já que o arquivo do disco virtual armazenará o sistema operacional e todos os arquivos colocados dentro da VM:

A próxima pergunta é relacionada ao suporte a SMP. Ao instalar o VMware Server em uma máquina com um processador dual-core, quad-core (ou com dois processadores em SMP), você tem a opção de ativar o suporte a SMP também para a máquina virtual, permitindo que o sistema instalado enxergue os dois processadores e possa dividir a carga entre eles (opção “Two”)

Na prática, você pode usar a opção “Two” mesmo ao instalar em uma máquina com apenas um processador, mas neste caso (obviamente) não existe qualquer ganho de performance:

Existe ainda uma opção de segurança, que permite restringir o acesso às máquinas virtuais no caso de um servidor compartilhado por vários usuários. Imagine o caso de um servidor dedicado, onde você instalou 4 máquinas virtuais, que serão sublocadas a 4 clientes diferentes. Para dar acesso às VMs criadas usando o vmware-server-console, permitindo que cada um possa acessar apenas sua própria VM (sem ter acesso às demais), você criaria 4 usuários de sistema separados (joao, maria, jose e manuel, por exemplo) e usaria cada um dos usuários para criar uma das VMs, marcando sempre a opção “Make this machine private”. Dessa forma, cada usuário teria acesso a apenas uma das VMs:

Os recursos do servidor são compartilhados entre as máquinas virtuais, com destaque para a memória RAM. A opção seguinte permite limitar a quantidade de memória disponível para cada máquina virtual.

Embora a conta pareça simples (afinal, se temos 1 GB de memória e estamos instalando 4 VMs, teríamos 256 MB para cada uma, certo? , encontrar o melhor valor é um pouco mais complicado do que parece.

Em primeiro lugar, o valor definido aqui não é diretamente atribuído, nem fica fisicamente reservado para a VM, pois o vmware é capaz de gerenciar a memória RAM e swap disponível, de acordo com o volume de memória utilizado por cada VM e pelo próprio sistema host em um dado momento. Apesar disso, o VMware reserva cerca de 160 MB de memória para o sistema host e não permite que você inicialize mais VMs do que o comportado pela memória excedente. Se você tem 1 GB de memória instalada no servidor, todas as VMs somadas poderiam utilizar pouco mais de 840 MB. Se você tiver 4 VMs, configuradas para consumir 256 MB cada uma, o VMware exibiria uma mensagem de erro ao tentar inicializar a quarta. Você pode ter um número quase ilimitado de máquinas virtuais no mesmo servidor, desde que não fiquem todas ativas simultaneamente.

É possível fazer com que o VMware faça swap de parte da memória reservada às máquinas virtuais, o que permite que você ative um número um pouco maior de máquinas virtuais simultaneamente, às custas de uma redução no desempenho. Para isso, configure a opção Host > Settings > Memory > Additional Memory (na tela principal) com o valor “Allow most virtual machine memory to be swapped”:

Outra exceção ocorre quando você usa uma única máquina virtual de cada vez. Neste caso, o VMware permite que você reserve um volume de memória muito maior do que a memória física disponível, pois ele é capaz de utilizar também a memória swap. Veja que no meu caso, o VMware permite reservar até 1764 MB, muito embora o servidor onde ele está instalado tenha apenas 1 GB:

Um bom cálculo é subtrair 192 MB da memória total disponível (para uso do sistema host) e dividir o excedente entre as VMs que você pretender manter ativas simultaneamente. Se o servidor tem 1 GB de memória e você pretende manter 4 VMs ativas, poderia reservar 208 MB para cada uma.

Ao instalar o sistema dentro de cada VM, você pode criar uma partição swap dentro do disco virtual. Embora o desempenho de acesso a essa partição swap virtual seja mais baixo, ela poderá ser usada normalmente pelo sistema guest quando necessário, como complemento à memória “física” reservada à VM.

Chegamos então à configuração da rede virtual, que é outro passo importante. Como vimos anteriormente, o VMware oferece 3 tipos de rede virtual. No primeiro, o modo bridge, a máquina virtual tem acesso completo à rede, pode receber um IP próprio e fica com todas as portas de entrada disponíveis, como se fosse um PC independente conectado à rede. Sempre que falamos em servidores, falamos no uso do modo bridge.

As outras duas opções podem ser interessantes para uso em desktop, onde você simplesmente instala uma VM e a usa em conjunto com o sistema principal, mas não são muito relevantes no nosso caso. No modo NAT, a máquina virtual tem acesso à rede e pode acessar a Internet, mas não possui portas de entrada, de forma que não é possível rodar servidores. No modo host-only a VM é conectada a um cabo cross-over virtual e tem acesso apenas ao próprio servidor, ficando desconectada do restante da rede.

Como disse, ao configurar servidores virtuais (e em diversas outras situações), o modo bridge é o único que interessa, por isso escolhemos a opção “Use bridged networking”:

Independentemente do tipo de HD que está instalado no host, o VMware utiliza internamente rotinas de acesso do padrão SCSI para os discos virtuais. O padrão SCSI é o preferido pelos desenvolvedores, pois as funções são bastante organizadas e o padrão é aberto e fácil de entender. Isso explica porque, no Linux, o suporte a gravadores de CD e (a partir do Kernel 2.6.20) o próprio suporte a HDs IDE foi incorporado ao sub-sistema SCSI, que já existia previamente.

Graças a isso, o sistema operacional instalado dentro da VM reconhecerá o HD como sendo SCSI, mesmo que ele seja IDE ou SATA. Durante a criação da máquina virtual, o VMware permite que você escolha qual modelo de controladora SCSI será simulada dentro da máquina virtual. Você pode escolher entre uma controladora BusLogic ou LSI Logic. O desempenho de ambas as opções é rigorosamente o mesmo, muda apenas o driver que o sistema operacional instalado dentro da máquina virtual irá utilizar:

É possível criar uma máquina virtual e aproveitar o disco virtual de uma anterior (opção “Use an existing virtual disk”), assim como você pode montar outro micro e aproveitar o HD antigo. Esta opção pode ser útil caso você queira aproveitar uma instalação antiga de um sistema operacional instalado em outra VM. Neste caso, bastaria indicar a pasta com a VM antiga. Entretanto, na maioria dos casos, você vai querer simplesmente criar um novo disco virtual, zerado. Para isso, escolha a opção “Create a new virtual disk”.

Ainda dentro da questão da controladora SCSI virtual, existe a opção de utilizar um modo de compatibilidade, onde o VMware faz com que o disco virtual apareça para o sistema dentro da VM como um HD IDE. Esta opção permite resolver problemas de compatibilidade, casos onde, por um motivo ou outro, o sistema dentro da máquina virtual não possui suporte a HDs SCSI, ou não consegue detectar corretamente a controladora SCSI virtual.

Se a instalação do sistema dentro da máquina virtual falhar, com um erro de “não é possível acessar o disco”, ou similar (sintoma de que o sistema operacional dentro da VM não conseguiu acessar o disco virtual), escolha a opção “IDE”, do contrário mantenha o “SCSI (Recommended)”:

Assim como no caso da memória, você deve definir um limite para o espaço em disco utilizado pela VM, através da opção “Disk size (GB)”:

O valor definido é o tamanho do “HD” que será visto pelo sistema dentro da máquina virtual. Reservando 8 GB, por exemplo, o sistema enxergará um HD de apenas 8 GB e, naturalmente, não poderá ocupar mais espaço do que isso.

A opção “Allocate disk space now” faz com que o VMware realmente reserve os 8 GB para uso da máquina virtual, criando um enorme arquivo vazio. Esta opção é a melhor do ponto de vista do desempenho, pois evita a fragmentação e permite o uso de otimizações adicionais, mas, por outro lado, aumenta bastante o espaço ocupado pelas máquinas virtuais, já que, 4 VMs com HDs virtuais de 8 GB, ocuparão 32 GB de espaço no HD do servidor.

Desmarcando a opção, o espaço é alocado de forma dinâmica. O disco virtual começa como um arquivo vazio, que ocupa poucos Kbytes. Dentro da máquina virtual, o sistema guest pensa que está formatando e usando um HD de verdade, mas todas as mudanças são mascaradas e feitas dentro do arquivo. Conforme você instala o sistema e outros programas, o arquivo vai aumentando de tamanho, até o limite definido. Enquanto ele não é atingido, o arquivo do disco virtual ocupa um espaço equivalente à quantidade de espaço realmente ocupado. Se você criou um disco virtual de 20 GB, mas apenas 2 GB estão em uso, você verá um arquivo de apenas 2 GB dentro da pasta da máquina virtual.

Concluindo, a opção “Split disk into 2 GB files” permite burlar as limitações de tamanho de arquivos em partições FAT e em diversos protocolos de transferência de arquivos (incluindo o próprio SFTP), que só suportam arquivos de até 2 GB. Mantendo a opção ativada, o disco virtual é dividido em arquivos de até 2 GB, o que facilita as transferências.

Concluindo, você precisa apenas indicar o nome e a localização do arquivo com o disco virtual. Por padrão ele é criado dentro da pasta com os outros arquivos da VM e com o mesmo nome desta. É possível também usar nomes como “C” e “D”, ou “sda” e “sdb” ou mesmo armazenar os arquivos em outras pastas. Para isso, bastaria indicar a localização na opção “Specify Disk File”:

Com isto a criação da máquina virtual está completa . Como você pode ver, o processo é simples. O principal objetivo dessa longa explicação foi explicar os detalhes e mostrar as opções escondidas.

Configurando a VM

Estamos agora de volta à tela inicial do vmware-server-console. As máquinas virtuais são abertas em abas, o que permite que você mantenha várias delas abertas ao mesmo tempo, limitado apenas aos recursos disponíveis no servidor. Não é incomum ter notícias de servidores rodando 100 máquinas virtuais ou mais, cada uma com um servidor completo. Muitas empresas de hospedagem oferecem a opção de locar um VPS, que é justamente uma máquina virtual. Eles são uma boa opção aos planos de hospedagem compartilhada (onde você recebe apenas um virtual host do Apache), pois a máquina virtual se comporta como um servidor real, permitindo que você instale aplicativos e modifique a configuração como quiser.

Clicando no “Edit virtual machine settings” você tem acesso às configurações da VM e pode alterar muitas das opções definidas durante a criação, além de muitas outras que estão disponíveis apenas aqui. Você pode inclusive fazer “upgrades” na sua VM, adicionando um segundo HD, mais memória, ou até mesmo uma segunda placa de rede. Tudo virtual.

O VMware permite que você utilize uma imagem ISO de um CD (ou DVD) como mídia de instalação. Em um desktop, isso lhe salvaria de ter que queimar os CDs, mas, em um servidor remoto, acaba sendo a única forma de instalar o sistema, já que você não teria como ir pessoalmente colocar o CD no drive de qualquer maneira. Você poderia se conectar ao servidor via SSH, aproveitar a conexão rápida para baixar o CD ou DVD de instalação da distribuição que pretende instalar diretamente para ele (use o “wget -c”, seguido do link de download) e, em seguida, usar o VMware para instalar o sistema dentro da VM diretamente a partir do ISO que acabou de baixar.

Para isso, acesse a opção “CD-ROM” dentro do menu de configurações da VM e marque a opção “Use ISO image”. Indique o arquivo ISO que será utilizado e estamos conversados. Depois de concluir a instalação do sistema, você pode voltar nesta mesma tela e desmarcar a opção “Connect at power on” para desabilitar o CD-ROM virtual:

Continuando, você pode ajustar a quantidade de memória atribuída à máquina virtual na opção “Memory”. Isso permite que você teste várias configurações, até chegar na ideal:

Assim como no caso do CD-ROM, a máquina virtual pode utilizar também disquetes de boot, incluindo a possibilidade de usar uma imagem de disquete salva em um arquivo. Hoje em dia é incomum que você precise usar disquetes de boot para instalar o sistema, de forma que você pode remover o floppy virtual, selecionando o dispositivo na lista e usando a opção “Remover”.

Você pode adicionar novos discos virtuais através da opção “Add > Hard Disk”. Assim como em um PC, a VM pode ter diversos HDs, que são reconhecidos pelo sistema da forma usual. É possível adicionar também uma segunda placa de rede (esta opção é muito boa para fins didáticos, pois você pode simular uma rede inteira, com vários PCs) e até mesmo adicionar suporte à placa de som, USB e outros periféricos, embora estas opções não sejam tão úteis no caso de um servidor.

Uma dica para melhorar o desempenho é desmarcar a opção “Disable write caching” nas propriedades do disco virtual. Ela fica ativada por padrão, fazendo com que as alterações feitas nos HDs das VMs precisem ser gravadas de forma síncrona no HD do servidor. Esta opção melhora a segurança contra perda de dados caso o servidor seja desligado incorretamente, mas reduz bastante o desempenho. Em um servidor que fica ligado continuamente, desativá-la representa um risco aceitável.

Dentro das opções do disco virtual, você encontra também a função para desfragmentar o arquivo, o que ajuda a melhorar o desempenho da VM e reduzir a utilização de espaço no HD do host:

Depois de tudo configurado, falta apenas fazer as honras, clicando no “Power on virtual machine”. Você pode voltar ao menu de configuração a qualquer momento através da opção “VM > Settings” no menu principal, mas a maior parte das opções ficam inativas enquanto a VM está rodando. Para modificá-las, você precisa primeiro finalizar o sistema e desligar a VM, usando a opção “Power Off”:

Uma vez inicializada a máquina virtual, o sistema dá boot a partir do CD, DVD ou disquete virtual contendo o sistema. Você é saudado com a tela de boot e prossegue a instalação do sistema da forma usual, como se estivesse instalando o sistema em um PC real:

Você pode encontrar dicas para a instalação de diversas distribuições Linux e para as várias versões do Windows e outros sistemas dentro de máquinas virtuais no:
http://pubs.vmware.com/guestnotes/wwhelp/wwhimpl/js/html/wwhelp.htm

Uma dica é que, ao instalar um sistema distribuído na forma de vários CDs ou DVDs, é possível trocar os arquivos ISO durante a instalação, simulando a troca dos CDs no drive.

Para isso, dê um boot normal utilizando a primeira mídia e, no ponto da instalação onde o sistema pede para trocar a mídia, clique no “VM > Removable devices > CD-ROM 1 > Disconect”. Isso simula a remoção do CD-ROM. Clique agora no “VM > Removable devices > CD-ROM 1 > Edit…”, para indicar o arquivo ISO do segundo CD e, em seguida, em “VM > Removable devices > CD-ROM 1 > Connect” para simular a reinserção do CD:

Se você está usando uma cópia local do VMware Server e está com os CDs de instalação em mãos, pode também configurar a máquina virtual para utilizar o drive de CD físico e ir trocando os CDs durante a instalação, da forma tradicional.

Se, por outro lado, você não quer se dar ao trabalho de fazer nenhuma das duas coisas, pode baixar a versão em DVD (quando estiver disponível), fazer uma instalação via rede (como no caso do Debian, onde você pode utilizar a versão “netinst”) ou ainda fazer uma instalação mais enxuta, de forma que o instalador consiga instalar o sistema utilizando apenas os pacotes disponíveis no primeiro CD.

Como disse anteriormente, a máquina virtual é na verdade um conjunto de arquivos, salvos dentro da pasta indicada durante sua criação. Dando uma espiada dentro dela, você encontra os arquivos do disco virtual, criado com a extensão “.vmdk” (como selecionei a opção de quebrar em arquivos de 2.0 GB, tenho no meu caso um conjunto de vários arquivos), o arquivo .vmsd, que é usado para gravar uma cópia do conteúdo da memória da máquina virtual quando você utiliza a opção “Suspend” (de forma que ela possa ser restaurada no ponto onde estava posteriormente) e também o arquivo .vmx, um arquivo de texto legível que armazena a configuração da máquina virtual:

Dentro do arquivo, a quantidade de memória RAM reservada à máquina virtual vai na opção “memsize =” e o arquivo ISO que será utilizado vai na opção “ide1:0.fileName =”. Ao desativar algum dos dispositivos virtuais, a opção referente a ele fica com a opção “FALSE”, como no caso do drive de disquetes, que fica desativado por causa da opção floppy0.present -”FALSE”.

Com um pouco de prática, você pode até mesmo alterar as configurações da VM diretamente dentro do arquivo, sem sequer precisar das opções gráficas, o que pode ser bastante prático para fazer alterações rápidas em um servidor com muitas VMs:

Há algum tempo, escrevi um script para o VMware Player no Kurumin 7, que permitia criar e editar as opções das máquinas virtuais, aplicando as mudanças diretamente no arquivo. É o tipo de coisa que não faria muito sentido no VMware Server, que oferece todas as opções de configuração, mas foi bastante útil para quem usava o VMware Player, que é a versão castrada. Mostrou também que as máquinas virtuais podem ser criadas e configuradas até mesmo via shell script.

Continuando, o arquivo “nvram” dentro da pasta serve para armazenar as configurações do Setup. Sim, a máquina virtual possui até mesmo um BIOS virtual, com direito a Setup e tudo mais. Para acessá-lo, pressione a tecla “F2″ na tela inicial, logo depois de iniciar a VM.

Nele você pode escolher entre dar boot pelo CD-ROM ou pelo HD e até mesmo acertar a hora do setup. A máquina virtual tem até mesmo um relógio de CMOS próprio, vinculado ao horário do relógio da placa-mãe:

Um bug conhecido, que afeta diversas distribuições, é a tecla “/” do teclado não funcionar dentro das VMs. Ele pode ser resolvido rapidamente adicionado a linha “xkeymap.keycode.211 = 0×073″ no final do arquivo “/usr/lib/vmware/config” e, em seguida, reiniciando o serviço “vmware”. Você pode fazer isso rapidamente usando os dois comandos abaixo:

# echo ‘xkeymap.keycode.211 = 0×073′ >> /usr/lib/vmware/config
# /etc/init.d/vmware restart

Já que a máquina virtual é na verdade apenas uma pasta com arquivos, você pode perfeitamente tirar cópias e transportá-las para outras máquinas. Se você precisa de 10 máquinas virtuais com servidores Debian, por exemplo, você não precisa fazer a instalação 10 vezes; pode instalar uma vez, tirar 10 cópias e depois apenas modificar as configurações de rede e acertar as peculiaridades de cada servidor.

Para tirar cópias locais de uma máquina virtual, basta copiar a pasta de instalação. Você poderia, por exemplo, usar o comando:

$ cp -a Debian-Etch/ Debian-Etch2

… gerando uma pasta de nome diferente para cada cópia.

Para abrir as VMs copiadas no vmware-server-console, clique em “File > Open” e indique o arquivo .vmx dentro de cada pasta copiada:

Ao inicializar as máquinas virtuais copiadas pela primeira vez, o VMware exibe um aviso sobre o número de identificação. Cada VM possui um número de identificação e, por motivos óbvios, não é recomendável utilizar várias VMs com a mesma identificação. Para evitar isso, use a opção “Always Create”, que faz com que o VMware passe a atribuir novos números de identificação conforme as cópias forem sendo inicializadas:

Naturalmente, é possível também copiar as máquinas virtuais para outras máquinas. Neste caso, a melhor opção é compactar a pasta. Como os arquivos da VM são salvos no disco virtual sem compactação, você pode reduzir o tamanho da pasta em duas vezes ou mais ao compactá-la.

Compactar a pasta antes de transferí-la também evita problemas relacionados à mudanças nas permissões dos arquivos. Para comprimir a pasta no Linux, use o comando “tar -zcvf”, seguido pelo arquivo .tar.gz que será gerado e a pasta que será compactada, como em:

$ tar -zcvf Debian-Etch.tar.gz Debian-Etch/

Depois de transferir o arquivo para a outra máquina, descompacte-o usando o “tar -zxvf”, como em:

$ tar -zxvf Debian-Etch.tar.gz

Ao invés de fazer toda a instalação do sistema na VM remotamente, tendo que lidar com a lentidão de atualização da tela, você pode criar a VM e fazer a instalação e configuração na sua máquina e transferir a VM para o servidor quando estiver tudo pronto. Fazendo uma instalação enxuta do Debian ou uma instalação do Ubuntu em modo servidor e compactando a pasta antes de transferir, o upload ficará com pouco mais de 200 MB.

Como disse a pouco, você pode utilizar o SSH, NX, VNC e outras opções de acesso remoto para administrar as máquinas virtuais remotamente, deixando o vmware-server-console apenas para emergências. A vantagem dele é permitir que você acompanhe todo o processo de boot do sistema, identificando e corrigindo problemas em casos onde o sistema passa a travar no boot ou não sobe a rede, por exemplo.

Configuração da rede

Ao instalar o VMware Server em um servidor da sua rede interna, a configuração dos endereços de rede para as máquinas virtuais precisa apenas seguir o padrão normal da sua rede, como se você estivesse adicionando novos micros ou servidores. A principal dúvida reside em como configurar os endereços das máquinas virtuais ao utilizar um servidor dedicado, hospedado externamente.

Na grande maioria dos casos, ao locar um servidor dedicado você recebe uma faixa de 8 endereços, onde 5 deles são utilizáveis, já que o primeiro e o último endereços ficam reservados aos pacotes de broadcast e ao endereço da rede e um deles fica sendo o endereço do gateway. Na maioria dos casos, as empresas de hospedagem utilizam faixas de endereços de classe A ou B, divididas em uma grande quantidade de redes menores, utilizando máscaras de tamanho variável, baseadas no sistema CIDR. A máscara mais comum é a “255.255.255.248″ (/29), que permite criar as redes de 8 endereços que comentei.

Seu servidor pode, por exemplo, utilizar o endereço 72.232.194.138, sendo que:

72.232.194.136: Endereço da rede
72.232.194.137: Gateway
72.232.194.138 a 72.232.194.141: Endereços utilizáveis
72.232.194.142: Endereço de broadcast

Nesta situação, você ainda teria vagos os endereços de 72.232.194.138 a 72.232.194.141. Os endereços ociosos podem ser usados para colocar no ar servidores virtuais, que podem desempenhar funções secundárias, serem usados como honeypots, ou até mesmo serem sublocados. Basta usar a imaginação.

Você poderia colocar no ar 4 máquinas virtuais diferentes, cada uma utilizando um dos endereços disponíveis. Você notará que cada uma realmente responderá e se comportará como um servidor completo. Como disse anteriormente, é como se fosse criado um “hub” virtual”, onde todas as máquinas virtuais são ligadas.

Cada VM seria então configurada para utilizar um dos endereços vagos dentro da faixa. Se você não tem um segundo servidor dedicado para assumir a função de servidor DNS secundário, pode delegar essa função a uma das VMs, evitando assim precisar sacrificar um dos endereços IP para o alias da placa de rede no servidor principal. Aqui temos um exemplo de configuração de rede para uma VM dentro de uma faixa de 8 endereços:

Aproveite para adicionar as máquinas virtuais à configuração do DNS. Aqui temos um exemplo de configuração onde três VMs foram incluídas como subdomínios de um domínio já configurado:

@ IN SOA servidor.gdhn.com.br. hostmaster.gdhn.com.br. (
2008061645 3H 15M 1W 1D )
NS servidor.gdhn.com.br.
NS vm1.gdhn.com.br.
IN MX 10 servidor.gdhn.com.br.
gdhn.com.br. A 64.234.23.12
www A 64.234.23.12
vm1 A 64.234.23.13
vm2 A 64.234.23.14
vm3 A 64.234.23.15
vm4 A 64.234.23.16

Naturalmente, você pode também registrar novos domínios para as máquinas virtuais, adicionando as zonas na configuração do DNS do servidor principal (nada impediria que as próprias máquinas virtuais abrigassem servidores DNS próprios, mas isso só complicaria a configuração).

Em casos onde você precisa criar mais do que 4 máquinas virtuais (e a configuração de hardware do servidor permita), você pode pagar por endereços IP adicionais, opção que está disponível por um pequeno extra em grande parte dos planos de hospedagem. Veja, por exemplo, esta tela de seleção do The Planet:

Por apenas 8 dólares (mensais) adicionais é possível fazer um “upgrade” para uma faixa de 13 endereços (máscara 255.255.255.240) e por 56 dólares é possível colocar as mãos em uma faixa de 61 endereços utilizáveis (máscara 255.255.255.192).

Aumentando a mensalidade em mais 45 dólares, seria possível atualizar o servidor para 2 GB de RAM e adicionar um HD secundário de 500 GB, o que permitiria rodar tranquilamente 8 ou mesmo 16 VMs simultaneamente.

Interface de gerenciamento via web

Concluindo, falta apenas instalar o VMware Management Interface (no servidor), de forma que você possa monitorar o status das máquinas virtuais já configuradas usando o navegador.

Assim como nos passos anteriores, você deve baixar o arquivo “VMware-mui”, descompactá-lo, acessar a pasta “vmware-mui-distrib/” que será criada e rodar o comando “vmware-install.pl“, para abrir o script de instalação, como em:

# tar -zxvf VMware-mui-1.0.5-80187.tar.gz
# cd vmware-mui-distrib/
# ./vmware-install.pl

Ao contrário do script de instalação do VMware Server, o script não pergunta sobre compiladores ou sobre os headers do Kernel, apenas confirma os diretórios de instalação. Embora seja uma interface de administração via web, o VMware-mui não precisa que o Apache (ou outro servidor web) esteja instalado, pois ele inclui um mini-servidor próprio, que inclui todas as funções necessárias. Ele também não conflita com o Apache caso instalado no mesmo servidor, já que utiliza uma porta diferente.

Para se conectar à interface de gerenciamento, acesse (no seu desktop) o endereço “https://seuservidor.com.br:8333” e logue-se usando o mesmo login e senha do vmware-server-console. Esta interface de gerenciamento é muito prática, pois você pode se conectar ao servidor para reiniciar uma máquina virtual até mesmo usando o celular, quando estiver preso no trânsito. Note que é necessário manter a porta “8333″ aberta no firewall do servidor:

Aqui temos duas máquinas virtuais ativas, uma com o SuSE e outra com o Ubuntu. A grande diferença de uso de memória entre os dois (29 MB para o Ubuntu e 159 MB para o SuSE) é porque o SuSE está rodando com a interface gráfica e um conjunto de outros serviços ativos, enquanto o Ubuntu foi instalado em modo servidor e está rodando apenas o SSH e o Apache.

Em geral, um servidor bem configurado e com apenas os serviços necessários ativos, consome bem menos memória RAM que um desktop (com exceção dos casos de servidores de alta demanda, naturalmente), por isso é mais fácil manter várias VMs ativas. O consumo de RAM do servidor cresce conforme aumenta o número de usuários e, consequentemente, de requisições simultâneas.

Naturalmente, nada lhe impede de configurar também máquinas virtuais rodando outros sistemas operacionais. Também estão disponíveis versões do VMware Server e do vmware-server-console para Windows, tornando a escolha da plataforma algo bem democrático.

Voltando ao VMware-mui, muita gente torce o nariz para a idéia de manter abertas as portas 902 (utilizada pelo vmware-server-console) e 8333. Se você for paranóico, é possível manter as portas fechadas e acessar a interface de gerenciamento e o console usando um túnel do SSH. Neste caso, você precisa manter aberta apenas a porta 22.

Para criar os túneis, use o comando “ssh -f -N -L porta:IPservidor:porta -l user IPservidor”. É preciso executar o comando duas vezes, uma para a porta 902 e outra para a porta 8333. Se você deseja se conectar no servidor “gdhn.com.br” usando o login “gdh”, por exemplo, os comandos seriam:

# ssh -f -N -L902:gdhn.com.br:902 -l gdh gdhn.com.br
# ssh -f -N -L8333:gdhn.com.br:8333 -l gdh gdhn.com.br

Uma observação é que o primeiro comando (que redireciona a porta 902) precisa ser executado na sua máquina (no cliente) como root, pois as permissões do SSH não permitem criar túneis para portas abaixo da 1024 utilizando um login de usuário.

Com os túneis criados, ao invés de se conectar ao endereço IP ou domínio do servidor, você passa a se conectar ao endereço “127.0.0.1″, ou seja, você se conecta ao localhost. O SSH se encarrega de redirecionar todos os dados através do túnel, enviando-os para as portas corretas no servidor remoto, mesmo que elas estejam fechadas no firewall (pois os dados trafegam na verdade através da porta 22, do SSH).

Os túneis são bem transparentes. A única dificuldade é que você precisa executar novamente os comandos cada vez que reiniciar o cliente ou caso ele seja desconectado da rede.

VMware Tools

Embora não seja obrigatório, é interessante instalar o VMware-Tools após terminar de instalar o sistema dentro da máquina virtual. Ele é um conjunto de drivers que faz o sistema guest rodar com um melhor desempenho e de forma mais transparente, sobretudo com relação à interface de rede virtual e ao vídeo.

Dentro da máquina virtual, o sistema guest não enxerga o hardware real do servidor, mas sim um conjunto de dispositivos virtuais criados elo VMware. É por isso que você pode usar a mesma VM em vários servidores diferentes, sem precisar ficar instalando drivers nem modificando o sistema guest.

Para instalar o VMware Tools dentro da máquina virtual, use (com o sistema carregado) a opção “VM > Install VMware Tools” disponível no menu principal:

A opção simula a inserção de um segundo drive de CD-ROM, contendo a mídia de instalação do VMware-Tools dentro da máquina virtual. Ao instalar em uma VM rodando Linux, o primeiro passo é montar o drive de CD-ROM, usando o comando “mount /media/cdrom0″ ou “mount /mnt/cdrom”.

Acessando a pasta correspondente, você encontra dois arquivos do VMware-Tools, um compactado em .tar.gz (a versão genérica) e outro em .rpm (a versão destinada ao Fedora e outras distribuições derivadas do Red Hat).

Copie a versão que vai instalar para a pasta “/tmp”. Para instalar o arquivo .tar.gz, descompacte o arquivo, acesse a pasta que será criada e execute o comando “./vmware-install.pl” (como root). Para o pacote em RPM, basta instalá-lo utilizando o comando “rpm -Uvh”

A instalação do VMware-Tools implica na instalação de diversos módulos de kernel que precisam ser compilados sob medida para o kernel em uso. O pacote inclui pacotes pré-compilados para muitas distribuições, mas, ao instalar uma distribuição menos comum, ou instalar uma versão recente, você vai precisar ter instalados os compiladores e os headers do kernel (no sistema guest, dentro da máquina virtual), para que o instalador possa compilar os módulos, assim como ao instalar o pacote principal do VMware Server.

Ao usar a opção em uma VM com o Windows, a instalação é mais simples, pois a inserção do CD-ROM virtual dispara o programa de instalação automaticamente (usando o autorun) e o instalador segue o tradicional modelo “Next > Next > Finish”:

Graças a todos os recursos que vimos, o VMware Server acaba sendo uma opção quase que ideal, já que é gratuito, flexível e fácil de instalar. Além de usá-lo em seus servidores para otimizar o uso dos recursos disponíveis, essencialmente transformando um único servidor em vários, você pode até mesmo usá-lo no seu desktop, no lugar do VMware workstation ou VMware Player.

Atualmente estamos assistindo a uma popularização muito grande do Xen, mas ele ainda perde no quesito da facilidade de uso. Outro concorrente que tem crescido é o KVM, que também citei anteriormente. Ou seja, mantenha um olho no VMware Server, e outro nas demais soluções. Como o mercado é muito volátil, não podemos dizer qual deles estará por cima daqui a 5 anos.

Fonte: www.guiadohardware.net

Livro Redes e Servidores Linux do Carlos Morimoto

E aí tchê! estava dando umas voltas na web e passando pelo site Guia do Hardware me deparo com algo interessante. O Carlos Morimoto está disponibilizando o seu livro Redes e Servidores Linux 2ª Edição, muito bom livro, comprei a algum tempo atrás, me ajudou muito e continua me ajudando.

Bom, quem quiser dar uma conferida eis o link: livro Redes e Servidores Linux 2ª Edição

Valew e até a próxima!

Soluções Integradas: livecd + firewall + router

Há algum tempo tenho visto amigos utilizando o PFSENSE que é um excelente LIVECD baseado no FreeBSD, o qual já vem preparado para ser um firewall e roteador, o PFSENSE possui um poderoso frontend web para administração de seus recursos.

Esta solução foi até utilizanda no último FISL pela equipe de infra-estrutura da ASL e parceiros.

Para aqueles que não abrem mão de usarem um ambiente 100% GNU/LINUX existem soluções que podem ser alternativas ao PFSENSE.

A seguir apresento algumas distros GNU/LINUX com foco em firewall/router e serviços.

1. Projeto Zeroshell

Opções de imagens:
- LiveCD
- VMare Image
- Compact Flash image
- ISO-CD image

http://www.zeroshell.net/
http://en.wikipedia.org/wiki/Zeroshell

Esta é uma distribuição que está disponível em LIVECD, COMPACT FLASH IMAGES e imagens do VMWARE.

Características principais:

- Radious Server;
- Captive Portal, para autenticação por navegador em hotspots;
- Modo Wireless Access Point, com suporte a 802.1X and WPA protocols, baseado em placas com chipset Atheros.
- Suporte a QOS com controle e garantia de banda por serviços;
- Traffic Shapping;
- VPN com suporte IPSEC/L2TP e OPENVPN;
- Roteamento dinâmico;
- Suporte a bridge 802.1D e protocolo spanning tree;
- Suporte a VLAN IEEE 802.1Q;
- Firewall (Packet Filter/Stateful Package Inspection);
- HTTP proxy com suporte Antivirus
- Bloqueio IPP2P para protocolos em Layer7 através de classificaço do QOS;
- DNS Server para multiplas zonas com suporte a reservo;
- DHCP Server para multiplas subnets com suporte a fixar IP através de MAC ADDR;
- Cliente PPPOE;
- NTP client e server;
- Syslog server para receber e catalogar logs de serviços remotos;
- Autenticaçào Keberos5, NIS e LDAP.
- Certificados X.509;

2. Endian Firewall

Opções de imagens:
- ISO-CD image
- Appliances

http://www.endian.com/en/community/about/
http://en.wikipedia.org/wiki/Endian_Firewall

Principais características:

- Firewall
- VPN
- Proxy HTTP transparente
- Filtro de conteúdo web
- Filtro web para antivirus
- Filtro web para spam
- Filtro de e-mail para antivirus
- Filtro de e-mail para spam
- Hotspot Wireless/Security
- Suporte SIP/VOIP
- IDS
- DHCP Server
- NTP Server
- Estatisticas detalhadas

A empresa Endian oferece appliances com sua solução opensource.

3. Projeto SmoothWall

Opções de imagens:

- ISO-CD image
- SVN Build em Hosts
- – Debian Etch 4 e Sarge 3.1
- – Ubuntu 7.04
- – Redhat 8.0 e 9.04
- – Fedora Core 1-3 e 6-7
- – Suse 9.0

http://smoothwall.org/
http://en.wikipedia.org/wiki/Smoothwall

Principais características:

- Stateful Firewall
- QOS
- SIP Proxy
- IM Proxy
- Estatisticas detalhadas
- DHCP-Server
- Suporte UPNP

4. Projeto IPcop

Opções de imagens:

- ISO-CD image
- USB-FDD image
- USB-HDD image
- ISO-CD image
- PXE image

http://www.ipcop.org/
http://en.wikipedia.org/wiki/IPCop

Inicialmente foi baseado no Smoothwall mas hoje os projetos tem desenvolvimento totalmente distintos e metas divergentes.

Tem tradução para o português do brasil

Principais características:

- Stateful firewall
- – port forwarding
- Suporte VLAN
- HTTP/FTP proxy (squid)
- IDS
- Logs locais ou remotos
- NTP client
- SSH Server
- Traffic Shapping
- VPN

5. Ebox Plataform

Opções de imagens:

- ISO-CD image
- LIVECD image
- Ubuntu 8.04 Packages
- SVN Builds Debian/Ubuntuu

http://www.ebox-platform.com/
http://en.wikipedia.org/wiki/EBox

Esta é uma solução baseada em Debian e mais recentemente Ubuntu.

O projeto EBOX é um framework completo para serviços de rede!

Principais características:

- Balanceamento de carga
- Firewall (netfilter/iptables)
- Proxy transparente com filtro de conteúdo (squid)
- Usuários e Grupos em árvore LDAP compatível com outros módulos (openldap)
- Controle de domínio para rede Windows (samba)
- Servidor de impressão para redes Unix e Windows (samba +cups)
- Servidor de e-mail (posfix + clamav + spamassassin)
- Servidor Jabber (jabberd)
- Servidor DHCP
- Servidor NTP
- Servidor DNS e DNS-CACHE (bind)
- Suporte a VLANS
- Sistema de backup integrado

Infelizmente ela não tem suporte a QOS ou filtros Layer 7 na firewall, mas quem sabe nas próximas versões

Vou tentar avaliar cada distro em máquinas virtuais para fornecer melhores parâmetros, o problema é que estou com uma conexão 3G o que dificulta fazer o download das ISOS, mas vou falando conforme for testando, quem já usa por favor deixe seu depoimento

Bom até agora falei bastante de GNU/LINUX mas nossos irmãos *BSB também tem excelentes projetos na área, vou apresentar 2 projetos para vocês, um deles já foi mencionado no começo do artigo

1. Projeto Monowall

Opções de imagens:

- ISO-CD image
- Raw CF Image para Net45xxx, Net48xxx, Wrap e Generic PC
- Root Tarball

http://m0n0.ch/wall/
http://en.wikipedia.org/wiki/M0n0wall

Principais características

- Stateful packet filter firewall
- IPsec e PPTP VPNs
- Inbound and Outbound Network Address Translation
- Captive portal
- Traffic shaper
- Inbound and Outbound port filtering.
- Support for 802.1q compatible VLANs.
- Multiple IP addresses on LAN and WAN ports.
- Replacement for commercial router

2. Projeto PFSENSE

Opções de imagens:

- LiveCD & Install image
- Embeeded image

http://www.pfsense.com/
http://en.wikipedia.org/wiki/Pfsense

Inicialmente baseado no Monowall.

Principais características:

- Firewall
- State Table
- NAT

- Redundância

- – CARP – CARP do OpenBSD habilitar hardware failover. Duas ou mais firewalls podem ser configuradas com um grupo failover. Se um dos nós para de responder o segundo assume automaticamente. O Pfsese também inclui sincronização de configurações, então se configurar o primeiro nó, os próximos nós também serão configurados automaticamente.

- – pfsync – pfsync consiste em uma tabela com informações da firewall, a qual é replicada para os demais nós. Isso significa que se um dos nós falhar, fazendo com que outro nó tenha que assumir, as conexões existentes serão mantidas, pois isto é importante para prevenindo problemas com serviços oferecidos.

- Balanceamento de carga de entrada ou saída
- VPN – Ipsec, OpenVPN, PPTP
- PPPoE Server
- RRD Graphs Reporting
- Estatísticas em tempo real usando AJAX
- DNS Dinâmico
- Captive Portal
- Servidor DHCP e relay
- QoS
- Traffig Shapper

O PFSense é uma das soluções mais usadas para firewall e roteamento por especialistas.

Fonte: gutocarvalho.net

Entendendo o DNS e o registro de domínios

Com frequência, ouvimos dizer que o sistema de DNS é a maior base de dados do mundo. Sob certos aspectos, realmente é, mas existe uma diferença fundamental entre o DNS e um sistema de banco de dados tradicional (como um servidor MySQL usado por um servidor Web, por exemplo), que é o fato do DNS ser uma base de dados distribuída.

No topo da cadeia, temos os root servers, 14 servidores espalhados pelo mundo que têm como função responder a todas as requisições de resolução de domínio. Eles são seguidos por diversas camadas de servidores, que culminam nos servidores diretamente responsáveis por cada domínio.

Um nome de domínio é lido da direita para a esquerda. Temos os domínios primários (chamados de top level domains, ou TLD’s), como .com, .net, .info, .cc, .biz, etc., e, em seguida, os domínios secundários (country code TLD’s, ou ccTLD’s), que recebem o prefixo de cada país, como .com.br ou .net.br. Nesse caso, o “com” é um subdomínio do domínio “br”.

Embora normalmente ele seja omitido, todo nome de domínio termina na verdade com um ponto, que representa o domínio raiz, de responsabilidade dos root servers. Quando um dos root servers recebe um pedido de resolução de domínio, ele encaminha a requisição aos servidores da entidade responsável pelo TLD (como “.com”) ou pelo ccTLD (como “.com.br”) do qual ele faz parte. Eles, por sua vez, encaminham a requisição ao servidor DNS responsável pelo domínio, que finalmente envia a resposta ao cliente.

Ao acessar o endereço “www.gdhn.com.br”, o cliente começaria enviando a requisição ao servidor DNS informado na configuração da rede (o DNS do provedor). A menos que tenha a informação em cache, o servidor consulta um dos root servers, perguntando: “quem é o servidor responsável pelo domínio gdhn.com.br?”.

O root server gentilmente responde que não sabe, mas verifica qual é o servidor responsável pelos domínios “.br” (o registro.br) e orienta o cliente a refazer a pergunta, dessa vez a um dos servidores da entidade correspondente. O processo pode envolver mais um ou dois servidores, mas eventualmente o cliente chega ao servidor DNS do responsável pelo site (informado ao registrar o domínio) que finalmente fornece o endereço IP do servidor ao cliente:

Assim como no caso do “com”, que é um subdomínio do “br” de responsabilidade do Registro.br, você pode criar subdomínios, como “www.gdhn.com.br” ou “ftp.gdhn.com.br” livremente. Estes subdomínios podem apontar para seu próprio servidor, para um servidor separado, ou mesmo serem usados como aliases para outros domínios. Dentro da sua zona, ou seja, do seu domínio, a autoridade é você.

Configurar o servidor DNS é uma etapa importante na configuração de qualquer servidor que vai disponibilizar serviços para a Internet, sobretudo hospedar sites, já que nenhum visitante vai querer acessar os sites hospedados através do endereço IP.

Registro de domínios

Assim como no caso das faixas de endereços IP, que são delegados pelas RIRs (Regional Internet Registries), como a ARIN (http://www.arin.net/) e a LACNIC (http://www.lacnic.net/pt/), os nomes de domínio são delegados através de entidades menores (com ou sem fins lucrativos), chamadas de “domain name registrars” (ou simplesmente “registrars“), que coordenam o registro, a delegação e a disputa de domínios. Embora o valor anual de manutenção de cada domínio seja relativamente baixo, o enorme volume de domínios registrados faz com que o registro de domínios seja um negócio que movimenta muito dinheiro.

Os requisitos para registrar domínios variam de acordo com o registrar. Para os TDLs, ou seja, os domínios primários genéricos, como “.com”, “.net”, “.org” e outros, não existe muita burocracia; basta escolher uma empresa de registro e pagar.

Você pode encontrar uma lista dos registrars oficialmente reconhecidos pela ICANN no:
http://www.icann.org/registrars/accredited-list.html

O maior é o Godaddy (http://godaddy.com), que cobra US$ 9.99 por ano, por domínio .com (com valores diferentes para outros prefixos), seguido pelo Enom (http://www.enom.com/). Existem também algumas empresas nacionais registradas, como a Locaweb (http://locaweb.com.br). Essas empresas concorrem entre si, o que faz com que os preços variem. Os registros de domínio são oferecidos como se fossem um produto, com direito a descontos e promoções:

Você pode ver estatísticas com relação ao volume de domínios TLD registrados, prefixos mais populares e outros detalhes no: http://www.domaintools.com/internet-statistics/

O ranking dos registrars (baseado no volume de domínios registrados por cada um) está disponível no: http://www.domaintools.com/internet-statistics/registrar-stats.html

Além das empresas listadas na página da Internic, que são os registrars primários, existem inúmeras empresas menores que entram como prestadores de serviço, intermediando o registro, como no caso dos provedores de acesso e de empresas como a Brasnic (http://brasnic.com).

Normalmente, elas cobram mais caro, já que precisam registrar o domínio junto a um dos registrars primários, repassando o valor cobrado por ele, e ainda ganharem alguma coisa. O registro de um domínio .com, que custa US$ 9.99 no Godady (e até 6.99 em outros registrars menores) custa US$ 12.00 na Brasnic, por exemplo.

O registro de domínios .br é menos caótico, pois eles são controlados por uma única entidade, o Registro.br (http://registro.br), uma entidade sem fins lucrativos. A taxa de registro é (enquanto escrevo) de R$ 30 anuais por domínio registrado, mas existem algumas exigências adicionais.

Para registrar um domínio “.com.br”, por exemplo era, até pouco tempo, necessário ter uma empresa aberta em território nacional, para registrar um domínio “.net.br” é necessário ter uma empresa dentro do ramo de telecomunicações e assim por diante. Pessoas físicas (residentes no Brasil, ou que possuam um contato no Brasil) podem registrar apenas domínios específicos, como o “nom.br”, “blog.br”, “flog.br” e outros. Em primeiro de maio de 2008 entrou em vigor uma nova norma, que flexibilizou o registro dos domínios “.com.br”, liberando o registro para pessoas físicas, desde que com um CPF válido.

Existem ainda outros detalhes interessantes, como o fato de empresas estrangeiras poderem fazer o registro apenas através de um procurador. Você pode ver mais detalhes no FAQ:
http://registro.br/faq/index.html

Note que o registro de domínios inclui apenas o cadastramento do domínio e o encaminhamento das requisições aos seus servidores DNS, informados durante o registro. Em muitos casos, são oferecidos serviços adicionais, como a exibição de uma página “em construção” (placeholder), a configuração dos servidores DNS para você, ou mesmo a hospedagem do site. Entretanto, estes são serviços adicionais, que variam de acordo com a empresa de registro escolhida.

Uma prática muito comum é registrar domínios em que você tenha interesse, mas que não pretenda usar de imediato, mostrando uma página genérica, contendo um “em construção” ou alguns links de anúncios. Esta prática é chamada de “domain parking” (reserva de domínios, ou estacionamento de domínios) e é bastante difundida, já que sai mais barato registrar um domínio antecipadamente do que ter que disputá-lo mais tarde. Existem também casos de empresas que deliberadamente registram um grande volume de domínios contendo palavras ou frases populares, com o objetivo de vendê-los mais tarde, ou simplesmente lucrar com cliques de visitantes que acessam os endereços por acidente.

Existem também casos de registros de domínios contendo marcas, ou palavras similares a marcas, com objetivo de enganar os visitantes (encaminhando-os a outras páginas) e/ou lesar ou extorquir os proprietários da marca. Esta prática é chamada de “cybersquatting” (grilagem de domínios) e é ilegal na maioria dos países, incluindo o Brasil.

Embora seja um processo demorado, é possível disputar a posse de um domínio registrado, o que se aplica em casos em que você é o detentor de uma marca registrada, ou é o proprietário de um site que esteja sendo lesado por um domínio similar, registrado com o propósito de roubar visitantes.

Para os domínios primários, o processo é chamado de UDRP (Uniform Domain-Name Dispute-Resolution Policy), cujos detalhes estão disponíveis no: http://www.icann.org/udrp/udrp.htm

Para os domínios ccTLDs, ou seja, os domínios com código de país, que são responsabilidade de entidades separadas, o processo varia. Algumas entidades aceitam a aplicação do UDRP, outras aplicam conjuntos particulares de regras, enquanto outras simplesmente não possuem uma política definida, se limitando a acatar decisões judiciais.

Atualmente (junho de 2008) o Registro.br ainda faz parte da terceira categoria, mas existem negociações com relação à adoção do UDRP. Você pode ver algumas cartas nesse sentido, trocadas entre os responsáveis pelo Registro.br e a ICANN, disponíveis no:
http://www.icann.org/cctlds/br/br-icann-letters-10may07.pdf

Fonte: GuiadoHardware

Ubuntu + Apache2 + Mysql + PHP5 “LAMP”

Aqui uma breve dica de como instalar tudo rapidinho no Ubuntu.Antes de mais nada vamos fazer um sudo apt-get update depois.

sudo apt-get install apache2 mysql-server-5.0 php5 php5-mysql

O simples comando acima irá instalar o apache 2, o mysql 5 e o php5, depois para testar se está tudo devidamente bem instalado crie um arquivo dentro de /var/www por exemplo

sudo vi teste.php

Dentro dele insira a linha <?php phpinfo(); ?>

Salve e saia, agora abra o seu navegador e digite http://localhost/teste.php se estiver tudo correto irás ver uma tela com várias informações sobre o seu servidor.

Dica de módulos a ser feita é a seguinte:

cd /etc/apache2/mods-enabled/
sudo ln -ns ../mods-available/php5.conf php5.conf
sudo ln -ns ../mods-available/php5.load php5.load
sudo /etc/init.d/apache2 reload

Beleza, está tudo pronto? Não! Ainda falta setar uma senha para o banco de dados MySQL, então faça o seguinte:

mysqladmin -u root password (senha que não precisa ser a mesma do sistema)

Pronto, agora temos o Apache, o MySQL e o PHP rodando, pode melhorar?

Claro que pode, um bom administrador de MySQL é o phpmysql, então faça o seguinte:

sudo apt-get install phpmyadmin

Agora se quiser usar a interface é só digitar http://localhost/phpmyadmin/

Mas eu gostaria de ter meu site em um host legal que não fosse meu ip, já que meu ip muda sempre que reconecto, para isso use o serviço do no-ip. Faça o cadastro e o seu domínio logo em seguida, assim:

sudo apt-get install no-ip

Agora vamos criar o host no seu apache assim:

sudo gedit /etc/apache2/httpd.conf

Agora insira o seguinte:

DocumentRoot /var/www/teste
ServerName “aqui vc coloca o host que vc criou no site do no-ip,sem aspas”
allow from all
Options +Indexes

agora vamos no hosts:

sudo gedit /etc/hosts

e coloque o ip da sua placa de redes local e o nome do host que vc criou no site do NO-IP.Exemplo:

192.168.254.10 diekn.serve-no-ip.com

Ok,salve o arquivo.

Agora vamos configurar o No-IP assim:

sudo no-ip -C
sudo no-ip
sudo no-ip -U15
sudo no-ip -S

Depois disso, estará pronto e funcionando e a cada 15 segundos ele atualizará o host no No-IP.

A parte do No-IP, foi retirada do Under-Linux.

Agora construa o seu site e fique tranquilo.

Fonte: andregondim.eti.br

Censurando a internet com o OpenDNS

Um assunto que rende muitas conversas inflamadas é o limite de censura dos pais sobre os filhos, enquanto alguns são muitos restritivos outros pais são completamente permissivos. Em se tratando de internet, controlar onde os filhos navegam pode fazer a diferença caso o pequeno rapaz sofra algum trauma causado por imagens chocantes, textos impróprios ou golpes praticados por estelionatários.

Eu (ainda) não sou pai e portanto não faria nenhuma diferença para mim, mesmo assim, a pedido dum amigo resolví criar um artigo falando sobre o assunto.

Neste artigo vamos falar do OpenDNS, este é um serviço gratuito que provê um DNS (em português : Sistema de Nomes de Domínios) incrementado. O serviço de DNS é responsável por atender solicitações do seu navegador (firefox é um deles) que traduz esses nomes de domínios como hamacker.wordpress.com para um endereço de IP válido. Quando um DNS não consegue resolver a tradução de um domínio então passa uma procuração para outro DNS mais completo e assim por diante até concluir que tal endereço exista ou não. O OpenDNS é um serviço de DNS como qualquer outro, mas que permite que certos endereços sejam respondidos como inexistentes e redirecionando-os para uma página de busca, deixando a navegação mais rápida e bloqueando endereços de internet que promovam pornografia, nudez, golpes, anonimato,… em geral sítios considerados perigosos a crianças, adultos e corporações.

Por exemplo, voce digita www.playboy.com.br e o OpenDNS então procura no banco de dados e determina que esse é um endereço proibido e conclui a operação numa página semelhante a essa :

O OpenDNS é o método menos invasivo que existe, pois é fácil de implementar e não necessita que programas estranhos sejam instalados no seu computador.

Voce precisa de um registro no opendns.org e registrar seu ip fixo/dinamico na rede deles. Esse método é muito bom, pois você pode determinar que critérios bloquear ou usar perfis de configuração prontos para proibir sítios de pornografia, mas deixar liberado sítios de nudez, ou bloquear um sítio em especifico ou ainda determinar atalhos (nomes curtos) para sítios muito acessados. Além de tudo isso, é possível ver as estatísticas de acesso de sua rede à Internet.

1) Habilite o OpeDNS no seu computador.

Mas não vou ensinar a implementar o OpenDNS dessa forma tão completa, o motivo é que eu teria de detalhar procedimentos de preenchimento de formulários, baixar um pequeno programinha para quem usa ip dinâmico e criar toneladas de telas e isso levaria muito tempo.

A maneira que vou ensinar é simplesmente apontar o seu micro para usar os servidores DNS do OpenDNS.

Acesse o menu do GNOME->Administração->Rede e em seguida acesse a guia “DNS” :

Clique em ‘Excluir‘ para remover os DNS existentes, porém anote-os antes num pedaço de papel para que numa situação imprevista você tenha a possibilidade de retorna-los.

A seguir clique em ‘Adicionar’, e adicione os seguintes servidores DNS :

208.67.222.222
208.67.220.220

Clique em ‘Fechar’, e pronto, voce já estará usando o OpenDNS e restringindo seu computador a sites que o que o OpenDNS acha que voce deve ser protegido. No entanto, isto pode ser insuficiente e vamos completar o registro e ter mais abrangência com o uso de filtros.

Atualização e Alerta Importante : Infelizmente notei que em alguns casos depois de um reboot, os DNSs acima se perderam, para corrigir isso e ter certeza de que não vai se repetir novamente dê um ALT+F2 e execute “gksu gedit /etc/dhcp3/dhclient.conf” e adicione as seguintes linhas ao arquivo:

# Adicionando o OpenDNS :
prepend domain-name-servers 208.67.222.222,208.67.220.220;

Salve e saia do editor.

Abra o terminal (bash) e execute o seguinte comando :

sudo ifconfig eth0 down

sudo ifconfig eth0 up

O comando acima vai reiniciar sua placa de rede.

Com o procedimento acima, sua rede/micro já estará usando o OpenDNS, no entanto, o padrão para bloqueio é bastante permissivo, se prosseguir com os passos seguintes voce vai estender as funcionalidades do OpenDNS.

2) Passo 2

Acesse o endereço http://www.opendns.com/ e clique no botão “Get Started” que aparecerá, semelhante a este :

3) Passo 3

Na tela seguinte voce tem três opções a escolha, escolha “Computer” para implementar o OpenDNS apenas no seu computador :

Passo 4) Criar uma conta no OpenDNS.org

Acesse novamente o navegador e clique na opção “Step 2 – Create an account” como mostra a figura :

E a seguir voce será direcionado a um formulário de registro como este :

Preencha o formulário acima com informações válidas, especialmente o email, pois será com este que será solicitado uma confirmação através de uma mensagem. Não esqueça de clicar no botão “Create Account” no final.

Se tudo ocorrer conforme o planejado, voce receberá a seguinte tela de confirmação :

Uma mensagem de confirmação foi enviada para seu email, portanto, abra tal mensagem e clique a URL que a acompanha, semelhante a esta :

Passo 5) Adicionando a sua rede ao OpenDNS

Após a confirmação voce será redirecionado à página de redes do OpenDNS, onde seu objetivo é adicionar seu computador/rede.

Clique no link exibido acima “Add a network” e um novo formulário surgirá :

O IP acima como padrão é o seu. Em “label” você digita um nome da rede (guarde este nome, pois voce usará ele depois) identificando aquele IP e em seguida clique em “Add this network”. O IP automatico que surge é sempre o seu, se voce estiver por traz dum firewall então será o do firewall e neste caso uma mascara de rede também poderá aparecer.

Se o seu IP é FIXO, então o processo de configuração pára por aqui, voce deve pular os passos seguintes e ir direto para o final do artigo onde há o subtópico Recursos Principais.

Se seu IP é dinamico, ainda lhe resta os passos seguintes.

Passo 6) IP DINÂMICO

Ainda na DashBoard do OpenDNS, vá na guia “Settings” :

No lado esquerdo, mais embaixo voce encontrará um botão “Setup a dynamic IP” então clique nele :

E então uma tela como a seguir será mostrada :

Habilite a opção “Enable dynamic IP update” e em seguida clique no botão “Apply”.

Passo 7) Instalando o cliente de IP Dinâmico para o OpenDNS.

Pois é, está tudo pronto, só falta agora o OpenDNS reconhecer quando o seu computador mudar de IP, o segredo está no cliente/protocolo DDNS que voce terá de instalar. Se não estiver disposto a instalar agora, apenas acesse a URL :

https://updates.opendns.com/nic/update?

Uma janela de autenticação se abrirá solicitando o login e senha. Talvez seja necessário esperar alguns minutos antes de começar a navegação.

Para usar um cliente DDNS eu recomendo o ddclient, pois já existe no repositório e é fácil de configurar, abra o terminal e execute :

sudo apt-get install ddclient

sudo gedit /etc/default/ddclient

E adicione este exemplo de conteúdo de configuração :

run_daemon=”true”

ssl=”yes”

E adicione este exemplo de conteúdo de configuração /etc/ddclient.conf :

sudo gedit /etc/ddclient.conf

E que contenha este teor :

##
## OpenDNS.com account-configuration
##
ssl=yes
use=web, web=whatismyip.org
server=updates.opendns.com
protocol=dyndns2
login=[login-criado-no-opendns]
password=[senha-criada-no-opendns]
[nome-de-rede-criado-no-opendns]

Não faz a mínima idéia do que é [nome-de-rede-criado-no-opendns], né ? No exemplo, lá em cima, o nome da rede criado foi [minha-casa], ajudou ?

Salve o arquivo e saia. Teste a execução com o comando :

sudo ifconfig eth0 down ;  sudo ifconfig eth0 up

ou voce também pode faze-lo como qualquer serviço :

/etc/init.d/ddclient restart

Se tudo ocorreu OK, então ao reiniciar o computador o serviço ddclient fará a autenticação automaticamente.

O ddclient não é o único método/programa para autenticação, existem outros, uns mais fáceis e outros mais difíceis. Uma lista desses programas (win, linux e mac) que podem ser usado é encontrada no endereço : http://www.opendns.com/support/dynamic_ip_downloads/

O mais recomendado é o inadyn, no entanto, voce tem que usar o que está disponivel no sítio da URL acima, pois o contido no repositório não fornece suporte ao OpenDNS (requer ssl). Eu uso IP FIXO, e tive que compilar vários howto’s diferentes para chegar ao ddclient da forma como esta descrito acima, portanto posso estar errado em alguma parte, se alguém tiver alguma sugestão ou acerto ela será bem vinda nos comentários.

Recursos principais

Vá novamente na guia “Settings” e clique no link “Adult Site Blocking” como mostra a figura a seguir :

Será exibido um formulário com uma relação de categorias do que pode ser bloqueado, selecione as opções que gostaria de bloquear :

http://www.opendns.com/support/dynamic_ip_downloads/

Clique no botão “APPLY” para colocar em operação o filtro.

Este foi apenas o básico, na dashboard voce encontrará mais informações como incluir um logo/foto acompanhado duma mensagem que aparecerá quando houver um bloqueio, listas brancas, listas negras, habilitar/desabilitar fishing (sites clonados) e outros recursos.

Funciona ?

O sítio deviantART inteiro está disponível, no entanto, veja o que acontece quanto experimento acessar as fotos na sessão de nús artisticos :

Os quadros que deveriam trazer as fotografias vinheram apenas com o logo vazio. Esse comportamento só foi encontrado no deviantART e não é o normal, o normal é o bloqueio como podemos ver a figura abaixo :

Sim, funciona !

Problemas ?

Conseguí fazer o teste num micro de um colega com o IP Dinamico e após a conecção à internet ainda leva alguns minutos (5 a 10 minutos) para o DNS começar a bloquear algo.

Tentei compilar o cliente DDNS recomendado que é o inadyn, ele compila, porém na hora de rodar dá um belo core-dump no Ubuntu Gutsy, se alguém conseguiu faze-lo rodar por gentileza reporte. Por enquanto, o ddclient vai dando conta do recado.

Conclusão

Eu demonstrei o OpenDNS como um método para controlar acesso à Internet, no entanto, ele pode ser utilizado também por empresas para controlar o acesso de seus funcionários à Internet. No próprio sítio www.opendns.org há howto’s prontos para como configurar um roteador ou no caso de um proxy então como configurar o DNS local e DHCP. É estupidamente fácil e em 5 minutos você põe sua empresa integrada ao OpenDNS.

Todo o sistema pode ser burlado, ainda mais se tratando de receitas de bolo escritas num blog. O OpenDNS também bloqueia proxies abertos na Internet, até mesmo o TOR desde que tais serviços usem nomes de domínios como referencia. Obviamente, é requerido que ninguém além do administrador possa configurar uma rede, senão já era essa pequena receita de bolo.

Fonte: hamacker.wordpress.com

Configurando Servidor de Nomes – DNS

Introdução

 

Referir-se aos hosts pelo seu endereço IP é bastante conveniente para computadores, porém para as pessoas o ideal é referir-se pelo seu nome. Para isso precisamos de uma tabela que converta o IP em nome e nome em IP.

Porém com o crescimento, já com milhares de computadores e outros milhares entrando, na internet fica impossível para qualquer um manter uma tabela desse tipo sempre atualizada. É ai que entra o servidor DNS, ou servidor de Nomes. O Servidor de nomes é uma base de dados, pública, mantida pelos sites que proporcionam a tradução já citada.

O arquivo hosts.txt

A velhos tempos, quando haviam poucos computadores conectados a ARPAnet (antiga rede predecessora da internet), cada computador tinha um arquivo hosts.txt, que depois foi alterado para o /etc/hosts no UNIX. Esse arquivo continha informações sobre todos os hosts da rede. Com tão poucos computadores, o arquivo era pequeno e fácil de mantê-lo atualizado.

A manutenção do arquivo hosts.txt era mantido pela SRI-NIC. Quando os administradores queriam fazer uma alteração no arquivo, enviavam a solicitação por e-mail. Quando uma alteração era feita, os administradores baixavam o arquivo via FTP.

A medida que a internet crescia, a idéia da administração centralizar os nomes dos hosts e a atualização do arquivo hosts.txt tornaram-se um grande problema, então a SRI-NIC projetou, no início dos anos 80, um banco de dados distribuído para substituir o hosts.txt. Esse novo sistema ficou conhecido como Domain Name System (DNS).

O DNS

O DNS é um banco de dados distribuído criado sob uma estrutura de domínio hierárquica. Cada computador que se conecta a internet o faz a partir de um domínio Internet. Cada domínio internet tem um nome de servidor com um banco de dados dos hosts em seu domínio. Quando um domínio se torna muito grande, a tarefa pode ser delegada a subdomínios, a fim de reduzir a carga administrativa.

O arquivo /etc/hosts

Ainda que o DNS se constitua no principal meio de resolução de nomes, ainda é encontrado na maioria das máquinas o arquivo /etc/hosts. Esse arquivo pode acelerar na resolução de nomes solicitados com freqüência, como o IP local. Além disso alguns nomes tem que ser resolvidos, no boot, antes que um DNS seja utilizado, como exemplo o caso de servidores NIS. Esse mapeamento é definido no arquivo /etc/hosts.

Exemplo de arquivo /etc/hosts:

#IP                  Endereço                 Alias
127.0.0.1            localhost
192.168.1.1          servidor                 www
72.51.46.57          www.vivaolinux.com.br    vivaolinux

A coluna a esquerda é o IP a ser resolvido. A coluna seguinte é o nome do host correspondente àquele IP. Qualquer coluna seguinte será alias para o host.

Instalando o servidor DNS

No Debian a instalação do servidor de nomes é muito fácil, basta, como root, digitar o seguinte comando em um terminal:

# apt-get install bind

Com esse comando iremos instalar o bind, que é o padrão da distribuição Debian. Poderia ser instalado também o named, que pode ser a melhor opção para outras distribuições, porém, não entraremos nesse caso.

Obs.: O servidor DNS e o cliente DNS são diferentes.

Todo computador Linux habilitado para comunicar-se entre rede possui um software chamado de cliente DNS, também conhecido como resolver. O resolver simplesmente consulta um servidor DNS atribuído no arquivo /etc/resolv.conf. A consulta segue a ordem do arquivo.

Servidores DNS retornam os valores consultados após consultarem o arquivo /etc/bind/named.conf e as referências para as quais ele aponta. Os clientes perguntam e os servidores respondem, muitas vezes após consultarem outros servidores.

A confusão muitas vezes surge quando temos o cliente e o servidor em uma mesma máquina, principalmente quando o cliente consulta o servidor da mesma máquina. Por isso, sempre devemos lembrar de que o cliente ou resolver utiliza o /etc/resolv.conf. Todos os outros como o /etc/bind/named.conf e os arquivos apontados por ele pertencem ao servidor.

Terminologia DNS

Cliente DNS – Componentes de software em todos os computadores da rede que transformam o endereço IP em nome e nome em endereço IP. Em máquinas Linux Debian, o cliente busca informações no arquivo /etc/resolv.conf.

Resolvedor – Para propósitos práticos, um sinônimo para Cliente DNS.

Servidor DNS – Componente de software que retorna a tradução de endereço IP em nome e de nome em endereço IP ao cliente DNS que solicitou. Em máquinas Linux Debian, o servidor DNS busca suas configurações no arquivo /etc/bind/named.conf.

Resolver – Converte endereço IP em um nome e um nome em endereço IP. Isso é feito pelo DNS e às vezes por outro software.

Zona – Um subdomínio ou sub-rede sobre os quais um servidor DNS possui autoridade.

Mestre – Um servidor DNS com autoridade sobre uma zona cujos dados são derivados dos arquivos de dados local. Assim um servidor de nomes pode ser mestre para algumas zonas e escravo para outras.

Primário – Sinônimo para mestre.

Escravo – Um servidor de nomes cuja autoridade sobre uma zona depende de dados derivados de outro servidor de nomes em uma zona de transferência. O outro servidor de nomes tanto pode ser um mestre como um outro escravo. Observe que um servidor de nomes pode ser mestre para algumas zonas e escravo para outras.

Secundário – Sinônimo para escravo.

Zona de Transferência – Uma transferência feita entre um servidor DNS mestre ou escravo e um servidor DNS escravo. O escravo inicia a zona de transferência após um tempo de refresh ou após ser notificado de que os dados no servidor remetente foram alterados.

Configurando um servidor DNS

O servidor DNS é um sistema potencialmente complexo, configurado por uma série de arquivos surpreendentemente confiáveis. Esses arquivos são formados por um arquivo de boot e vários arquivos de dados de zona, onde cada arquivo de zona é apontado por um registro de zona no arquivo de boot.

Com os exemplos essa explicação ficará mais clara.

No Debian, com o bind instalado, o arquivo de boot DNS é o /etc/bind/named.conf.

Comentários neste arquivo podem ser feitos de três formas:

/* estilo c */
// estilo c++
# estilo shell

Outras declarações seguem o formato:

Keyword {statement; statement; …; statement;};

Tudo neste arquivo é delimitado por chaves, espaço e ponto-e-vírgula. Logo, espaçamento múltiplos, tab, quebra de linha não afetam a configuração.

Inclua no arquivo o apontamento da zona que corresponde ao seu domínio, informando em qual arquivo ele deve procurar a configuração de zona quando o seu domínio for digitado.

zone “dominio.casa” { # domínio da rede que deseja incluir no DNS
type master;
file “/etc/bind/dominio.casa.zone”;   # arquivo que conterá as informações para tradução do nome
};

Agora inclua o apontamento para o IP reverso. Neste caso, qualquer endereço ip na sub-rede especificada será tratada pelo arquivo apontado por ele.

zone “1.168.192.in-addr.arpa” {      # endereço da sub-rede
type master;
file “/etc/bind/named.198.168.1″;    # arquivo de configuração que tratará o IP
};

Os arquivos de zona, no nosso caso estarão na diretório /etc/bind/. Os arquivos de zona são apontados pela declaração zone do arquivo de boot.

A primeira coisa a entender sobre os arquivos de zona é que sua sintaxe é totalmente diferente do arquivo de boot named.conf.

Há 10 registros possíveis:

• SOA – inicialização de autoridade

• NS – nome do servidor

• A – registro de endereço

• PTR – registro de ponteiro

• MX – intercâmbio de carreio

• CNAME – nome canônico

• RP e TXT – as entradas de documento

• HINFO – informações sobre os host

• NULL – registro de recurso nulo sem formato de dados

Supondo que o endereço de sua sub-rede seja 192.168.1 e que o servidor é 192.168.1.1, o computador 1 é 192.168.1.2 e o computador 3 192.168.1.3.

Crie o primeiro arquivo o /etc/bind/dominio.casa.zone e adicione o seguinte código:

$TTL    604800
@        IN SOA dominio.casa. root.dominio.casa. (  # indica para qual domínio o SOA é obrigatório
200007201       ; serial (d. adams)   # Serial que mostra aso DNS secundários como realizar transferência de zona
28800           ; refresh       # indica o tempo em segundos de intervalo para o servidor DNS secundário consultar o primário para saber se houve alteração
14400           ; retry      # tempo em segundo para conexão com o servidor primário caso a tentativa no tempo de refresh falhe
3600000         ; expiry  # tempo de descarte das informações no cache
84400 )         ; minimum  # indica quanto tempo os dados devem ser guardados no cache antes que expire a validade
;

www             IN A    192.168.1.1
www2            IN A    192.168.1.1
www3            IN A    192.168.1.1
serv            IN A    192.168.1.1
comp1           IN A    192.168.1.2
comp2           IN A    192.168.1.3

@               IN MX 10 dominio.casa.c
@               IN NS    dominio.casa.
@               IN A    192.168.1.1

Neste caso o endereço www.dominio.casa, www2.dominio.casa, www3.dominio.casa e serv.dominio.casa se referem ao mesmo IP ao 192.168.1.1.

O host comp1.dominio.casa se refere ao IP 192.168.1.2 e comp2.dominio.casa te levará ao micro com IP 192.168.1.3.

No caso do IP reverso, crie o arquivo /etc/bind/named.198.168.1 com as seguintes linhas:

$TTL    604800
@       IN      SOA     dominio.casa. root.dominio.casa.  (
2000072001 ; Serial
28800      ; Refresh
14400      ; Retry
3600000    ; Expire
86400 )    ; Minimum

@       IN      NS      dominio.casa.
10      IN      PTR     dominio.casa.

Os dados no arquivo de IP reverso tem o mesmo significado do arquivo anterior.

Fonte: Vivaolinux! Autor: Geraldo José Ferreira Chagas Júnior <gjr_rj at msn.com>