1.

Instalação do FreeBSD:

1.1 Bootando o Sistema.:

Existem várias maneiras de bootar o seu sistema para a instalação do FreeBSD, mas
trataremos, nesse documento, apenas das duas maneiras mais usuais.

A Primeira forma de bootar seu sistema, e mais recomendada caso seu sistema permita,
é bootar pelo CD, para isso basta configurar o Setup da BIOS da sua placa mãe para
procurar pelo boot primeiro no CD. A maioria das placas mães mais atuais permitem esse
recurso.

A segunda maneira é a mais comum de todas, e é a que será dada mais ênfase, que é o
boot por disquetes. No próximo Item você vai saber como e onde criar seus discos de boot,
mas nesse momento, vamos aos fatores práticos...

Com os discos de Boot na mão, você deve configurar o Setup da BIOS da sua Placa Mãe
para procurar pelo Boot primeiro no Drive de disquetes (normalmente tido com A:\, floppy,
ou apenas A no Setup da BIOS), então iniciar seu Sistema com o disco do 'kern.flp' para o
primeiro Boot.

Você verá o seu sistema bootando, algumas informações sobre seu Sistema e Sobre o
Boot do sistema a ser instalado serão mostradas, e, após o final, o sistema pedirá o
segundo disco, chamado de 'mfsroot' (mfsroot.flp). Agoura sim o Kernel do seu sistema
será carregado, e então o boot se completará e o menu de instalação, o sysinstall, será
carregado.

1.1.2. Criando os Discos de Boot.:

Existem duas maneiras de se criar os discos de Boot para a instalação do FreeBSD, a

primeira é pelo MsDos/Windows e a segunda é via qualquer sistema Unix, inclusive um
outro FreeBSD. Como supomos que a maioria das pessoas que vão ler esse documento
estarão migrando de algum sistema Unix, como o Solaris ou algum clone de Unix, como o
Linux, então imagina-se que elas queiram fazer seus discos de boot a partir desse
método;

Em ambos os casos serão necessárias as imagens do 'kern' e do 'mfsroot' que podem

ser encontradas no diretório 'floppies' do CDRom do seu RELEASE, ou em
ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/4.3-RELEASE/floppies/, onde '4.3-
RELEASE' se refere ao Release atual do sistema. Se você tiver problemas de
congestionamento nesse site, tente os espelhos nacionais
(ftp://ftp.br.freebsd.org/pub/FreeBSD/).

Dentro dos diretórios específicos de cada versão do FreeBSD existe o diretório de

Floppies (discos) da distribuição. Baixe as imagens do kern.flp e do mfsroot.flp referentes
à versão que você vai instalar. Como nosso documento é escrito a partir da versão 4.3-
RELEASE, é do diretório floppies do 4.3-RELEASE que nós faremos o download das
imagens. Informações adicionais podem ser encontradas em http://freebsd.eeviac.org é
claro, e também http://eeviac.org

Bem, com as imagens em mãos, a criação dos discos de boot devem ser feitas, no Unix,
com o comando "dd if=kern.flp of=/dev/fd0" e "dd if=mfsroot.flp of=/dev/fd0" ]:-) Pronto...
Eis os dois discos prontos... Esse é um processo simples e conhecido se você está
migrando de outro sistema Unix ou clones. Se você vai fazer seu disco de Boot a partir do
Windows/Dos, você vai precisar do aplicativo rawrite.exe que pode também ser
encontrado dentro do diretório 'tools' nos endereços citados acima, ou em qualquer CD
com distribuições Unix, inclusive no CDRom do RELEASE do FreeBSD, também sob o
diretório 'tools.'

A Utilização do rawrite também já deve ser conhecida da maioria das pessoas que estão
lendo essa documentação do FreeBSD, mas a sintaxe deve ser: "rawrite -f kern.flp -d a -n"
e "rawrite -f mfsroot.flp -d a -n" ou simplesmente digite rawrite e siga as instruções do
prompt.

1.2 Menu de configuração do Kernel.:

Logo no início, o primeiro item da instalação, te da a opção de configurar o kernel do

sistema para bater com as informações do seu hardware. Nesse menu de configuração do
Kernel, você tem três opções (figura 1), onde, na ordem:

1 - A primeira é para você pular a configuração do kernel, caso você tenha certeza que
tudo já está certo, diz na legenda... :-);

2 - A segunda, te oferece uma configuração texto-visual do kernel, mostrando seus

dispositivos e permitindo que você altere as interrupções, endereço de acesso à memória,
e ‘o diabo a quatro’ no seu sistema. Essa opção é tida como a mais fácil;

3 - A Terceira é para os Experts, é uma configuração mais avançada do seu Kernel,

logo na instalação, contudo é a mais indicada para enviar os parâmetros necessários pro
kernel poder controlar seu hardware. O uso é bem fácil, e o comando help proporciona
uma legenda fácil de ser entendida. São passados parâmetros pro kernel basicamente
com a sintaxe 'intem_a_configurar <device> [valor]', por exemplo: port ed0 0x0300 e
também irq ed0 9, onde, na ordem, essas instruções alteram a porta da device 'ed0'
(interface de rede padrão NE2000) para '0x300' e alteram sua irq para 9. Várias outras
opções são suportadas e como ja dito, o comando help é bem claro nessa opção.

Não se espera que ninguém que esteja disposto a usar essa documentação da EEVIAC
seja um expert em hardware, mas queremos deixar claro que se você está vindo de um
outro sistema Unix qualquer, e ainda não aprendeu a conhecer ao menos o Hardware que
você tem em casa, eis a grande oportunidade da sua vida para descobrir as interrupções
(IRQs) e DMA's (acesso direto a memória) do seu Modem, Placa de Som, Vídeo, Mouse,
Unidade de fita... ]:-)

Bom, mas para não criarmos longas dores de cabeça logo no início, vamos pular essa
pré-configuração do Kernel e escolhermos a Primeira opção: SKIP KERNEL
CONFIGURATION. Porque pular? Você vai ver que é muito mais interessante compilar o
seu Kernel depois da Instalação já pronta.

1.3. /stand/sysinstall - O Menu Principal

Pode se acostumar com essa carinha (figura 2)... você vai ver esse menu muito durante
sua vida de Usuário/Administrador de FreeBSD. O Sysinstall é a principal ferramenta de
configuração e administração de recursos básicos no FreeBSD. E eis também a principal
diferença na instalação do FreeBSD em relação a outros Unix e clones de Unix.

Esse Menu te oferece todos os recursos de Instalação, Administração, Configuração,

Documentação e uma série de outras opções, por isso faremos uma Análise de cada Item
desse Menu:

1.3.1 Usage - Quick Start - How to Use This Menu;

É Basicamente um guia de por onde começar a se encontrar nesse menu, fala sobre a
movimentação no Menu (Teclas e Comandos) e do que cada opção vai tratar. Não é
necessários falarmos essas Teclas, uma vez que tudo é bem intuitivo: Setinhas movem
pra cima e pra baixo, tecla de ESPAÇO seleciona ou entra na opção, ENTER confirma ou
alterna o Menu, ESC sai... enfim... tudo bem fácil.

1.3.2 Standard - Begin a Standard Installation (recommended);

É por onde deve-se começar uma instalação padrão, ou seja, a instalação default, onde
tem um pouco de tudo, e tudo de importante... é a instalação recomendada pelo sistema...

1.3.3 Express - Begin a Quick Installation (for the impatient);

A Tradução do Item já descreveria tudo: 'Inicia uma Instalação Rápida, para os

impacientes'. É uma instalação básica com algumas coisinhas a mais... Seria uma
instalação mínima com algumas adições... :-P

1.3.4 Custom - Begin a Custon Installation (for the experts);

Essa é a opção para inicializar uma instalação personalizada, para os experts, diz o
sistema... Na verdade é necessário um pouco de conhecimento do que se quer para o seu
sistema e o que não é necessário, por isso é recomendada para um usuário já com
alguma experiência, pois pode definir bem o que serve ou não para ele... Essa opção te
oferece a possibilidade de modificar algumas informações do sistema também... deve-se
ter cuidado, e aproveitar ao máximo :o)

1.3.5 Configure - Do post-install configuration of FreeBSD;

Será a opção mais visitada por você depois da instalação: te permite configurar ou
reconfigurar vários dispositivos do sistema, incluindo ferramentas para administração de
usuários, hardware, interface, sistemas e etc;

1.3.6 Docs - Installation instructions, README, etc;

Contém documentação sobre o sistema, instruções para instalação, arquivos README,

documentação sobre algumas implementações do sistema, enfim é uma fonte ótima de
documentação disponível pra ser consultada durante e após a instalação. Contém
também informações de Copyright e sobre a licença BSD. Tudo em inglês.

1.3.7 Keymap - Select Keyboard Type;

Te permite configurar o seu teclado... Aqui começa um pouco da importância de

conhecer o seu hardware... Entre e escolha o mapeamento do seu Teclado...

1.3.8 Options - View/Set various installation Options;

Permite que você veja e configure várias opções do sistema, algumas delas muito
importantes e que merecem algum cuidado, outras nem tão relevantes... Veremos essas
mesmas opções mais detalhadamente adiante...

1.3.9 Fixit - Enter repair mode with CDROM/Floppy or start shell;

Permite que você entre no seu sistema para arrumar algum problema de instalação ou
má configuração que por ventura possa evitar que seu sistema trabalhe eficientemente...
tem a função dos modos de resgate (rescue) de outros sistemas Unix, a tradução direta
desse Item poderia ser: Arrume Isso!

1.3.10 Upgrade - Upgrade An Existing System;

Para você atualizar o seu sistema, caso já exista um FreeBSD mais antigo instalado.

1.3.11 Load Config - Load default install configuration;

Pede para você adicionar um arquivo via disquete com extensão .cfg que contenha as
informações para que a instalação se faça. Funciona assim: imagine que você,
administrador Unix tenha como salvar as opções básicas das instalações que você faz,
que você nunca mais tenha que selecionar aqueles pacotes um por um, satisfazendo as
suas necessidades, se suas necessidades são sempre as mesmas, e ainda por cima se
pudesse salvar o que você espera dos seus devices e partições em todas as instalações
que você for fazer... pois é... é a possibilidade de fazer isso tudo, que essa opção do
FreeBSD oferece... uma facilidade interessante pra quem sempre precisa fazer instalações
custom.

1.3.12 Index - Glossary of Functions;

É um índice de todas as funções que esse menu pode oferecer, fazendo uma breve
descrição da função e já te levando direto para a tela de configuração da mesma... :-)

1.4. Custom - A Nossa Instalação (figura 3);

Para continuarmos com nossa instalação, teremos que escolher entre um dos modos
(Custom, Standard ou Express), e a nossa opção é a Instalação Personalizada. Não que
você deva se sentir o devorador dos Unix (Unices) para instalar em modo Expert, contudo,
nossa intenção é documentar a opção mais completa, então vamos em modo Experiente.
 Mesmo porque não esperamos que quem esteja seguindo esse manual, deseje instalar
em modo Express ou uma instalação Padrão... Afinal a comunidade BSD da importância
a coisas que sejam mais que o comum, o padrão. ]:)

Então seguiremos todas as opções do próximo Menu (figura 3). Escolha 'Custom' com a
barra de espaço e analisaremos:

1.4.1 [X Exit] - Exit this menu (exiting to previous);

Seguindo a tradução: Faz você sair desse Menu, voltado para o menú anterior que foi
descrito acima...

- Não tem necessidade de informações adicionais.

1.4.2 [2 Options] - View/Set various installation Options (figura 4);

Lembra-se da opção 1.3.8 na descrição do Menu anterior (acima)? Bem, agora sim
iremos analisa-la de forma mais detalhada:

- NFS Secure: Escolha YES (com a tecla de espaço)

NFS é o sistema de Arquivos Nativo do Unix, se você for habilitar NFS é bom que ele
esteja em modo seguro, concorda?

- NFS Slow: Escolha YES

Essa opção diminui a velocidade do tráfego de informações na rede NFS, e isso é ótimo
quando não se tem uma rede veloz, com placas de 100mbps e outras desse tipo. Não
adianta sua rede querendo os dados em uma velocidade que as outras maquinas não
suportem, então, para evitar gargalos na rede, foi implementada essa opção. Se sua rede
for de alta velocidade, escolha NO para que o NFS seja o mais rápido possível.
 - Debugging: Escolha YES

Vamos escolher YES, porque queremos ter o número maior de informações possíveis
sobre nossa instalação, certo? Dica: Use o segundo terminal (ALT+F2) durante o processo
de instalação pra você ver detalhes do DEBUG da mesma.

- No Warnings: Escolha NO

É importante você ser advertido do que esteja acontecendo de errado com seu sistema...
Mensagens de erro aqui não são como no Windows, uma rotina... aqui deve-se levar a
sério, e serem analisadas.

- Yes To All: Escolha NO

Adivinha porque? Essa opção marca todas as outras com um SIM. Esse não é o nosso
caso.

- DHCP: Escolha NO

Mesmo se você pretende se conectar via modem a um provedor, essa não é a hora de
startar DHCP no FreeBSD; Essa opção deve ser utilizada se você for instalar o sistema por
rede, e se o endereço IP da sua estação não for definido de forma estática.

- FTP Username: Mantenha ftp

Como nossa instalação será feita por mídia comum (CDRom) então essa opção não será
utilizada. Essa opção é extremamente importante se você for instalar seu FreeBSD
remotamente, em rede, via FTP. Se o servidor FTP onde você vai se conectar não aceitar
usuários anônimos, normalmente 'ftp' ou 'annonymous' então essa opção permite que
você defina um usuário e senha válidos para a conexão FTP.

- Editor: Mantenha /usr/bin/ee

Mante-lo porque é o editor que com certeza você sabe que estará instalado antes de
você portar outros Editores... o VI também faz parte da instalação, mas se o editor default
é o ee, vamos mante-lo então. Faz parte do feeling do FreeBSD;

- Tape Blocksize: Mantenha 20

Você vai usar unidade de fita? Se não, não há porque mudar o tamanho do bloco das
fitas. Mas se for, você saberá quais especificações melhor pra sua unidade de fita de
dados.

- Extract Detail: Mantenha high

Mais uma vez, toda informação possível é bem vinda, então que os detalhes da
extração estejam no nível alto (high);

- Release Name: Altere de acordo com sua necessidade, ou não altere.

Pessoalmente não sei se existe algum problema em mudar esse nome, o único
problema que eu pude constatar é que na instalação, apareceu um prompt dizendo que o
nome do RELEASE do FreeBSD que eu estava utilizando não coincidia com o RELEASE
que continha no CDRom, e se eu quisesse que a instalação continuasse mesmo assim...
Várias vezes continuei e outras não... nunca houve diferença, a não ser que algumas
especificações do meu sistema ficavam com o nome de EeviacBSD-4.3, o que eu achava
kitsch. Mas atenção, se você for fazer sua instalação por rede, sem o CDRom, então o
nome aqui deve ser exatamente o mesmo nome do RELEASE que o sistema vai procurar
quando se logar no servidor FTP remoto. Se a instalação em questão for de algum
snapshot do sistema -CURRENT então você deve preencher com algum nome parecido
como FreeBSD 5.0-20001223-CURRENT, que é a versão do snapshot da data em questão.

- Install Root: Mantenha /

Usualmente a Raiz de nossa instalação será sempre '/'.

- Browser Package: Mantenha lynx

É Legal utilizar o lynx como browser default, primeiro porque você não tem muita
opção sem portar antes da instalação, e depois, porque faz parte do feeling Unix... lynx, vi
editor...

- Browser Exec: Mantenha /usr/local/bin/lynx

Porque é o caminho onde o sistema vai procurar o executável do Browser escolhido. ]:)

- Media Type: Escolha agoura, ou mais tarde.

Se a opção estiver '<not yet set>' ou seja: ainda não configurada, e você apertar a tecla
de espaço em cima, o 'sysinstall' te levará para a tela de seleção de mídia, ou seja, onde
você vai escolher de onde deseja instalar (Partição DOS, FTP, HTTP, Linux, CDRom...).
Nossa opção de instalação é CDROM, então se você selecionar agoura, ou deixar pra
depois, quando chegarmos na Seleção do Tipo de Mídia, não vai fazer diferença! Tudo bem
se escolher agoura ou mais tarde... ];)

- Media Timeout: Mantenha 300 ou suba um pouquinho

É o tempo que o sistema deve esperar (em milesegundos) por alguma informação antes
de retornar uma prompt de erro ou demora... Se você vai instalar por outros meios que
não o CDRom, como via FTP por exemplo, é interessante elevar um pouco esse número,
senão, não há porque seu CDRom não responder em 300ms...

- Package Temp: mantenha /usr/tmp

É o caminho onde os pacotes serão temporariamente alojados durante a instalação. Se

quiser, selecione outro. Fica à critério e necessidade do administrador.

- Newfs Args: mantenha -b 8192 -f 1024

São os comandos para executar quando para criar um Novo File System. Esses
argumentos indicam o tamanho do bloco e inodes.

- Config Save: Mantenha YES

 Para salvar as configurações.

- Re-scan Devices: Se necessário, utilize-a.

Se você clicar com a barra de espaço, irá re-procurar e re-analisar os Devices de seu
sistema... você pode fazer o que quiser, não vai mudar muita coisa, a não ser que você
ache que um de seus devices pararam... ou que apareceram outros do nada... enfim, pode
ser interessante se uma interface de rede está iddle e você suspeita que ela tenha caído.

- Use Defautls: Resetar?

Se você apertar espaço aqui em cima, reseta todas as opções e volta tudo pro original,
destruindo as alterações que você efetuou até aqui.

Depois que tudo estiver pronto, aperte 'Q' para sair ou ESC.

1.4.3 [3 Partition] - Particionando seu HD para o FreeBSD;

Eis o FDisk do FreeBSD (figura 5);

Basicamente a idéia é a mesma do Fdisk do Linux, DOS, ou qualquer outro; Você tem
as partições atuais, e dispõe de comandos para criar novas partições, deletar as antigas,
enfim várias opções disponíveis. Mesmo considerando que o usuário que se propõe a ler
essa documentação já tem certa experiência, vou tentar explicar o que fazer agora de uma
maneira que qualquer leigo (ou quase) possa entender.

Vamos começar pelos comandos disponíveis, os quais aparecem escritos no botton (em
baixo) da tela, como legenda. É importante ressaltar que, a pesar de alguma semelhança
com os Fdisk mais usuais, é necessários sempre ter atenção, pois os comandos não são
os mesmos, e então alguma ação mal planejada pode colocar em risco dados que você não
queira perder.
 As setas movem o cursor pra cima e pra baixo na Tabela de Partições.

A tecla 'A' é utilizada caso você deseje que todo o seu disco rígido seja usado para a
instalação do FreeBSD. Essa é a opção mais comum quando se pretende montar um
Servidor com FreeBSD, e a menos utilizada quando vai se instalar seu FreeBSD junto a
outro Sistema Operacional.

Utilizando essa tecla, para ressaltar, todas as partições são ignoradas e sobrepostas
pela partição FreeBSD.

A tecla 'D' deleta a partição selecionada, transformando-a em espaço livre.

A tecla 'T' muda o tipo da Partição Selecionada. Para explicar melhor: você tem uma
partição alojada como tipo Linux Nativa (ext2fs) e deseja transforma-lo em FreeBSD, e
não quer se dar ao trabalho de deletar a partição e criar outra, então basta apertar 'T'
(todos os comandos podem ser em minúsculas também) e informar o número da partição
a qual ser transformada, no caso de FreeBSD, número 165. Claro que isso pode ser feito
de qualquer tipo para qualquer tipo departição.

A tecla 'G' ajusta o tamanho do Drive. É usado para redimensionar uma partição, caso
o tamanho atual não seja o desejado.

A tecla 'U' desfaz todos as modificações feitas desde que você entrou no FDisk do
FreeBSD.

A tecla 'C' cria uma partição, bastando mover o cursor pra cima do espaço livre alocado,
e apertar 'c'. Então surgirá uma prompt pedindo o tamanho da partição, em blocos, ou em
Megas. Se você for digitar em Megas termine o número com a letra M, em Maiúsculo (ex.:
2048M para dois Gigas de partição).

A tecla 'S' ajusta a partição atual como bootável.

A tecla 'Q' (Quit) Encerra as operações de Particionamento de HD e salva as alterações

na Tabela de partição.

Agoura, vamos entender a tabela que demonstra o tipo das partições.

É bem simples e me ocorreu de colar aqui um exemplo da tabela, mas acho que não é
necessário, ela pode ser encontrada na figura anterior!

A Tabela demonstra o Início (OffSet), o Tamanho (Size), o Final (End), o Tipo de

Partição (Desc) e outras informações. Essas informações são o bastante para você
entender a Tabela.

Agoura voltaremos ao nosso ponto inicial. Como já dito, para montar o nosso Servidor
FreeBSD, utilizaremos todo o nosso Disco Rígido como partição FreeBSD, então apenas é
necessário digitar a letra 'A' para que a partição FreeBSD seja criada.

Mas, como sabemos que isso não acontecerá com algumas pessoas que estão lendo
esse documento, vamos descrever então o processo de particionamento de discos de
forma a mantermos nosso querido Windows e Instalar o FreeBSD como outro sistema
operativo. E também porque instalar apenas o FreeBSD sem outro sistema operativo é
tarefa mais simples e facilmente assimilada a partir da explicação à seguir.

1.4.3.1 Dicas Extras - Particionando Para Windows (não relacionados);

Então vamos fazer o seguinte: Você se é um usuário precavido e Unix User usual,
normalmente já tem separadinho em seu HD a partição do Windows das outras Unix,
mas se não o tem, é hora pra isso. Faça BackUp de todos os seus arquivos e programas
importantes e que você não possa perder, de Windows, e boote o seu Sistema com um
disco de Boot de DOS. Então utilize de alguma ferramenta de particionamento de discos
para separar o tamanho do seu HD entre o que você pretende deixar para o Windows e o
espaço livre. Essas ferramentas podem ser o Fdisk do Dos, FIPS, Partition Magic... Enfim...
Não faz parte da idéia desse trabalho ensinar ninguém a utilizar ferramentas de
particionamento do Windows. Procure na documentação desses aplicativos. A maioria é
fácil de usar em especial Partition Magic que é seguro além de fácil, podendo oferecer até
mesmo o particionamento sem perda de dados.

1.4.4. Continuando...

Bom, voltando a nossa situação, agora você pode enxergar no FDisk do FreeBSD uma
partição do tipo FAT (escrito 'fat' em 'Desc') com um tamanho (Size) bem grandinho e
avantajado. Essa partição é a do Windows, se ela sumir por algum motivo, digite 'U'
imediatamente, porque não queremos perde-la. Teoricamente.

Obrigatoriamente tem que existir outros tipos de partições também em Desc, ou sejam
unused, ou sejam ext2fs (Linux Nativa) ou Linux Swap; Então você tem a opção de deletar
as partições Linux Nativa e Swap afim de criar espaço livre (unused).

Agoura sim, você opta por criar (tecla 'C') uma ou mais de uma partição. Não se
preocupe nesse momento com a partição de Swap. A gente brinca com ela a seguir. Se
você então tem as duas (ou apenas uma) partição FreeBSD e a sua fat visíveis na tabela,
então basta terminar esse particionamento, apertando a tecla 'Q'.

Em seguida, o 'sysinstall' irá apresentar três opções de Boot para o seu sistema
(figura6). A Primeira opção oferece a instalação do BootMgr, que é o gerenciador padrão
de boot do FreeBSD. É um LOADER do FreeBSD, porém com suas características... Essa
é a opção indicada por nós para a instalação. Marque o BootMgr com a tecla de espaço e
dê [OK].
 A Segunda opção, Standard instala o Boot do FreeBSD no setor mestre de inicialização,
sem gerenciar o boot de um segundo Sistema Operacional.

A Terceira opção não faz nada no setor de boot, nem toca se quer, e continua o boot do
Windows ou outro que estivesse alocado na mbr; É o ideal se a intenção é bootar o
FreeBSD por disquete.

1.4.5. [4 Label] Definindo as Partições (figura 7);

Essa opção é particularidade ótima do FreeBSD;

 Uma vez que você já tenha definido o espaço para a partição ou as partições 'FreeBSD'
e deseje que a seleção do tamanho das partições de Swap e de outros contextos do
sistema de arquivo sejam definidas automaticamente (realmente recomendado), então
basta apertar a tecla 'A' e depois a tecla 'Q' para sair e encerrar de vez a questão de
particionamentos ];D

Mas se você quer sentir o gostinho de ser Expert logo, e deseja criar você mesmo seus
Swap e UFS, então basta saber que as teclas (no menu em baixo - botton) tem as mesmas
funções que na tela anterior (comentadas logo atrás...) e que agora você dispõe de dois
novos comandos: tecla 'N' para definir um novo tipo de sistema, e a 'M' para montar a
partição.

Mas antes vamos fazer algumas pequenas considerações e indicações, caso você
pretenda usar seu FreeBSD como servidor. Quando você usa a opção Auto Defaults For
All! com a tecla 'A' o Sysinstall calcula o espaço em disco para o FreeBSD junto à
quantidade total de memória para o melhor particionamento possível do disco.
Normalmente esse cálculo é muito bem feito e na maioria das vezes é cabível aceitar o
conselho do sistema em relação ao tamanho das partições. Contudo, em algumas
situações você, como administrador do sistema deve relevar vários fatores.

Por exemplo, o cálculo da partição de SWAP é feita dobrando-se o rotal de memória

disponível e acrescentando 10% da mesma (SWAP = 2*(RAM)+10%). Em casos onde você
tenha, 128MB de memória, ou mais, sua SWAP facilmente vai atingir mais que 260MB
em disco. Para uma utilização mais eficiente da técnica de memória virtual, recomenda-se
então que o espaço total de SWAP seja dividio em duas partiçoes (2*130MB), assim cada
partição conterá um número menor de inodes resultando em uma gerência melhor e mais
eficiente dos recursos de swap.

Outras considerações são em relação à utilização do servidor. Se você está preparando

um servidor que vai ter vários usuários, por exemplo, e você considera que esses usuários
movimentarão uma grande quantidade de e-mails, então você deve considerar cuidados
especiais com a partição /var, onde os e-mails são alocados. Portanto se os e-mails vão
significar uma grande quantidade de dados no seu servidor, deve-se analisar um tamanho
mais indicado para a partição /var. Muitos administradores preferem não quebrar a
cabeça com isso no momento do particionamento, e preparam, depois da instalação, o
espaço para os e-mails utilizando links simbólicos (symlinks, com o comando ln),
apontando o diretório de e-mails para algum lugar na partição /usr (/var/mail -->
/usr/var/mail/) por exemplo. Também é uma saída válida e inteligente.

Em caso de seu servidor ser usado primariamente como um servidor Proxy-Cache,

então você deve considerar atenção especial ao diretório /usr/local/squid, e porque não,
preparar uma partição especial pra ele, já que é em /usr/local/squid/cache onde fica a
enorme quantidade de dados cacheados pelo seu proxy? Então o particionamento distinto
da /usr e da /usr/local/squid é uma boa saída para uma melhor organização das suas
partições.

Esse tipo de análise é válida para qualquer ambiente Unix, mas usuários de FreeBSD
pelo seu bom-senso e experiência em ambientes unix costumam ser mais cuidadosos com
a preparação do servidor que outros administradores de Unix. Apesar da eficiência
conhecida do FreeBSD em trabalhar com um número elevado de dados sem problemas de
perda de desempenho, o particionamento racionalizado de um servidor resulta também
em segurança, visto que possíveis problemas físicos ou lógicos em uma das partições não
afetam as outras, podendo inclusive, em casos extremos ser re-instalada uma partição
(por exemplo, /usr) sem nem tocar em outras (/usr/home e /usr/local por exemplo, caso
tenham sido particionadas distintamente), evitando assim problemas com perca de dados.

Claro que esses exemplos são em casos extremos. Raramente um sistema de arquivos
BSD reporta problemas. Nem diminui seu desempenho. Agoura você já é um expert em
partições FreeBSD... Boa Sorte :)

1.4.6. [5 Distribution] Escolha qual distribuição você quer instalar;

Distribuição é apenas um nome para um conjunto de arquivos e aplicativos separados

para a instalação. Ao invés de escolher tudo, ítem por ítem do que você quer instalar, você
pode optar por distribuições contendo o que você precisa, e depois escolher por algum
detalhe da mesma distribuição. É como se fossem pacotes separados por assuntos.
Descreveremos agoura todas as opções dessa tela:

- X Exit
Volta pra tela anterior.

- All
Instala todas as fontes, todos os binários e todo o Sistema X Window e disponibiliza a
chance de escolher os gerenciadores de janelas e interfaces com o usuário, além de
disponibilizar que todos sejam instalados. É a opção indicada para se instalar tudo!

- Reset
Reseta tudo que você já tenha escolhido, ou seja, não marca nada!

- 4 Developer
Instala todos os sources (fontes), todos os binários e toda a documentação, e não
instala os jogos. É o ideal para usuários que queiram utilizar o FreeBSD como base de
desenvolvimento e programação. Instala tudo que for pra programação e desenvolvimento.

- 5 X-Developer
Instala o mesmo que a opção 'Developer' acrescido do sistema X Windows todo.
Indicado para pessoas que desejam desenvolver em ambiente gráfico também. Instala gtk,
qt, tcl, glade, além do X Windows completo, servidor e fontes.

- 6 Kern-Developer
Instala todos os binários e documentação e as Fontes do Kernel. Opção ideal para
desenvolvedores de soluções com o FreeBSD onde exista a necessidade de implementar
novas rotinas para o Kernel do sistema. Ou simplesmente recompilar o sistema.
Reconendado também para contribuidores diretos do Core-Team.

- 7 X-Kern-Developer
Instala o mesmo que o Kern-Developer acrescido do sistema X Windows todo. Caso
algumas alterações que você venha a implementar no Kernel utilize chamadas da/para a
interface gráfica. Ou simplesmente queira ter o servidor gráfico instalado também.
Utilizado em circunstâncias como desenvolvimento de jogos como o BRain, onde
chamadas no Kernel venham a ser implementadas.

- 8 User
É a opção do sistema para a maioria dos usuários, composta apenas de todos os
binários e toda a documentação. Ideal pros usuários que pretendem utilizar muito o
FreeBSD mas não pretendem desenvolver em cima dele.
 - 9 X-User
Instala o mesmo que a opção User, porém acrescidos de todo o sistema X Windows. É a
opção ideal para uma Workstation Unix, fazendo do FreeBSD um sistema de interfaces
gráficas agradáveis e fáceis de se utilizar. Conta com inúmeros gerenciadores de janelas,
todos os mais relevantes desenvolvidos pro servidor X.

- A Minimal
Instala a menor configuração possível para a execução do FreeBSD. É típica de
usuários que preferem instalar aplicações ou módulos do sistema operacional
posteriormente, à medida do necessário, racionalizando assim completamente o espaço
em disco utilizado pelo sistema.

- B Custom
Permite que você mesmo edite a sua distribuição. Pro Alternativo e Anti Social que não
se encaixa em nenhuma das descrições acima, essa é a opção ideal, visto que permite que
você instale apenas o que você selecionar, apenas os conjuntos do sistema que você
deseja (por exemplo, você não quer instalar a Compat 2.2, mas quer as bibliotecas de
criptografia, etc...), os aplicativos que você ache necessários, enfim, tudo escolhido a dedo.
É a mais demorada, visto que são muitas aplicações do sistema e de programas a serem
escolhidas.

Bom, agora você sabe o que cada distribuição instala, e com certeza já sabe qual delas
se encaixa melhor com suas necessidades. Claro que caso você ache que nenhuma delas
é perfeita ao que você precisa, você vai optar por editar por si próprio a sua instalação.
Nesse caso, se isso se tornar uma rotina, é indicado que você crie um arquivo .cfg como
já comentado acima, para poupar seu tempo na seleção dos packages.

No nosso documento vamos escolher a opção 'All' (figura 8) porque estamos instalando
um servidor para Estudos, então sabemos que logo necessitaremos dos outros aplicativos.
Também porque o que não for necessário pode ser excluído posteriormente, com a
utilização das ferramentas pkg_info e pkg_delete, que serão explicadas no Capítulo 3
dessa documentação.

Ao final da escolha da distribuição desejada, aparecerá uma prompt do 'sysinstall'

perguntando se você deseja instalar o padrão de criptografia 'DES' (figura 9) e advertindo
que esse padrão de criptografia deve apenas ser usado caso você seja residente nos
Estados Unidos ou Canadá. Diz que o Site Servidor pode encontrar problemas se utilizar
essa criptografia sendo estrangeiro. Creio que é porque é uma criptografia não aberta à
qual não tem licença para usuários fora dessas duas regiões. O sistema indica que seja
usada a criptografia padrão Unix MD5. Optamos por utilizar a MD5 já que nosso servidor
será oficial. Então opte por não [NO] à instalação da 'DES'. Vale lembrar que a criptografia
DES não permite senhas com número de caracteres acima de 8. Mais uma razão para que
nós não optemos por ela.

Depois mais uma tela pergunta se você deseja instalar a Coleção de Ports (figura 10) do
FreeBSD. Diz que é uma importante e valiosa coleção que custará apenas 90 Megas de
espaço em Disco para essas mais de 4000 ports. Claro que esses 90 Megas incluem
apenas o início da instalação das Ports. Muito mais espaço será preciso ao instalar e
compilar cada uma delas, e se você é um dos sortudos que tem toda a coleção de CDs do
FreeBSD, as ports já estão todas lá, não será necessário o download das TarBalls.

Bem, mas antes vamos explicar o que são as ports. Ports são programas Unix (e até
Linux) que foram 'Portados' para o FreeBSD, ou seja, foram rescritos e otimizados para
funcionar perfeitamente bem no FreeBSD. Os ports são a maior coleção de aplicativos do
FreeBSD. A instalação dessa 'Ports Collection' vai funcionar da seguinte forma: Serão
instalados vários (inúmeros mesmo) diretórios com vários assuntos diferentes relacionados
aos aplicativos portados, todos a partir do caminho '/usr/ports/' aos quais você poderá
começar a instalação deles. A instalação segue da seguinte forma: você entra no diretório
do assunto e do aplicativo portado que deseja instalar, digita 'make install', então o sistema
se loga no ftp correspondente e baixa a tarball do aplicativo portado, e depois o instala
automaticamente (você não faz nada...:). Sem dúvidas é um processo diferente, e necessita
que você esteja conectado na Internet para isso. Mas como o FreeBSD é um sistema
Servidor de Rede (Internet) cremos então que isso não seja um impecílio. O fator mais
relevante disso é em relação a economia de espaço, já que você apenas baixa os arquivos
que realmente irá necessitar, evitando que eles sejam adicionados na instalação, e permite
que, se você tiver os CDs com os 'Ports Collection', isso se torne ainda mais rápido. Além de
fazer o download da TarBall com o código fonte do aplicativo escolhido e compilar/instalar
o mesmo, o ports ainda trata de verificar a confiabilidade do aplicativo, fazendo a checagem
do Checksum, instalando os Patches quando necessário e inclusive cuidando do
download/compilação/instalação das dependências do aplicativo. O lixo criado pela
compilação e seu fonte descompactado podem ser imediatamente eliminados com o
comando 'make clean' logo depois que a instalação estiver completa. Os arquivos baixados
pelo 'ports' ficam armazenados em '/usr/ports/distfiles/'.

Por tantas vantagens nós optamos (e claro, recomendamos que você faça o mesmo) por
instalar a 'Ports Collection', então escolha o [YES] com louvor (hehehe). Quanto mais
ports disponíveis, melhor, sempre... hoje o FreeBSD conta com 5.103 ports disponíveis, e
essa coleça cresce a cada dia. ];-D

1.4.7. [6 Media] - Seleciona de onde fazer a instalação (figura 11).

Se você já escolheu que deseja fazer a instalação a partir do CDROM (ou sua escolha)
na opção 'Options' então essa opção já está definida, senão é esse o momento de escolher
de onde você vai instalar tudo, já que até agora você só usou os discos de Boot.

Existe a possibilidade de fazer a instalação de diversos lugares, tanto localmente

(Partição DOS, Linux, Disquetes, Unidades de fita, CDRom) quanto remotamente (FTP
Passivo ou não, HTTP, NFS), mas a nossa opção é a mais comum delas: CDROM; Então se
você ainda não clicou espaço em cima de CDROM faça-o agoura... ]:-)

Vou fazer uma consideração que eu jugo importante, sobre a instalação via FTP. É um
dos meios mais recomendados de se instalar o FreeBSD remotamente. É a forma como a
Yahoo instalou o sistema pela primeira vez, e é a forma mais usada para a instalação de
usuários que testam e ajudam no desenvolvimento da série -CURRENT do FreeBSD, já
que apenas os snapshots podem ser encontrados Online, nunca em CDs, imagens ISO ou
outra mídia.

O sysinstall recomenda vários mirrors, em todo o planeta para a instalação via FTP,
inclusive vários no Brasil, situados na Federal do Rio, Universidade de Campinas, Federal
de São Carlos, etc... e permite também que você selecione um endereço manual, caso
deseje instalar via FTP na sua Intranet, por exemplo.

1.4.8. [7 Commit] - Finalmente Particiona, Extrai, Define e Instala o Sistema.

É aqui que finalmente você põe seu sistema para instalar. Usualmente se usa essa
opção para atualizar o sistema com algo que você não tenha instalado também, voltando
a esse menu, dentro do 'sysinstall'.
 Finalmente, agora é só sentar e esperar... e ficar atento para um eventual SIM durante
a Instalação. Depois você verá a temida mensagem de ‘Última Chance!’ (figura 12) do
sistema, dizendo que agora seriam feitas todas as modificações nas partições e pra você
somente prosseguir se tivesse certeza. Go On!

Durante o processo de instalação você pode verificar o andamento em porcentagem, na

primeira console, pode verificar todos os detalhes e advertências da instalação, e pode até
já ir mechendo no seu FreeBSD durante a própria instalação, já que ele te oferece uma
shell com interpretador de comandos para o que for necessário, na console (tty) 3, 4.

1.5. Configure - Pós configuração do FreeBSD;

Bem, eis que terminou a Instalação do FreeBSD e você cai de volta na tela do
'sysinstall' quando é feita uma pergunta de você deseja rever alguma configuração de seu
sistema. Essa talvez seja a primeira vez que você se vê obrigado a entrar no Configure.

Ou se você já se acostumou (se não, logo vai), entrar sempre no '/stand/sysinstall'

para voltar aqui e dar uma fuçadinha no sysinstall, então vamos explicar o que deve ser
feito após a instalação e durante o uso normal do FreeBSD nesse menu.

Ao entrar no '/stand/sysinstall' e escolher 'Configure', você cairá de frente com muitas

opções de configuração do seu sistema. Agoura explicaremos uma à uma pra que servem
e quando configura-las.

1.5.1. Distributions;
Essa opção permite que você reinstale ou adicione alguma configuração de conjuntos
de distribuições. Já é uma tela conhecida do usuário à essa altura. As explicações para a
distribuição na hora da instalação se aplicam perfeitamente nesse momento. É útil em
casos onde você tenha instalado um sistema enxuto, mas se vê diante da necessidade de
recompilar o sistema. Então a opção de instalação dos fontes necessários (sources) pode
ser utilizada mesmo com o sistema já instalado.
 1.5.2. Packages;
Eis uma das opções fundamentais desse menu. O Packages permite que você instale
via 'sysinstall' todos os pacotes pré-compilados para o FreeBSD contidos no CD, tais
como o Apache, WuFtpd, BitchX, gtk napster, qpopper, qmail, entre outros. Essa função
poderia ser feita igualmente com o 'pkg_add' via /cdrom, mas o 'sysinstall' a efetua
automaticamente. Muito importante essa opção, lembre-se dela futuramente.

1.5.3. Root Password;

Uma das mais simples e importantes também. O nome da opção já diz o que ela faz:
Permite Ajustar/Modificar a senha do Super Usuário / Administrador do sistema. (root).
Basicamente é um 'passwd root' efetuado pelo sistema.

1.5.4. Label;
Outro item importante, e que também já foi visto. Permite que você redefina agora os
Títulos e partições de sistema (como Swap, /usr...) do seu sistema. Agoura porém é
preciso muito mais atenção, uma vez que seu sistema já está instalado, e mexer nas
partições dele pode por muita coisa a perder. Backup é vida! Poser essa frase, mas se
aplica!

1.5.5. FDisk;
Volta à ferramenta de particionamento do FreeBSD. Assim como o item anterior,
trabalhar com essa ferramenta com o sistema já instalado necessita muita atenção para
não correr riscos de perder informações. Depois de sair do FDisk do FreeBSD, mesmo que
alteração alguma tenha sido efetuada, ele pergunta novamente se você deseja instalar o
'BootMgr' na MBR. Isso é perfeito para restaurar o BootMgr caso seu setor primário de
inicialização tenha sido apagado, ou esteja com problemas.

1.5.6. User Management;

Gerencia os grupos e usuários do sistema. Permite que você adicione/exclua usuários
e grupos. Não sei até que ponto essa opção é relevante, já que essa administração pode
ser feita com mais eficiência através dos comandos do console, mas é um ponto de
referência ao usuário menos experiente.

1.5.7. Console;
Essa opção tem a função de permitir ao usuário que ele customize o console do
sistema de acordo com suas necessidades e gostos. Veremos as sub opções desse menu:

- 1. Font: Permite que você escolha a fonte do console entre uma variedade grande de
fontes disponíveis.

- 2. Keymap: Permite que você ajuste o mapeamento do teclado de acordo com o

console. Vários padrões usuais de teclados estão disponíveis, mas se você não encontrar o
seu, use U.S. ISO * (última opção), que pode não ser perfeito, mas vai permitir ao menos
que você se vire um pouquinho melhor, já que é o padrão ISO Norte Americano.

- 3. Repeat: Permite que você configure a taxa de tempo para repetição de caracteres
quando você mantém a tecla pressionada. Existem as alternativas para Slow, Normal,
Fast e Default, na ordem, Lenta, Normal, Rápida e Padrão, onde padrão utiliza o timeout
de repetição que o seu teclado define sozinho.

- 4. Saver: Permite que você escolha entre algumas proteções de tela padrão do console.
Eu pessoalmente gosto da segunda proteção, que é um capetinha em modo texto (ascii)
rodando de um lado pra outro. Faz o servidor ficar bonitinho à vistas das pessoas; O
chucky (capetinha) gráfico também é uma boa opção, mas menos singela... A última
opção define o timeout, em segundos, de quando o Saver vai ser acionado.

- 5. ScreenMap: É recomendado não alterar essa opção a não ser que você more em
algum canto Alternativo da Europa. Brincadeira, ele altera o mapeamento distinto em
países ao redor do mundo, não é o caso de ninguém perto de onde essa documentação vai
ser lida.

1.5.8. Time Zone;

Simplesmente ajusta a Zona do Meridiano onde você se encontra, para fins de ajustes
e sincronia do relógio.

1.5.9. Media;
Lembra-se da opção de 'Media' da instalação? É a mesma coisa, permite que você
escolha a mídia de onde você vai instalar/atualizar seus novos Aplicativos da pós-
configuração.

1.5.10. Mouse;
O Sistema informa aqui que você pode Copiar e Colar textos no Console, entre outras
opções, utilizando o 'Mouse Daemon' do FreeBSD para gerenciar seu Mouse. Depois que
você configurou esse Daemon, você pode indicar o caminho '/dev/sysmouse' como sendo
sua unidade de Mouse e 'MouseSys' ou 'MouseSystem' como protocolo do Mouse ao
utilizar o XFree Server. Vejamos então nossas opções:

- Type: Escolhe o protocolo de configuração do seu mouse. Entre PS/2, Defaults da

Microsoft e outros, você deve encontrar o seu. Conta com a opção Auto, que define
automaticamente, quando possível, qual o seu mouse.

- Port: Define em que porta (device) está instalado o seu mouse. Normalmente esse
device é o 'sio0', ou seja, a COM1.

- Enable: Liga e testa o Mouse Daemon do FreeBSD. Nessa opção você vai ser
perguntado se seu mouse está funcionando ou não. Caso esteja, responda [YES] e a
configuração é Salva. Senão, digite [NO] e redefina o protocolo (Type) e a Porta (Port) do
Mouse até funcionar. Volte nessa opção para testar.

- Disable: Define que você não vai usar o Daemon SysMouse como device para o seu
mouse, independente deste estar configurado ou não.

1.5.11. Network;
Essa opção gerencia os vários aspectos de configuração da rede, incluindo as interfaces,
clientes, serviços, protocolos e outros. Pode ser considerado o item mais importante dessa
pós-configuração pelo '/stand/sysinstall'. Vejamos agora os itens um por um:

1.5.11.1. Interfaces;
Configura as interfaces de rede do FreeBSD que estão disponíveis no kernel e que
foram identificadas como instaladas pelo Sistema. Normalmente aqui você pode
configurar sua placa de rede, sua conexão PPP, Slip e outras mais usuais. Pode passar
dados às interfaces, como endereço IP, endereço de BroaCast, máscara de rede, gateway
padrão, servidor de nomes, endereçamento via DHCP ou não. Todas opções que serão
preenchidas pelo sysinstall dentro do /etc/rc.conf que contém dados que serão passados
ao kernel e aos daemons e controladoras de interfaces sempre que o precisar dessas
informações (usualmente no momento do boot apenas).
 1.5.11.2. NFS Client;
Configura o seu FreeBSD como cliente NFS, caso você for utilizar uma rede NFS para
bootar seu sistema, por exemplo, ou vá montar remotamente alguma partição NFS no seu
sistema local.

1.5.11.3. NFS Server;

Configura seu sistema como Servidor NFS. NFS é o Sistema de Arquivos de Rede Nativo
do Unix, e é muito útil para aplicações pesadas de rede. Procure saber mais sobre NFS,
que vale a pena. Nesse menu você prepara seu FreeBSD para ser servidor de pontos de
montagem em uma rede NFS.

1.5.11.4. AMD;
É o Serviço de Montagem Automática de Devices. Ótimo se você tem discos e/ou
partições Linux e/ou Fat e deseja que elas sejam montadas na inicialização, além de
outras utilizações inusitadas.

1.5.11.5. AMD Flags;

Define Parâmetros de ênfase e importância (as flags) no Auto Mounter Daemon.

1.5.11.6. TCP Extensions;

Permite que as Extensões RFC1323 e RFC1644 sejam utilizadas no Sistema. Essas
extensões são Request For Comments que possivelmente você pode necessitar. Vale a pena
deixar habilitado.

1.5.11.7. Gateway;
Habilita seu FreeBSD como roteador de pacotes entre as interfaces da rede. É essencial
se você for utilizar seu Free como servidor de Intranet, em especial se ele for servir
Internet à outros clientes Mascarando IPs Falsos, via tabela de tradução de endereços
(técnica NAT).

1.5.11.8. NPDate;
Permite que você se conecte à uma série de servidores que atualizam sua máquina de
acordo com um relógio Atômico, mantendo a hora do seu Servidor sempre atual. Manter as
datas e hora no seu servidor atualizada é ponto crucial para a precisão dos logs gerados
em seu sistema, além de tarefas agendadas. Então automatizar a atualização da sincronia
desses dados é relevante.

1.5.11.9. Router;
Permite que você escolha o Daemon que vai fazer o roteamento na sua rede.
Normalmente, esse Daemon é o Routed, e é o mais indicado também na maioria das vezes.

1.5.11.10. RWhod;
Permite rodar o Daemon do Remote Who no seu FreeBSD. Perigoso, aconselhamos que
somente seja feito se não houver outra alternativa, mas sempre há.

1.5.11.11. AnonFTP;
Permite configurar seu Servidor para aceitar FTP Anônimo. Essa é uma grande
ferramenta pra comunicação atualmente. A Transferência de Arquivos por FTP é bem
mais rápida que HTTP, e a opção de Anônimo permite que qualquer pessoa, mesmo que
não seja usuário de seu servidor, possa transferir os dados que você disponibilizar para o
login anônimo.
 1.5.11.12. PCNFSD;
Servidor de Autenticação para Clientes com PC-NFS. Você vai usar muito esse serviço
em uma rede local específica.

1.5.13. Startup;
Aqui você poderá ajustar determinados serviços para iniciarem automaticamente no
momento do Boot do FreeBSD. É importante que você tome cuidado para não inicializar
serviços que não usará ou serviços que possam colocar a segurança de seu servidor em
risco. Serviços que você não use sobrecarregam a memória e processador sem necessidade.

Agoura vamos descrever rapidamente cada um dos principais serviços que podem ser
inicializados no momento do Boot do FreeBSD.

- APM: Auto Power Manager. É o gerenciador automático de Energia, especialmente

indicado para Notebooks e Lap Tops, já que utiliza a bateria da melhor maneira possível.

- PCCARD: Cartão para gerenciamento de dispositivos PCMCIA, também muito

utilizados em Lap Tops com FreeBSD.

- PCCARD MEM: Se essa opção estiver ligada, inicia junto ao boot um gerenciador de
endereços de Memória para os Cartões PCMCIA.

- PCCARD Ifconfig: Mostra uma lista com todos os cartões de gerenciamento de

dispositivos PCMCIA para Ethernet que podem ser configurados.

- Startup Dirs: Normalmente os administradores costumam programar Shell Scripts

para efetuar alguns ajustes do sistema que são feitos sempre da mesma forma. Grande
parte das vezes, vários dispositivos de Rede e serviços são startados à partir de scripts
feito pelos administradores, assim como regras de firewall e tráfego de dados. Para isso,
essa opção permite que você ajuste uma lista de diretórios que contenham esses scripts,
para que eles sejam executados no momento da inicialização do sistema. O Diretório
padrão dos scripts de inicialização é /usr/local/etc/rc.d/, contudo vários outros podem
ser definidos. Ótima função!

- Named: Inicia no boot do sistema, o Servidor de Nomes padrão do FreeBSD, o named.

Normalmente em uma rede você vai precisar usar esse servidor de nomes (Name Server
para DNS), e é aqui que você define a inicialização dele junto ao sistema.

- Named Flags: Flags são opções especiais de um daemon para implementação

avançada da segurança e outras opções desse daemon no FreeBSD. Aqui você define
quais Flags o 'named' deve possuir. O Conceito de Flags você verá futuramente quando
entrar em um contexto mais aprofundado do sistema. Mas usualmente para os Daemons,
são apenas opções para execussão.

- NIS Client: Prepara o sistema para ser um cliente NIS. NIS é uma estrutura muito
usada em tráfegos pesados de rede e requer autenticação do usuário no sistema para
realizar qualquer trabalho na rede.

- NIS Domain: Ajusta o 'Domain Name' da NIS, caso este esteja sendo usado.
 - NIS Server: Se você for usar seu FreeBSD como Servidor NIS, sendo assim o maior
ponto de referência da Rede para toda e qualquer ação dos usuários, então é aqui que
você inicia o Serviço.

- Accounting: Caso seu servidor for rodar processos de contagem, é aqui que você o
inicia.

- lpd: Caso você tenha uma impressora ligada ao seu sistema, aqui você inicia o
Daemon para gerenciamento de impressoras.

- Linux: Essa é a opção para ajustar a compatibilidade com binários de Linux. Caso
você queira que seu FreeBSD aceite binários escritos para o Linux, então você deve
carregar esse serviço no boot do sistema.

- SCO: Esse outro serviço permite que você execute também Binários IBCS2 utilizados
em SCO Unix.

- Quotas: O Kernel do FreeBSD permite outro grande artifício para gerenciamento de

administração do Sistema, que é a opção de Quotas. Maiores informações sobre o que é e
como utilizar Quotas, você verá mais adiante, mas para fazer com que o Free cheque as
quotas na inicialização da máquina, marque essa opção.

Essas são as ferramentas que você dispõe para iniciar esses serviços automaticamente,
mas pode-se implementar outros meios de se fazer isso. O uso de Shell Scripts é uma
importante arma no gerenciamento de um sistema.

1.5.14. Option;
Permite que você reajuste ou modifique os mesmos itens da opção 'Option' da
Instalação, o qual foi amplamente comentado na parte de instalação do nosso documento.

1.5.15. XFree86;
Aqui você é auxiliado na configuração do seu Servidor Gráfico XFree. O XFree merece
capítulos e mais capítulos à parte para ser explicado, portanto vamos apenas ajudar na
configuração dele. Mesmo porque o resto você aprende na prática.

- XF86Setup: Configuração completamente gráfica do servidor XFree. Se Sua placa de

vídeo for detectada automaticamente, é interessante utilizar essa ferramenta para
configurar seu Servidor X no FreeBSD.

- XF86Config: É Um Shell Script para você configurar seu Servidor XFree86 em módulo
Texto, ou seja, no Console. É o mais utilizado deles e o que mais merece atenção.

- XF98Setup: O mesmo que o XF86Setup, mas pra micros mais novos, e chipset de
placas de video distintos.

1.5.16. Desktop;
Depois que seu Servidor XFree já estiver devidamente configurado com seu hardware,
você vai precisar de algum gerenciador de janela. Normalmente por default um
Gerenciador já vem instalado, mas você tem a opção de escolher outro, ou outros,
lembrando que o XFree permite que você utilize mais de um gerenciador gráfico ao mesmo
tempo. Não é kitsch? Vamos ver as opções que temos.
 - KDE: 'The K Desktop Enviroment' é um gerenciador Desktop bastante completo e
bem popular que lembra o Windows, e isso as vezes faz com que alguns vários usuários
mais preconceituosos se sintam irritados e não a vontade. Além de ser um gerenciador
Pesado. Mas se sua máquina tiver alguma Memória Ram Disponível, é uma boa opção.

- Gnome + WindowMaker: Instala e otimiza seu sistema para usar o Gnome em

conjunto com o Window Maker. Gnome é o Gerenciador GTK. Ótimo!

- Gnome + Enlightenment: Combinação perfeita na minha opinião, mas não pode ser
uma opção à se considerar se for utilizar o sistema como servidor, já que sobrecarrega
demais toda a máquina. O Enlightenment por si só já é um gerenciador gráfico pesadinho,
em conjunto com o Gnome a coisa fica ainda mais agravante, e em um servidor não se
pode brincar de desperdiçar recursos. Em compensação como DeskTop, Workstation, a
dobradinha G+E garante um módulo gráfico bonito, fácil de utilizar e muito ágil.
Compensa conhecer se já não forem velhos conhecidos do Linux ou outros Unix.

- AfterStep: Um bom gerenciador de janelas, leve e customizável. Ótima opção para

evitar desperdício de Memória sem ficar apenas no Console.

- WindowMaker: Um dos gerenciadores XFree que mais tem fãs e usuários. É leve, tem
uma aparência bonita, Desktop customizável... Enfim, Perfeito para máquinas que não
tenham recursos sobrando mas nem por isso deixam a desejar.

- fvwm2: Outro gerenciador interessante pra não consumir recursos desnecessários e

nem por isso ficar sem uma interface gráfica boa de trabalhar. Confira-o também.

Como nossa documentação é escrita à partir de um servidor, nós não indicamos que se
utilize muito de Interface Gráfica, para poupar recursos de Memória e Processamento. É
interessantíssimo evitar sempre que possível que o XFree86 esteja sendo executado,
mesmo porque, por ser um 'Servidor' Gráfico, é possível que seja acessado remotamente.
Mas sem pensar na segurança, nos mantendo apenas nos recursos, é desaconselhável
usar o X.

Caso eventuais necessidades da interface gráfica do FreeBSD apareçam,

recomendamos então que o XServer seja 'startado' para aquela sessão, e logo após tirado
do ar. Gerenciadores leves são a dica. Windowmaker mesmo não sendo o mais leve de
todos, também é uma boa opção se não der pra evitar a interface gráfica.

Claro que não podemos deixar de recomendar que você instale uma interface mais
completa e mais bonita, quando tiver hardware sobrando, só pra ter o gostinho de ver
como o Desktop do FreeBSD pode ser a uma alternativa mais bonita e mais fácil até que
sistemas operacionais gráficos, como Window$ ou OS-9. E já que citamos o OS 9,
comparemos então com a interface aqua existente no OS X da Apple. Já que eles se
inspiraram no FreeBSD e BSD 4.4 pra fazer seu kernel unix (o Darwin) se inspiraram
também na interface. Toda a transparência é conhecida de usuários do Enlightenment e
as espeficiações swing da interface Aqua é analogia direta do gtk.

1.5.17. HTML Docs;

Documentação do FreeBSD, disponível depois da instalação, em formato HTML, para
ser visualizado no 'lynx' ou qualquer outro browser, gráfico ou não. Ótima alternativa
para se familiarizar com o sistema, caso você seja novo em ambiente FreeBSD.

2. Configuração do Kernel do FreeBSD

 Obviamente você já deve ter ouvido falar muito do kernel do sistema. Se você vem pro
FreeBSD de outros sistemas Unix já está familiarizado com uma série de rotinas de
otimização de kernel. Contudo faremos aqui um breve walkthrough do kernel do FreeBSD
e do papel do kernel no sistema.

O Kernel é o núcleo central do Sistema Operacional, sendo responsável direto por

controlar tudo ao seu redor. O kernel é responsável direto pelo controle de todo o
hardware, processo, usuários, devices, portas seriais, paralelas, enfim, todo o
computador em sí é controlado pelo kernel, que é a parte fundamental do sistema
operacional. Basicamente o sistema operacional é o kernel acrescido de uma shell onde o
usuário se comunica com... o kernel.

Vamos entender, sucintamente como funciona o computador em relação ao

usuário/kernel/hardware. Dentro de uma analogia baseada em máquina de níveis vamos
adotar uma analogia um pouco mais simples, trabalhando apenas com os níveis de maior
importância. Numa ordem definida, os níveis são: Hardware, Kernel, Shell, Usuário. Em
todos os casos esses são os níveis existentes, em outros casos podemos encontrar,
facultativamente, um nível GUI (Graphical User Interface) entre a Shell e o Usuário, em
casos específicos onde o hardware não pode ser controlado exclusivamente pelo kernel,
temos um outro nível entre o Kernel e o Hardware, chamado de Driver, e inúmeros outros
casos onde esses 4 níveis não são únicos.

Mas vamos entender agora o funcionamento primário do computador. O computador

em sí, em termos, é o Hardware, fisicamente falando. Contudo para controlarmos esse
hardware é utilizado algorítimos especiais, que tratam-no diretamente. Esse conjunto de
algorítimos é reunido no kernel do sistema, que através de chamadas de sistema
(syscalls) e de agendamento de tarefas (threads schedulling) controlam a memória, discos,
processadores, registradores, barramentos, etc, de todo o hardware.

O kernel tem funções de tratamente de usuários e processos, além de hardware. Ele

gerencia quais processos (programas) estão em atividade no momento, quais usuários são
os responsáveis pelos processos, quais usuários estão logados no sistema, quais usuários
e/ou processos estão fazendo acesso a disco, distribui e faz a paginação da memória
utilizada por todos esses processos e usuários, enfim, todo esse gerenciamento complexo
e extremamente relevante no sistema operacional, é função do kernel.

A Camada seguinte na nossa máquina de níveis exemplo, é a Shell. Shell é uma porta
de entrada para a comunicação do usuário com o sistema operacional, com o kernel, com
o computador. A Shell é composta basicamente de uma capsula (shell) que liga você
(usuário) ao sistema operacional. É provida de interpretadores de comandos, que tem a
função de entender ordens digitadas no ambiente (shell) como comandos, procurar nos
caminhos pré-definidos (path) aqueles comandos (em forma de binários ou ambiente) e
executa-los tratando da forma como for necessária, e ao final da ação, retornando uma
resposta de volta ao usuário.

Então, quando você digita 'ls' por exemplo, a shell (interpretador de comando em
questão) procura por um código de máquina (binário) que corresponda à ordem dada pelo
usuário, e então encontra o ls, executa-o e retorna resposta pro usuário. Esse 'executar'
em questão consiste em interpretar os códigos daquele programa, envia-lo ao kernel, que
analisa o que a shell esta pedindo e retorna a resposta, então a resposta é retransmitida
ao usuário. Então quando um ls retorna todos os arquivos e diretórios de um outro
diretório, o que realmente esta acontecendo é: o interpretador de comando (shell) esta
enviando ao kernel uma ordem dizendo que o usuário quer saber o conteúdo do trecho do
disco em questão. Então o kernel varre esse trecho do disco, descobre todos os arquivos e
outros diretórios contidos, nome dado a cada um desses arquivos, tamanho que eles
estão ocupando em disco (inodes) e retorna pra shell.

Normalmente quando essa resposta é retornada à shell ela ainda é interpretada antes
de ser repassada ao usuário, mostrando o nome do arquivo/diretório, espaço em disco
que está sendo utilizado (inodes interpretados em bytes) e outras informações distintas.

Esse tipo de comunicação entre hardware-kernel via shell acontece sempre, mesmo
quando você não está enviando comando algum ao sistema. Em alguns ambientes, você
pode inserir ainda uma camada gráfica entre a shell e o usuário, chamada de GUI, que é a
interface gráfica. Nesse caso essa interface, em forma de janelas, normalmente, interpreta
a resposta do kernel e retorna um ambiente gráfico, com icones de pastas onde são
diretórios, icones específicos para cada tipo de arquivo, enfim, tudo de glamuroso e
agradável que o ambiente gráfico proporciona. Contudo é uma camada a mais na
máquina de níveis até o kernel, o que resulta em perda de desempenho.

Acreditamos que você já pode entender a função do kernel e da shell em relação ao

usuário e ao hardware. O Kernel faz tudo e a shell apenas envia pro kernel as vontades do
usuário. O desempenho do computador, analogicamente pode ser interpretado (apenas
em forma de exemplo, sem conhecimentos técnicos) como a distância entre o hardware e
o usuário. A Camada maior dessa distância é o kernel, que é o mais importante também.

Contudo, podemos diminuir essa distância, aumentando o desempenho do

computador. O passo mais importante é diminuir a camada maior na nossa máquina de
níveis: o kernel. Como assim diminuir o kernel? Em ambiente Unix aberto, você tem a
liberdade para customizar o seu núcleo (kernel). O kernel do sistema operacional,
genericamente tem suporte à vários (inúmeros) tipos de dispositivos, por uma simples
razão, não se sabe previamente qual vai ser o hardware onde a o sistema operacional será
instalado, então não se sabe quais hardwares o kernel vai ter que controlar, por isso
existe o suporte a tipos distintos de hardware.

A consequência disso é um kernel que, por mais enxuto que seja, vai conter suporte a
inúmeros dispositivos que simplesmente não existe no seu computador. E mesmo não
existindo, o kernel vai ter a habilidade de controla-los. E nesse casos, essa habilidade é
sinônimo de recursos (memória/processamento) sendo utilizados sem necessidade. Então,
se a possibilidade de controlar dispositivos que nós não temos utiliza recursos, porque
simplesmente não retiramos essas habilidades do kernel?

Em sistemas proprietários você não pode nem abrir o kernel, tão pouco altera-lo
customiza-lo, como sistemas da Novell, da Microsoft (windows), e outros Unix
proprietários. O resultado dessa incapacidade é um kernel grande, cheio de suporte a
dispositivos que nós não temos, e, infelizmente muitas vezes a incapacidade de controlar
algum dispositivo que nós temos. É a ironia em forma de sistema, nós termos um kernel
que trate dispositivos estranhos mas não trate os que nós temos. Nesse caso é necessário
uma camada a mais, ou seja, um nível a mais na nossa máquina de níveis entre o kernel
e o hardware, que são os chamados 'drivers'. Resultado é um kernel grande, cheio de
suporte a dispositivos inexistentes no nosso computador, e acrescido ainda de mais uma
camada, distânciando ainda mais o kernel do hardware, e consequentemente o hardware
do usuário. Com isso você imagina os recursos que são utilizados, e como o desempenho
da nossa maquina vai descrescer relevantemente.

Em sistemas Unix abertos, você tem em mãos os códigos utilizados no kernel do

sistema, e a consequência direta disso é a possibilidade de customizar um kernel próprio,
exclusivamente para o hardware que você tem na sua máquina, e outras funcionalidades
mais, como o número de usuários simultâneos no sistema, número de processos, etc. O
resultado direto disso é um kernel enxuto, exclusivo para a sua máquina, e
consequentemente, a diminuição de nível do kernel, na nossa máquina de níveis,
utilização racional dos recursos (onde o kernel só vai utilizar o necessário pra controlar a
sua máquina), além da improbabilidade de ser preciso adicionar um driver para controlar
determinado dispositivo. Isso porque, o suporte que possívelmente pode não existir no
kernel genérico, pode ser adicionado posteriormente.

Enfim, sabendo utilizar o kernel de um sistema da melhor forma possível, você com
certeza terá rendimentos mais proveitosos. Porém essa vantagem toda pode se virar contra
o usuário e se tornar uma longa dor de cabeça, se por ventura, você sobrecarregar seu
kernel, ou implementar suportes incorretos a determinado dispositivo.

Se você está migrando de um outro sistema Unix, ou mesmo de um Linux, por exemplo
já saber que otimizar e recompilar um kernel é tarefa usual nesse maravilhoso mundo do
código fonte aberto. Agora, nós vamos ao longo desse capítulo, ensinar a você como
compilar, da forma correta, o kernel para o seu FreeBSD.

Sabemos muito bem os maiores problemas de sistemas operacionais que não nos
permite customizar nosso kernel para, apenas o que nós precisamos. É um pesadelo ter
um sistema que suporta diversos periféricos e placas que saem completamente de nossa
realidade ou necessidade.

Tendo um kernel que suporte exatamente todo o nosso sistema e as funções que nós
queremos utilizar nele, economizará relevantemente o consumo de Recursos de nosso
sistema... E recursos obviamente é algo que quanto mais pudermos trabalhar de forma
racional, melhor maneiras teremos de proporcionar a performance máxima de nossa
máquina.

2.1. Kernel no FreeBSD

No FreeBSD, quando inciamos nosso sistema pela primeira vez, utilizamos um kernel
padrão, chamado de GENERIC. Esse kernel possui suporte a grande maioria dos
dispositivos e controladores existentes. É sem dúvida o bastante para utilizar seu sistema.
Contudo, esse kernel GENERIC, apesar de compacto contém suporte a tipos distindos de
dispositivos, e não contém algum suporte a tarefas importantes, as quais nós veremos
futuramente.

Parecido com alguns Unix conhecidos, e direferente de outros, a forma de gerar um

novo kernel para nosso sistema se consiste em editar o arquivo de configuração do novo
kernel a ser compilado. Deve-se sempre gerar um kernel a partir da configuração genérica
do mesmo, a não ser que você seja um guru do FreeBSD e já saiba de cabeça quais
parâmetros e linhas servirão ou não para o seu kernel, e consiga digita-las em um arquivo
sem se basear no GENERIC. Pessoalmente não conheço nenhum.

A configuração do novo kernel deve ser baseada nas entradas de um segundo arquivo,
o LINT. O LINT é um arquivo que contém todos os dispositivos suportados pelo FreeBSD,
e não pode jamais ser seguido a risca para configuração de um novo Kernel. O ideal é você
fazer uma cópia do seu kernel genérico e a partir dele, iniciar a configuração de seu
kernel, sempre consultando o LINT para saber como inserir suporte à dispositivos que
você necessite. Quanto mais você conhecer o LINT mais poderá otimizar seu sistema.
 Inicialmente seu sistema deve ter reconhecido todos os dispositivos básicos da sua
máquina, utilizando-se pra isso o kernel GENERIC. Comumente alguns dispositivos não
são reconhecidos da forma correta. Isso ocorre em especial com MODEMs e Placas de
Rede ou de Som, porque são definidas portas e IRQs diferentes das que ele está
trabalhando.

O que acontece então? Todas as entradas para que o FreeBSD possa controlar esse
dispositivos básicos estão presentes no arquivo de configuração GENERIC do kernel, mas
pode acontecer algum conflito ou não satisfação de recursos. Por exemplo, o kernel
procura por aquele recurso em determinada Interrupção (IRQ) e determinada DMA... e seu
dispositivo se encontra em outra IRQ e DMA. Esses são os fatos mais usuais, assim como
o recurso procurando em device diferente da qual seu hardware está instalado. Isso quase
sempre ocorre com o MODEM, uma vez que o FreeBSD procura por ele na cuaa1 (sio1 -
que é a COM2), e várias vezes ele está na COM4 (cuaa3, sio3), ou outras delas. As vezes
acontece também com placas de som, ou placas multi-seriais.

Como resolver esses e outros problemas você verá a seguir, assim como implementar
propriedades que o kernel usual não ostenta, como o uso de quotas por exemplo.

Bom, mas antes de iniciarmos, vamos ver alguns pontos interessantes.

É usual aos administradores de Sistemas de Redes usar o nome da máquina como

nome do kernel. Isso ajuda na hora de reconhecer o sistema que você está tratando,
quando esse estiver em uma grande rede com outros vários sistemas com FreeBSD por
exemplo. Também é de prache que o aquivo de configuração tenha o mesmo nome do
Kernel, e esse em LETRAS MAIUSCULAS, como ocorre com o GENERIC e o LINT.

Mais uma vez, antes de iniciarmos a compilar o nosso kernel, eu relembro vocês
(desculpe se esta massante, mas é importante você assimilar isso), que é ótimo conhecer
o LINT antes de inciar a configuração de seu novo kernel. Por isso de uma boa olhada e
leia antentamente o LINT. Em Inglês de fácil entendimento. Um amigo meu está
trabalhando na tradução do LINT do FreeBSD 4.3 e eu prometo disponibiliza-lo em um
próximo review desse capítulo. Contudo o LINT muda a cada versão, e queira ou não você
vai precisar ler esse arquivo quando não souber determinado parâmetro ou sintaxe da
entrada do kernel.

2.2. Configurando um novo Kernel no FreeBSD

A partir do momento que você conhece o hardware do sistema para o qual você
pretende customizar seu kernel, tudo se torna mais fácil. Vamos então agoura guia-lo
passo a passo durante a criação de seu novo kernel. Se você estiver trabalhando em
plataforma Alpha, considere o caminho: /usr/src/sys/alpha/conf ao longo da
documentação.

- Primeiro, entre no diretório onde se encontra o seu kernel: /usr/src/sys/i386/conf

Pra isso digite:

# cd /usr/src/sys/i386/conf
- Agora faça uma cópia do arquivo de configuração do kernel genérico como o arquivo de
configuração de seu novo kernel. Lembrando das dicas básicas, que o kernel deve estar
em letras maiúsculas e com o nome da máquina.

Pra isso, estando em usr/src/sys/i386/conf, digite:

# cp GENERIC EEVIACBSD

Claro que para esse exemplo eu considerei que a máquina em questão se chamasse
EeviacBSD, que é a minha estação.

- O terceiro passo é o passo prático em si. Esse passo é onde nós editaremos o nosso
kernel. Utilize o editor que você mais gosta para edita-lo. No nosso caso, sempre
aconselhamos o editor padrão, o ‘ee’.

Dessa forma, devemos então digitar:

# ee EEVIACBSD

2.2.1. Dicas para otimização do seu Kernel.

Agora sim, eis o arquivo de configuração do kernel atual na nossa frente. É nesse
arquivo que iremos excluir os suportes que não precisamos, e adicionar os que venhamos a
necessitar. No nosso caso, tivemos alguns probleminhas, entre os quais incluía a nossa
placa de rede. Para tanto, concluímos então que a melhor maneira de configurar o nosso
kernel, era começando pela exclusão dos suportes os quais nós não necessitávamos.

Pra isso, o que fizemos e aconselhamos que você faça também, é ler todo o seu kernel.
Como nós não utilizamos disco rígidos SCSI (em caso de compilação para servidores
possívelmente você vai estar utilizando SCSI, então atenção em qual controladora você vai
excluir), retiramos todo o suporte a controladoras desse tipo. Retiramos também suporte a
alguns protocolos de placas de rede que sabíamos não ser a que nós utilizaríamos.
Sabíamos que a nossa era uma NE2000 compatível e uma 3Com.

Depois de uma primeira enxugada imediata, quando você bate os olhos e sabe que não
precisa daquilo, chegou a hora de retirar suporte a outros dispositivos que também não
estavam sendo utilizados.

Para isso, usamos o comando dmesg.

Quando você digita dmesg, o sistema apresenta a você as conclusões de boot do

sistema. Então podemos verificar todos os dispositivos que foram carregados, seus
endereços, protocolos e memória, assim como podemos também visualizar os dispositivos
suportados que não foram encontrados, aqueles que seu kernel sabe como trabalhar, mas
que você não tem... exatamente o que queremos evitar.

Portanto use o comando dmesg, depois disso pressione a tecla Scroll Lock para travar
sua tela, e role-a com Page Up e Page Down para ir anotando o que o seu kernel não
encontrou. Depois de anotado os ‘not found’, você já tem em mãos a grande maioria dos
dispositivos que seu kernel suporta mas que não estão sendo utilizados. Ou seja, estão
sobrecarregando seus recursos.
 Agora com certeza você já tem uma boa lista de itens a serem retirados do seu kernel.

2.2.2. O Kernel Genérico.

Agora que você já deu uma drenada básica no seu kernel, é hora de conhecer o resto
dos dispositivos básicos que ele suporta. Segue então o seu kernel genérico comentado
linha a linha. Esses comentários foram enviados em uma lista de discussão, e foram
devidamente analisados e modificados antes de entrar na documentação de FreeBSD
utilizado por nós.

Segue então o kernel:

Primeira consideração: os 5 primeiros itens aqui apresentados são obrigatórios na

configuração de qualquer kernel que você compile para FreeBSD.

machine ``i386''

Bom, uma vez que o FreeBSD roda sob a arquitetura intel ou compativel, associamos a
esta palavra chave esta o valor "i386". Caso você seja um dos privilegiados que esta
trabalhando com o FreeBSD em plataforma alpha basta modificar essa linha pra avisar o
kernel, mas seu GENERIC já vai ter se encarregado de ajustar isso pra 'alpha'.

cpu ``cpu_type''

Inclui no kernel o suporte para cada tipo de CPU suportada pelo FreeBSD.

Os valores possiveis para cpu_type sao:

o I386_CPU
o I486_CPU
o I586_CPU (Pentium)
o I686_CPU (Pentium Pro)

O kernel generico possui suporte a todos os tipos de CPU, de modo que ao recompilar
seu kernel e recomendado que voce inclua no seu kernel, suporte apenas para a CPU que
voce possui.

Isso ira economizar preciosos KB de memoria RAM do seu sistema.

ident EEVIACBSD

Esta e a identificacao do seu kernel. Uma boa escolha e utilizar o hostname como
nome do kernel, isso facilita quando se possui varios hosts, cada um com um kernel
diferente, em uma mesma rede.

maxusers <um número>

Esta linha define o tamanho de varias tabelas importantes no sistema.

De uma forma geral esta variavel deve ter o valor definido de acordo com o numero de
usuarios simultaneos que voce espera ter em seu sistema, pois o numero maximo de
processos simultaneos que seu sistema podera executar, sera dado pela expressao: 20 +
16 * <maxusers>

OBS: O valor definido como maxusers nao limita o numero de usuarios que podem
logar simultaneamente no servidor, e sim o número máximo.

config kernel_name root on root_device

Esta linha especifica a localizacao e o nome do kernel.

A variavel kernel_name devera ter sempre o valor kernel , ja a variavel root_device ,

devera ter o valor /dev/ad0, caso seu HD seja IDE ou /dev/da0 se seu HD for SCSI.

Agora sim, você vai acompanhar cada iten suportado pelo seu sistema. Esse debug do
kernel GENERIC deve ser creditado à FreeBSD Primeiros Passos, mantida por Edson Brandi,
provavelmente a publicação na lista de discussões também tem crédito a ele.

options MATH_EMULATE
Informa ao kernel para simular um co-processador matematico caso seu computador
nao possua um. Voce so vai precisar desta linha se seu PC for um 386 ou um 486 SX.

options ``COMPAT_43''
Inclui ao seu kernel, compatibilidade com o 4.3 BSD.

options BOUNCE_BUFFERS
Dispositivos ISA ou EISA , operando no modo de compatibilidade ISA, so podem
acessar sua memoria DMA em sistemas com menos de 16 MB de RAM. Esta opcao ira
permitir que os dispositivos que usam DMA funcionem em sistemas com mais de 16 MB
de memoria.

options UCONSOLE
Esta opcao ira permitir a seus usuarios definir um console para o qual deverao ser
enviadas todas as mensagens enviadas a voce (talk, write, etc).

options SYSVSHM
Esta linha prove suporte ao sistema de memoria compartilhada do System V. Se voce
pretende emular programas Linux ou jogar games como o DOOM ou QUAKE nao deixe de
incluir esta linha ao seu kernel.

options SYSVSEM
Esta linha prove suporte ao sistema de semafaros do System V.

options SYSVMSG
Esta linha prove suporte ao sistema de mensagens do System V.

options FFS
Esta linha inclui no kernel o suporte basico ao sistema de arquivos de um HD. Linha
obrigatoria para que possui um HD.

options NFS
Esta linha inclui no kernel suporte ao sistema de arquivos NFS. Se voce nao planeja
usar seu sistema como servidor ou cliente NFS voce pode remover esta linha do seu
kernel.

options MSDOSFS
Esta linha inclui no kernel suporte ao sistema de arquivos do MS-DOS. Se voce nao
planeja montar nehum HD que utilize este sistema de arquivos, voce pode remover esta
linha do seu kernel.

options ``CD9660''
Esta linha inclui no kernel suporte ao sistema de arquivos ISO 9660 para Cd-ROMs.
Voce pode remover esta linha de seu kernel caso voce nao possua um drive de CD-ROM.
CDs de audio nao precisam deste suporte.

options PROCFS
Esta linha inclui no kernel suporte ao sistema de arquivos utilizado pelo sistema para
gravar informacoes sobre os processos em execucao (/procs), linha obrigatoria para a
maioria dos sistemas.

options MFS
Esta linha inclui no kernel o suporte ao sistema de arquivos "Memory-mapped".
Basicamente um disco em memoria RAM usado para armazenar rapidamente arquivos
temporarios.

options QUOTA
Esta linha inclui no seu kernel o suporte ao sistema de quotas dem disco.

options INET
Inclui suporte para Networking (rede).

controller isa0
Esta linha inclui ao kernel suporte a barramentos ISA.

controller pci0
Esta linha inclui ao kernel suporte a barramentos PCI.

controller fdc0
Esta linha inclui no seu kernel suporte a controladora de floppy drives (Discos flexiveis
ou tapes de backup)

controller adc0
Esta linha inclui no seu kernel suporte a controladora IDE primaria. Os dispositivos
wd0 e wd1 sao respectivamente os HDs master e slave. wdc1 e a controladora IDE
secundaria.

device acd0
Esta linha inclui no seu kernel suporte a CD-ROMs IDE. Se voce possui um CD-ROM
IDE certifique-se de incluir a linha "options ATAPI" ao seu kernel.

device npx0 at isa? port ``IO_NPX'' irq 13 vector npxintr

npx0 e a interface para a unidade de ponto flutuante do co-processador matematico.
NAO REMOVA ESTA LINHA!!!
 device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr
Inclui suporte ao tape drive QIC-02/QIC-36

device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr

Inclui suporte a CD-ROMs Mitsumi (LU002, LU005, FX001D).

device scd0 at isa? port 0x230 bio

Inclui suporte a CD-ROMs Sony (CDU31, CDU33A).

controller matcd0 at isa? port ? bio

Inclui suporte a CD-ROMs Matsushita/Panasonic.

controller bt0 at isa? port ``IO_BT0'' bio irq ? vector btintr

Inclui suporte a maioria das controladoras SCSI da Buslogic.

controller uha0 at isa? port ``IO_UHA0'' bio irq ? drq 5 vector uhaintr
Inclui suporte as controladoras SCSI da UltraStor modelos 14F e 34F.

controller ahc0
Inclui suporte as controladoras SCSI Adaptec modelos 274x/284x/294x.

controller ahb0 at isa? bio irq ? vector ahbintr

Inclui suporte a controladora SCSI Adaptec modelo 174x.

controller aha0 at isa? port ``IO_AHA0'' bio irq ? drq 5 vector ahaintr
Inclui suporte a controladora SCSI Adaptec modelo 154x.

controller aic0 at isa? port 0x340 bio irq 11 vector aicintr

Inclui suporte a controladora SCSI Adaptec modelo 152x e as placas de som usando a
Adaptec AIC-6360.

controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr

Inclui suporte as placas ProAudioSpectrum usando as controladoras NCR 5380 ou
Trantor T130.

controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr
Inclui suporte a controladora SCSI Seagate ST01/02 8 bit.

controller wds0 at isa? port 0x350 bio irq 15 drq 6 vector wdsintr
Inclui suporte a controladora SCSI Western Digital WD7000.

controller ncr0
Inclui suporte as controladoras PCI SCSI modelos NCR 53C810, 53C815, 53C825,
53C860 e 53C875.

options ``SCSI_DELAY=15''
Esta linha informa ao kernel para fazer uma pausa de 15 segundos antes de testar
cada dispositivo SCSI em seu sistema.

controller scbus0
Se voce possui alguma controladora SCSI, esta linha prove um suporte generico aos
dispositivos SCSI. Linha obrigatoria caso voce possua algum dispositivo SCSI.
 device sd0
Inclui suporte a HDs SCSI.

device st0
Inclui suporte a tape drives SCSI.

device cd0
Inclui suporte a CD-ROMs SCSI.

device sc0 at isa? port ``IO_KBD' tty irq 1 vector scintr

sc0 e o drive default do console. Consulte o arquivo LINT para ver as demais opcoes

options ``PCVT_FREEBSD=210''
Linha obrigatoria quando se utiliza o driver de console vt0

options XSERVER
Linha obrigatoria quando se utiliza o driver de console vt0 e se pretende rodar o
XFree86.

device mse0 at isa? port 0x23c tty irq 5 vector ms

Insira esta linha caso voce possua um mouse Logitech ou um mouse ATI InPort.

device psm0 at isa? port ``IO_KBD'' conflicts tty irq 12 vector psmintr
Insira esta linha caso voce possua um mouse do tipo PS/2.

device sio0 at isa? port ``IO_COM1'' tty irq 4 vector siointr

Inclui suporte as suas portas seriais, sio0 = COM1 , sio1 = COM2, sio2 = COM3, sio3 =
COM4, cada porta precisa de um irq exclusivo.

device lpt0 at isa? port? tty irq 7 vector lptintr

Inclui suporte a suas portas paralelas

device de0
Inclui suporte a placas de rede ethernet baseadas nos chips DC21040, DC21041 e
DC21140 da Digital.

device fxp0
Inclui suporte a placa de rede ethernet Intel EtherExpress Pro/100B.

device vx0
Inclui suporte a placas de rede ethernet 3Com modelos 3C590 e 3C595.

device cx0 at isa? port 0x240 net irq 15 drq 7 vector cxintr
Inclui suporte a placas multiportas Cronyx/Sigma sync/async.

device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr
Inclui suporte a placas de rede ethernet da Western Digital SMC 80xx e 8216; Novell
NE1000 e NE2000; 3Com 3C503; HP PC Lan Plus (HP27247B e HP27252A)

device el0 at isa? port 0x300 net irq 9 vector elintr

Inclui suporte a placa de rede ethernet 3Com 3C501.
 device eg0 at isa? port 0x310 net irq 5 vector egintr
Inclui suporte a placa de rede ethernet 3Com 3C505.

device ep0 at isa? port 0x300 net irq 10 vector epintr

Inclui suporte a placa de rede ethernet 3Com 3C509.

device fe0 at isa? port 0x240 net irq ? vector feintr

Inclui suporte a placas de rede ethernet Fujitsu MB86960A/MB86965A.

device fea0 at isa? net irq ? vector feaintr

Inclui suporte ao adptador FDDI DEC DEFEA EISA.

device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr
Inclui suporte a placas de rede ethernet AT&T StarLAN 10 e EN100; 3Com 3C507;
padrao NI5210.

device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr
Inclui suporte a placa de rede ethernet Intel EtherExpress 16.

device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr
Inclui suporte a placas de rede ethernet Digital EtherWorks 2 e EtherWorks 3 (DEPCA,
DE100, DE101, DE200, DE201, DE202, DE203, DE204, DE205, DE422).

device lnc0 at isa? port 0x300 net irq 10 drq 0 vector lncintr
Inclui suporte a placas de rede ethernet Lance/PCnet (Isolan, Novell NE2100, NE32-
VL).

device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr
Inclui suporte ao controlador ethernet PCMCIA da IBM/National Semiconductor.

device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr
Inclui suporte ao controlador ethernet 3Com PCMCIA Etherlink III.

pseudo-device loop
Interface de loopback para TCP/IP. Linha obrigatoria.

pseudo-device ether
Linha obrigatoria caso voce possua alguma placa de rede.

pseudo-device sl numero
Inclui suporte ao protocolo SLIP, o numero especificado determina quantas conexoes
SLIP seu server pode manter simultaneamente.

pseudo-device ppp numero

Inclui suporte ao protocolo PPP, o numero especificado determina quantas conexoes
PPP seu server pode manter simultaneamente, atraves do pppd.

pseudo-device tun numero

Inclui suporte ao protocolo PPP, o numero especificado determina quantas conexoes
PPP seu server pode manter simultaneamente, atraves do ppp.
 pseudo-device bpfilter numero
Inclui suporte ao "Berkeley packet filter", necessario para o IPFW

controller snd0
Inclui suporte para uma placa de som generica. Linha obrigatoria caso voce possua
uma placa de som.

device pas0 at isa? port 0x388 irq 10 drq 6 vector pasintr

Inclui suporte a placa de som ProAudioSpectrum audio digital e MIDI.

device sb0 at isa? port 0x220 irq 7 conflicts drq 1 vector sbintr
Inclui suporte a placa de som SoundBlaster audio digital.

device sbxvi0 at isa? drq 5

Inclui suporte a placa de som SoundBlaster 16-bit audio digital.

device sbmidi0 at isa? port 0x330

Inclui suporte a interface MIDI da SoundBlaster 16, se voce possue uma SB16 voce
deve inserir esta linha ou seu kernel nao ira compilar!

device gus0 at isa? port 0x220 irq 10 drq 1 vector gusintr

Inclui suporte a placa de som Gravis Ultrasound.

device mss0 at isa? port 0x530 irq 10 drq 1 vector adintr

Inclui suporte ao sistema de som da Microsoft.

device opl0 at isa? port 0x388 conflicts

Insira esta linha se voce possue uma placa de som e pretende executar arquivos MIDI
com o programa playmidi.

device mpu0 at isa? port 0x330 irq 6 drq 0

Inclui suporte a placa de som Roland MPU-401.

device uart0 at isa? port 0x330 irq 5 vector ``m6850intr''

Inclui suporte a interface 6850 UART para MIDI.

device pca0 at isa? port ``IO_TIMER1'' tty

Inclui suporte a audio digital atraves dos auto-falantes do PC.

pseudo-device gzip
Esta linha permite ao FreeBSD executar o rpograma gzip.

pseudo-device log
O log e usado para gravar as mensagens de erro do kernel. Linha obrigatoria

pseudo-device pty number

Limita o numero simultaneo de logins remotos e/ou janelas xterm, maximo 64.

device joy0 at isa? port ``IO_GAME''

Inclui suporte a PC joystick.
 pseudo-device speaker
Inclui suporte ao alto-falante de seu PC

device de0
device fxp0
device tl0
device tx0
device vx0
device xl0

Mais Devices de rede, não se pode modificar a ordem dessas e das próximas entradas,
porque elas devem ser procuradas e reconhecidas em uma ordem certa.

No momento ie0 deve ser procurada antes de ep0, aguarde as atualizaçòes na revisão
1.20 desse arquivo

device ed0 at isa? port 0x280 net irq 10 iomem 0xd8000 vector edintr
device ie0 at isa? port 0x300 net irq 10 iomem 0xd0000 vector ieintr
device ep0 at isa? port 0x300 net irq 10 vector epintr
device ex0 at isa? port? net irq? vector exintr
device fe0 at isa? port 0x300 net irq ? vector feintr
device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr
device lnc0 at isa? port 0x280 net irq 10 drq 0 vector lncintr
device ze0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zeintr
device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr
device cs0 at isa? port 0x300 net irq ? vector csintr
pseudo-device loop
pseudo-device ether
pseudo-device sl 1
pseudo-device ppp 1
pseudo-device tun 1
pseudo-device pty 16
pseudo-device gzip # Exec gzipped a.out's
options KTRACE #kernel tracing

Kernel Tracing, adiciona o ktrace(2) do seu kernel, sobe um pouco a utilização de

recursos, mas se você vai trabalhar com chamadas de sistemas e quer trabalhar com
ocorrência de erros dela, então é importante manter.

options SYSVSHM
É o suporte ao sistema de compartilhamento de memória dos Unix System V.

2.2.3. Construindo e instalando seu kernel já configurado.

Pronto! Teoricamente agoura você já tem informações mais que suficiente para ajustar
o kernel do seu sistema de acordo com suas necessidades. Agora sim é hora de finalmente
compilar o núcleo do seu sistema. Mas antes você deve considerar não retirar nenhum
suporte que você não esteja certo de não precisar. Isso pode ser fatal no seu sistema, ou
pode ser uma dependência em potencial.

Para compilar agora seu kernel de acordo com as configurações que você acabou de
ajustar, faça o seguinte.
 - Configure seu Kernel, digitando config NOME_DO_SEU_KERNEL, no nosso caso:

# config EEVIACBSD

Agora então é criado um diretório contendo a base-fonte do kernel à ser compilado. O

caminho do diretório é mostrado na tela. Devemos então entrar nesse diretório. No nosso
caso digite:

# cd ../../compile/EEVIACBSD.

Considerando que você esteja em /usr/src/sys/i386/conf você sempre deve ir

para ../../compile/NOME_DO_SEU_KERNEL. /usr/src/sys/compile/SEU_KERNEL
portanto.

- Em seguida satisfaça as dependências de módulos e configurações do seu novo

kernel, de acordo com o Kernel que você acabou de editar. Para isso, dentro do diretório
do seu kernel, digite:

# make depend

As coisas agora começam a demorar um pouco, variando de acordo com sua máquina.
De qualquer forma, você está começando a compilar o núcleo do seu sistema. Se você está
achando isso interessante mal espere a chegarmos na atualização do fonte todo de nosso
sistema, o make world :-). Bom, voltando ao kernel:

- Depois que as dependências foram satisfeitas, é hora de construir seu novo kernel. O
passo seguinte agora é dar um Make. Digite então:

# make

Mais algum tempo será necessário. Agora o sistema estará construindo o seu novo
kernel, de acordo com as dependências do sistema, ou seja, criando um kernel
exatamente para o sistema. Nesse ponto, se alguma configuração do kernel que você
editou não estiver de acordo com o sistema, você verá algumas mensagens de erro.

Se isso acontecer, leia as mensagens e tente entende-las. Normalmente os erros nesse

momento são bem fáceis de entender e saber o motivo. Basicamente em caso de erros, você
está chamando suporte a algum dispositivo que antes você não avisou que ele seria
utilizado. É como você configurar suporte a discos SCSI com determinada especificação,
se você não avisou o kernel que ele vai ter que suportar controladoras SCSI. Tudo bem
lógico.

- Finalmente chegou o momento de instalar o seu kernel. Para isso, digite:

# make install

Nesse diretório onde tudo está acontecendo.

Agora ele vai compilar o seu kernel no seu sistema, como sendo o kernel do próprio, ou
seja, vai instalar o seu kernel.
 Desse momento em diante você elegeu o novo kernel como o kernel do FreeBSD. Agora
é só reiniciar seu sistema com um reboot rápido, para então carregar sua máquina com
seu novo kernel.

- Para bootar agora com seu novo kernel, digite:

# fastboot.

Agora você está mais que andando com suas próprias pernas, está andando com as
pernas que você escolheu pra si mesmo. Ou não? Bom, agora que você bootou com seu
novo kernel, é hora de você descobrir se tudo está funcionando bem, e, especialmente, se
por ventura o motivo maior de você recompilar seu kernel (algumas vezes, dispositivos,
como o MODEM) satisfez suas expectativas.

Caso o resultado seja negativo, recompile seu kernel usando os dados certos. É
fundamental conhecer duas coisas no seu dispositivo: DMA e IRQ. Se esses dados não
estiverem dispostos corretamente pro kernel, ele nunca os reconhecerá. Se você errou,
recompile o kernel de novo.

Agora a parte que muitos estão esperando chegar para saber. Se por algum motivo seu
sistema não iniciou com seu novo kernel, então basta digitar kernel.old no momento do
boot. Dessa forma você inicia sua máquina com o núcleo antigo.

2.3. Relembrando os passos.

Vamos então recapitular os passos necessário para nosso novo kernel.

- Entre no diretório onde se encontram os kernels:

Para isso:

# cd /usr/src/sys/i386/conf

- Faça uma cópia do GENERIC como seu novo kernel:

# cp GENERIC EEVIACBSD

No nosso exemplo, considerando seu servidor com nome de de EeviacBSD;

- Edite seu novo kernel com seu editor predileto:

# ee EEVIACBSD

- Configure seu arquivo como o novo kernel:

# config EEVIACBSD

- Ente no diretório do seu kernel:

# cd ../../SEU_KERNEL
 - Cumpra as dependências.

# make depend

- Construa seu kernel:

# make

- Instale seu kernel:

# make install

- Reinicie seu sistema com seu novo kernel:

# fastboot

- Lembre-se, se não bootar com o novo kernel, então inicie seu sistema com o kernel
antigo, digitando kernel.old no momento do boot.

- Tire o resto do dia de folga, vá beber uma pepsi ao som de Pearl Jam com os amigos.
Computador te deprime, os amigos te sorriem :) (how poser...)

2.4 Compilação do Kernel em ambientes futuros.

O Subcapítulo 2.4 dessa documentação antes da revisão tratava de um estudo de caso

que ilustrava o problema de uma interface de rede, e o solucionamento do mesmo
utilizando os meios que a recompilação do kernel coloca em suas mãos. Contudo agora
esse case foi adicionado como addenda no final dessa capítulo.

Vamos tratar agora de exemplificar a rotina de compilação do Kernel em ambiente

FreeBSD futuro. Hoje na série 4.X ainda é possível recompilar o kernel da forma como foi
explicado logo acima, contudo desde o final da versão 4.2 e e na versão 4.3 já existe uma
outra forma, mais rápida e segura que a atual. Essa forma consistem na compilação
previamente conhecida durante o processo de make world do FreeBSD nas versões
anteriores.

Até o momento da edição do novo Kernel, tudo permanece igual, contudo desde o
config pra frente, a rotina se altera.

Considerando que você já tenha o arquivo do seu kernel editado no

/usr/src/sys/i386/conf/SEU_KERNEL rotina essa feita exatamente como explicado acima,
agora você pode se dirigir à base-fonte do sistema operacional (/usr/src/) e chamar a
compilação do kernel, você vai 'pular' o processo manual de configurar o kernel, checar
dependencias e mandar ele ser compilado. Para isso você vai utilizar o comando make
buildkernel KERNEL=NOME_DO_SEU_KERNEL

Na prática, já com o arquivo do seu kernel editado:

# cd /usr/src/
# make buildkernel KERNEL=EEVIACBSD (no caso considerando EEVIACBSD como o
nome do Kernel)
# make installkernel KERNEL=EEVIACBSD

Pronto, esses dois comandos substituem todos os outros anteriormente explicados. O

primeiro manda o sistema construir o novo kernel, ele configura, checa as dependências e
começa a construir o kernel, caso haja algum erro no novo kernel, o erro é indicado aqui e
o processo de construção do kernel não se conclui. Caso tudo esteja bem você ja pode dar
o segundo comando.

Agora sim o segundo comando instala o novo kernel do seu FreeBSD e te deixa a
vontade para reiniciar seu sistema e usar seu novo kernel. Caso haja algum problema as
ações a serem tomadas são as mesmas já explicadas ao longo desse documento.

Como você pode perceber essa maneira é mais simples e mais automatizada.
Atualmente as duas maneiras podem ser feitas para compilar um novo kernel pro seu
sistema, contudo em versões futuras não sabemos quais delas vão ser adotadas nem se
ambas vão continuar a co-existir. No FreeBSD -CURRENT, versão 5.0-20001223
com últivo CVSup (atualizacão completa do sistema, veja capítulo 4) realizado em 28 de
Abril (2001), foram encontrados erros durante a checagem de dependências manualmente
no kernel, contudo a compilação dessa segunda forma ocorreu perfeitamente, o que deixa
claro que a forma com que o sistema checa as dependências nessa segunda maneira são
distintas. Talvez essa seja adotada.

2.5 Reconhecendo o seu modem no FreeBSD

Faz parte desse capítulo também aprendermos a reconhecer o modem no nosso

sistema porque, adivinha onde você vai ter que reconhecer? Isso mesmo, normalmente se
seu Modem não é reconhecido de imediato pelo FreeBSD, a solução para reconhece-lo
então é configurar seu kernel.

O FreeBSD procura usualmente o modem na cuaa1 (sio1) que é a COM2 no Windows.

Por default (padrão), as portas cuaa2 e cuaa3 (sio2 e sio3), respectivamente COM3 e
COM4, não são ativadas no FreeBSD.

Vamos supor então que seu modem esteja na COM4 do Windows. Essa configuração é
a mais comum dos modems internos no Brasil. Se você tem modem externo, certamente
ele deve estar na COM2, não tendo problemas com isso. No FreeBSD a COM4 é a device
cuaa3 (sio3 para o kernel).

Dessa forma, a configuração inicial que você tem no seu kernel será algo como:

# Serial (COM) ports

device sio0 at isa? port "IO_COM1" flags 0x10 tty irq 4
device sio1 at isa? port "IO_COM2" tty irq 5
device sio2 at isa? disable port "IO_COM3" tty irq 5
device sio3 at isa? disable port "IO_COM4" tty irq 5

Como você pode visualizar, a sio2 e sio3 estão desligadas (disable). Para que o kernel
enxergue seu modem, no nosso exemplo, onde a COM4 tem o modem instalado, você deve
remover a palavra disable da linha da COM4 (sio3) e configurar a IRQ de acordo com a do
seu modem. Na minha casa, o FreeBSD está assim:
 # Serial (COM) ports
device sio0 at isa? port "IO_COM1" flags 0x10 tty irq 4
device sio1 at isa? port "IO_COM2" tty irq 5
device sio2 at isa? disable port "IO_COM3" tty irq 5
device sio3 at isa? port "IO_COM4" tty irq 3

Não se confunda com as nomenclaturas das portas. No Windows, elas começam do 1,

COM1, COM2… no FreeBSD, começa do Zero, sio0, cuaa0, sio1, cuaa1. Para facilitar o
conhecimento das devices do FreeBSD, nada melhor que conhecer o porque dos nomes.
sio por exemplo é a Serial Input Output número N do sistema. Portando Serial I/O 1,2...
Essa dica vale pras outras devices também, como os wd2s2 da vida. Algo do tipo Writable
Disk número dois Slice dois, e ad0s1 que é o Ata Disk Zero, Slice Um. Assim
sucessivamente, toda device tem um nome fácil de se assimilar.

Assim que você recompilar seu kernel novamente, seu modem estará respondendo.
Claro, desde que você realmente tenha um modem, certo? Não vá achando que qualquer
modemzinho de 80 reais vai ser reconhecido dessa forma. Modem é Modem. Modens que
compartilham recursos (memória e processamento) com o RAM e CPU principal do
computador não são suportados pelo FreeBSD, porque não são MODEMs. Portanto nada
que se pareça com winmodem é suportado pelo kernel do FreeBSD.

2.7 Implementando o sistema de Quotas no kernel do FreeBSD

Agora cuidaremos para que o kernel do seu FreeBSD suporte o sistema de controle de
quotas. Esse sistema de controle de Quotas é um atributo muito importante no FreeBSD.
Ele permite que você defina quanto cada usuário pode usar de espaço em disco para suas
atividades.

Com a implementação de controle de quotas no Kernel do seu FreeBSD, você poderá

controlar o espaço utilizavel para e-mails, mara suas páginas pessoais, para estocagem de
arquivos, enfim, tudo que seja necessário controlar em termos de espaço em disco. A
utilização desse atributo é clara: permitir controle de espaço em disco de acordo com as
necessidades do sistema.

Bom, basicamente o que você precisa fazer para iserir o suporte ao controle de Quotas
no kernel do seu FreeBSD, é simples, basta inserir uma linha na configuração do seu
Kernel.

A linha em questão é "options QUOTA" e para fazer isso você tem duas maneiras,
óbvias, claras e fáceis. A primeira é editar seu kernel com seu editor de textos preferido, e
a Segunda é adicionar sem editor de texto algum. Vejamos agora.

Entre no diretório de configuração do kernel onde se encontra o seu arquivo de kernel,

edite o seu kernel, e insira a linha em questão, que habilita o suporte a Quotas no seu
sistema.

# cd /usr/src/sys/i386/conf
# ee SEU_KERNEL

Insira a linha "options QUOTA"

Salve o arquivo de edição do seu kernel.

 Ou então, insira diretamente no seu kernel a linha em questão. Para isso, digite o
seguinte:

# echo "options QUOTA" >> /usr/src/sys/i386/conf/SEU_KERNEL

Ou então:

# cat /usr/src/sys/i386/conf/LINT | grep QUOTA >>

usr/src/sys/i386/conf/SEU_KERNEL

Pronto, agoura basta compilar o seu kernel de novo, e seu sistema já estará com
suporte a Quotas. A Configuração de Suporte a Quotas do FreeBSD pode ser encontrada
na documentação apresentada no próximo capítulo.

Antes de reiniciar seu sistema com o novo kernel, porém, edite o arquivo /etc/rc.conf e
substitua a linha ‘check_quotas="NO"’ para ‘check_quotas="YES"’

# echo 'check_quotas="YES"' >> /etc/rc.conf

E apague a opção contrária. Fácil, não? :)

2.8 Firewall no FreeBSD (ipfw no kernel)

Uma das melhores e maiores características do FreeBSD é a robustes, confiança e

competência com que um sistema de Firewall pode ser implementado nele. O Kernel do
FreeBSD possui suporte a módulos de tratamente de informações (pacotes) que se tornam
uma grande arma na mão de um administrador de sistemas.

Uma firewall bem implementada com FreeBSD torna-se um módulo de segurança de

redes dos mais difíceis de serem quebrados. Dependendo da implementação do
administrador, o FreeBSD oferece dispositivos que impossibilitam qualquer acesso
indevido ao sitema.

Mais a frente você encontrará documentos mais detalhados sobre a utilização dessas
ferramentas, mas agoura vamos nos direcionar à implementação do suporte ao kernel para
elas.

Os módulos de IPFIREWALL do kernel do FreeBSD assim como o módulo DUMMYNET

são duas dessas armas importantes no gerenciamento de pacotes do sistema. Ambos
serão necessários na maioria das impletações relacionadas a configuração de firewall.
Alternativamente o FreeBSD também conta com outros dispositivos no kernel para
controlde de pacotes, entre eles os mais conhecidos, IPF, IPSec.

Vejamos então quais opções possíveis de serem incrementadas no kernel do seu

sistema, e quais as funções de cada:

options IPFIREWALL
Essa opção define o suporte do kernel ao IP FIREWALL. Essa é uma opção relevante e
fundamental para configuração de qualquer bom firewall. Insira essa opção no seu kernel
sem dúvidas!
 options IPFIREWALL_VERBOSE
Permite que a codifição dos pacotes sejam logadas. É a única maneira dos logs serem
efeitvados pelo syslogd. Sem essa opção, mesmo que você queira que seu firewall logue
suas atividades, nada acontecerá.

options IPFIREWALL_FORWARD
Permite suporte a Proxy Transparente. Importantíssimo de acordo com suas
necessidades.

options "IPFIREWALL_VERBOSE_LIMIT=100"
Define o tamanho do limite dos logs a serem "remanjejados" pro syslogd. A
Documentação oficial do FreeBSD faz uma piada dizendo que essa opção é importante em
redes hostis, para evitar que você crie um ataque de "Denial Of Services" com os Logs do
sistema por acaso.

options IPFIREWALL_DEFAULT_TO_ACCEPT
O Padrão da implementação do IPFIREWALL é negar pacotes de qualquer fonte para
qualquer destino. Essa opção faz o contrário, e diz que você vai permitir o repasse desses
pacotes de qualquer fonte para qualquer destino. A idéia dessa opção é fazer uma
implementação contrária, onde quase tudo é permitido, e você vai criar regras de negação
de pacotes manualmente.

Fora essas opções relacionadas aos módulos de gerenciamento de pacotes IPFIREWALL

temos também o módulo DUMMYNET, fundamental na implementação de controle de
fluxo de largura de bandas, entre outras funções.

Para adicionar esse suporte ao kernel, basta adicionar uma linha no seu kernel:

options DUMMYNET
Bom, para adicionar então essas opções no kernel, edite o arquivo de configuração do
seu kernel e insira os suportes desejados:

# ee /usr/src/sys/i386/conf/SEU_KERNEL

Adicione as linhas e salve o arquivo. Ou se preferir, adicionar todos os suportes do

IPFIREWALL digite o seguinte:

# cd /usr/src/sys/i386/conf/
# cat LINT | grep IPFIREWALL >> SEU_KERNEL

E no caso do DUMMYNET:

# cd /usr/src/sys/i386/conf/
# cat LINT | grep DUMMYNET >> SEU_KERNEL

Pronto! Agoura você já sabe como implementar os suportes necessários aos principais
módulos de firewall do seu FreeBSD. Veja mais sobre Firewall com FreeBSD e sobre o
ipfw nos capítulos seguintes. Adicionar o IPF e o IPSec no seu kernel é exatamente igual
os exemplos com o IPFIREWALL e com DUMMYNET

ADDENDA ÚNICA: Case ilustrativo, rede NE2000, no Grupo de Estudos de

FreeBSD da Faculdade.
 O motivo do kernel ser o segundo item da nossa documentação é simples. Como é um
estudo baseado em experiências reais, tivemos uma surpresinha desagravável, mas que
deu alguns dias de prazer até resolve-la. Nossa máquina não reconhecia de jeito nenhum
nossa placa de rede. Tínhamos uma placa conectada em um slot ISA, com exigências de
recursos um tanto delicadas.

Quando colocado em teste, o sistem reconhecia as placas de redes de outras diversas

máquinas, sendo essas PCI e ISA. Mas justo na nossa máquina e com a nossa placa de
rede, isso não acontecia. Pensar em trocar de máquina para por a placa (ou por ventura
uma outra) em um slot PCI foi cogitado, mas não seria a alternativa que mais renderia
conhecimento.

Claro que a conclusão, partindo do fato do sistema reconhecer outras placas ISA e PCI,
é que o kernel genérico não estava com entradas compatíveis no que dizia respeito a placa
de rede e o micro. Então a solução clara era, recompilar o kernel para ele reconhecer a
placa de rede.

Pois é, mas a simplicidade acabou quando constatamos que a placa de rede em

questão exigia DMA 0x300 e IRQ 3.

Percebemos então que essa combinação de DMA e IRQ eram, de certa forma, uma das
mais requisitadas do sistema.

A primeira alteração no kernel foi alterar as entradas da DMA e da IRQ da ed0 (device
da placa de rede) para os respectivos valores. Quando bootamos o kernel, novo, o
resultado foi: placa de rede reconhecida. Quatro linhas depois, o boot parou. Comflito da
IRQ 3 com determinado device que não servia pra nada.

A solução foi alterar aquela device. Agora a IRQ 3 não era mais necessária por aquele
problemático artefato.

Recompilamos de novo o kernel e, dispositivos disputavam pelo acesso na memória no

endereço 0x300. Pensamos em retirar o dispositivo, mas eram inúmeros. Tentamos então
usar a placa de rede em outra DMA. Isso aconteceu duas vezes.

Nada feito, só reconhecia mesmo na 0x300. Estranho, também achei, mas era o fato.

Percebi então que alguns dos dispositivos que usavam esses mesmos recursos nem
eram necessários ao sistema, foi então que resolvi fazer o que eu dei a dica no sub-
capítulo logo acima. Usando o dmesg eu vi tudo que era ou não necessário, foi tudo então
retirado, e o que sobrou que era necessário e pedia o mesmo recurso, foi delicadamente
atribuído às devidas IRQs e DMAs possivelmente compatiíveis com as que eles requeriam.
Como já havíamos testato isso na placa de rede, e ele realmente queria de toda forma os
recursos citados, fizemos isso com os outros dispositivos então.

O resultado final foi, o kernel FREEBSD da FATECBSD número #5 funcionando

perfeitamente com a placa de rede e todos os outros dispositivos.

Esse pequeno case, tem a função ilustrativa na demonstração de problemas comuns

como podem ser facilmente resolvidos com o poder que configurar seu próprio kernel te
dá.
 NOTA: O Intuíto desse segundo capítulo é deixar o usuário/aluno ápito a configurar e
compilar o seu próprio kernel, sempre satisfazendo as necessidades do sistema, em relação
à dispositivos e recursos da rede. É impossível documentar todas as prováveis
necessidades do administrador de sistemas em relação a possíveis modificações no kernel.
Contudo, temos certeza que a documentação disponível aqui vai ajudar e muito a iniciar
essa aptidão toda. A Experiência é a única arma que pode prover a um administrador todo
o conhecimento que ele precisa. Felizmente o LINT é de fácil assimilação e inglês de simples
compreensão.

E se algo deu errado com seu novo kernel, lembre-se, para bootar usando o kernel
anterior, na prompt do boot do sistema, onde aparece escrito F1 Dos, F2 FreeBSD, (ou
diferente), aperte a tecla de espaço, e depois entre com o kernel.old, apenas digitando
"kernel.old". Em ambiente futuro pode existir a nacessidade de digitar load kernel.old na
tela de contagem de 10 segundos, apertando a barra de espaço. Pronto, agora é só
conferir o que não foi bem editado em seu kernel, arrumar o problema e compilar de novo.

3. Informações de Âmbito Geral.

Olá! Esse capítulo da nossa documentação poderia ter o nome de Misc, de Mais
Informações ou qualquer outra coisa que sintetizasse a junção de uma série de
informações breves porém de suma importância. E é justamente isso que nós trataremos
agora, das questões mais comuns relacionadas a configuração do FreeBSD, e que na
maioria das vezes, as soluções são simples e diretas. Aproveite esse que com certeza será
um dos capítulos mais consultados da nossa documentação.

3.1 Instalando aplicativos portados - ports

A coleção de aplicativos portados do FreeBSD é baseada em um guia, um índice de

cada aplicativo que aponta para vários endereços na Internet onde o código fonte dos
mesmos podem ser encontrados.

Já foi comentado no Capítulo 1 dessa documentação o que são os ports, mas vamos
relembrar. Ports são aplicativos que foram portados, ou seja reescritos para o sistema
FreeBSD. É uma coleção com milhares de aplicativos de outros Unix (Unices), e
especialmente de Unix-Like do tipo Linux, que foram escritos novamente para
funcionarem perfeitamente, e as vezes até melhor que os originais, em plataforma
FreeBSD. Esses aplicativos são portados por inúmeros programadores ao redor do mundo
que programam para o FreeBSD; A comunidade FreeBSD é ainda mais absolutista que
outras de Unix de fonte aberto... por isso a qualidade dos aplicativos portados é louvável.

Agora vamos logo ao que interessa.

O diretório dos índices dos ports fica em /usr/ports/
Dentro de /usr/ports/ ficam os subdiretórios divididos por assunto, e dentro dos
assuntos, o aplicativo.

Para instalar, basta entrar dentro do diretório do aplicativo que você quer e digitar
make install.

# cd /usr/ports/sub_dir/dir_do_aplic
# make install

Por Exemplo, para instalar o cliente de e-mails 'pine':

 # cd /usr/ports/mail/pine4/
# make install

A partir desse momento o sistema se loga em algum dos endereços da internet pré
definidos no índice, baixa o código fonte, compila e instala o aplicativo. Conforme
percebe-se, para instalar um aplicativo portado pelo ports, é necessário estar na Internet.

Além de fazer o download do fonte do aplicativo, compilar o mesmo e instalar, o ports

ainda fazem checagem de segurança, checam a confiabilidade do aplicativo baixado pro
seu sistema, utilizando o checksum e aplica todos os patches de atualização do aplicativo
sempre que necessário, além de iniciar automaticamente a instalação (via ports também)
de qualquer dependência que o aplicativo venha a necessitar.

Depois do download, a TarBall com o fonte do aplicativo fica armazenada em

/usr/ports/distfiles. A limpeza do lixo criado pela compilação do aplicativo (sob o
diretório work/) pode ser feita com o comando make clean após a instalação com sucesso
do aplicativo.

3.2 Usando Interpretador de Comandos Shell BASH

O BASH com certeza é o Interpretador de comandos (Shell) mais usado e mais querido.
Contudo, o bash tem alguns problemas de frequentes bugs descobertos, e exatamente por
esse entre outros motivos, e porque o FreeBSD preza segurança do sistema acima do
conforto do usuário, o Shell padrão do sistema é o (c)sh e não o bash.

Mas não há nada que impeça você de ter o bash em seu sistema, e utiliza-lo com
interpretador de comandos padrão, contudo, recomendamos que você instale o bash2,
que é conhecido com bash seguro. Outra coisa é, apesar de ter o bash instalado, não usa-
lo como interpretador shell padrão em seu sistema. Deixe sempre o (c)sh como padrão,
especialmente para usuários do sistema e utilizados por daemons. Claro que poucos
precisam, e os que precisam de shell, deixe com (c)sh mesmo.

Para isso, instale o bash2 a partir do ports:

# cd /usr/ports/shells/bash2
# make install

Pronto, seu bash2 será baixando, compilado e instalado. Agora você tem o Bash-2x
instalado em seu sistema, no caminho /usr/local/bin/bash

Para adicionar esse como shell default para seus usuários, no passwd de cada um
deles, ao invez de chamar o /bin/sh, você põe o caminho /usr/local/bin/bash, como no
exemplo:

# vipw

Na linha do seu usuário, faça a modificação:

root:wll34fItx5pi.:0:0::0:0:El Pixie Root &:/root:/usr/local/bin/bash

 Caso você for mudar a shell do usuário ROOT para bash (não recomendado), e a
mesma coisa, para musar a shell padrão de cada usuário, por exemplo, no caso do
usuário Eksffa:

eksffa:w34fgrgll34fI9782lo.:0:0::0:0:Patrick Tracanelli
&:/usr/home/adm/eksffa:/usr/local/bin/bash

Você pode usar também o comando

#chfn eksffa

Para editar o passwd do sistema, é importante ressaltar, não utilize outro editor, como
ee, pico... porque eles não atualizarão o sistema, e sim apenas o arquivo de referência.
Apenas o vipw e o chfn garante a imediata reconfiguração do database do sistema.

Bom, então porque eu digo que não há necessidades de ajustar os shells default de
cada usuário para bash, e recomendo que não o faça?

A Resposta é a melhor possível: Por segurança. Para usar o shell BASH, basta apenas
digitar bash, mesmo com sh ou csh como shell padrão. Imediatamente você passa a
trabalhar com o BASH, e isso da segurança de restringir alguns usuários a poder fazer
isso, e que um usuário tenha bash, sendo utilizado de modo incorreto.

# bash

Esse comando é o necessário para iniciar o uso do BASH, e mantendo outro shell como
padrão. Recomendamos fortemente que isso seja feito.

3.3 Diferenciando arquivos usando cores no LS.

Existe um aplicativo portado para o FreeBSD que se chama GNULS. Esse LS de

padrões GNU aceita a opção --color, diferenciando assim os arquivos normais, dos
diretórios, dos arquivos executáveis, dos Links, de imagens, enfim, tudo do jeitinho que a
gente sabe que facilita a vida..

Para instalar o GnuLs, você pode utilizar de algum pacote pré-compilado, ou baixar e
compila-lo pelo ports. Para instalar o pacote, caso você tenha o GNULS em CD ou tenha
baixado o Donwload dele, basta usar a ferramenta pkg_add.

Monte o CDRom:

# mount /cdrom

Depois entre no diretório onde você pode encontrar o gnuls, normalmente:

# cd /cdrom/packages/misc/

E então instale o aplicativo

# pkg_add gnuls*.tgz
 Pronto, seu gnuls está instalado.

Agora da forma que nós recomendamos, utilizando o ports.

Entre no diretório /usr/ports/misc/gnuls/ e instale o aplicativo.

# cd /usr/ports/misc/gnuls/

# make install

Em seguida o sistema se conectará via FTP em um dos endereços pré definidos e fará o
donwload do código fonte, depois ele compilará e instalará o gnuls, tudo automaticamente.

Pronto, agoura você já está com o gnuls instalado, via package ou pelo ports. Agora é
só providenciar para que, toda vez que você de um LS, ele chame o gnuls com a opção --
color.

Para isso, basta criar uma alias:

# alias ls="gnuls --color"

ou
#alias ls="gnuls --color=auto"

Pronto, agora toda vez que você der um LS, o sistema chamará o gnuls com a opção --
color. Kitsch, não? ]:)

Para que isso se efetive automaticamente sempre que você se logar no sistema, coloque
essas aliases dentro do diretório /etc/profile.

3.4 Alterando o Cursor do Console do FreeBSD

O FreeBSD pode ter 3 tipos de cursores distindos. São o 'normal', o 'blink' e o

'destructive'.

Respectivamente, o primeiro é o cursor default do FreeBSD, aquele quadradinho

estático na tela. O segundo é o quadradinho default do FreeBSD, mas piscando
freneticamente... O Terceito é como o do Linux, fica um Underline ("_") piscando na tela.

Particularmente o que eu mais gosto é o blink. Parece que o sistema fica dizendo vai,
digita um comando, vai quero ordens, vamos, faça alguma coisa... é muito kitsch a
velocidade que o cursorzinho pisca, querendo sempre o próximo comando, eheheh...

Para alterar entre esses cursores, utiliza o aplicativo vidcontrol

# vidcontrol -c blink

No meu caso, e

#vicontrol -c [normal/blink/destructive]

Conforme sua escolha.

 De uma olhada nas outras funções do vidcontrol também, ele permite você mudar as
cores e fontes do console, inclusive o background, ehehhe... coloque a fonte verde e o
fundo preto e se divirta com um revival do sistema Unix na época dos monitores
monocromáticos, que eram lindos...

Para fazer o cursor desejado sempre ser iniciado como padrão, prossiga da mesma
forma que para adicionar o mouse em todos os consoles, mas adicione dessa vez a linha
allscreems_flags="-m on -c _nome_do_cursor" da seguinte forma:

# ee /etc/rc.conf

Agora adiciona a linha allscreems_flags="-m on -c blink"

Salve o arquivo, e pronto, na próxima vez que você reiniciar o seu sistema, você terá
Mouse em todos os consoles e terá o seu cursorzinho frenético piscando sem parar.
Coloque o cursor que você desejar.

3.5 Conectando-se à Internet via Modem (ppp)

Bom, aqui a maior dificuldade é o seu modem ser reconhecido pelo Sistema.
Normalmente você terá que recompilar seu kernel novamente, incluindo suporte ao seu
modem, com as DMAs e IRQs corretas. Uma explicação mais detalhada da compilação do
seu kernel de acordo com o seu modem pode ser encontrada no segundo capítulo da
nossa documentação. Parece complicado no início, mas depois de pronto você vai ver que
foi fácil. Vamos rever isso aqui.

Partindo do princípio que você já sabe compilar um kernel no FreeBSD, basta agoura
saber em qual interrupção seu modem opera. Entre no diretório do kernel e edite o seu
kernel.

# cd /usr/src/sys/i385/conf/
# ee ARKIVO_DO_SEU_KERNEL

No caso da minha máquina pessoal, que eu conecto via Modem:

# cd /usr/src/sys/i386/conf
# ee EEVIACBSD

Bom, eu cheguei no ponto de falar da minha máquina pessoal porque foi lá que eu
configurei pela primeira vez, e o IRQ padrão não funcionou. Por isso, saiba a IRQ do seu
Modem. O Manual, a Placa em sí, ou pelo Windows, são 3 maneiras de saber. Pelo
Windows, veja em propriedades do modem, qual porta e IRQ seu Modem usa.

Agora procure pela seguinte entrada em seu Kernel:

device sio3 at isa? disable port "IO_COM4" tty irq 5

Nesse caso, vamos configurar seu Modem supondo que ele está na porta COM4 do
Windows, que é a cuaa3 no FreeBSD, ou sio3 para o Sistema. Se Esse não for o seu caso,
basta modificar de acordo com o seu sistema, ou veja no Capítulo 2 esse mesmo
procedimento, mas com mais detalhes.
 Finalmente, retire a entrada "disable" e ajuste a sua IRQ.

No caso do meu Modem está assim:

device sio3 at isa? port "IO_COM4" tty irq 3

Prontinho, agora é só recompilar o seu Kernel, e seu sistema responderá pelo seu
Modem.

Mais uma vez ressaltamos a importãncia de conhecer o hardware da sua máquina para
esse tipo de operação. Se você não sabe compilar o seu kernel, ou não se lembra, consulte
o Capítulo 2 da nossa documentação.

Bom, se seu modem já respondia ao seu sistema, todo esse texto acima foi a toa, e
agora sim chega a parte da configuração para se conectar ao seu provedor.

Bom, o primeiro passo é editar o aquivo /etc/resolv.conf para ajustar as configurações

de resolução de domínios na Internet. Para isso:

# ee /etc/resolv.conf

Configure as linhas domain, nameserver e search, para os dados do seu provedor de

acesso. É fundamental conhecer essas informações do seu provedor:

domain DOMINIO_DO_PROVEDROR.COM.BR
nameserver IP_DO_DNS_DO_PROVEDOR
search IP_DO_DNS_DO_PROVEDOR

No caso da Fatec:

domain FATECTQ.COM.BR
nameserver 200.210.2.10
search 200.210.2.10

Pronto, salve o arquivo /etc/resolv.conf

Agora começaremos a configurar o PPP para o seu provedor. Edite o arquivo

/etc/ppp/ppp.conf

# ee /etc/ppp/ppp.conf

Normalmente você já encontrará alguns dados de exemplo pra configuração de seu

ppp.conf

A configuração do seu ppp.conf deve estar assim:

#----------------------Configuração Exemplo Máquina EeviacBSD.def-------------------------

----#
default:
set device /dev/cuaa3
set speed 115200
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT \ OK-AT-OK
ATE1Q0
OK \\dATDP\\T TIMEOUT 40 CONNECT"
fatec:
set phone "3527005"
set reconnect 3 20
set redial 2 20
set timeout 240
set login
set authname eksffa
set authkey eksffaownsthisshittyworld
set ifaddr 10.0.1.2/0 10.0.1.1/0 255.255.255.0 0.0.0.0
add default HISADDR
enable dns
#---------------------------- conf Exemplo Máquina EeviacBSD.def -----------------------------
--#

A dica é ter atenção quanto à disposição do arquivo ppp.conf

A partir do exemplo acima, as unicas linhas que devem ser modificadas são:

set device /dev/device_do_seu_modem

fatec: (deve ser alterada pelo nome do seu provedor ou uma identificação qualquer).
set phone "NUMERO DO FONE DO PROVEDOR"
set authname NOME_DO_USUARIO
set authkey SENHA_DO_USUARIO

Prontinho, lembrando mais uma vez, modifique apenas o que foi indicado. Algum
espaço no lugar errado pode fazer seu ppp não funcionar, e com certeza o fará. Salve as
configurações do seu ppp.conf e vamos nos conectar.

Agoura basta digitar ppp:

# ppp

Ok, agora irá aparecer na prompt do seu console, algo assim:

ppp ON EeviacBSD>

Você está no ppp. Nesse local digite "dial seu_provedor"

ppp ON EeviacBSD> dial fatec

Então o ppp irá buscar todas as configurações do ppp.conf na linha referente ao "fatec:"
e irá discar. Depois de conectado, a prompt do seu ppp irá ficar maiúscula, de acordo com
a verificação, autenticação e estabelecimento da conexão, resultando numa prompt
assim:

PPP ON EeviacBSD>

Para desconectar basta digitar "close", para sair do PPP, digite "quit".

PPP ON EeviacBSD> quit

 Bom, agora sim você viu como funciona, e descobriu que não tem nada de complicado
demais e que não possa ser feito. Se você for atencioso, percebeu também que, quando
você digita "dial fatec", o ppp busca na sua configuração a relação do que ser discado, no
caso a configuração a partir de "fatec:"

Isso quer dizer que sim, você pode ter configurado mais de um provedor para se
conectar com seu FreeBSD, basta seguir as regras para edição do ppp.conf. Veja o
exemplo do arquivo ppp.conf que eu tenho em casa:

#----------------------Configuração Exemplo Máquina EeviacBSD.def-------------------------

----#

default:
set openactive 10
set device /dev/cuaa3
set speed 115200
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT \ OK-AT-OK
ATE1Q0
OK \\dATDP\\T TIMEOUT 40 CONNECT"

fatec:
set phone "352 7005"
set reconnect 3 20
set redial 2 20
set timeout 240
set login
set authname eksffa
set authkey eksffaownsthisshittyworld
set ifaddr 10.0.1.2/0 10.0.1.1/0 255.255.255.0 0.0.0.0
add default HISADDR
enable dns

mdbrasil:
set phone "344 5000"
set reconnect 3 20
set redial 2 20
set timeout 240
set login
set authname thamaia
set authkey tha12zmaia
set ifaddr 10.0.1.2/0 10.0.1.1/0 255.255.255.0 0.0.0.0
add default HISADDR
enable dns

zup:
set phone "344 5500"
set reconnect 3 20
set redial 2 20
set timeout 240
set login
set authname desa
set authkey dr12z
set ifaddr 10.0.1.2/0 10.0.1.1/0 255.255.255.0 0.0.0.0
 add default HISADDR
enable dns

#---------------------------- conf Exemplo Máquina EeviacBSD.def -------------------------------#

Dessa forma quando eu digito

ppp ON EeviacBSD> dial fatec

ppp ON EeviacBSD> dial mdbrasil
ppp ON EeviacBSD> dial zup

O ppp tenta se conectar, respectivamente no provedor da Fatec, no da MDBrasil e na

ZUP.

Isso ajuda muito quando se tem vários provedores disponíveis. Mais uma vez, atenção
com a disposição da configuração. Um espaço a mais ou a menos fará a diferença.

Agora vamos dar uma atenção especial a formas de conexão sem usar esse script de
discagem, o ppp.conf.

Se você quiser fazer a conexão manualmente, basta digitar aqueles dados apresentados
acima no prompt do PPP:

ppp ON EeviacBSD> set device /dev/cuaa3

ppp ON EeviacBSD> set speed 115200

ppp ON EeviacBSD> set phone 123456

ppp ON EeviacBSD> set set authname <nome_do_usuario>

ppp ON EeviacBSD> set authkey <senha>

ppp ON EeviacBSD> enable dns

ppp ON EeviacBSD> dial

Claro que não existe vantagem aparente nesse processo de conexão, o script no
ppp.conf é mais vantajoso, contudo você pode precisar acompanhar a conexão caso
encontre alguma dificuldade em conectar, o que raramente acontece. O comandoo enable
dns manda ele pegar o servidor de nomes indicado pelo atendedor, alterando assim o seu
resolv.conf

Uma outra forma de se conectar é utilizando o terminal ppp para se comunicar

diretamente com o modem, para isso, você chama o terminal dentro do PPP, então você
checa pela resposta do modem, manualmente, e disca, manualmente também à conexão,
espera o momento de voltar para o modo de comunicação de pacotes:

ppp ON EeviacBSD> set set authname <nome_do_usuario>

ppp ON EeviacBSD> set authkey <senha>

 ppp ON EeviacBSD> term
AT
OK <
ATDT 23455455
EXPECT CONNECT <
OK
~p

Esse é um exemplo típico de utilização do terminal PPP, o comando AT checa pela

resposta do Modem, o ATDT manda ele discar (discagem de TOM) o número indicado
(ATDP para discagem por pulso). Depois disso ele vai esperar a directiva connect e então
você vai visualizar um monte de caracteres (braces) estranhos, que é o chamado ppp
garbage.

Então é o momento de retornar ao modo de pacotes para que a conexão seja

estabelecida, com o comando '~p'.

Se ainda assim algum problema que você venha a encontrar não puder ser resolvido,
você deve optar pelo comando set log no PPP, para saber os parâmetros utilize help set
no prompt do PPP; Quanto mais parâmetros você adicionar ao set log mais preciso seu
log vai ser, e mais fácil de descobrir algum problema, contudo, maior o arquivo de log vai
se tornar também. O arquivo de log vai ser gerado em /var/log/ppp.log.

Contudo, o próprio PPP pode dar informações do que está acontecendo, em sua própria
interface. Logo após uma conexão com sucesso, o ppp se torna PPP, então vamos
entender o que cada um desses P em maiúsculo indica:

ppp ON MAQUINA> nenhuma conexão foi estabelecida entre você (cliente) e o servidor
(antendedor RAS)

Ppp ON MAQUINA> O atendedor RAS em chamado atendeu sua máquina e uma

comunicação foi estabelecida com sucesso entre ambas as partes.

PPp ON MAQUINA> Agora seu usuário e senhas foram validados e você foi autenticado.

PPP ON MAQUINA> Finalmente agora houve uma concordância de endereços IPs entre
você e o servidor que te atendeu, agora você obteve um endereço IP não-estático que vai
identificar você para o resto do mundo durante toda sua conexão.

Isso vai ajudar muito a entender quando e porque sua conexão não se completou.
Agora você já está apto a se conectar remotamente via PPP na Internet e resolver qualquer
possível problema com essa conexão.

3.6 Rolar a Tela no Console, como SHIFT+PAGE UP/PAGE DOWN em outros Unix
ou clones.

É diferente, mas é extremamente simples. No FreeBSD pra você voltar e rolar a tela do
console, você tem que travar a tela e mover. Para isso, aperte a tecla "Scroll Lock"e use as
setinhas ou as teclas PAGE UP/PAGE DOWN para rolar. Destrave com "Scroll Lock"
novamente, para voltar ao normal.
 3.7 Tirando as Mensagens do Sistema que aparecem em todos os Consoles.

Por default, tudo de importante que ocorre com o sistema é logado e impresso na tela. Na
verdade isso é ótimo, pois tem a finalidade de chamar a atenção do usuário que estiver
usando o sistema, para alguma coisa que esteja acontecendo. Algumas vezes são
advertências de erro, outras são informações de alguem que logou no servidor, alguma
tentativa de RELAY, portscanning, enfim, tudo aparece do nada na tela do cidadão que
está na máquina. Perfeito para um Servidor, pra chamar atenção do administrador, mas
algumas vezes isso enche as paciências com mensagens bobas que nós não queiramos
que apareçam no nosso console sem ser convidadas.

Para tirar então todas aquelas mensagens, você deve editar o /ets/syslog.conf

# ee /etc/syslog.conf

Comente (coloque # no início das linhas) as seguintes linhas:

*.err; kern.debug;auth.notice;mail.crit /dev/console

*.err root
*.notice; news.err root
*.alert root
*.emerg *

Fazendo as linhas ficarem assim:

#*.err; kern.debug;auth.notice;mail.crit /dev/console

#*.err root
#*.notice; news.err root
#*.alert root
#*.emerg *

Agora salve as configurações do /etc/syslog.conf e re inicie o Daemon de Logs do

Systema, o syslogd. Para isso digite:

# killall -HUP syslogd

Agora sim, as mensagens de erro, alerta, emergência, autorização, notificação e todas

outras que usualmente aparecem em todos consoles serão apenas logadas, sem serem
impressas na tela.

3.8 Refazendo o gerenciador de Boot após instalar o Windows.

O Sistema Operacional da Miscrosft, ao ser instalado, altera o setor primário de boot e

coloca o boot dele lá sem perguntar ao usuário se é isso que ele deseja. Para resolver esse
problema de alienação da MBR e imposição da Microsft, existem duas opções.

Uma delas é bootar o FreeBSD com algum boot qualquer, por CD ou Disquetes. Então,
você entra na parte da instalação em que você define as partições. Não altere nada, e na
saída ele irá perguntar de você quer instamar o BootMgr, enfim, tudo exatamente como
explicado no capítulo de Instalação da Documentação da Eeviac.
 Depois saia e aplique as mudanças. Pronto, eis o seu Gerenciador de Boot prontinho
novamente.

A segunda opção é a mais fácil e é pelo Windows mesmo... No seu CD da distribução

do FreeBSD existe o bootinst.exe e o boot.bin.

Localize esses dois arquivos e copie-os para um diretório qualquer do Windows. Por
exemplo, C:\freebsd\ A seguir, execute o bootinst.exe com o boot.bin como parâmetro:

C:\freebsd\bootinst.exe boot.bin

O aplicativo perguntará em que disco você deseja instalar o BootEasy, e as opções são
0 para o primeiro disco e 1 para o segundo. Prontinho, agora reinicie o seu sistema, pois
você está no Windows, e bem vindo ao gerenciador de Boot, pra você escolher o FreeBSD,
claro... ]:-)

3.9 Configurando o seu Mouse para COPIAR/COLAR no console.

Copiar e colar textos é uma das tarefas mais básicas de um Sistema Operacional. E
nos Unix essa tarefa costuma ser ainda mais fácil que em outros sistemas operacionais,
com o apoio do Mouse. Sabemos que é só marcar o trecho com o Mouse, e pronto, está
copiado. Pra colar é só utilizar o segundo ou terceiro botão. Quer coisa mais fácil? Agora
vamos cnfigurar o nosso mouse de dois botões para copiar e colar no console do FreeBSD.

É simples, tão simples e fácil quanto ouvir Ava Adore do Pumpkins.

Para isso, você deve editar o arquivo /etc/rc.conf e adicionar a linha moused_flags="-m
2=3".

Para isso:

# ee /etc/rc.conf

Adicione a linha: moused_flags="-m 2=3"

Salve o arquivo, e pronto, a próxima vez que você carregar seu Sistema, você vai sair
copiando e colando feito um louco. Kitsch, não? Mas é essencial.

3.10 ALT+F1 no BitchX portado pro FreeBSD.

A função comumente aplicada às teclas ALT+F1, ALT+F2, são agora ESC+F1, ESC+F2,
ESC+F3... (...)
Prontinho, /join #FreeBSD,#radiohead,#Seattle agoura.

3.11 Ligando seu Mouse em outros Consoles

Seu mouse só funciona no console principal e isso não anda te agradando? Tudo bem,
isso é normal, e a solução é bem simples. No terminal que você deseja usar o mouse,
basta digitar
 # vidcontrol -m on

Se você quer que o mouse seja ativo em todos os consoles pra sempre, ao invéz de
apenas algum console específico, também é fácil. Edite o arquivo /etc/rc.conf e nele
adicione a linha allscreems_flags="-m on"

# ee /etc/rc.conf

Agora adiciona a linha allscreems_flags="-m on"

Salve o arquivo, e pronto, na próxima vez que você reiniciar o seu sistema, você terá
Mouse em todos os consoles.

3.12 Saiba como ter ainda mais consoles.

Como cada console do sistema é uma Device, então para permitir que seu FreeBSD
trabalhe com mais consoles, você tem que criar as Devices para os mesmos. O FreeBSD
tem um aplicativo que cuida de criar as devices. Ele fica dentro do /dev, onde ficam
também as Devices. Então para criar a device, basta digitar:

# cd /dev

# ./MAKEDEV vty12

Pronto, agora você criou mais uma device para terminal, basta agoura editar o
/etc/ttys

# ee /dev/ttys

Adicone agoura as Devices criadas:

ttyv0 "/usr/libexec/getty Pc" cons25 on secure

ttyv1 "/usr/libexec/getty Pc" cons25 on secure
ttyv2 "/usr/libexec/getty Pc" cons25 on secure
ttyv3 "/usr/libexec/getty Pc" cons25 on secure
ttyv4 "/usr/libexec/getty Pc" cons25 on secure
ttyv5 "/usr/libexec/getty Pc" cons25 on secure
ttyv6 "/usr/libexec/getty Pc" cons25 on secure
ttyv7 "/usr/libexec/getty Pc" cons25 on secure
ttyv8 "/usr/libexec/getty Pc" cons25 on secure
ttyv9 "/usr/libexec/getty Pc" cons25 on secure
ttyva "/usr/libexec/getty Pc" cons25 on secure
ttyvb "/usr/libexec/getty Pc" cons25 on secure
ttyvx "/usr/X11R6/bin/xdm -nodaemon" xterm off secure

Pronto, agora salve as configurações do /dev/ttys e mate o processo com:

#kill -HUP 1

Prontinho, menos um problema.. ]:)

 3.13 Reconhecendo sua RAM Total.

No kernel do FreeBSD, você avisa quanto o sistema disponibilizará ao máximo de

Memória Principal para suas atividades. Pra evitar que o sistema saia procurando por
memória onde não tem Se você não editou isso no seu Kernel, é provável que sua RAM
Total não seja reconhecida, e apenas o Limite máximo.

Vamos supor então que você tem 512 Megas de Memória Principal. Edite o Kernel do
seu sistema e inclua ou substitua a linha seguinte:

options "MAXMEM=(512*1024)"

Se você tiver mais, substitua o 512 pela memória total que você tem. Agora compile seu
kernel novamente e pronto. Se você não sabe como compilar seu Kernel, consulte o
Capítulo 2 dessa documentação.

3.14 Modificando o Editor Padrão.

É fácil mudar o editor padrão do sistema para o seu preferido. Se você estiver usando o
interpretador shell csh ou sh, digite:

# setenv EDITOR seu_editor_preferido

Exemplo:

# setenv EDITOR pico

E se você estiver usando Bash, digite:

# export EDITOR=seu_editor_preferido

Exemplo:

# export EDITOR=pico

Para tornar essa alteração fixa em seu sistema, adicione a linha predefidinida para o
seu shell no arquivo /etc/profile

# ee /etc/profile

Adcione a linha, e salve o arquivo. Prontinho, agora seu editor preferido será o padrão
do sistema.

3.15 Montando outras Partições (Fat, Linux) e disquetes. / Entendendo as

Devices do FreeBSD.

Assim como no Linux, é possível montar partições FAT no seu FreeBSD, e é possível
também montar partições Linux e algumas outras. Contudo, é necessário que seu sistema
esteja com o suporte aos tipos de arquivos que serão montandos. Esse suporte deve
existir no kernel que você está utilizando. Para ver se a partição que você quer montar é
suportado pelo seu kernel, liste os seus File Systems, usando o comando lsvfs

# lsvfs

O resultado deve ser algo do tipo:

Filesystem Refs Flags

------------------------- --------- -------------
mfs 0
ufs 1
nfs 0 network
msdos 0
procfs 1 synthetic
cd9660 0 read-only

Como você pode identificar (espero que possa...) nosso kernel de exemplo não tem
suporte à tipos de arquivos ext2fs. Mas contém à FAT (msdos).

Nesse caso, teremos que adicionar suporte à partições Linux. Faça o mesmo se não
existir suporte à partição Windows. Edite o seu kernel e adicione a linha.

options "EXT2FS"

Agora sim, salve e compile o seu kernel, e eis o seu kernel com suporte à Partições
Linux. Se você não sabe compilar o Kernel, consulte o Capítulo 2 da nossa documentação.

A sintaxe básica para montar sistemas de arquivos diferentes deve ser conhecida:

# mount [opções] [device/da/partição] [ponto/de/montagem]

No caso da partição ser Linux, a sintaxe é:

# mount_ext2fs [device/da/particao/linux/] [/ponto/de/montagem]

Para montar uma partição Windows então, vamos criar o diretório que será nosso
ponto de montagem. Nesse exemplo, vamos criar o /windows. Depois montaremos,
supondo que a device da partição windows seja /dev/ad0s2. Vamos então:

# mkdir /windows
# mount -t msdos /dev/ad0s2 /windows
# cd /windows

Pronto, agora você pode ver toda a partição Windows do seu sistema no diretório
/windows do seu FreeBSD. Para montar um disquete, o procedimento é o mesmo,
substituindo as opções. Vamos considerar que seu disquete esteja formatado em Fat
(windows).

# mkdir /diskete
# mount -t msdos /dev/fd0 /diskete
# cd /diskete
 Prontinho, agoura nós criamos o diretório /diskete, montamos o conteúdo do disco
flexível nesse diretório, e agora é só trabalhar com ele. No terceiro exemplo, vamos supor
que nosso sistema tenha dois sistemas operacionais, o FreeBSD e o Linux. Ou Três:
FreeBSD, Linux e Windows. Montaremos agoura a partição do Linux no nosso FreeBSD.

Vamos criar o diretório /linux, vamos montar o conteúdo da partição Linux nesse
diretório do nosso FreeBSD e usa-lo. Consideremos que nosso Linux esteja na Device
/dev/ad1s2.

# mkdir /linux
# mount_ext2fs /dev/ad1s2 /linux
# cd /linux

Prontinho, agora você já sabe como montar qualquer coisa que precise em seu
FreeBSD. Talvez o que você não saiba segue um caminho mais técnico. Agora você tem
que saber reconhecer qual device é correspondente à sua partição. Tentaremos explicar
de forma sucinta, como reconhecer seus Devices, sabendo qual partição de qual disco
corresponde ao que.

As devices são formadas da seguinte forma:

/dev/xxx

Onde xxx é sempre correspondente às suas Devices. Em caso dos discos rígidos, a
sitaxe mais usual é:

/dev/adxsxx

Vamos tentar entender então. Você tem inúmeros Disco rígidos, com inúmeras partições
primárias e/ou extendidas cada um. Isso tudo tem que ser representado de alguma forma
para o sistema, então vamos ser lógicos como os programadores que desenvolvem o
FreeBSD. Acha que as devices são bagunçadas? Você vai ver que não...

No Exemplo a seguir, vamos considerar que nós temos um Sistema Operacional Linux
na device:

/dev/ad0s2

E então, qual o motivo desse nome? Vamos 'debugar' Esse caminho:

/dev/ - Diretório do sistema que se alojam as devices. Nada de mais.

/dev/ad - Indica que nós estaremos trabalhando com um Disco Rígido. "ad' pode ser
interpretado como "Ata Disk" ou disco gravável padrão ata.

/dev/ad0 - No FreeBSD o esquema dos discos segue o da BIOS, portanto o disco rígido
número 1, no caso do disco for do tipo IDE, seria chamado pela BIOS de IDE0, e portante é
chamado pelo FreeBSD de ATA Disk 0. Então já identificamos que estamos trabalhando
com nosso primeiro disco rígido.

/dev/ad0s2 - Na grande maioria dos casos, nossos disco rígidos, por motivos de
segurança e performance, são particionados. As partições para o FreeBSD são chamadas
de Slices, ou fatias, e cada Slice corresponde a uma Partição. Já deu pra entender agora
então, que nós estamos trabalhando com o disco rígido número 1, e com a segunda
partição.

Essa é a lógica das devices de disco no FreeBSD. Os nomes das devices variam
seguindo essa lógica, e pode variar mais ainda, quando tratarmos de partições lógicas e
primárias, e de discos rígidos do tipo SCSI.

Podemos encontrar devices como:

/dev/ad1s2a
/dev/da0s2b
/dev/fd0

Onde, essas variam de Tipo de Discos, SCSI ou IDE, e de partições, e sendo essas
partições primárias, lógicas, secundárias, enfim... e no último caso, o /dev/fd0,
corresponde à device do primeiro disquete. Para entendermos, /dev/fd0 é a Device do
Floppy Disk número 0, ou o primeiro disquete.

Agora você já sabe como as devices do FreeBSD são separadas, e com certeza já pode
identificar cada uma delas. Devemos lembrar que essa explicação foi baseada na versão
4.3 do FreeBSD.

O mais importante agora é você saber em que partição de que disco está qual sistema.
Como você usualmente é quem é o dono do sistema, e deve ter feito todas as partições,
então acho que não existe mais problemas.

3.16 Bootar em Modo Monousuário.

No momento do boot do seu sistema, você é perguntado sobre bootar o FreeBSD ou

outro sistema Operacional. Escolhendo com o F1, F2 correspondente ao FreeBSD.Então
vai começar a contagem de 10 segundos para bootar o kernel. Nesse momento, aperte a
tecla de espaço (essa barrona grandona, maior que as outras teclas, na parte de baixo do
seu teclado).

Você cairá numa prompt assim:

disk1s1a>

Nesse momento é só digitar boot -s

disk1s1a> boot -s

Agora seu sistema iniciará em Single User Mode. Ou Modo Monousuário.

3.17 Implementação de Quotas no FreeBSD.

O sistema de controle de Quotas é um atributo muito importante no FreeBSD. Ele

permite que você defina quanto cada usuário pode usar de espaço em disco para suas
atividades.
 Com a implementação de controle de quotas no Kernel do seu FreeBSD, você poderá
controlar o espaço utilizavel para e-mails, para suas páginas pessoais, para estocagem de
arquivos, enfim, tudo que seja necessário controlar em termos de espaço em disco. A
utilização desse atributo é clara: permitir controle de espaço em disco de acordo com as
necessidades do sistema.

Teoricamente se você usa seu FreeBSD a nível de aprendizagem ou uso doméstico,

possívelmente nunca vai precisar setar os ajustes de QUOTAS para usuários. Isso
ocorrerá se seu FreeBSD é servidor, mas não compartilha muitos usuários também.

Mas caso seu FreeBSD seja um Servidor de aplicações e serviços múltiplos, e vários
usuários tenham acesso ao sistema, você mais cedo ou mais tarde sentirá a necessidade
de implementar controle de utilização de disco em seu FreeBSD.

Consideramos que você já compilou seu novo kernel com suporte à opção de QUOTAS no
seu sistema, e também já habilitou seu sistema para conferir as quotas de cada usuário
sempre que necessário, ou seja, já substituiu a opção check_quota='NO' por
check_quota='YES', no seu /etc/rc.conf

Agora sim vamos entender e começar a trabalhar com as configurações de quotas de

usuários. Podemos definir, inicialmente dois tipos de quotas possíveis, a userquota e a
groupquota, quotas por usuários e por grupos, nessa ordem.

Para usarmos as quotas, devemos antes definir em que sistema de arquivo nós
implementaremos esse monitoramento. Para isso, devemos editar o arquivo /etc/fstab e
nele indicarmos a quais partições de sistema de arquivos utilizaremos o controle de quota.
As linhas de identificações devem ser parecidas com a linha a seguir:

/dev/ad0s1f /usr ufs rw,userquota 2 2

Para entendermos, nessa linha eu estou dizendo ao sistema que a partição /usr,
encontrada na device /dev/ad0s1f será um sistema de arquivos de leitura e gravação e
que poderá ter sua quota restrita por usuário.

Você deve configurar seu sistema da maneira que melhor lhe parecer, de acordo com
seus discos e suas partições. Nesse caso setamos a partição /usr para ter seu controle de
quotas monitorado, pois é nessa partição que se encontra o diretório dos usuários de
nosso sistema.

Cabem aqui algumas considerações, feitas por Edson Brandi, UOL:

"Os limites aplicados atraves do uso de quotas sao baseados no espaco disponivel ao
usuario em disco (block quotas) e/ou no numero de arquivos por ele mantidos no sistema
(inode quotas). Em ambos os tipos (block/inode) , podemos definir dois limites distintos:
Hard e Soft .

O limite Hard nao pode ser excedido. supondo se que se definui para um usuario uma quota
Hard de 1000 blocos e se atualmente ele esta utilizando 900 blocos ele ira poder alocar
mais 100 blocos, porem ao tentar alocar 101 blocos , a operacao nao sera permitida.

O limite Soft pode ser excedido por um periodo determinado de tempo. Este periodo e
conhecido como perido "grace" e seu default e 7 dias, apos este periodo o limit soft e
convertido em hard e nenhuma outra operacao sera permitida ao usuario, enquanto ele nao
voltar a ficar abaixo do limite Hard. "

Pronto, passadas essas considerações, vamos definir as quotas para os usuários. As

quotas idividuais por usuários ou por grupos são definidas atravéz do comando 'edquota'.

edquota -u <usuário>

Para definirmos as quotas individuais para cada usuário, e

edquota -g <grupo>

Para setarmos os valores de quotas para os grupos de usuários.

Quando você vai definir ou reajustar alguma configuração de quota, o banco de dados
do sistema de quotas é consutado, e a apresentação desses dados é feita com o editor de
texto padrão no ambiente do sistema. Normalmente esse editor de texto é o 'vi', e para
modificar esse editor padrão, se você estiver usando um interpretador de comandos BASH,
digite:

# export EDITOR=ee

Nesse caso, considerando que você queira definir o 'ee' como o editor de texto padrão
do seu sistema. E caso seu interpretador de comandos seja o default, csh, digite:

# setenv EDITOR=ee

Também considerando que você queira substituir o 'vi' pelo 'ee'. Mais detalhes sobre
esses procediemto de ajuste de editores padrão podem ser encontrados anteriormente
nesse mesmo capítulo.

Então vamos editar as quotas de algum usuário agoura. Na nossa documentação,

vamos usar um usuário de testes, denominado por nós 'velouria'.

Para que você possa entender e visualizar melhor nosso exemplo, considere o
/etc/fstab da nossa documentação como sendo:

/dev/ad0s1b none swap sw 0 0

/dev/ad0s1a / ufs rw 1 1
/dev/ad0s1f /usr ufs rw,userquota 2 2
/dev/ad0s1e /var ufs rw,groupquota 2 2
/dev/wcd0c /cdrom cd9660 ro,noauto 0 0
proc /proc procfs rw 0 0

Certamente você reparou que definimos, a título de documentação apenas, a partição

/usr para ter sua quota gerenciada pelo sistema, usuário por usuário, e definimos a
partição /var para ter sua quota gerenciada pelo, sistema grupo por grupo.

Vamos então checar as quotas do usuário velouria.

# edquota -u velouria
 Então teremos sempre dados da seguinte forma, em nosso editor padrão:

Quotas for user velouria:

/usr: blocks in use: 15000, limits (soft = 30000, hard = 35000)
inodes in use: 100, limits (soft = 600, hard = 2000)

Podemos identificar então que o usuário velouria, em nosso sistema, pode utilizar até
35000 blocos de disco, cada bloco contendo 1024 bytes. Essa é a matemática para se
definir as quotas. O limite de 35000 é hard, e conforme considerado acima, é o que não
será excedido.

Podemos também verificar que o usuário velouria pode usar até 2000 inodes, ou seja,
2000 nós no sistema de arquivos, e que apenas 100 deles estão sendo utilizados no
momento.

Ainda podemos identificar, que são definidas essas regras para a partição /usr,
conforme configurado por nós anteriormente. Se outras partições tivessem controle de
quotas por usuário habilitado, então elas estariam descritas no nosso editor.

Vejamos, no nosso exemplo, o controle de disco por grupos de usuários.

# edquota -g fatecbsd
Quotas for group fatecbsd:
/var: blocks in use: 23422, limits (soft =10000, hard = 150000)
inodes in use: 200, limits (soft = 3000, hard = 42000)

Agora nesse caso, você já pode identificar sozinho os limites de utilização de disco
definidos pro grupo fatecbsd, mas queremos ressaltar nessa documentação, que a
partição em questão não é mais a /usr, e sim a /var, conforme configurado em nosso
/etc/fstab

Essa opção de quotas é extremamente poderosa, e deve-se tomar cuidado para não
definir quotas para usuários de sistema, por exemplo, e que essa restrição de recursos
não faça falta posteriormente.

É dessa forma que você alterará as quotas para cada usuário, ou para grupos. Acredito
que a partir dessa explicação você não encontre mais problema algum. Para verificar as
configurações de quotas utilize o comando quota -v <usuario>

Para mais informações consulte o 'man quota' e tudo que for relacionado, mas isso já é
o bastante para uma configuração básica.

3.18 Compartilhando sua partição SWAP entre Linux e FreeBSD

Bom, essa é uma das primeiras atualizações que eu faço à esse capítulo. Agora vamos
tratar de um assunto que com certeza interessa a grande parte dos usuários mais
avançados de sistemas operacionais de Rede. Se nós temos um computador pessoal,
nossa workstation rodando Linux e FreeBSD, e ambos os sistemas utilizam de uma
partição de SWAP, e nunca estão rodando ao mesmo tempo, então porque não
compartilhar o mesmo espaço para SWAP entre os dois sistemas operacionais?
 Bom, fazer o Linux usar a SWAP do FreeBSD eu não sei se é possível. Talvez não
porque o Linux requer uma espécie de autenticação especial no tipo da partição para
trata-la como SWAP, mas o FreeBSD pode tratar qualquer partição como espaço para
fazer SWAP. Então vamos compartilhar nosso espaço de forma que o Linux possa
entende-lo como SWAP e o FreeBSD também possa usar esse mesmo espaço pra SWAP.

Por motivos que eu creio estarem bem claros, esse sub-capítulo não é direcionado à
leigos, e não serei mais tão minucioso nas explicações, de forma como ocorre ao longo de
toda a documentação. Esse Como Fazer é destinado a usuários de FreeBSD e Linux, com
um nível médio ao menos de conhecimento nos dois sistemas operacionais.

Eu tive como base para preparar essa documentação um "mini how-to" que pode ser
encontrado em http://www.ibiblio.org/pub/Linux/docs/HOWTO/mini/other-
formats/html_single/Linux+FreeBSD.html escrito por Niels Jensen (nkbj@image.dk). Não
posso deixar de citar também o fx do #FreeBSD na Brasnet que me falou desse mini how-
to quando eu precisei compartilhar minha SWAP.

Bom, eu vou procurar documentar com certa atenção e um pouco de detalhe a mais
que no "hot-to" citado, mesmo porque eu encontrei outras dificuldades, que consegui
resolver. Considere que, sempre que eu citar partições, eu configurei o compartilhamento
de espaço em SWAP duas vezes, uma máquina com FreeBSD 4.3-STABLE junto a um
Linux Mandrake 2.2.12 e em outra maquina, com FreeBSD 4.1.1-STABLE com Conectiva
Linux 5.1, na Faculdade. Mas nessa Segunda eu formatei, porque ficou tudo estranho,
acho que errei alguma cousa... Na que tinha fbsd+mandrake tá perfeito até hoje! Mas o
importante disso é frizar que nenhuma vez existia o Windows como terceito sistema
operacional.

Se esse for o seu caso, considere as devidas adapatações nas minhas citações de
partição, e mãos a obra.

3.18.1 Considerações sobre as partições SWAP do FreeBSD

O particionamento da SWAP no FreeBSD se difere do Linux em alguns pontos, e, como

uma vantagem, a SWAP no FreeBSD segue um conjunto mais flexível de necessidades, o
que permite que o FreeBSD use tipos especiais de partições para seu espaço de SWAP.

A forma como o FreeBSD trata essas partições segue o mesmo esquema dos
tradicionais BSD, portados porém para uma boa convivência com os Computadores
Pessoais atuais, o que lembra de fato bastante o estilo de particionamento de outros
sistemas unix, como Ultrix, Digital Unix, Sun OS e Solaris, além, claro dos irmãos
OpenBSD e NetBSD, que são sistemas UNIX reais.

O FreeBSD não pode ser instalado em uma partição lógica criada pelo Linux ou mesmo
pelo DOS. E ainda, o fdisk do Linux mostras as partições 386/BSD ou BSD sem que você
force pra isso, com o comando "b" durante a execussão normal do fdisk.

3.18.2 Nomenclatura de partições no FreeBSD e no Linux

As partições no FreeBSD e no Linux são nomeadas de forma distintas, ou seja, as

devices controladoras tem nomes diferntes para cada partição.
 O Linux trata as unidades de disco como hda para o primeiro disco e hdb para o
segundo e assim sucessivamente. Já o FreeBSD trata os discos de forma mais parecida
com as BIOS das placas mães, chamando o primeiro disco de ad0, o segundo de ad1, e
assim por diante... Lembrando que, em versões anteriores ao FreeBSD 4.0-CURRENT, ou
seja, dos FreeBSD 3.X e anteriores, as devices se chamavam wd0 e wd1, seguindo a
mesma lógica. Se esse for o seu caso, de estar usando FreeBSD 3.X, por favor, considere.

Para as partições de disco, o Linux numera a patição, em ordem crescente e depois da

letra que identifica o disco, assim as devices das partições se chamam hda1, hda2, hda3,
hdb1 etc. O FreeBSD faz quase igual essa distinção, porém assinando a SLICE, ou
partição antes de indica-la, e rotulando uma letra ao tipo de partição, ficando assim as
devices ad0s1, ad0s2, ad1s1, ad1s1b etc...

Dessa forma, imagine a seguinte tabela para um entendimento melhor:

Linux FreeBSD -3.5 FreeBSD

+4.0
Primeiro disco IDE /dev/hda /dev/wd0 /dev/ad0
Segundo disco IDE /dev/hdb /dev/wd1 /dev/ad1
Primeiro disco SCSI /dev/sda /dev/sd0 /dev/da0s0
Segundo disco
SCSI /dev/sdb /dev/sd1 /dev/da0s1

E exemplo de partições (slices) considerando que estamos analisando a device

/dev/ad0 no FreeBSD....

Linux FreeBSD +4.0 FreeBSD -

3.5
Primeira primária /dev/hda1 /dev/ad0s1 /dev/wd0s1
Segunda primária /dev/hda2 /dev/ad0s2 /dev/wd0s2
Terceira primária /dev/hda3 /dev/ad0s3 /dev/wd0s3
Quarta primaria /dev/hda4 /dev/ad0s4 /dev/wd0s4

3.18.3 Instalando e preparando o Linux

Bom, primeiro instale o Linux normalmente, já prevendo o espaço livre que você quer
utilizar pro FreeBSD... lembre-se que o Linux não precisa de uma partição SWAP, então
isso pode ser fundamental na hora de decidir entre fazer ou não essa partição no
momento da instalação, já que se você não fizer, vai entrar no máximo 3 vezes no Linux
sem SWAP.

Bom, mas se você faz mesmo questão da partição SWAP no Linux, então faça ela no
espaço fora da sua partição, ou seja, onde ficará o FreeBSD tão logo você instale, já que
você vai Ter que apagar mesmo essa partição SWAP depois...

Continue a instalação do Linux normalmente como você já esta cansado de fazer... se

você não sabe instalar o Linux, leia documentação especializada pra isso... Ou melhor,
desencana de ler isso aqui e vai assistir Dragon Ball! Bom, depois que seu Linux já está
instalado redondinho, você vai ter que recompilar o seu Kernel. Se você é usuário de
Linux mas não tem conhecimento ainda o bastante para compilar o Kernel, procure
documentação para isso pela Internet, ou entre em contato comigo que eu te mando
ótimo material.
 Na compilação do seu novo kernel, você terá que incluir o suporte UFS e também
suporte a tabelas de partição do tipo BSD, ou seja, do tipo que seu FreeBSD vai trabalhar.
Essas opções aparecem com os nomes: UFS filesystem support (read only) e com nome
de BSD disklabel (FreeBSD partition tables) support.

Para adiciona-las, as entradas no configurador do seu kernel deverão ser parecidas

com:

UFS filesystem support (read only) (CONFIG_UFS_FS) [N/y/m/?] y

BSD disklabel (FreeBSD partition tables) support (CONFIG_BSD_DISKLABEL) [N/y/?]
(NEW) y

Ou se você usa alguma interface mais sociável para compilar seu Kernel, então basta
marcar o suporte a essas mesmas duas entrada, no menu do seu Kernel.

Agora tome cuidado para não deixar de se lembrar de nenhum dos próximos detalhes.
O primeiro, é você instalar o seu novo Kernel, reboote o seu sistema com o novo kernel, e
lembre-se de preparar um disco de boot compatível com esse kernel agora. Faça um boot
novo pro seu Linux. Agora edite o arquivo /etc/fstab e apague a entrada que aponta sua
partição de SWAP no Linux, se é que você criou uma...

# pico /etc/fstab

E delete a entrada da sua SWAP, algo parecido com:

/dev/hda4 none swap sw 0 0

Agora sim você está pronto pra instalar o seu querido FreeBSD :-)

3.18.4 Instalando e configurando o FreeBSD

Agora a parte mais inteligente da coisa: instale o seu FreeBSD!

Instale o seu FreeBSD normalmente, sempre prestando atenção à ordem de

particionamento e dos tipos de partição. Se você escolher que o FreeBSD se auto
particione, então a SWAP será a Segunda partição. Se você costuma particionar na mão
para o seu FreeBSD, então lembre-se de onde está a SWAP.

Se existir a partição de SWAP do Linux, então delete-a e aproveite o espaço pro

FreeBSD

Agora, depois que sua instalação do FreeBSD estiver completa, reboote o seu sistema e
entre nele com o disco de boot do Linux, que você fez para o novo kernel do linux.

Depois, já no Linux, use o comando dmesg e filtre as entradas dos discos (hd) para Ter
conheciement do seu particionamento atual. O comando deve ser:

# dmesg | grep hd

E a saída para esse comando deve ser algo parecido com:

 # dmesg | grep hd
Partition Check - hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 >

Ou seja, agoura você pode visualizar onde está todas as suas partições do Linux e as
do FreeBSD...

Nesse exemplo você identifica a partição Linux /dev/hda4 como sendo a sua partição
que está o FreeBSD, e as demais, como as partições contendo o FreeBSD.

Lembre-se que eu comentei pra você se inteirar de qual era a partição de SWAP no
FreeBSD. Se você não sabe, trate de descobrir, e se o particionamento das slices do
FreeBSD foi automática, então a Segunda partição BSD é a de SWAP, ou seja, a hda6.
Sendo assim adicone agoura essa partição de SWAP no Linux, editando o arquivo
/etc/fstab e adicionando a linha:

/dev/hda6 none swap sw 0 0

Para isso, use um editor de textos como o pico:

# pico /etc/fstab

E adicione a linha

/dev/hda6 none swap sw 0 0

Lembra-se que eu disse que o FreeBSD pode usar qualquer partição como espaço para
SWAP e que o Linux necessitava de uma assinatura especial na partição, certo? Para
garantir essa assintatura, você teria que usar o comando "mkswap" sempre que você
entrasse no Linux.

Pra evitar essa chateação, você pode encontrar o script que faz isso na sua inicialização.
Esse script que roda o "swapon", é comumente encontrado no caminho
/etc/rc.d/rc.sysinit

Mas isso pode variar de acordo com as distribuições Linux que você usa. Ache o
arquivo, e, antes da linha com o comando "swap -a" adicione essa entrada:

awk -- '/swap/ && ($1 !~ /#/) { system("mkswap "$1"") }' /etc/fstab

Isso assinara como partição de SWAP qualquer partição descrita como SWAP no
arquivo /etc/fstab e, se tudo correr bem, isso já é o bastante pra você estar usando seu
Linux e FreeBSD com a mesma partição para SWAP. Use o comando "free" pra garantir o
tamanho da sua partição de SWAP, reboote no FreeBSD pra ter certeza que tudo esta
correto, e se não estiver, você pode ter usado partição errada para definir como SWAP.

Ambos, LILO e BootMgr podem ser usado como gerenciadores de sistema operacional e
gravados na MBR. A escolha é sua... O LILO é mais facil de tratar e menos rigoroso, mas
eu confio mais no BootMgr. Já que você curtiu a idéia de brincar com FreeBSD+Linux
juntos, então leia o próximo sub-capítulo.

3.19 Montando sistemas de arquivos do FREEBSD no LINUX.

 Se existe realmente a necessidade de ter os dois sistemas operacionais instalados na
mesma máquina, e você fica com maior frequência no Linux (talvez porque você trabalhe
em empresas de Linux), então esse capítulo vai ajudar a você ler partições BSD a partir
do Linux. Até que você apague todo seu Linux e use somente FreeBSD.

Mas enquanto isso não acontece, ou não deixam que você faça acontecer, vamos
analisar outras formas de utilizar o seu Linux da melhor forma possível junto ao FreeBSD.
O FreeBSD tem suporte nativo a diversas ações ligadas a compatibilidade e uso em
conjunto com o Linux, e, apesar do Linux não ser tão competente em tratar o FreeBSD
como o FreeBSD é com o Linux, ele conta com alguns quebra-galhos que podem ser
usados, quando se necessita profundamente do FreeBSD mas tem-se que estar no Linux.

Nós vamos tratar agora de montar as partições com sistema de arquivos do FreeBSD
no Linux. No Capítulo 3.15 você viu que é extremamente fácil fazer a ação reversa, que é
montar ext2fs no FreeBSD, ou seja, montar o Linux no FreeBSD é fácil, porque o
FreeBSD é mais completo. O Kernel mais atual do Linux já tem algum suporte a esse tipo
de ação, mas o ideal ainda é:

Existe outra versão do UFS do Linux, que não necessita nem que suporte a UFS seja
adicionado no Kernel. Essa versão se chama U2FS, e pode ser encontrada no endereço:

http://www.mathi.uni-heidelberg.de/~flight/projects/u2fs/

Agora é só instalar o U2FS e incluir o carregamento dele como módulo no KERNEL.

Adicione também o suporte aos BSD disklabels, e lembre-se você pode abrir mão do UFS
agora. Detalhes sobre compilação de Kernel de Linux, como já disse não vem ao caso.
Procure documentação especializada, ou entre em contato comigo que eu providencio
ótimo material.

Agora sim, pra montar FreeBSD no seu Linux, use o comando:

mount -t u2fs /dev/hda8 /mnt

Ou se o seu kenel for mais atual, use o comando:

mount -t ufs -o ufstype=44bsd /dev/hda8 /mnt

Lembre-se, nem tudo é festa pra essa solução Linux: O U2FS é bem suportado apenas
para montar sistemas de arquivos para leitura. READ-ONLY FS. Versões para montar
com direitos de escrita existem, mas não são confiáveis, seguras. Eu não recomendo.

3.20 Instalando Binários do FreeBSD no Linux

Não sonhe tão alto... os pacotes iBCS do Linux dizem que podem fazer isso, apesar de
ninguém ter nunca conseguido.

4. Atualizando seu Sistema à partir dos Repositórios Centrais; Fazendo -STABLE;

CVSup

4.1 A atualização do Kernel nos Unix-Like mais usuais e no FreeBSD.

 Bom, esse capítulo vai tratar de uma das principais e mais comuns (por incrível que
pareça) atividades relacionadas a manutenção da estabilidade e confiança do FreeBSD; a
atualização do seu código fonte, ou seja, a atualização total do seu sistema.

Em relação aos Unix-Like mais conhecidos (a maioria dos Linux) a atualização e/ou
compilação de um novo Kernel é sempre a atividade mais usual na manutenção de sua
versão e atualização do mesmo. Isso porque "O Linux é apenas um Kernel". Acho que bati
pela primeira vez com essa frase nas listas de discussão sobre FreeBSD, tanto na
Brasileira quanto na Norte Americana (hehe, ok, a culpa da frase é do pessoal da
lista... ;p ), mas não descordei da Frase.

Quando você lê e aprende sobre o Linux, nunca sabe ao certo o que foi, afinal de
contas, que o Linus Torvalds fez... certo? Mas se sabe que não existe um Linux, ou uma
distribuição do Linux que seja mantida por ele. Isso porque ele desenvolveu o Kernel do
Linux, ou seja, o núcleo (ou o "Coração do Sistema" como alguns preferem) desse clode de
sistema Unix para Computadores Pessoais (IBM PC, x86, Intel).

A tarefa de fazer cada Linux o mais recente é a tarefa de escrever suas versões de
sistemas operacionais Linux com o Kernel mais recente... ou seja, é inteiramente baseado
e dependente do Kernel, o trabalho que homens como Alan Cox (Red Hat) e Patrick
Volkerding (Slackware), que é fazer de suas distribuições de Linux as mais adequadas,
para os usuários e seguidores de cada distribuição, em relação ao Kernel. Alguns seres
como o Alan Cox trabalham ativamente junto ao Linus Torvalds no desenvolvimento
também do Kernel, além de suas distribuições.

Por isso nos diversos Linux, a atualização do Kernel é o máximo que se pode fazer em
relação a atualização do sistema. Ter o kernel mais recente é garantia de ter o seu Linux o
mais atualizado possível. Em sistemas computacionais proprietários (como Windows (NT e
2000), Solaris, SCO Unix, IBM AIX, Novell Netware, etc...) não é possível a atualização ou
acesso aos códigos do kernel, nem para uma alteração pessoal, por isso estamos tratando
o Linux em nossos exemplos, por ser um sistema baseado em Unix e por ser aberto
também.

Bem, mas vamos voltar ao FreeBSD. Como você percebeu, a tarefa de compilar e fazer
um novo Kernel, no FreeBSD, é muito, muito mais usual que no Linux. Ao menos essa é a
intenção. Compilarmos o nosso kernel sempre para satisfazer da melhor forma possível as
necessidades de nosso sistema, e nunca termos módulos no Kernel que não
necessitemos... Por isso compilamos um novo Kernel a toda hora no FreeBSD. Com
frequência muito maior que no próprio Linux, que é um Kernel.

Isso garante que tenhamos sempre um sistema enxuto, e sem desperdícios de recursos.

4.2 Os Repositórios Centrais e o fonte STABLE.

Bem, esqueçamos então o Kernel, e vamos falar do sistema em sí. O FreeBSD permite
que você atualize não só o seu Kernel, como todo o seu sistema. Sim, o código fonte
inteiro do seu FreeBSD pode ser atualizado, garantindo assim que você tenha sempre a
versão mais estável do seu sistema.

Vamos partir do princípio. Quando você instala seu FreeBSD a partir de um CD, ou
uma imagem ISO, ou mesmo via FTP, você está instalando a base do lançamento de sua
versão, ou seja, o RELEASE da versão. Você nunca tem o sistema mais recente, mais
atual e mais confiável, porque versões novas e novas atualizações são apresentadas ao
mundo a cada poucos minutos...

Mas isso também não quer dizer que você esteja instalando um FreeBSD não confiável.
Pelo contrário, o FreeBSD é sempre o melhor que se pode ser de um Unix, e cada -
RELEASE é feito a partir do -STABLE anterior de sua série. Conheço administadores de
sistemas que simplesmente nunca viram a necessidade de atualizar o fonte de seu
sistema... como o administrador da Universidade de Franca (www.unifran.br) por exemplo,
que até hoje está com o FreeBSD 2x RELEASE.

4.2.1 Os Repositórios Centrais.

Você pode encontrar diversos servidores ao redor do mundo, que oferecem o códio
fonte mais recente para as diversas versões do FreeBSD. Esses servidores são chamados
de Repositórios Centrais. As versões 2x, 3x e 4x do FreeBSD são as que tem mais ênfase
na atualização de seu fonte hoje.

Basicamente o que acontece com esses códigos fontes dos repositórios centrais é, a
cada atualizaçãozinha que acontece com o FreeBSD, o fonte que foi atualizado é colocado
no ar a mercê dos usuários do FreeBSD. Essas atualizações podem ser desde alguma
coisinha para a melhoria do desempenho do seu sistema, alguns bugs não importantes,
até a descoberta de algum problema (bug) realmente sério em relação a alguma versão do
FreeBSD.

Em síntese, assim que algum Bug em alguma versão do FreeBSD (3x, 4x, 2x) é
descoberto, os desenvolvedores do sistema correm para resolver o problema, e assim que
a correção do Bug está pronta, imediatamente elas são colocadas On Line, nos
Repositórios Centrais. Dessa forma, a única garantia de se ter realmente o FreeBSD mais
estável e seguro possível, é ter a atualização mais recente de seus fontes.

A atualização do Código Fonte do sistema pode ser feita por inteiro, ou por partes,
chamadas de coleções ou módulos. Isso permite que apenas de tempos em tempos você
precise fazer uma parada planejada em seu sistema, para atualização por completo do
mesmo, e permite que você atualize determinado módulo ou coleção que teve um Bug
importante corrigido.

A identificação de como atualizar o Fonte completo ou apenas alguns módulos são

feitas no arquivo de configuração do(s) programa(s), e nós veremos isso com detalhes a
seguir.

E existem duas maneiras bem práticas de baixar o código fonte mais recente da sua
versão do FreeBSD. A primeira e ideal é utilizando o CVSup. A Segunda, apenas
recomendada em algumas situações, é a utilização do CTM.

O CVSup é o método mais recomendado porque sua ação depende tão somente do
administrador do sistema, já o CTM é uma maneira de atualizar o seu fonte que
independe de você, você configura as ações do CTM, e daí em diante a atualização de
novos fontes é feita automaticamente. Essa última opção é apenas recomendada quando
você não pode ter uma conexão ativa por muito tempo com a Internet.

A seguir vamos aprender a atualizar o sistema de ambas as maneiras. Vamos

considerar duas etapas para a atuaização por completo do seu sistema: A Primeira, é
sincronizar o fonte do seu sistema com os Repositórios Centrais; a segunda é compilar e
instalar o novo código fonte atualizado.

4.3 Sincronizando seu Fonte com o Repositório Central usando o CTM

O CTM. O CTM é um método para sincronização de seu código fonte ideal para
sistemas que não tenham uma conexão constante ou não possam estar conectados por
muito tempo à Internet. Normalmente esse tipo de circunstância é encontrada em
empresas que usam o FreeBSD como servidores de aplicações em sua Intranet, ou
pessoas não muito normais que querem usar seu FreeBSD como Desktop e mesmo assim,
sendo apenas o seu Desktop, fazem questão de ter a versão do seu FreeBSD mais
atualizada possível.

Se você simplesmente não tem uma conexão TCP/IP disponível ativamente pra você,
então o CTM é a melhor maneira de manter o seu sistema sincronizado com a árvore do
fonte dos repositórios centrais ao redor do mundo.

Eu pessoalmente não uso o CTM para atualizar os meus sistemas, mas para escrever
essa documentação eu configurei o meu FreeBSD pra atualizar automaticamente pelo
CTM. Os passos foram seguidos do "The FreeBSD Handbook" e a parte de CTM foi
contribuída por Poul-Henning Kamp <phk@FreeBSD.org>. Entenda esse trecho da
documentação como uma tradução para o português do FreeBSD Handbook, mas um
pouco mais direcionada, já que eu vou citar exemplos e demonstrar o que foi feito.

Bom, existem duas maneiras de se atualizar a árvore do fonte do seu sistema com a
dos Repositórios Centrais, usando o CTM. Uma delas é, se você tiver algum tipo de
conexão direta, mesmo que por um período pequeno de tempo com a Internet, pode
utilizar a forma de atualização via FTP. Se não, pode ajustar seu sistema a receber
automaticamente as atualizações por e-mail.

Essas atualizações são feitas por pequenos arquivos que são enviados a você (ou
buscados, via FTP), e que, usualmente, tem o menor tamanho necessário.
Frequentemente esses arquivos, que são chamados de "deltas", não ultrapassam o
tamanho de 5Kb. Algumas vezes apenas (uma em cada dez) esses pequenos "deltas"
podem chegar a ter entre 50Kb e 100Kb, e invariavelmente muito raramente, chegar a ter
mais que 100Kb. As atualizações são em média de 3 a 5 pequenos deltas por dia, nos
módulos onde essas são mais frequentes.

Uma única vez, a cada sistema que você tem que configurar para atualizar o fonte com
CTM, você precisará baixar um arquivo que tem em média 50MB. Mas essa tarefa é única.

4.3.1 Montando sua árvore CTM para atualização Inicial do sistema.

Inicialmente você precisa de duas coisinhas para preparar o seu sistema para receber
atualizações constantes do código fonte. A primeira delas é ter o programa CTM no seu
computador. Desde a versão RELEASE do FreeBSD 2.0 o CTM já está incorporado ao
FreeBSD, usualmente encontrado em /usr/src/usr.sbin/CTM , ou se você não tem o CTM
porque seu FreeBSD é mais antigo que o 2.0 (raramente) ou por algum outro motivo
desconhecido (Murphy), então você pode encontrar o CTM em:

ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm
 E os pequenos Deltas para alimentar o fonte do seu sistema. Esses pequenos deltas
podem ser conseguidos via FTP ou por E-Mail. Se você quiser pegar seus "deltinhas" por
FTP, basta se conectar, via FTP em:

ftp://ftp.freebsd.org/pub/FreeBSD/CTM/

E de lá se conectar no subdiretório específico da sua versão. Caso você estja usando o

FreeBSD 3.x então você terá que pegar seus deltas a partir do endereço:

ftp://ftp.freebsd.org/pub/FreeBSD/CTM/src-3/

E se você estiver usando o FreeBSD 4.x, então os deltas necessários ao seu sistema
estão em:

ftp://ftp.freebsd.org/pub/FreeBSD/CTM/src-4/

Ou se você quizer receber as atualizações automaticamente por e-mail, em média 3 por

dia, então você terá que enviar um e-mail para majordomo@freebsd.org e se inscrever nos
pequenos módulos de atualização. Esses módulos (listas) podem ser, entre os disponíveis:

ctm-announce
ctm-cvs-cur
ctm-cvs-cur-fast
ctm-gnats
ctm-ports-cur
ctm-src-2_1 (usual e fast)
ctm-src-2_2 (usual e fast)
ctm-src-cur-fast (e usual)
ctm-src-3 (usual e fast)
ctm-src-4 (usual e fast)

Mas vale lembrar que, essa lista pode mudar. Para saber sempre quais as listas
(módulos) disponíveis, basta se inscrever na lista ctm-announce@FreeBSD.org. Depois
para começar a receber a atualização, basta enviar e-mail com o nome-da-
lista@FreeBSD.org e no corpo da mensagem escrever "subscribe nome-da-lista".

Para a nossa documentação, eu me inscrevi apenas nas listas ctm-src-4@freebsd.org e

na lista ctm-announce@FreeBSD.org, mas você deve se inscrever na que melhor se
adequar a sua situação.

Vale lembrar que a lista ctm-cvs-cur@freebsd.org suporta a árore inteira do CVS, a

lista ctm-src-cur@freebsd.org suporta o ramo CURRENT (ou seja, desenvolvimento) e a
lista ctm-src-4@freebsd.org suporta o ramo das versões 4.X.

Tome cuidado para não se inscrever em listas desnecessárias e receber fontes errados.

Uma dica interessante: é recomendável (ao menos eu recomendo) criar um usuário no

seu sistema apenas para cuidar desses e-mails que conterão as atualizações. Pode-se
usar também um usuário já existente para outras finalidades, que não tenha seu
endereço de e-mail comprometido. Eu usei o usuário "velouria" que é um usuário para
testes do sistema, que já foi comentado na configuração de Quotas, Capítulo 3 dessa
documentação.
 4.3.2 Usando CTM pela primeira vez, o Único arquivo grande.

Inicialmente você precisa configurar um diretório onde você queira guardar os seus
deltas CTM. Para isso, crie um diretório de acordo com seu sistema. Eu criei um diretório
CTM na partição /usr, e aconselho que você faça o mesmo. Para isso digite no console do
seu FreeBSD, logado como ROOT:

# mkdir /usr/CTM

Pronto. Agoura você vai precisar de um Delta inicial. Esse delta é o maior arquivo com
o qual você vai trabalhar. Por padrão, a cada uma média de 100 pequenos deltas, é criado
um Delta maior, chamado de "src-cur*xEmpty.gz" (onde * corresponde a versão do delta
vazio) e normalmente tem de 25 a 50 Megas, em arquivos no formato ".gz" (compactados)
para economizar espaço em disco. Se você tem o CD da versão RELEASE do seu sistema,
então um "Delta Empty" como esses podem ser encontrados no CD, enconomizando assim
o download de um arquivo grande.

Mas vamos considerar que você não tenha o CD, então terá que baixar o arquivo
"empty" correspondente a sua versão do FreeBSD. Vamos tratar da versão 3.X e da 4.X
que são as que você certamente estará usando.

Para conseguir o arquivo "empty" para a árvore inicial do CTM na versão do FreeBSD
4.X, hoje, 6 de Agosto de 2000, 03:42 da Manhã, você deve baixar o Downloado do
arquivo em:

ftp://ftp.freebsd.org/pub/FreeBSD/CTM/src-4/src-4.0000xEmpty.gz

O arquivo se encontra hoje com 55,6Mb. A partir do momento que você escolheu o
"Delta Empty" para iniciar a sua árovre CTM, você precisará também de todos os outros
pequenos deltas com numeração superior a ele, os quais podem ser encontrados também
no mesmo diretório do arquivo "Empty" , ou seja, nesse mesmo caso, o endereço FTP é:

ftp://ftp.freebsd.org/pub/FreeBSD/CTM/src-4/

Vamos agora considerar que você vai atualizar o fonte usando o CTM de um sistema
que use o FreeBSD 3.X; Para conseguir o arquivo "empty" para a árvore inicial nessa
versão, o arquivo que você deve baixar hoje, 6 de Agosto de 2000, 03:44 da Manhã pode
ser encontrado em:

ftp://ftp.freebsd.org/pub/FreeBSD/CTM/src-3/src-3.0300xEmpty.gz

O arquivo se encontra hoje com 47,8Mb. A partir que você escolheu o "Delta Empty"
para iniciar a sua árvore CTM na versão 3.X, assim como relatado anteriormente, você
também precisará de todos os deltas com numeração maior que ele, os quais também
podem ser encontrados no mesmo diretório do arquivo "Empty" do FreeBSD 3.X, ou seja,
no endereço:

ftp://ftp.freebsd.org/pub/FreeBSD/CTM/src-3/

Agora que você já sabe onde e como conseguir os Deltas iniciais e os Deltas
subsequentes, vamos colocar eles no lugar certo. Considerando que você esteja seguindo
o meu conselho e trabalhando no diretório /usr/CTM então você deve criar mais três
subdiretórios, que são, respectivamente no nosso exemplo: /usr/CTM/deltas,
/usr/CTM/src e /usr/CTM/temp.

Para isso, digite, logado como ROOT:

# mkdir /usr/CTM/deltas
# mkdir /usr/CTM/src
# mkdir /usr/CTM/temp

No primeiro diretório, o /usr/CTM/deltas/ você deve colocar todos os arquivos deltas

com numeração maior ao "Delta Empty" que inicializará a sua árvore CTM. No segundo
diretório, o /usr/CTM/src/ se encontrará a fonte da sua árvore CTM; e o Terceiro diretório,
o /usr/CTM/temp/ será utilizado durante os processos de transição dos arquivos que
serão recebidos por e-mail para o diretório dos deltas.

Caso você tenha criado um usuário apenas para cuidar dos e-mails da atualização do
sistema, ou tenha utilizado um usuário já existente no seu sistema, como eu fiz com o
usuário "velouria" então basta se logar como esse usuário e executar os seguintes
comandos:

$ su -
$ Password: *****************

Isso fará você se tornar super usuário; isso é necessário para você inicializar a sua
árovre CTM. Note que como usuário "velouria" a prompt da minha shell é representada
pelo caracter "$" e como superusuário, a prompt da minha shell é representada pleo
caracter "#". Agora vamos enfim iniciar nossa árvore CTM. Para isso digite:

# cd /usr/CTM/src
# ctm -v -v ../deltas/src-cur.*

Dessa forma você entrará no diretório dos fontes CTM (/usr/CTM/src), e criará a árvore
CTM a partir dos arquivos Deltas existentes em ../deltas/ (que na verdade é o
/usr/CTM/deltas). Agora sim saia do login do superusuário e volte a trabalhar como o
usuário "velouria", para isso digite:

# exit

Agora sim, como usuário que cuidará da árvore CTM, digite o seguinte comando:

$ ctm_rmail -p /usr/CTM/tmp -d /usr/CTM/deltas -b /usr/CTM/src $MAIL

Esse comando vai pegar os e-mails que conterão os Deltas, irá aplicar esses Deltas à
sua árvore CTM, e em seguida apagará os e-mails. O ideal é sempre automatizar o
processo, para isso, você deverá criar dois apelidos de e-mail no seu sistema. Um apelido
de e-mail com o nome de "receiver-ctm" e outro com nome de "owner-receiver-CTM".

Para criar esses apelidos de e-mail e automatizar esse processo, você terá que editar o
arquivo /etc/alias e relacionar o apelido do "receiver-ctm" ao comando "|ctm_rmail -p
/usr/CTM/tmp -d /usr/CTM/deltas -l /CTM/assembly.log" e o apelido "owner-receiver-
CTM" ao usuário do sistema que será responsável pela atualização dos Deltas. Para isso,
logados como superusuário, vamos digitar:

# ee /etc/alias

Para editar o /etc/alias com o editor ee; Em seguida adicione essas duas entradas no
arquivo que esta sendo editado:

receiver-ctm: "|ctm_rmail -D -p /usr/CTM/tmp -d /usr/CTM/deltas -b /usr/CTM/src

-l /ctm/ctm.log"
owner-receiver-CTM: velouria@localhost

Agora salve o arquivo. Para consolidar a criação e apelidos de e-mail, nós devemos
atualizar o banco de dados de e-mail do sistema. Para isso digite:

# newaliases

Agora sim, vamos entender nossas últimas alterações: a primeira alteração relacionará
todos os arquivos que forem enviados ao "receiver-ctm" com o comando que decodificará
todos os deltas que chegarem no sistema, e depois irá instala-los automaticamente a
atualizar a sua árvore CTM, irá deletar os e-mails depois da atualização, e documentará
todas as ações no arquivo ctm.log.

A Segunda linha enviará mensagens de erros ou informações sobre novas atualizações

ao usuário velouria@localhost, que é o dono direto do apelido "owner-receiver-CTM". A
expressão "localhost" é a interface de LoopBack do sistema, isso indica que o usuário é
existente naquela mesma máquina, evitando assim que precisemos relacionar o apelido
de e-mail a um nome do tipo "velouria@freebsd.eeviac.org" por exemplo.

O último comando, "newaliases" atualiza o banco de dados de apelidos de e-mail no

sistema.

Pronto! Agora você terá automaticamente seu sistema atualizado com o Repositório
Central. Agora basta compilar o seu sistema sempre que desejar aplicar as alterações dos
fontes obtidos através do CTM. Como proceder para atualizar o fonte do seu sistema você
verá a seguir nesse mesmo capítulo.

Lenbrando que a utilização do CTM é recomendada apenas nos casos especiais citados
anteriormente. A utilização do CVSup é mais eficiente, segura e bem mais fácil.

4.4 Sincronizando seu Fonte com o Repositório Central usando o CVSup.

Agora vamos ensinar você a sincronizar o código fonte do seu sistema utilizando o
CVSup. Essa é a maneira mais fácil, eficiente e segura, já que não requer um usuário
recebendo e-mails com arquivos, nem apelidos de e-mail ou qualquer outra complicação
que seja.

A utilização do CVSup ocorre da seguinte forma: o CVSup é um aplicativo que se

conecta a um servidor (Repositório) central que contém todas as atualizações dos fontes,
de acordo com a versão do sistema que você está usando, e se conecta no servidor que
você configurar. A partir desse ponto, ele efetua o download, ou seja, copia pro seu
FreeBSD todo o código fonte estável disponível nos Repositórios. Ou se você preferir, ele
copia apenas os fontes atuais de determinados módulos do sistema, tudo de acordo com
sua preferência.

Para utilizar o CVSup para atualização do seu sistema, é necessário apenas duas
coisas. A primeira é a instalação do CVSup. A Segunda é editar o arquivo de configuração
com os dados necessários para a atualização do sistema.

Para instalarmos o CVSup, podemos faze-lo a partir do CDRom do FreeBSD ou instalar

a partir do Ports. Para instalarmos a partir do CDRom, basta colocarmos o CD do
FreeBSD no Drive da sua máquina, montar o CDRom e adicionar o pacote pré-compilado.
Para isso façamos:

Coloque o CD do FreeBSD no Drive de CDRom do seu Computador. Digite o comando:

# mount /cdrom

Depois instale o pacote pré-compilado do CVSup:

# pkg_add /cdrom/packages/All/cvsup-bin*.tgz

E, para instalar o CVSup a partir do ports, digite:

# cd /usr/ports/net/cvsup-bin
# make install

O Primeiro comando levará você até o diretório do binário CVSup, dentro do ports, e o
segundo inicializará a instalação, depois disso o sistema baixa sozinho o código-fonte do
CVSup e o compila, criando assim o binário para utilização. Mais informações sobre como
instalar aplicativo portados (a partir do ports) podem ser encontradas no Capítulo 3 desse
documento.

4.4.1 Criando o seu SupFile - Arquivo de Configuração do CVSup

Agora sim você já tem o CVSup no seu FreeBSD. Agora basta apenas criarmos o
arquivo de configuração que conterá as informações necessárias para o CVSup atualizar o
código-fonte do seu sistema.

Vejamos a seguir um como esse arquivo de configuração do CVSup deve ser. Ele deve
conter ao menos as seguintes linhas:

*default host=cvsup3.br.freebsd.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=RELENG_4
*default delete use-rel-suffix
*default compress
src-all

Essas são as linhas mínimas necessárias para a utilização do CVSup na atualização do

seu sistema. As seis primeiras linhas (todas com um asterisco na frente) são obrigatórias.
 Vamos entender melhor o que significa cada um desses parâmetros:

4.4.1.1 De onde sincronizar o nosso código-fonte?

*default host=cvsup3.br.freebsd.org

Essa linha indica o servidor do Repositório de onde o nosso sistema será sincronizado.
Essa linha indica que a máquina cvsup3.br.freebsd.org será o servidor de onde todo o
código-fonte do sistema será atualizado. A entrada br. no servidor de nomes (DNS) dos
servidores principais da FreeBSD.org direciona o endereço a um servidor que se situa na
nação Brasileira, portanto os Repositórios Centrais mais próximos de nós serão os que
tiverem o sufixo br. no seu endereço. Nesse caso o servidor cvsup3.br foi o que nós
optamos.

Outras possibilidades de configuração para essa entrada são:

*default host=cvsup2.br.freebsd.org
*default host=cvsup4.br.freebsd.org
*default host=cvsup3.freebsd.org

Onde as duas primeiras são outros servidores de Repositórios Centrais para o Brasil, e
a última é uma opção de servidor Fora do Brasil. É um servidor Norte Americano nesse
caso. Uma lista de endereços possíveis podem ser conseguidos no site do FreeBSD
(www.FreeBSD.org).

4.4.1.2 Onde manter nosso arquivo de "status"?

*default base=/usr

O FreeBSD mantém informações importantes para o CVSup, as quais são chamadas

de informações de base, em um diretório base. Essas informações são importantes para o
CVSup trabalhar da melhor maneira possível quando for atualizar o seu sistema.
Originalmente os manuais do FreeBSD indicam esse diretório base como o
/usr/local/etc/cvsup; Mas em várias listas sobre FreeBSD, se comenta sobre a uma
melhor eficiência quando o diretório base é o mesmo onde todas as atualizações do
código-fonte serão colocadas. Nesse caso portanto, o diretório /usr.

4.4.1.3 Onde você quer por a atualização no seu próprio sistema?

*default prefix=/usr

Essa entrada direciona o CVSup a colocar todos os arquivos de códigos-fonte que ele
atualizar no diretório indicado. É indicado que coloquemos esses arquivos no caminho
onde ficam todos os fontes de nosso sistema, ou seja, no /usr/src, mas como o diretório
src/ já é implícito em todas as coleções (módulos) de atualização, então o correto é
apenas o caminho /usr

4.4.1.4 Para qual versão você quer atualizar?

*default release=cvs tag=RELENG_4

 Essa entrada contém duas informações. A primeira indica que o CVSup deverá
atualizar o código-fonte para a última versão estável disponível no Repositório (default
release=cvs). Essa opção não deve nunca ser alterada, é ela que garante que após a
atualização do sistema, nós teremos as últimas e mais estáveis versões possíveis. A
segunda informação (tag=RELENG_4) indica para qual versão do FreeBSD você quer
atualizar. Na opção descrita acima, nós estamos indicando ao CVSup que atualize para a
última versão estável existente do FreeBSD-4.X. Hoje, 19 de Maio de 2001, a última
versão atual existente do FreeBSD-4.X é o FreeBSD 4.3-STABLE. Mas outras opções
podem ser ajustadas, e de outras formas. Por exemplo:

*default release=cvs tag=RELENG_3

Essa opção força o CVSup a atualizar o sistema para o FreeBSD-3.X mais recente e
estável que existir atualmente no Repositório Central. Independente de qualquer coisa, o
mais importante é a versão ser a última estável da série 3.X Atualmente isso
transformaria o seu FreeBSD-XX no FreeBSD-3.5.3-STABLE, que é o mais estável da
série 3.X hoje.

*default release=cvs tag=RELENG_3_5

Essa opção força o CVSup a baixar o código fonte do FreeBSD-3.5-STABLE, e

transformar o seu FreeBSD no 3.5-STABLE, independentemente se existir ou não uma
versão mais estável da série 3.X, como um FreeBSD-3.8-STABLE, (uma suposição).

*default release=cvs tag=.

Essa opção faz CVSup do seu FreeBSD pra última versão em desenvolvimento.
Portanto não atualiza para uma versão -STABLE, e sim para uma -CURRENT (corrente
desenvolvimento.

4.4.1.5 Outras opções necessárias.

*default delete use-rel-suffix

*default compress

Mais algumas configurações são usualmente necessárias para o arquivo cvsup. A

opção "delete" da plenas permissões para o CVSup deletar todos os arquivos que forem
desnecessários durante e após a atualização do sistema. Sempre acione essa opção para
garantir que seu sistema esteja sempre o mais atualizado possível.

A opção "use-rel-suffix", é necessária. Veja agora a pequena observação que o Manual

Oficial da FreeBSD.Org fala sobre essa opção:

"use-rel-suffix is ... arcane. If you really want to know about it, see the cvsup(1)
manual page. Otherwise, just specify it and do not worry about it."

Em outras palavras, diz pra você colocar a opção lá e não se preocupar com nada. E
pra você checar o Manual do cvsup(1) se quiser realmente saber sobre isso... Eu fui ver
no "man" e lá diz que é pra você confirmar que vai realmente usar as configurações de
RELENG no sufixo indicado... confuso, então desencana e coloca...
 A opção "compress" diz pro CVSup utilizar o método de compressão de arquivos do
GZIP. Diz que se sua conexão com a Internet for por um canal T1 (tipo de conexão de
banda larga) ou maior que isso, então não é necessária essa opção. De outra maneira, a
compressão ajuda substâncialmente na velocidade da atualiazação.

4.4.1.6 Quais coleções atualizar?

src-all

Essa opção diz ao sistema que você vai atualizar todos os fontes, sem nenhuma
exceção. Se a intenção não for atualizar o sistema completamente, módulos específicos
podem ser carregados para a atualização. Isso é muito comum em casos onde você tem
um sistema atualizado a algum tempo, e recentemente aconteceu a descoberta de um Bug
e a possibilidade de "Buffer Overflow" utilizando algum binário de comando do sistema.
Como o "ls" por exemplo.

No caso apresentado acima, o administrador do sistema teria a intenção de atualizar

apenas os fontes dos binários do sistema, e não o sistema todo. Esse tipo de situação é
muito comum, e pra isso os módulos de atualizção do CVSup são importantes.

Para uma melhor compreensão, segue abaixo um exemplo de arquivo de configuração

do CVSup com várias entradas. Exemplos de entradas alternativas estão comentadas, ou
seja, com um caracter "#" na frente e nessa COR, e são ignoradas pelo sistema. Apenas as
não comentadas, e nessa COR são lidas pelo CVSup. Veja:

#-----------------------------Exemplo de Arquivo de Conf. do CVSup----------------------------

*default host=cvsup3.br.freebsd.org
#*default host=cvsup2.br.freebsd.org
# Esse endereço acima poderia ser um exemplo de Repositório Central alternativo.
*default base=/usr
*default prefix=/usr
*default release=cvs tag=RELENG_3
#*default release=cvs tag=RELENG_4
#*default release=cvs tag=RELENG_3_5
# Os dois Exemplos comentados acima configurariam o CVSup para atualizar o código-
fonte da
# última versão estável do FreeBSD 4, e a outra linha, atualizaria para o FreeBSD 3.5
em
# especial. Mesmo que existisse outra versão 3.X mais recente estável. A que não está
# comentada manda atualizar para a última versão 3.X Estável.
*default delete use-rel-suffix
*default compress
src-all
# Se você não quiser atualizar o seu FreeBSD inteiro, então basta comentar a linha
acima
# "src-all" E descomentar a coleção (módulo) abaixo que você queira atualizar.
#src-base
#src-bin
#src-contrib
#src-etc
#src-games
#src-gnu
 #src-include
#src-kerberosIV
#src-lib
#src-libexec
#src-release
#src-sbin
#src-share
#src-sys
#src-tools
#src-usrbin
#src-usrsbin
#--------------------Fim Do Exemplo Do Arquivo De Conf. Do CVSup------------------------

Então basta editar um arquivo de configuração com as entradas que você desejar. Para
criar o arquivo de configuração que melhor satisfaça as necessidades do seu sistema,
proceda da seguinte forma:

# ee /usr/supfile

Onde será criado o arquivo /usr/supfile, e o mesmo será editado com o editor "ee".
Agora basta digitar as entradas necessárias para configuração do CVSup que melhor se
adeque às necessidades do seu sistema. Ou se preferir, basta copiar o exemplo
apresentado acima e fazer as alterações que você julgar necessárias.

Agora basta salvar o arquivo /etc/supfile e se preparar para atualizar o seu sistema.

4.5 Finalmente Atualizando o seu Sistema com o CVSup.

Agora sim chegou a hora de atualizar seu sistema a partir do CVSup. A linha de
comando para a utilização do CVSup é:

# cvsup supfile

Onde, claro, o supfile é o arquivo de configuração que você acabou de criar. No nosso
caso então, o comando ideal seria:

# cvsup /etc/supfile

Se considerarmos (e assumirmos) que você está rodando o CVSup sobre o X11

(Servidor X), uma vez que o CVSup é um programa gráfico, então uma tela com interface
GUI (Grafical User Interface - Interface Gráfica com Usuário) irá aparecer (ver Anexo
Único, Capítulo 4.8). Com ela, uma janela com alguns botões usuais. Aperte o botão "GO"
e Voi-Lá (será que é assim que se escreve?). Assista enquanto o código-fonte do seu
sistema é inteirinho atualizado...

Vale lembrar que se você estiver usando o CVSup pela primeira vez, você deve estar
usando ele como superusuário, para que, dessa forma, o CVSup tenha as permissões
necessárias para a atualização por completo do seu sistema. John Polstra
<jdp@FreeBSD.org>, que foi a pessoa que documentou pela primeira vez a utilização do
CVSup, no Manual Oficial do FreeBSD, diz que se você está atualizando sua árvore pela
primeira vez, então é normal que você esteja nervoso, com medo e apreensivo. Tudo bem,
ele fala sobre nervoso, o resto eu que acrescentei.
 Se esse for o seu caso, podemos fazer uma prévia da atualização verdadeira. Podemos
rodar o CVSup sem tocar em nenhum arquivinho importante do seu sistema, não
correndo risco algum assim. Apenas uma simulação. Claro que isso não tem graça.

Para isso basta criar um diretório de testes, e depois executar o CVSup indicando para
esse diretório. Para isso faça o seguinte:

# mkdir /var/tmp/teste
# cvsup /usr/supfile /var/tmp/teste

Agora você criou o diretório /var/tmp/teste e depois acionou o programa CVSup para
rodar nesse diretório de testes. Agora o CVSup irá se logar normalmente no Repositório
indicado no supfile mas não irá nem tocar o /usr/src. Ele irá fazer a comparação, e
colocará os arquivos que serão baixados no diretório indicado. A configuração base
também não será modificada. Partindo do princípio que você não precisa ser ROOT para
ler o /usr/src então você também não precisa ser superusuário para rodar o CVSup dessa
maneira.

Se você não estiver usando o X11, pelo fato do seu FreeBSD ser um servidor, ou
simplesmente não gosta de interface gráfica, então você pode usar o CVSup da seguinte
forma:

# cvsup -g -L 2 /etc/supfile

Eu não sou tão radical (pelo contrário, eu amo Enlightenment) quando estou na minha
máquina pessoal, mas em relação a atualizar o fonte do sistema eu prefiro faze-lo do
console. A opção "-g" diz pro CVSup não usar sua interface gráfica. A opção "-L 2" diz pro
CVSup imprimir na tela as saídas de detalhes da operação. Existem 3 níveis de detalhes,
"-L" de 0 a 2. O 2 é o mais detalhado, o Zero não mostra nada, a não ser mensagens de
erros.

Para mais informações relacionadas à outras opções do CVSup digite:

# cvsup -H

Mas tudo que você precisa saber já foi explicado. Se você gosta da maneira como o
fonte do seu sistema é atualizado com o CVSup (obviamente essa é a melhor forma) então
você pode cogitar a utilização do CVSup no Cron do seu sistema, mas vale lembrar que
pra usa-lo com o Cron, você deve desbilitar sua interface gráfica.

4.6 Compilando e Instalando seu Novo Sistema "STABLE"

Finalmente, chegou a hora...

Depois de atualizar o seu Sistema com o CTM ou com o CVSup, essa é a hora de,
finalmente, compilar, atualizar e instalar o seu novo sistema estável.

Mas antes valem algumas recomendações. A primeira delas, é que você precisa de um
bom espaço em disco, em especial na partição /usr para atualizar seu sistema com
sucesso. Em algumas documentações se fala entre 600Mb e 800Mb livres. O meu sistema
tem mais de 2GB livres, mas já compilei em sistemas com 500Mb livres, e nunca tive
problemas.
 A documentação oficial do FreeBSD não diz nada em relação ao mínimo de espaço
necessário.

Outra recomendação é fazer o clássico "Make World" do seu sistema logado com o
sistema em Single User Mode (modo monousuário). Para isso, basta digitar, como Root:

# shutdown now

E pronto, o seu sistema mata todos os processos necessários e para tudo, mantendo-se
apenas em modo mono-usuário. A última dica e recomendação, nem deveria ser dada,
deve ser usual na vida de um administrador de sistemas Unix, é fazer backup. Raramente
(nunca soube de ter acontecido) perde-se dados importantes durante a atualização do
sistema, mesmo quando esse falha, mas backup nunca é demais...

Para finalmente atualizar o seu sistema, devemos seguir de formas distintas no

FreeBSD 3.X e no FreeBSD 4.X. Veremos nas duas versões como proceder.

Para atualizar seu FreeBSD 3.X, entre no diretório dos fontes do sistema, faça a
compilação/construção do seu novo mundo (sistema) e depois finalmente, instale seu
novo mundo (sistema). Para isso digite:

# cd /usr/src/
# make buildworld
# make installworld
ou
# make world

Pronto, esses são procedimentos que vão demorar muito, muito tempo para terminar, e
quando acabar (depois de várias horas), você terá o mais recente e mais estável sistema
Sistema Unix da Distribuição-Linhagem de Berkeley.

Mas não se esqueça que, antes de reiniciar o seu sistema STABLE, você tem que
recompilar o seu Kernel. Tarefa mole, depois de um Make World. Mas se você não se
lembra como fazer, consulte o Capítulo 2 desse trabalho.

Agora vamos atualizar o fonte do nosso FreeBSD 4.X. O procedimento para isso é
menos simples, mas você se acostuma logo, e durante algum tempo, foi bem difícil se
completar com sucesso... mas parece que o problema era com os Repositórios,
recentemente já está tão simples como deve ser... sem precisar sair lendo logs de erros
para descobrir o que aconteceu...

Bom, sigamos então os procedimentos. Primeiro, claro, entre no diretório /usr/src/

depois construa seu novo sistema. Em seguida construa seu novo Kernel de acordo com
algum kernel já existente em seu sistema, ou edite um agora. Depois já instale esse
Kernel. Desproteja seu Kernel de gravações, renomeie seu kernel para /kernel.old, copie
seu kernel para /kernel, proteja novamente seu kernel contra gravações, entre em modo
mono-usuário, de um Make InstallWorld no /usr/src onde fica o fonte do seu sistema, e
finalmente, reinicie seu sistema.

Na prática:

# cd /usr/src
# make buildworld
 # make buildkernel=NOME_DO_SEU_KERNEL
# make installkernel=NOME_DO_SEU_KERNEL
# chgflags noschg /kernel
# cp /kernel /kernel.old
# mv /SEU_KERNEL /kernel
# chgflags schg /kernel
# shutdown now
# cd /usr/src
# make installworld
# shutodown -r now

-------------- Dica pessoal: -------------------

# cd /usr/src
# make buildworld
# make buildkernel KERNEL=EEVIACBSD
# make installkernel KERNEL=EEVIACBSD
# shutdown now
# mount -t ufs -a
# cd /usr/src
# make installworld
# mergemaster <- nao se esqueca dele... :)

Ótimo! Agora eis o seu sistema Unix com FreeBSD 4.3-STABLE (ou posterior) rodando
maravilhosamente atualizado. Mas lembre-se, na versão 3.X do FreeBSD, você deve
recompilar o seu Kernel antes de reiniciar seu sistema.

4.7 Paciência!!!

Esse sub-capítulo é somente para lembrar, que os processos de construção,

atualização e instalação do novo sistema estável (STABLE) é muito demorado. Tanto no
FreeBSD 3.X quanto no FreeBSD 4.X você pode fazê-lo no Sábado a noite, antes de sair
de casa para se divertir, que na Madrugada (ou manhã) do dia seguinte o processo ainda
estará sendo efetivado.

Se for atualizar o sistema de um Provedor de Acesso ou Serviço, então avise

anteriormente os seus clientes que haverá essa parada programada de suas atividades
normais, se é que você não roda sob um esquema de Alta-Disponibilidade, ou tenha um
servidor espelhado pra substituir o principal em casos de parada programada. E espero
que seu sistema tenha uma boa configuração e bons recursos.

Normalmente, em sistemas recentes com uma boa configuração, a operação não deve
levar mais que 5 horas. Em média leva 4 horas. Na minha máquina, um Dual SMP
escalonados @444Mhz e 128Mb de RAM a atualização do meu último FreeBSD 5.0-
CURRENT levou 2,5 horas. O FreeBSD 3.5-STABLE levava menos tempo...

Não se esqueça de recompilar seu Kernel antes de rebootar seu sistema.

4.8 Anexos.
4.8.1 - Anexo Único:

Screen Shot do CVSup - GUI

 Esse é um Screen Shot do CVSup - GUI (Interface Gráfica com o Usuário) em plena
atualização do código-fonte do sistema. Como você pode ver, as informações são bem
detalhadas, dando controle total ao administrador do que está acontecendo com seu
sistema. Não vai ser usual Screen Shots de interface gráfica durante essa documentação,
essa exceção é por conta de saciar uma possível curiosidade do leitor.

Apesar de bonitinha, a utilização do CVSup no FreeBSD em módo gráfico não é

recomendada. Ao menos eu não recomendo, e todas as pessoas com quem converso
também preferem, por desencargo de consciência (já que hoje em dia o X11 é bem estável)
fazer CVSup no Console.

5. BIND/DNS - Configurando Servidor de Nomes no FreeBSD

 Nesse capítulo trataremos de um dos mais nobres serviços que um servidor de Internet,
Intranet ou Extranet pode oferecer. Trata-se do DNS (Domain Name Server) ou Serviço de
Domínio de Nomes. Ou pra simplificar, os servidores de nomes.

A Configuração desse serviços, em ambiente Unix é quase sempre muito parecida.

Basicamente segue-se um padrão e formato para estabelecer nomes, zonas, rotas, e
ajustar o servidor de nomes (normalmente o named) para adotar essas configurações.
Depois dizemos ao nosso sistema que o BIND será responsáveis por essas consultas.
Todos os detalhes para que se possa configurar o DNS será explicado minuciosamente ao
decorrer desse capítulo.

Nessa documentação abordaremos o configuração de um Servidor de Nomes em

ambiente FreeBSD Unix, e o responsável por esse serviço será o BIND, servidor de nomes
de Berkeley. O BIND (Berkeley Internet Name Domain) é o servidor de nomes mais
utilizado no mundo. É utilizado inclusive pelos Root Name Servers, as espinhas dorsais do
serviço de nomes no mundo todo.

A Configuração do BIND é, no geral sempre parecida nos ambientes Unix, portanto

feitas as considerações necessárias, os procedimentos aqui apresentados com o FreeBSD
poderão ser aplicados à qualquer outro sistema Unix.

O BIND pode ser encontrado, via FTP em ftp://ftp.isc.org/isc/, no Internet Service

Consortium, ou no mirror brasileiro do ISC: ftp://ftp.pop-mg.com.br/pub/isc/. Sempre
sob o diretório bind/, bind8/ ou bind9/.

As informações aqui contidas, especialmente os esclarecimentos teóricos foram

baseadas no livro "DNS and BIND", escrito por Paul Albitz e Cricket Liu, publicado pela
O'Reilly & Associates. Os exemplos aqui apresentados são meramente ilustrativos, porém,
são baseados em configurações reais e funcionais.

A maior parte desse documento descreve os procedimentos para configuração de um

servidor de nomes, usando o BIND 8.2.4 e FreeBSD 4.3-STABLE. Considerações sobre o
BIND 9 são realizadas com base na versão 9.1.2 do BIND. Apesar de ser o mais popular, o
BIND não é o único set destinado à configuração de servidores de nomes. Eventualmente,
o Servidor da Faculdade de Tecnologia de Taquaritinga (fatectq.com.br) será usado como
exemplo, apenas de forma ilustrativa.

5.1 Introdução ao DNS

5.1.1 Conceitos de Nomes e Endereços

Toda interface de rede ligada a uma rede TCP/IP é identificada por um endereço IP
formado por 32 bits. Um nome pode ser atribuído a qualquer dispositivo que possua um
endereço IP. A atribuição de nomes aos endereços se deve ao fato de que é muito mais
fácil uma pessoa se lembrar de nomes do que de números. O software de rede entretanto
trabalha apenas com os números.

Na maior parte dos casos, os nomes e números podem ser usados indistintamente.
Desta forma, os comandos telnet freebsd.fatectq.com.br e telnet 200.210.2.11 levam
ao mesmo computador. Quando se utilizam nomes é necessário que exista um serviço que
efetue a conversão deste nome em um número IP para que se estabeleça a conexão.

5.1.2 Tabelas de Tradução Número x Nome

 A tradução entre nomes (mais facilmente memorizáveis) e números passou por diversos
estágios durante o desenvolvimento da Internet e das redes que a precederam.
Inicialmente existia uma tabela, chamada hosts.txt, mantida pelo DDN-NIC e que era
distribuída a todos os computadores da Internet. Com o crescimento da Internet este
esquema se tornou inviável, exigindo a criação de um serviço mais eficiente para a
resolução de nomes. A tabela hosts.txt foi substituída por um banco de dados distribuído
denominado Domain Name Service (Domain Name Server quando se trata da máquina e
dos daemons servidores que fazem o serviço) concebido por Paul Mockapetris. As
especificações encontram-se descritas na RFC 1034.

5.1.3 DNS - Domain Name Service

O DNS, ou Domain Name Service, foi desenvolvido para oferecer uma alternativa à
resolução de nomes através do arquivo hosts.txt que pudesse garantir seu
funcionamento eficiente mesmo em face do crescimento explosivo por que vem passando
a Internet, permitindo ao mesmo tempo que informações sobre computadores novos
sejam rapidamente disseminadas conforme a necessidade.

5.1.4 BIND (Berkeley Internet Name Domain)

Em ambiente Unix, o serviço DNS é implementado através do software BIND. O BIND é

um sistema cliente servidor. O lado cliente do BIND é chamado resolver. Ele envia
perguntas relativas a informações contidas no DNS a servidores de nomes (nameservers).
O servidor DNS responde à estas perguntas. O lado servidor do DNS chama-se named. O
Conjunto BIND/NAMED é a opção mais usada e mais confiável (quando bem
administrada) para serviços de nomes em sistemas Unix. Essa também é a nossa opção
pra serviço de nomes no FreeBSD. Não por acaso, o BIND é desenvolvido pela Berkeley,
assim como o BSD.

- Zonas
O termo zona (zone) se refere a informações contidas em um arquivo do base de dados
do DNS.

- Domínio
Parte da hierarquia de domínios, em forma de árvore de nomes, identificada por um
nome de domínio, e sempre sendo um tronco inferior à uma outra árvore de nomes (salvo
em casos extremos, os Top Level Domains ou Nomes de Níveis Altos).

5.1.5 Configurações BIND (Servidor)

O software BIND pode ser configurado de diversas maneiras. São as seguintes as

configurações mais comuns:

caching-only
Caching-only são servidores que rodam o programa named mas não são fontes oficiais de
informação a respeito de domínios. Estes servidores obtém a resposta a todas as
perguntas que lhe são direcionadas a partir de algum servidor remoto.

Servidores Primários
O servidor primário é a fonte oficial de todas as informações a respeito de um domínio
específico. Ele carrega as informações sobre o domínio a partir de arquivos locais
mantidos pelo administrador do domínio. O servidor primário é o servidor mestre devido
ao fato de que pode responder a qualquer pergunta sobre seu domínio com total
autoridade.

Servidores secundários
Servidores secundários são aqueles que transferem um conjunto completo de informações
a partir do servidor primário. Os arquivos descrevendo as zonas são transferidos do
servidor primário e armazenados no servidor secundário como um arquivo local. Esta
transferência chama-se zone transfer. O servidor secundário mantém uma cópia completa
de todas as informações a respeito do domínio e responde a perguntas com autoridade.
Consequentemente, um servidor secundário também é considerado um servidor mestre.

5.2 Configurações RESOLVER (Cliente)

O resolver é uma biblioteca de rotinas invocadas por processos que utilizam serviços
de rede.
Existem duas maneiras de se configurar o resolver. Pode-se usar a configuração
default, ou criar o arquivo /etc/resolv.conf, modificado para atender às necessidades
locais.

A configuração default utiliza o computador local como name server default e obtém o
nome de domínio default a partir da string retornada pelo comando hostname.

Para que esta configuração funcione o computador precisa estar rodando o processo
named e o seu nome precisa estar corretamente configurado. Se o sistema local não
estiver rodando o programa named, ou se o nome do domínio não puder ser obtido a
partir do comando hostname, faz-se então necessária a utilização do arquivo
/etc/resolv.conf.

5.2.1 O arquivo /etc/resolv.conf

A configuração do resolver utilizando o arquivo /etc/resolv.conf possui algumas

vantagens em relação à configuração default. Este arquivo oferece a possibilidade de se
definir claramente a configuração e permite que se especifique servidores de nomes
adicionais que podem ser usados caso o servidor default não responda.

Exemplo:
domain fatectq.com.br
nameserver 200.210.2.10
nameserver 200.210.2.11

search fatectq.com.br

5.2.2 Domínios

O DNS é um sistema hierárquicamente distribuído, concebido para realizar a tradução

de nomes para números necessária ao estabelecimento de conexões entre computadores
ligados à Internet. Sob este sistema não existe nenhum repositório central que contenha
informações sobre todos os computadores ligados à Internet.
 Esta informação é distribuída por milhares de computadores, denominados servidores
de nomes, ou name servers. Estes servidores de nomes encontram-se organizados de
maneira similar ao sistema de arquivos do Unix.

Esta hierarquia pode ser representada da seguinte forma:

O DNS possui um domínio raiz, localizado no topo da hierarquia de domínios, que é
servido por um grupo de servidores denominados root name servers . Esses servidores
raiz são mantidos pela InterNIC (falaremos sobre essa instituição mais adiante), e essas
máquinas ficam localizadas em diversas partes do planeta, América do Norte (Estados
Unidos/Canadá), Ásia e Europa.

5.3 Criação de Domínios e Subdomínios

O InterNIC (Internet Network Information Center), nos Estados Unidos tem a autoridade
para alocar domínios. Para obter um domínio, o interessado precisa submeter um pedido
ao NIC para criar um domínio sob um dos domínios de alto nível (net, gov, mil, org, com,
edu).

O NIC americano delegou à Fundação de Amparo à Pesquisa do Estado de São Paulo

(FAPESP, a autoridade para alocar domínios em níveis abaixo do domínio .br (net.br,
gov.br, mil.br, org.br, com.br e edu.br), Portanto o domínio .br é um Top Level Domain,
mantido pela Fapesp.

O registro de um domínio é feito diretamente através da Web no endereço

http://registro.br, neste endereço é possível também verificar se domínios pretendidos já
foram registrados. Diferentemente das normas adotadas nos EUA, a FAPESP não autoriza
o domínio de registros em nome de pessoas físicas. Apenas empresas ou órgãos
registrados de qualquer espécie e profissionais liberais podem se candidatar ao registro de
domínios. Prevê-se para breve a abertura do registro de domínios na Internet também
para pessoas físicas. Para o registro de domínios é cobrada uma taxa de R$50,00 e uma
taxa anual de manutenção do mesmo valor.

A InterNIC permite a aplicação de regras próprias para o registro dos domínios em todo
o mundo, portanto as regras para se registrar um domínio delegado sob o Top Level .br
são diferentes das formas de registro de outros domínios, não representados pela Fapesp.

5.4 Resolução de Nomes

5.4.1 Resolução Recursiva

Na recursão (recursion), o resolver envia uma pergunta recursiva a um servidor de

nomes para obter informações a respeito de um domínio. O servidor de nomes interrogado
é então obrigado a obter os dados solicitados ou retornar um erro informando que os
dados solicitados não existem ou que o domínio em questão é inexistente. O servidor de
nomes não pode redirecionar o cliente para outro servidor de nomes porque a pergunta foi
recursiva.

Se o servidor de nomes não for o servidor oficial do domínio a respeito do qual se quer
obter informações, ele terá que perguntar a outros servidores de nomes até obter a
informação solicitada. Ele poderá enviar perguntas recursivas a outros servidores,
obrigando-os a obter a resposta e retorná-la, ou poderá enviar perguntas iterativas se
aproximando de outros servidores que estejam mais próximos do domínio que está
procurando.
 5.4.2 Resolução Iterativa

A resolução iterativa não requer tanto trabalho por parte do servidor de nomes
consultado. Na resolução iterativa, o servidor de nomes retorna ao cliente a melhor
resposta que já conhece. Não existem perguntas adicionais.

O servidor de nomes consultado pesquisa seus dados (inclusive o seu cache). Se não
encontra a informação desejada entre estes dados, ele tenta fornecer ao cliente (resolver) a
melhor informação que puder que possibilite a continuação da resolução do nome
desejado. Normalmente esta informação consiste de nomes e endereços de servidores que
estejam mais próximos dos dados que se procura.

5.4.3 Resource Records (RR)

A maior parte das entradas nos arquivos de banco de dados do DNS são chamadas de
Resource Records. As pesquisas feitas pelo DNS ignoram se as letras são maiúsculas,
minúsculas ou misturadas. Normalmente se utilizam apenas letras minúsculas. Os RRs
precisam iniciar na primeira coluna.

A tabela abaixo lista os tipos principais de RRs encontrados nos arquivos de

configuração do DNS:

SOA - Marca o início de uma Zona com autoridade máxima sobre o Domínio referido.
Sintaxe ordenada é o Domínio em questão, o endereço de domínio do admin, um número
serial e os parâmetros Refresh, Retry, Expire e TTL Mínimo, em segundos. Para mais
informações veja a RFC 883 e RFC 2808.

NS - Lista um servidor de nomes com autoridade sobre este domínio.

A - Mapeamento quartenário de nomes para endereços IP (xxx.xxx.xxx.xxx)

PTR - Ponteiro utilizado para mapeamento reverso, ou de endereços para nomes.

CNAME - Nomes canônicos (para aliases) - Canonical Names são os Apelidos referidos na
configuração de um Servidor de Nomes.

NULL - Uma referência NULA de Nomes. Sem dados e sem formato.

TXT - Informações textuais

RP - Responsible Person - Informações sobre o responsável pelo Servidor de Nomes, por

um MX Record ou por uma entrada TXT.

HINFO - Host Information. Informações sobre o Host, como qual o Sistema Operacional.

Fonte de informações para essas entradas foi o FreeBSD System Manager’s Manual
NAMED(8)
Internet domain name server (DNS) - Para mais informações, digite no seu FreeBSD: man
named
5.5 Arquivos de Configuração

Agora nós trataremos dos arquivos de configuração do servidor de nomes no FreeBSD.

Antes, porém, vamos fazer algumas observações sobre a estruturação hierárquica desses
arquivos.

Em síntese, quando você aprende a desenvolver os arquivos de configuração do DNS

para um sistema Unix, você tende a seguir os padrões adotados pelo curso que você fez,
pelos amigos que te ensinaram, pelos arquivos que você obteve como exemplo e aprendeu
sozinho, ou pela documentação que você leu para aprender a configurar o servidor de
nomes.

Outras vezes esses padrões são adotados devido ao sistema que você está usando. Mas
o mais importante é você ter em mente que as configurações do seu DNS, é você quem faz,
portanto o mais importante é entender como funcionam os arquivos utilizados para que,
qualquer leitura de um outro servidor de nomes possa ser facilmente assimilada. Você
pode ter um padrão próprio de configuração.

Durante essa documentação, adotaremos um padrão hierárquico utilizado por mim

(Patrick Tracanelli) na configuração do servidor de nomes nos sistemas com FreeBSD que
eu implemento. Mas para melhorar o conteúdo desse documento, vou sempre relatar as
formas mais usuais que as pessoas costumam configurar seus arquivos.

Para isso, devemos entender a ordem que os arquivos hierarquicamente são invocados.
Quando se inicia o servidor NAMED, o primeiro arquivo que você deve mostrar a ele é um
arquivo de configuração básico, que contém informações que dizem, qual é o diretório
padrão onde o servidor de nomes deverá trabalhar seus arquivos. Depois disso, esse
mesmo arquivo também indica quais outros arquivos, e de que tipo eles são, que devem
ser procurados para determinada finalidade. Você entenderá isso de forma clara a seguir.
O Passo seguinte, é o servidor de nomes carregar todos esses arquivos de configuração
indicados (no caminho indicado no início do arquivo, sob a directiva directory{}).

Nesse momento então, se o conteúdo de todos esses arquivos for interpretável pelo
named, então seu servidor de nomes deverá estar rodando. Interpretável porque, aqui sim,
o conteúdo das informações deve seguir uma padronização que o servidor de nomes
entenderá.

O que diferencia e influencia o administrador na adoção de um padrão é normalmente

o sistema onde ele trabalha, e a versão dos softwares com os quais ele trata. Usualmente
o named, quando iniciado por padrão, procurava pelo arquivo named.boot para iniciar
seu serviço de nomes. Em alguns sistemas Unix e clones de Unix, como o Linux, o padrão
é procurar pelo arquivo, no caminho /etc/named.boot

Os named mais novos, no entanto, adotaram o arquivo padrão a ser procurado como
sendo o named.conf, uma opção mais considerável, na minha opinião. Outra grande
diferença é que, em sistemas Unix System V, esse caminho também é o /etc/named.conf,
porém no FreeBSD, o named trabalha no diretório /etc/namedb ou seja, então ao ser
iniciado, o named procura pelo arquivo /etc/namedb/named.conf, para então carregar
toda a configuração de serviços de nomes.
 Se você nunca trabalhou ou viu alguém configurando um servidor de nomes está
achando essas informações todas desordenadas, mas tente apenas entender o conceito,
pois a prática é bem associável a ele.

Bom, depois de carregado então o arquivo inicial de configação, o named recebe

informações que dizem em que diretório ele deverá trabalhar os seus arquivos de nomes.
Recebe informações sobre quais arquivos de bases de dados contém as informações com
as quais ele vai trabalhar, e de que tipo; Então essas informações são carregadas. Em
alguns ambientes Unix, os administradores costumam trabalhar seu serviço de nomes
com os arquivos de base de dados no diretório /var/named/. No FreeBSD Unix o padrão
é trabalhar as configurações no mesmo diretório da base de dados, ou seja, com a base de
dados também em /etc/namedb.

Essa é uma das difereças que cabe a você adotar ou não, de acordo com seu tipo de
administração. Eu adoto o padrão /usr/named, ou /usr/home/named. O porque deu
fazer isso é, algumas vezes segurança (como quando rodo o BIND chrootado, por exemplo)
e outras vezes, também por segurança, hahaha xsxsxsx Prometo esclarecer esses pontos
adiante. Agora vamos continuar com a implementação em sí.

A última difereça é como nomear os arquivos. Com o Servidor de Nomes, nós estaremos
trabalhando com alguns tipos diferentes de arquivos. Arquivos de Base de Dados de
informações sobre a máquina servidora, base de dados do domímio pelo qual nosso
servidor de nomes tem autoridade, base de dados de domínios virtuais dos quais nós
também temos autoridade, base de dados de relacionamento global, com os Root Name
Servers e com outros grandes servidores de nomes importantes (que é o que fará nosso
servidor de nomes se comunicar com os principais servidores ao redor do mundo), ainda,
com informações sobre a interface local de nomes, e por último, trabalharemos com
informações reversas de tudo isso sob o que nós temos autoridade.

A grande questão é, todos esses arquivos, são arquivos de texto, e como nos Unix não
existe distinção de arquivos por extensão, a forma como você nomeia seus arquivos deve
ser sua maior aliada na organização do seu servidor de nomes.

Dois arquivos porém não devem ser tratados com outros nomes. Não que não possa,
apenas não é indicado. Estes são, o named.ca que é o arquivo que colocará o seu servidor
de nomes em contato com os outros servidores principais ao redor do mundo, e o
named.local, contendo informações sobre a máquina servidora de nomes. No caso a sua
máquina.

Para organizar a minha vida, eu costumo tratar todos os arquivos de Data Base (dase
de dados) da seguinte forma: db.identificação. Ou seja, de acordo com o que eu vou usar,
eu mudo a identificação, dessa forma, os meus arquivos de DNS ficam, por exemplo,
db.dominio, db.XXX.XXX.XXX, db.dominio-virtual, db.outracoisqualquer, e apenas o
named.ca e named.local ficam intactos. Essa na minha opinião é a melhor forma de
identificar meus dados.

Por padrão, a maioria dos administradores costumam usar dominio.zone para as

zonas relacionadas, dominio.rev para os dados sobre dominios reversos, e o que bem
entenderem para outras informações....

Addenda: Para modificar os padrões de localização de diretórios do BIND, você deve

usar a opção ./configure --help, se você for compilar um novo BIND a partir do código fonte.
Opção mais usual é: ./configure --sysconfdir=/etc/namedb e depois make e make install
para finalizar a compilação. Os programas compilados estarão disponível acima do diretório
bin/ dentro do local de compilação.

Ao decorrer dessa documentação, vamos assumir estar configurando um servidor de nomes

para o domínio eeviac.com.br, com as seguintes informações:

Domínio: eeviac.com.br
Servidor Primário: eeviacbsd.eeviac.com.br
Servidor Secundário: xffa.eeviac.com.br
Segundo Secundário: corduroy.eeviac.com.br
Faixa de IPs da Rede: 200.230.200.0 até 200.230.200.63
Portanto Máscara: 255.255.255.192

Considerações adotadas, vamos ver tudo isso na prática.

5.5.1 /etc/namedb/named.conf

O arquivo a partir do qual o named carrega todas as informações de configuração, por

default, é o arquivo /etc/namedb/named.conf A localização deste arquivo, no diretório
/etc/namedb/, pode ser mudada por meio da diretiva -c. Por exemplo o comando:

# named
Fará com que o BIND seja inicializado utilizando a informação contida no arquivo
/etc/namedb/named.conf

Já o comando:

# named -c /usr/local/algum_diretorio/named/named.conf
Fará com que o BIND seja inicializado com a informação contida no arquivo
/usr/local/algum_diretorio/named/named.conf

Mas a maioria dos sistemas Unix utiliza esta convenção, de sempre manter o arquivo
de inicialização do named onde ele procura por default, evitando usar a opção -c ou
apenas fazendo uso dela pra ter certeza de estar iniciando o named da forma correta. O
arquivo named.conf abaixo exemplifica a configuração de nosso servidor, como se fosse
um site pequeno, com apenas um domínio e apenas uma classe C:

options {
directory "/usr/named/";
query-source address * port 53;
};

zone "." {
type hint;
file "named.ca";
};

zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};
zone "eeviac.com.br"{
type master;
file "db.eeviac";
};

zone "0-63.200.230.200.in-addr.arpa"{
type master;
file "db.200.230.200";
};

O quadro abaixo explica resumidamente o significado de algumas das diretivas que

podem ser utilizadas no arquivo /etc/namedb/named.conf

DIRECTORY - Informa ao named o diretório onde se encontram todos os arquivos

referenciados. Por exemplo, o arquivo named.ca, se encontra na realidade em
/usr/namedb/named.ca

HINT - Informa ao named onde se encontra a lista dos root nameservers utilizada para
fazer a inicialização de seu cache.

MASTER - Pode ser utilizada diversas vezes, e sinaliza ao named quais são os domínios
para os quais possui informações oficiais (authoritative).

SECONDARY - Declara este servidor como secundário da zona especificada.

FORWARDERS - Lista servidores para os quais queries são enviados

SLAVE - Obriga o servidor a usar apenas forwarders

Esse foi um pequeno exemplo, a partir de agora comentaremos nossas configurações e

explicaremos o porque de cada directiva estar sendo usada. Não vamos usar comentário
como se fosse o arquivo comendado, com o # ou ;. Simplesmente considere que tudo que
estiver escrito de agora em diante na cor amarelo escura, é comentário e deve ser
completamente desconsiderado quando você for implementar seu próprio servidor de
nomes.

Dessa forma, vamos analisar agora, como trabalharia o nosso arquivo named.conf, se
utilizassemos esse pequeno exemplo apenas para o nosso domínio:

options {
/* declara que estamos iniciando uma opção que deve
* ser interpretada pelo nosso servidor de nomes
*/
directory "/usr/named/";
/* indica que a opção aberta na linha
anterior vai apontar
* pro nosso servidor de nomes o diretório
padrão, onde ele
* vai encontrar todos os arquivos que serão
referenciados
* a partir de agora, nesse mesmo arquivo
*/
query-source address * port 53;
/* é uma Segunda opção, repare que a TAG options{}; ainda
* não foi terminada, ok? Bom, essa opção indica ao NAMED que ele
* responderá ao BIND, quando esse fizer
perguntas na porta 53
* o porque disso? No FreeBSD agora
pode-se definir outras
* portas para trabalhar de maneira mais eficiente com firewalls.
*/

};
/* agora sim, a tag options {}; está terminada. */

zone "." {
/* Lembre-se: a intenção é você aprender, ao invés de simplesmante copiar
* então atenção a essa diferença, agora a tag não foi iniciada com a
* mesma sintaxe que anteriormente. A directiva ZONE trata da Zona
* referenciada, portanto, antes se indica de que zona você está falando
* aí sim abre a tag {}; para inserir as opções. Nessa linha estaremos
* trabalhando com os domínios absolutos, a raiz de todos os servidores
* de nomes. Ou seja, os Root NameServers, como já vimos antes.
* Então, para indicarmos que é a zona mais alta possível, usamos a
* directiva "."
*/

type hint;

/*
agora estamos indicando que essa zona é do tipo hint, lembra-se da
* tabela que vimos acima? Nosso servidor entrará em contato com os Root
* NameServers para prepar o nosso cache de resolução de nomes.
*/

file "named.ca";

/* agora estamos indicando qual arquivo tem os endereços dos Root

* Nameservers para nos conectarmos.

*/

};

/* Mais uma vez, fechando os informações da opção zone "." {}; */

zone "0.0.127.in-addr.arpa" {

/* lembra-se que a directiva ZONE trabalha indicando antes de que zona

* se trata, para somente depois iniciar as opções certo? Agora estamos

* tratando da Zona Local Reversa, ou seja, do forma reversa com a qual
* nossa maquina será tratada pela interface de Loopback ("lo").
* Essa é a sintaxe, que quer dizer que estamos tratando do reverso
* da rede na entrada do endereçamento dos socks arpa no kernel.

* Parece confuso, e é mesmo, mas lembre-se da sintaxe, reverso da rede

* ponto (.) entrada (in) do endereço (addr) arpa.

*/

type master;
/* tipo de entrada ‘master’ na tabela acima. Master, lembrando

* são os tipos de Zonas pelas quais nós temos autoridade na

* na Internet... pode ser usado inúmeras vezes, sempre

* que for preciso indicar uma zona pela qual nós respondemos
*/

file "named.local";
/* Bom, aqui estamos indicando que as informações sobre essa

* Zona que nós dizemos Ter autoridade está no arquivo

* named.local Como você já deve ter notado, pela directiva da

* zona, nós estamos falando da zona local, de loopback, então

* esse arquivo conterá apenas informações sobre a rede 127.0.0.0

* ou seja, como somos a única máquina da interface de loopback,

* esse arquivo vai conter informações sobre a máquina 127.0.0.1,

* ou seja, apenas informações sobre a maquina local (localhost).

*/

};
/* Mais uma vez, terminando a directiva. */

zone "eeviac.com.br"{
/* Como já entendemos a sintaxe da directiva zone ""{}; então já

* podemos visualizar que agora sim estamos tratando de uma

* zona da Internet, que certamente será alcançada por outras zonas

* outras máquinas e outras redes. Então agora estaremos tratando

* da vida de um domínio pro resto do mundo. Nesse caso, esse domínio

* é o nosso próprio domínio, eeviac.com.br. Atenção a partir de agora.

*/
type master;

/* Como nós respondemos com toda autoridade do mundo para

* o domínio eeviac.com.br e somos os responsáveis pelo mesmo,

* então é claro que é um domínio do tipo master.

*/
file "db.eeviac";

/* Estamos indicando que todas as informações sobre o Domínio

* eeviac.com.br estão guardadas no DataBase ‘db.eeviac’ do diretório

* referenciado no início do named.conf

*/
};

/* fim dos parâmetros da zona eeviac.com.br */

zone "0-63.200.230.200.in-addr.arpa"{

/* Agora muita atenção! Lembra-se da rede reversa de loopback? Pois bem

* agora não estamos mais tratando de uma rede privada, estamos

* tratando das informações reversas da rede toda! Vamos entender a

* a sintaxe: zona do tipo reversa, dos clientes 0-63 (Zero até 63) da rede

* 200.230.200.0 de máscara 192, ou seja, todos os clientes dentro da nossa rede.

* Como nós somos os responsáveis por esses hosts devemos prover também

* a tradução reversa de nomes, informando o nome da máquina quando

* o query quiser informações de nome sobre um endereço IP.

* Ou seja, a próxima base de dados

* terá que conter informações reversas (se você leu com atenção as
* tabelas anteriores, já pode imaginar que elas serão referenciadas usando

* a directiva PTR certo? Nerdão!) de todos os IPs da nossa rede.

*/

type master;
/* É claro que nós respondemos com autoridade pelo reverso da nossa rede

* então essa zona é mesmo do tipo master, nós somos os donos!

*/

file "db.200.230.200";
/* e esse é o arquivo que contém a Base de Dados reversa da

* nossa rede/domínio. Certamente você entendeu agoura porque eu

* eu nomeio como db.200.230.200, certo?!

*/
};

ATENÇÃO: No BIND 9 a informação sobre a zona reveresa não deve ser apresentada na
forma

xxx-xxx.xxx.xxx.xxx.in-addr.arpa (como 0-63.200.230.200.in-addr.arpa nesse exemplo)

pois serão interpretadas como uma zona reversa de endereços IP de Próxima Geração
(IPv6). Nesse caso apresente a informação omitindo a zona de abrangência, deixe que
apenas o arquivo reverso faça isso. Use apenas a rede, sem os hosts. Portando no nosso
exemplo, para uma zona reversa IPv4 utilize 200.230.200.in-addr.arpa (xxx.xxx.xxx.in-
addr.arpa onde xxx.xxx.xxx é a rede reversa); Para zona reversa IPv6 utilize
xxx.xxx.xxx.xxx.xxx.in-addr.arpa (onde xxx.xxx.xxx.xxx.xxx é a rede reversa IPv6).

Essa sintaxe também pode ser adotada no BIND 8.2.4 e superiores, não comprometendo a
eficiência das informações.

5.5.2 /usr/named/named.ca

Bom, você certamente se lembra da primeira zona do nosso arquivo de configuração, a

zona "." Do tipo hint ou seja, onde nós nos conectaríamos com os Root Nameservers para
prepararmos nosso cache de nomes... Pois bem, claro que você pode visualizar que essa
nossa entrada faz referência ao arquivo (file) named.ca; Então vamos analisar esse
arquivo estático.

Este arquivo contém a informação necessária para se inicializar o cache com os dados
relativos aos Root Nameservers.

As informações deste arquivo são praticamente estáticas, porque fazem referências a

servidores que quase nunca mudam de endereço. Algumas alterações raramente são
feitas, mas quando feitas, são para atualizar algum endereço ou outro, ou são para
adicionar novos servidores. A InterNIC disponibiliza este arquivo via ftp anônimo, e os
endereços para a atualizalicação dele são encontrados em:
ftp.rs.internic.net:/domain/named.root para FTP anônimo, ou para acesso via Gopher,
no endereço: RS.INTERNIC.NET, sob o menu InterNIC Registration Services (NSI),
submenú InterNIC Registration Archives e arquivo named.root.

Recomenda-se a verificação deste arquivo periodicamente a cada 3 meses, e

recomenda-se que o seu named.ca seja sempre criado a partir da versão mais recente. A
tarefa de pegar esse arquivo é muito fácil e pode ser facilmente automatizada, com algum
script simples no cron.

Para pegar o arquivo, no FreeBSD use o comando:

# ncftp ftp.rs.internic.net:/domain/named.root

Dessa forma você pode visualizar a facilidade em criar um script que atualize sozinho,
junto ao cron, as informações sobre os Root Nameservers! Bom, agora vamos dar uma
olhada no arquivo. Essa é a descrição do arquivo named.ca atualizado via FTP, na data
de 22 de Agosto de 1997. Um tanto velhinho, mas não mudou nada. Até a data atual
(Maio de 2001) você pode usar esse arquivo com tranquilidade.

; This file holds the information on root name servers needed to

; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . "
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC registration services
; under anonymous FTP as
; file /domain/named.root
; on server FTP.RS.INTERNIC.NET
; -OR- under Gopher at RS.INTERNIC.NET
; under menu InterNIC Registration Services (NSI)
; submenu InterNIC Registration Archives
; file named.root
;
; last update: Aug 22, 1997
; related version of root zone: 1997082200
;
;
; formerly NS.INTERNIC.NET
;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
;
; formerly C.PSI.NET
;
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;
; formerly TERP.UMD.EDU
;
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
;
; formerly NS.NASA.GOV
;
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;
; formerly NS.ISC.ORG
;
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
;
; formerly NIC.NORDU.NET
;
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
;
; temporarily housed at NSI (InterNIC)
;
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10
;
; housed in LINX, operated by RIPE NCC
;
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
;
; temporarily housed at ISI (IANA)
;
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
;
; housed in Japan, operated by WIDE
;
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
; End of File

5.5.3 /usr/named/named.local
 Seguindo a ordem de inicialização do nosso servidor de nomes, agora o named.conf
chama a interface reversa de Loopback, e aponta para o arquivo named.local para obter
os dados. Então vamos entender agora a função do arquivo named.local

Segue a descrição do arquivo named.local encontrado na nossa configuração em

/usr/named/

O FreeBSD tem um script em PERL dentro do diretório /etc/namedb que cria esse
arquivo automaticamente para a sua máquina. Facilitando assim o seu trabalho e não
necessitando que se faça um arquivo na mão. Esse script em PERL vem sem permissões
de execussão por default, portanto de essa permissão (chmod +x) e execute o script.

;
; BIND data file for local loopback interface.
;
@ IN SOA localhost. root.localhost. (
98101401 ; serial
28800 ; refresh
14400 ; retry
3600000 ; expire
86400 ; default_ttl
)
@ IN NS localhost.
1 IN PTR localhost.
;
;

Acompanhe agora com a tabela dos Resource Records (RRs - Capítulo 5.4.3), e vamos
entender então quais os dados e como estão sendo passados para o nosso servidor de
nomes. Lembrando que nós estamos tratando de uma zona do tipo master, ou seja, onde
nós temos autoridade e responsabilidade total sobre os dados que estamos tratando.
Felizmente essa é a interface de Loopback, mas o rigor das informações é o mesmo para
outras zonas da Internet as quais nós tenhamos autoridade. Vamos então acompanhar o
arquivo, seguindo o mesmo esquema do named.conf onde as observações estarão na cor
amarelo escuro.

;
; BIND data file for local loopback interface.
;

; É a descrição do arquivo, os dados referentes à interface de

; loopback local para o BIND. Os ponto e vírgula ‘;’

; são observações (comentários) nesse arquivo.

$TTL 14400
@ IN SOA localhost. root.localhost. (

; A forma como iniciamos um arquivo de Zona é dizendo sobre qual zona

; estamos trabalhando, sempre uma zona que tenhamos autoridade total.

; E já vimos na tabela dos RRs que a entrada para apontar autoridade

; sobre uma zona é a entrada SOA. Tínhamos também a descrição da sintaxe

; da entrada SOA, que era o Domínio da Zona em questão, o edereço de domínio do admin

; um número serial, e os parâmentros Refresh, Retry, Expire e TTL Mínimo,

; em segundos, certo? Como você pode ver, a sintaxe toda está referida aqui.

; O arquivo inicia com uma @, @ em inglês se pronuncia como a conjunção "at" que

; que é como se fosse, traduzindo livremente, como a conjunção "em" na nossa língua

; ou seja, referenciamento de lugar, local. Foje ao assunto desse capítulo, mas vamos

; a uma breve adenda: É por isso que os endereços de e-mail tem o formato

; alguem@algum-dominio, ou seja, o endereços se refere a alguem em algum lugar, onde

; nesse caso o lugar é a zona (domínio) da internet onde ele se encontra.

; Bom, voltando. Inicialmente, com o BIND antigo, era preciso usar uma arroba (@) antes

; de anunciarmos a entrada (IN) da zona que estamos tratando. Hoje em dia a arroba (@)

; não é mais necessária, mas ainda pode ser usada.

; Então agora já sabemos que na linha cima estamos apontando uma entrada (IN) ao
nosso

; servidor de nomes, e depois percebemos que essa entrada é do tipo Autoritativa, ou seja,

; nós temos total controle sobre ela. A seguir então segue-se a ordem da sintaxe dessa

; entrada SOA, primeiro o domínio da Zona em questão, que nesse caso é a zona

; de Loopback, ou seja, o localhost, que é seguido do domínio (zona) do administrador.

; A Sintaxe da zona do administrador é "usuário.zona", as mensagens de erro ou mal

; funcionamento do nosso servidor de nomes será enviada a ele. No nosso caso, ele é

; root.localhost por estarmos tratando do superusuário, no nosso host (máquina).

; Abre-se parênteses para os próximos dados.

98101401 ; serial

; A primeira entrada é o número serial que identifica o nosso servidor de nomes.

; É um número que segue o formato acima, e tem uma função importante,

; da mesma forma que nos conectamos aos Root Nameservers para fazermos

; uma verificação e criar o nosso cache com dados sobre nomes, claro que

; os dados do nosso servidor de nome também são referenciados, porque nós

; temos autoridade sobre um (ou vários) domínios importantes, então tudo que

; o nosso servidor de nomes diz, é importante pra Internet como um todo.

; Sempre que esse número serial é alterado, os Root Nameservers atualizam

; suas informações em relação ao nosso servidor de nomes. Alterar incrementando

; o nosso serial força os outros servidores de nomes a atualizarem suas informações

; sobre nós.

28800 ; refresh

; Bom caso não alteremos o serial do nosso servidor de nomes, existe um tempo, em
segundos

; que nós forçamos a sincronia dos nossos dados com os outros servidores de nomes do
mundo.

14400 ; retry

; Caso não consigamos exportar ou importar novos dados, existe um tempo, também em
segundos

; para uma nova tentativa. É o retry.

3600000 ; expire

; Esse é o limite para os dados no servidor de nomes e pra sincronia entre nós e o

; resto do mundo expirar, caso não haja atualizações.

86400 ; default_ttl
; Default TTL (Time To Live) é o tempo de vida padrão para uma requisição de nome ser
resolvida

; Depois desse tempo a requisição morre... essa entrada para default_ttl é usada se o noss
arquivo

; não tiver uma entrada $TTL no inicio.

; fecha o parênteses, porque acabou os dados requeridos para a entrada (IN) autoritativa
(SOA)

@ IN NS localhost.

; Nessa linha, estamos indicando uma entrada (IN) de um servidor de nomes (NS) com
autoridade

; sobre o o Domínio (zona) em questão. O Servidor de nomes (NS) com autoridade sobre a

; zona de loopback (localhost) é a mesma máquina local, portanto, localhost. Em síntese,

esse

; linha esta indicando que ela será servidora de nomes para a zona dela mesma.

1 IN PTR localhost.

; Como essa entrada de zona é do tipo reversa (0.0.127), na entrada de endereçamento

arpa

; (.in-addr.arpa) então devemos apontar para os endereços reversos da zona. Como já

; temos em mente que a zona que estamos trabalhando é a de loopback, então só existe a

; nossa própria máquina nessa zona, portanto o cliente (host) número 1 somos nós. De
uma

; olhada na tabela de RRs para ver como declaramos endereçamento reverso dos hosts de
uma

; zona e você vai lembrar que pra isso usamos os Ponteiros (PTR) apontando o host ao
nome.

; Portanto a primeira máquina de noss zona (1) é uma entrada (IN) do tipo reversa, que
aponta

; (ponteiro - PTR) para a máquina local (localhost).

E eis o final do nosso arquivo named.local, que indica a nossa zona e reverso da
interface de Loopback. A importância dessa identificação é a segurança que a
identificação de uma zona inteira a um único host pode oferecer, sendo esse único host o
próprio servidor de nomes.

Dessa forma, antes de sermos apenas mais um host de uma zona que temos
autoridade (o que você verá a seguir) somos o único host de uma zona própria também.
Ou seja antes de sermos o nosso endereço IP real para o resto do mundo, nós somos o
127.0.0.1, e isso traz segurança à varios tipos de configuração.

5.5.4 /usr/named/db.eeviac

A próxima entrada no arquivo de configuração do nosso servidor de nomes aponta

também para uma zona. Agora sim a situação é a mais importante. A zona a qual
estamos tratando é a zona que nós pegamos para nosso exemplo, a zona eeviac.com.br
ou seja, a partir de agora, toda informação sobre serviço de nomes e de hosts dentro
dessa zona, somos nós quem somos responsáveis e temos total autoridade. Autoridade é
sinônimo direto de responsabilidade, pois toda informação referente a essa zona na
Internet estará por nossa conta. Dessa forma temos que Ter o nosso servidor de nomes
funcionando com perfeição e com configurações claras, para que o resto do mundo
entenda toda informação que estamos passando em relação à eeviac.com.br (nosso
exemplo).

Como nós temos informações oficiais sobre a zona ‘eeviac.com.br’ então ela é do tipo
master, que é a forma como é apontada no named.conf, e toda informação sobre essa
zona do tipo master está contida na base de dados que é chamada pelo mesmo arquivo de
db.eeviac. Poderia ser eeviac.zona ou zone.eeviac de acordo com a forma que cada
administrador implementa.

É esse db.eeviac que nós vamos analisar agoura. Segue um exemplo de como deve ser
o arquivo:

$TTL 14400
@ IN SOA eeviac.com.br. root.eeviac.com.br. (
2000041003 ; serial
28800 ; refresh
14400 ; retry
3600000 ; expire
86400 ; default_ttl
)
@ IN NS eeviacbsd.eeviac.com.br.
@ IN NS ns.embratel.net.br.
@ IN NS xffa.eeviac.com.br.
@ IN MX 10 smtp.eeviac.com.br.
@ IN MX 20 xffa.eeviac.com.br.
@ IN A 200.230.200.10
rt IN A 200.230.200.1
ras IN A 200.230.200.2
eeviacbsd IN A 200.230.200.10
smtp IN A 200.230.200.10
; smtp IN CNAME mail.eeviac.com.br
pop3 IN A 200.230.200.10
; pop3 IN CNAME mail
ftp IN A 200.230.200.10
; ftp IN CNAME wwwfserv.eeviac.com.br
www IN A 200.230.200.10
; www IN CNAME wwwfserv
host3 IN A 200.230.200.3
maq4 IN A 200.230.200.4
maq5 IN A 200.230.200.5
host6 IN A 200.230.200.6
ma7 IN A 200.230.200.7
eeviac8 IN A 200.230.200.8
xffa IN A 200.230.200.9
corduroy IN A 200.230.200.11
eev12 IN A 200.230.200.12

Como você pode ver, esse arquivo agoura é bem completo, e contém vasta informação.
Na verdade, esse arquivo não contém apenas as informações de nomes da sua zona
(domínio) mas também toda informacão de nomes dos clientes (hosts) da sua rede ou
zona. Essa informação é o relacionamento de um nome, dentro da sua zona, ou um
apelido (ALIAS) de um nome dado para outro host, o que é chamado de Nome Canônico
(CNAME). Vamos então acompanhar e entender cada linha do arquivo de base de dados
que representa toda informação para zona eeviac.com.br:

$TTL 14400

; Tile To Live à ser usado. Não é obrigatório, se essa opção não existir o

; default_ttl será utilizado.

@ IN SOA eeviac.com.br. root.eeviac.com.br. (

; como vimos na entrada do named.local, essa é a indicação de uma entrada (IN)

; no nosso servidor de nomes, e a entrada é do tipo que nós temos total autoridade,

; ou seja, é do tipo Autoritativa (SOA) e a zona faz referência à um domínio, ou o nome

; da zona, que no exemplo anterior era a zona localhost, e agora a zona é a zona da

; internet ‘eeviac.com.br’. A seguir o endereçamento do mantenedor desse domínio, no

caso

; o root do domínio ‘eeviac.com.br’. No geral: estamos dizendo que a partir de agora, a

zona

; na internet representada por eeviac.com.br será respondida por nós. Nós temos
autoridade

; e responsabilidade sobre a informação referida a essa zona, em relação ao resto do

mundo.

; No entando, vamos fazer uma pausa para um detalhe que eu propositalmente deixei de
; comentar quando comentamos o arquivo named.local; Se você reparar, o domínio da
zona é

; terminado por um ponto final, sempre que esse é referenciado. Veja o trecho:

; @ IN SOA eeviac.com.br. root.eeviac.com.br. (

; podemos observar um ponto ao final do domínio eeviac.com.br, ficando eeviac.com.br. e

; a mesma cousa no endereço do mantenedor root.eeviac.com.br. A explicação para isso, é

; que ao colocarmos um ponto final, ao final do domínio da nossa zona, estamos

indicando

; que é um domínio absoluto, ou seja, depois do ponto nunca vai existir mais nada. Na

; prática, nunca vai existir um host depois da zona referida, assim, nunca existirá uma

; máquina com nome eeviac.com.br.host1 por exemplo. Poderá, e existirá sempre um host

; antes, mas nunca depois, sendo, um host, um nome canonico com o nome de www

; por exemplo, ou seja, www.eeviac.com.br, mas nunca eeviac.com.br.www.

; Parece bobo eu explicar isso, ou mesmo fazermos questão de indicar um domínio

absoluto

; ao nosso domínio, mas não é tanto. Vou fazer mais uma adenda, mesmo sabendo que
vou

; me extender sem necessidade, mas por curiosidade, vou comentar... Até o final do
primeiro

; semestre de 1999, alguns dos Root Nameservers, ou os da Internic ou algum servidor da

; Fundação Amparo (FAPESP), que é o orgão responsável pelos nomes no Brasil, não
entendia

; ou reconhecia o final do Domínio Absoluto. E como os domínios no Brasil são de níveis

; superiores aos da Internic, (.br), os Root Nameservers da Internic, ou os da FAPESP não

; referenciavam isso, achando que os domínios absolutos diretos (.com, .net, .org, .gov,
etc)

; poderiam aparecer níveis acima do .br Brasileiro. Sendo assim, os

domínios .com.br, .net.br,
; .gov.br e outros, não eram respeitados pelos Name Servers do mundo inteiro, inclusive
os

; Brasileiros, mesmo que contivessem um ponto final no fim da zona. Bom, onde eu quero

; chegar com isso? Por causa desse probleminha que quase passou em branco por mais
tempo

; Existe uma ceita Americana de Sado Masoquismo e Cultura Negra (satanismo) que se
chama

; Black Rose, ou Rosa Negra. E o domínio dessa ceita na Internet é br.org . Até então tudo
bem

; mas pelo fato dos Root Namerservers acharem que acima do nível .br ainda poderia
existir

; outro dos absolutos, então toda vez que um domínio .br era sucedido de um .org (por
exemplo

; o mega portal brasileiro http://www.uol.com.br.org) então entrava nos servidores da

Black

; Rose .Org e dizia que o endereço correspondente não pode ser encontrado nos servidores
deles.

; Ou seja, sempre que fizessemos isso com algum domínio, então caíamos nas páginas de
BDSM

; Sado Masoquista e Satânicas da Black Rose. Não sei até que ponto isso era
desconhecido, mas

; quem falou disso comigo foi um grande amigo, o Ric Milk (ASBYTE). Quando
descobrimos isso,

; nós saímos correndo tentando registrar br.net, br.com, jp.net. jp.org, fi.net

; e outras... Mas não deu certo... e o Leite mandou uma série de e-mail pra Fapesp e

; Internic dizendo que isso estava acontecendo... Quem sabe não arrumaram isso por

; conta dos mails do Milk...

2000041003 ; serial

; Esse é o serial da nossa zona eeviac.com.br, você se lembra da descrição dele no arquivo

; named.local certo? O Número serial costuma ser formado da data e da ação, assim, esse
; número serial estaria representando o serial da terceira alteração feita em 10 do mês

; 04 do ano 2000. Mas na verdade isso é uma adoção apenas, e não tem que ser levada

; ao pé da letra. As Man Pages (páginas de manuais) do named dizem que o serial

; pode ser até pontuado, mas que é algo desnecessário devido ao fato da tradução

; dos Inteiros reais serem via concatenação, e não via multiplicação ou adição. Diz ainda
que você

; pode escrever o mês, o ano e o dia do mês, que ainda assim esses serão dados dentro do

; padrão que o BIND entende, que é de 32 bits, se bem que isso terá que ser repensado

; no ano 4294, mas ninguém se importa com isso por enquanto...

28800 ; refresh

; lembra-se da descrição do refresh no arquivo named.local certo? Pois bem então

; vamos obter mais informações... o tempo do refresh, em segundos é também

; o tempo que os servidores secundários da sua zona/rede irão perguntar ao servidor

; primário se houve alguma mudança na Zona. Se a mudança acontece, então uma

; área de transferência de dados é aberta para a atualização do servidor de nomes.

14400 ; retry

; é o tempo em segundos para iniciar uma nova tentativa de atualização ou sincronia

; de dados no servidor de nomes.

3600000 ; expire

; O tempo no expire, além da função descrita ateriormente é também o período máximo

; que o servidor secundário vai insistir em atualizar seus dados...

86400 ; default_ttl

; E esse é o valor mínimo para o TTL (Time to Live) que o servidor permanecerá insistindo

; com uma requisição com resposta negativa, caso outro valor não tenha sido previamente

; anunciado com um $TTL inicial

)
; Fecha o parênteses porque é o fim da configuração obrigatória de todos os parâmetros

; da entrada SOA (autoritativa).

@ IN NS eeviacbsd.eeviac.com.br.

; Lembra-se que, de acordo com a tabela dos Resource Records (RRs) a entrada para se

; referenciar um servidor de nomes é NS (de Name Server), então nessa linha estamos

; dizendo que a entrada (IN) do nosso servidor de nomes (NS) é eeviacbsd.eeviac.com.br

; portanto essa é a máquina que estará nos servindo, ou seja, eeviacbsd é essa mesma

; estação (host) que nós estamos configurando, portanto a primeira entrada dos servidores

; de nomes padrão no nosso DNS é nós mesmos. Detalhe no ponto final ao final do
domínio.

@ IN NS ns.embratel.net.br.

; Podemos Ter mais que um servidor de nomes configurado em nosso DNS, e esse
segundo

; é o Servidor de nomes da embratel, um dos principais pontos de referência de serviços

; de nomes no Brasil, ou seja, esse servidor de nomes será consultado sempre que não

; pudermos responder pela requisição de nossos clientes. No caso de não sermos

autoridades

; sobre o o domínio que esta sendo consultado, então perguntaremos ao NS da embratel,

se

; o nosso próprio não puder responder.

@ IN NS xffa.eeviac.com.br.

; E configuramos ainda um terceiro servidor, mais por finalidade demonstrativa. Não é

necessário

; Ter mais que um servidor de nomes e um secundário, ou seja, você deve sempre
configurar o

; seu próprio NS e o de um backbone (espinha dorsal da rede), nesse caso o NS da

embratel.

; Veja que as entradas são sempre iguais, e apontam a entrada (IN) de um

; servidor de nomes (NS) e em seguida o nome+domínio da máquina. Lembramos que a

arroba
; (@) não é mais obrigatória nos BIND/NAMED atuais.

@ IN MX 10 smtp.eeviac.com.br.

; Bom, o serviço de e-mail é um dos principais e mais básicos quando se trata

; de um domínio (zona) da Internet. Imagina-se que por todos os domínios que nós

; tenhamos autoridade queira-se poder configurar e-mails para essas zonas. Dessa forma

; devemos indicar o(s) servidor(es) de e-mail que responde(m) por nossa(s) zona(s).

; Podemos indicar quantos servidores de e-mails sejam necessários, ou estejam

; configurados, podendo ser inclusive máquinas de fora da nossa rede (zona).

; O mínimo que se deve ter indicado é a entrade (IN) de um servidor de e-mail

; ou Mail eXchanger (MX) com preferir, para que possa receber as mensagens

; de e-mail enviadas à usuários em nossa zona (rede/domínio). A Sintaxe dessa

; entrada deve ser: IN (entrada) MX (servidor de email, Mail eXchanger) seguidos

; de um número X e depois o nome+Domínio da máquina indicada. Bom, esse

; número indica a preferência (0..99) que o servidor tem, em caso de existir mais

; de um servidor que responde pelas zonas que temos autoridade. Esse valor é

; reverso, ou seja, quanto menor o valor do número, maior preferência sobre os

; outros servidores de e-mail (MX) ele tem. Dessa forma, se tivermos 2 ou 3 servidores

; distindos, então seus valores poderão ser 0, 5, 10... ou 0, 1, 2 ou 1, 2, 4 enfim, a

; forma como você vai administrar é o que difere a situação numérica.

@ IN MX 20 xffa.eeviac.com.br.

; Agora você está vendo isso na prática, um segundo servidor de e-mail

; referenciado, mas com uma prioridade mais alta que o primeiro, como

; a prioridade é reversa, então esse servidor só será usado se o

; primeiro negar o destinatário, ou estiver fora do ar. Vamos entender... é enviado um e-

mail

; para um determinado usuário, de uma determinada zona, então seu

; servidor que tem autoridade sobre essas zonas, deve identificar qual

; servidor vai receber os e-mails daquela zona ou usuário. Assim, se um

; e-mail é enviado para pixies@velouria.com.br, e se você tem autoridade

; (SOA) sobre o domínio velouria.com.br, então o seu servidor DNS deverá

; se responsabilizar por entregar esse e-mail. Ele pergunta ao seu servidor com

; menor entrada (no nosso caso smtp.eeviac.com.br, com entrada 10) e esse

; servidor diz que não reconhece esse usuário desse domínio. Então seu servidor

; passa a requisição para o próximo servidor que ele conhece, com a próxima entrada

; mais baixa, no caso a entrada 20, que aponta o servidor xffa.eeviac.com.br; Se esse

; servidor aceita e-mails para esse domínio (zona - velouria.com.br) e reconhece o

usuário

; (pixies) então o e-mail esta entregue. Mas se esse servidor de e-mail também não

; responde por esse usuário e/ou zona (velouria.com.br) e não existe outro servidor de

; e-mail cadastrado no seu servidor DNS (uma terceira entrada -IN- de servidor de mail

; -MX- com um valor maior que o último consultado), então uma mensagem de erro

; é enviada ao remetende do e-mail, dizendo que não pode entregar o e-mail, ou seja,

; a mensagem que o e-mail voltou...

@ IN A 200.230.200.10

; Agora vamos começar a adicionar os mapeamentos quartenários (A)

; dos endereços IPs correspondentes a cada máquina (host). Lembrando

; que, o endereço IP de um host é composto pelo endereço da rede seguido

; do endereço referente à aquela máquina na rede. Dessa forma, a máquina

; com IP 200.230.200.53 é o host (cliente/máquina) de número IP 53, na nossa rede

; que é a 200.230.200.0, certo? Bom, essa primeira entrada é obrigatória

; para resolver o domínio sem um host

; ou seja resolver eeviac.com.br pro endereço IP em questão. Essa entrada diz que
; as configurações acima criadas são referentes à aquela náquina, e demonstra o

; endereço Quartenário dela. Isso evita que o DNS precise ser consultado para

; perguntar que é aquela máquina de nome eeviacbsd, no domínio eeviac.com.br.

; Agora sim começa um dos serviços mais importantes de nosso servidor de nomes,

; você se lembra da introdução desse capítulo que diz que as máquinas conversam entre

; si usando os endereços IPs a nível de software e hardware, mas que isso é transparente

; para o usuário leigo, certo? E você viu que, até agora muitas vezes nós fizemos

; referências a nomes inteiros de identificação, certo? Como a entrada MX que indica

; smtp.eeviac.com.br e a Segunda entrada MX que aponta para xffa.eeviac.com.br, e

; o principal, o nosso servidor eeviacbsd.eeviac.com.br. Esse ao menos é apontado no

; primeiro referenciamento do nosso DNS, e diz que a máquina é a 200.230.200.10, mas

; e o resto? É agora que vamos tratar dos nomes dos clientes... ( os hosts ).

rt IN A 200.230.200.1

; A sintaxe para as entradas quartenárias de referenciamento de IPs (com exclusão da

; primeira entrada que não precisa ter o nome da máquina (host) e hoje em dia nem a

; arroba é mais obrigatória, e que nós já vimos pra que serve essa entrada) é:

; O nome da máquina sob a zona primária, referenciando uma entrada (IN) do tipo

; endereço Quartenário IP (A) e apontando esse endereço quartenário. Vale lembrar que

; o "nome da máquina sob a zona primária", e é quartenário enquanto estiver

configurando

; um servidor de nomes com endereço IPv4. Isso quer dizer que o nome completo do
endereço

; daquele host derá o nome dele + a zona autoritativa sobre a qual ele pertence.

; No nosso exemplo, como a nossa zona SOA é a eeviac.com.br, então o endereço

completo

; vai ser o nome do host mais essa zona. Nessa entrada acima, estamos então dizendo que

; o nome "rt" é uma entrada (IN) pro endereço IP quartenário (A) referente a 200.230.200.1
ras IN A 200.230.200.2

; Essa próxima entrada quer dizer... a mesma coisa, mas faz referência de nome de outra

; máquina a outra entrada quartenária. No Caso, essa entrada diz que o nome "ras" é

; correspondente à entrada (IN) de IP Quartenário (A) referente a 200.230.200.2

; Uma dica, para melhor performance da sua rede em relação ao servidor de nomes (DNS)
é

; sempre usar os hosts mais baixos da sua rede para serem as máquinas com maior
requisição

; ou seja, os servidores. E se houver alguma máquina que seja servidor, e o host (IP) dela
seja

; superior a o de um host menos importante, então indique ela antes nas suas entradas
DNS.

; Depois você indica os outros clientes (hosts) menos acessados.

eeviacbsd IN A 200.230.200.10

; Nesse caso escolhemos o primeiros host de nossa rede (200.230.200.1) para ser o nosso

; servidor de rotas, ou seja o nosso roteador, por isso o nome "rt" O Segundo IP/host é o

; nosso Autenticador Remoto (RAS) por isso o nome "ras" (IP 200.230.200.2). O RAS é o

; autenticador/atendedor das nossas conexões remotas, ou seja é o servidor responsável

; pelas conexões dial-up (PPP/SLIP), caso existam na nossa

; rede/domínio/zona, caso sejamos um

; provedor de acesso INTERNET. Essa terceira entrada, não é a do host 3, mas sim a do

; host 10 da nossa rede (200.230.200.10) e é referenciada agora, porque é o nosso

servidor

; principal, onde está rodando, entre outras coisas importantes, esse servidor de nomes
aqui.

; A entrada diz que o host com nome "eeviacbsd" é uma entrada (IN) para o endereço IP

; quartenário (A) referente à 200.230.200.10

smtp IN A 200.230.200.10
; Essa entrada diz que a máquina com nome de smtp (que foi referenciada lá em cima)

; é a entrada quartenário para o IP 200.230.200.10, e você vai perguntar, se pode

; existir duas referências de nomes distintos à mesma máquina... a resposta é que

; pode, mas não é o indicado, ou não é o ideal. Para esse tipo de ação, prover

; um apelido (alias) para uma máquina, existe a entrada de nomes canônicos, os

; Canonical Names, os chamados CNAMEs.

*smtp IN CNAME eeviacbsd.eeviac.com.br

; Agora estamos vendo o que seria a forma ideal de se prover aquela entrada acima.

; Por isso em cor vermelha, em Itálico e com asterisco (*) antes da entrada. Essa entrada

; não deveria existir no nosso arquivo, porque existe a de cima. Ela está aqui por motivos

; didáticos, portanto quando você for fazer o seu DNS, escolha por apenas uma forma de

; atribuir outro nome à mesma máquina. A Sintaxe dos nomes canônicos é, o nome
referente

; à entrada de nome canônico referente ao nome da máquina verdadeira, ou seja, de quem

; aquele nome será um apelido. Podemos apontar uma máquina fora de nossa rede,
podemos

; usar apenas o nome do host, ou também o nome do host + domínio ou zona.

pop3 IN A 200.230.200.10

*pop3 IN CNAME eeviacbsd

; Essas duas linhas acima fazem de novo as referências que eu acabei de comentar,
lembrando

; que o ideal é a Segunda entrada. Escolha uma delas e substitua pela outra, deixando
apenas uma

; no seu DNS, e detalhe na sintaxe, agora aponta apenas para o nome do host (eeviacbsd)
e não

; mas o host+dominio como antes. Ambos estão perfeitos.

ftp IN A 200.230.200.10

*ftp IN CNAME wwwfserv.eeviac.com.br

www IN A 200.230.200.10

*www IN CNAME wwwfserv

; Mais dois exemplos para garantir que você entendeu esse conceito de nomes

; distindos para a mesma máquina. Vamos supor que você tenha uma outra máquina,
que seja

; servidor de arquivos e de páginas html. Claro que você vai ter que indicar o nome dela
até

; o final dessa configuração, e o nome dela na nossa hipótese é wwwfserv, portanto,

estando

; sob sua autoridade (SOA) ela é a máquina wwwfserv.eeviac.com.br. Ela na verdade será
sempre

; envocada quando suas páginas Internet serão chamadas, ou quando alguém for se
conectar

; via FTP nela, então você cria os apelidos www e ftp para a sua wwwfserv, ou seja, agora
sempre

; que o endereço de nome www.eeviac.com.br ou ftp.eeviac.com.br for chamado, a

mesma

; máquina será invocada. Isso explica muito da Internet atual.

host3 IN A 200.230.200.3

; Bom, agora sim você continua dando seus nomes à suas máquinas. O Nome que você

; quiser, por isso os exemplos abaixo não seguem um padrão. Para demonstrar que pode
ser

; o nome que você bem entender. Claro que deve-se considerar uma opção de organização

; Se outros servidores existissem, como o nosso exemplo wwwfserv, o nome teria que ser

; configurado, claro...

maq4 IN A 200.230.200.4

; Agora em todas essas entradas estamos adminindo que seja de simples hosts da

; sua rede ou zona....

maq5 IN A 200.230.200.5

; Configure todos os nomes, até o final da sua rede.

host6 IN A 200.230.200.6

; Se por exemplo a máquina 6 fosse do presidente da sua empresa, ela poderia Ter

; o nome de presidente, para ser a máquina presidente.eeviac.com.br no seu DNS...

ma7 IN A 200.230.200.7

; Faça como quiser, da melhor forma para a organização e agilidade da sua empresa,
escola,

; provedor internet...

eeviac8 IN A 200.230.200.8

; Lembrando-se sempre da sintaxe: nome IN A ENDEREÇO

xffa IN A 200.230.200.9

; e que o nome será sempre sob a sua zona (SOA), ou seja, no próximo caso...

corduroy IN A 200.230.200.11

; ...o nome completo do host 11 é corduroy.eeviac.com.br lembra-se?

eev12 IN A 200.230.200.12

eevbr13 IN A 200.230.200.13

|| || || || || || ||

|| || || || || || ||

Agora o nosso servidor de nomes já está quase perfeito. Ele já pode responder com total
autoridade pelos nomes dos hosts da nossa zona (domínio/rede) e ao fazermos uma
consulta ao nosso servidor de nomes, ele pode identificar e servir informações que
permita qualquer outra máquina ou rede na internet identificar o endereço IP dos nomes
dos nossos hosts. Sendo assim, se alguém quiser saber qual o endereço IP por exemplo,
da máquina xffa.eeviac.com.br assim que o nosso servidor de nomes for interrogado,
então a resposta (200.230.200.9) será imediatamente exibida. Estamos quase prontos...

5.5.5 /usr/named/db.200.230.200

Agora vamos tratar da última entrada no nosso arquivo de configuração do servidor de

nomes, o named.conf. Na última entrada do named.conf ele faz referência a uma zona,
que varia de 0 a 63, da rede 200.230.200, indicando uma entrada de endereço arpa, e
depois indica que essa zona é do tipo master, ou seja, de onde temos autoridade, e indica
o arquivo db.200.230.200 como sendo a base de dados (data base) das informações que
o servidor de nomes deverá adotar.
 Na verdade essa entrada no named.conf (63-0.200.230.200.in-addr.arpa) indica uma
zona reversa. E o arquivo de base de dados contém informações reversas sobre essa zona.
Pode-se reparar que a zona em questão, no named.conf é eeviac.com.br ou seja, agora
estaremos tratando com o endereço reverso de todos os hosts de nossa
rede/zona/domínio.

E qual a importância de mantermos informações sobre as zonas reversas no nosso

servidor de nomes? Muita! As informações referentes as zonas reversas permite que se
localize o nome de uma máquina (um host na rede) sabendo apenas o endereço IP do
mesmo. Ou seja, no arquivo de zonas, o db.eeviac, nós ensinamos o nosso servidor de
nomes a indicar um endereço IP a partir de um nome, e agora ensinaremos a indicar o
nome a partir do endereço IP, é essa a ação reversa que deverá ser respondida sempre
que o nosso servidor de nomes for perguntado.

O Arquivo de zona reversa em um servidor de nomes lembra muito o de definições de

zona (o db.eeviac ) e se difere na adição das interfaces dos hosts. Você se lembra que
para definir os nomes, nós obtinhamos o nome e adicionava-mos uma entrada (IN) do tipo
quartenaria (A) ao endereço IP referente ao nome da máquina (host). Agora nós faremos a
função reversa, ou seja, a partir do host da nossa rede (no nosso caso: 0 até 63 porque
nossa rede abrange esses hosts apenas) deveremos permitir que o nosso servidor de nome
identifique o nome da máquina.

Vamos dar uma olhada no formato que esse arquivo deve ter:

$TTL 14400
@ IN SOA eeviac.com.br. root.eeviac.com.br. (
2000041003 ; serial
28800 ; refresh
14400 ; retry
3600000 ; expire
86400 ; default_ttl
)
@ IN NS eeviacbsd.eeviac.com.br.
@ IN NS ns.embratel.net.br.
1 IN PTR rt.eeviac.com.br.
2 IN PTR ras.eeviac.com.br.
10 IN PTR eeviacbsd.eeviac.com.br.
10 IN PTR pop3.eeviac.com.br.
10 IN PTR smtp.eeviac.com.br.
10 IN PTR ftp.eeviac.com.br.
10 IN PTR www.eeviac.com.br.
9 IN PTR xffa.eeviac.com.br.
3 IN PTR eev3.eeviac.com.br.
4 IN PTR eev4.eeviac.com.br.
5 IN PTR eev5.eeviac.com.br.
6 IN PTR eev6.eeviac.com.br.
7 IN PTR eev7.eeviac.com.br.
8 IN PTR eev8.eeviac.com.br.
11 IN PTR freebsd.eeviac.com.br.
12 IN PTR eev12.eeviac.com.br.
13 IN PTR eev13.eeviac.com.br.
14 IN PTR eev14.eeviac.com.br.
15 IN PTR eev15.eeviac.com.br.
16 IN PTR eev16.eeviac.com.br.
17 IN PTR eev17.eeviac.com.br.
18 IN PTR eev18.eeviac.com.br.
19 IN PTR eev19.eeviac.com.br.

Bom, sem contar todo o início do arquivo, a descriminação da zona de autoridade

(SOA), você deve ter reparado duas particularidades, a primeira, é o final dos endereços
descritos estarem com um ponto final, ou seja, declarando que é um domínio absoluto, e
outra cousa, que você com certeza reparou, se se lembra da nossa tabela de RRs
(Resource Records), que é o uso de ponteiros (PTR). Já comentamos que para tratarmos
de dados reversos, usaremos os ponteiros. Você percebe que agora, apenas os hosts da
nossa rede estão descriminados. Para evitar um arquivo de exemplo muito grande, nós
terminamos o arquivo no host 19, mas ele deve continuar até o 62 (uma vez que o IP 63 é
o broadcast da rede) ou até o penúltimo host da sua rede, seja ela do tamanho que for.

A descrição dos endereços IPs podem ser completos, mas não tem porque conter a rede,
se no named.conf nós declaramos que trataremos da rede 200.230.200.in-addr.arpa, o
servidor de nomes já sabe exatamente de que rede estamos tratando. Agora a ação
reversa indica para o nosso servidor de nomes que, para o cliente (host) número X da
nossa rede, nós estamos adicionando uma entrada (IN) que aponta (PTR) para o nome da
máquina. Vamos analisar com mais detalhes então esse arquivo:

$TTL 14400
@ IN SOA eeviac.com.br. root.eeviac.com.br. (
2000041003 ; serial
28800 ; refresh
14400 ; retry
3600000 ; expire
86400 ; default_ttl
)

; até aqui a entrada é absolutamente familiar, ou seja, você

; já consegue entender cada entrada e sua função.

@ IN NS eeviacbsd.eeviac.com.br.

@ IN NS ns.embratel.net.br.

; até aqui também, nenhuma novidade, esses são as entradas para os

; dois servidores de nomes que estaremos alimentando com nossos dados

; reversos. Alimentando e nos servindo também.

1 IN PTR rt.eeviac.com.br.

2 IN PTR ras.eeviac.com.br.

; agora sim, estamos tratando as entradas reversas do roteador (rt)

; e do autenticador/atendedor da nossa rede (ras). Atenção na forma

; como o nome + domínio/zona são tratados, com um ponto final depois

; do .br, você deve se lembrar disso ao criar o seu db reverso.

10 IN PTR eeviacbsd.eeviac.com.br.

10 IN PTR pop3.eeviac.com.br.

10 IN PTR smtp.eeviac.com.br.

10 IN PTR ftp.eeviac.com.br.

10 IN PTR www.eeviac.com.br.

; agoura, como o nosso host 200.230.200.10 é na verdade

; o servidor principal da nossa rede/zona, então adicionamos

; uma entrada reversa para cada nome que ele deve responder.

; Isso é opcional e na maioria dos casos adiciona-se apenas a entrada

; reversa do nome verdadeiro do servidor, ou seja, eeviacbsd.eeviac.om.br

9 IN PTR xffa.eeviac.com.br.

; e essa é a entrada reversa para o nosso servidor secundário.

3 IN PTR eev3.eeviac.com.br.

4 IN PTR eev4.eeviac.com.br.

5 IN PTR eev5.eeviac.com.br.

6 IN PTR eev6.eeviac.com.br.

7 IN PTR eev7.eeviac.com.br.

8 IN PTR eev8.eeviac.com.br.

11 IN PTR corduroy.eeviac.com.br.

; e assim segue, repare que agora inserimos os dados reversos

; para o nosso segundo servidor secundário...

12 IN PTR eev12.eeviac.com.br.
13 IN PTR eev13.eeviac.com.br.

14 IN PTR eev14.eeviac.com.br.

15 IN PTR eev15.eeviac.com.br.

16 IN PTR eev16.eeviac.com.br.

17 IN PTR eev17.eeviac.com.br.

18 IN PTR eev18.eeviac.com.br.

19 IN PTR eev19.eeviac.com.br.

; e assim você deve continuar com todos os hosts da sua rede,

; sempre adicionando um ponteiro para apontar o IP para o

; nome certo da máquina. Lembre-se sempre da sintaxe:

; a entrada do IP do host/máquina indicando uma entrada (IN)

; de um ponteiro (PTR) que aponta ao nome da máquina que

; corresponde a aquele IP. Não se esqueça do ponto final

; no nome completo da máquina. É isso aí! Eis o seu Reverso!

5.6 Iniciando o DNS no FreeBSD

Bom, agora que você já tem todos os arquivos que compõe a configuração do seu
servidor de nomes prontos, então é hora de iniciar o seu servidor de nomes, e cuidar para
que ele se inicie sempre que necessário, junto ao sistema operacional, e com os
parâmetros corretos.

Bom, você já sabe que é o BIND quem faz as requisições ao NS, para obter informações
sobre nomes, e depois retorna essas informações ao cliente que fez esse pedido. Então,
para melhorar sua segurança, você deve garantir que o BIND seja o único que tenha o
direito de fazer essas requisições. Sabe também que o NAMED é o programa mais usado
para essa tarefa. Então você vai ter que avisar ao seu sistema FreeBSD que ele vai ser
servidor de nomes, e que vai usar o NAMED como o programa para tal. Ainda: vai dizer
pro NAMED ser levantado pelo usuário e grupo do usuário BIND. Esses fatos não são
obrigatórios, mas ajudam na segurança do seu servidor.

Lembra-se que no início desse capítulo eu disse que mudava o local dos diretórios onde
os arquivos de base de dados e configuração do servidor de nomes ficava, por segurança,
certo? Bom, vamos lembrar de um detalhe... pra rodar o servidor de nomes, o usuário
deve ser alguém com um pouco mais de direitos no sistema, e isso não é bom. O Usuário
BIND tem alguns privilégios que podem ser perigosos, se alguém mal intencionado puder
usufruir deles de alguma forma.

Felizmente, não é nada fácil se tornar o usuário que roda seu servidor de nomes, e o
que pode ser feito, as vezes (bem raramente...) é algum ser muito esperto conseguir
executar comandos arbitrários no seu sistema, com os direitos do root. Poucos comandos
podem ser executados, e o suposto invasor faz isso quase que às escuras, mas quando se
tem um pouco mais de liberdade, um terceiro pode até abrir uma shell no seu servidor, aí
estamos totalmente à mercê.

E como essa forma de exploitar um servidor BIND é mesmo quase sempre as escuras,
com comandos lançados às cegas, então, é claro que se o invasor conheça menos do seu
sistema, então melhor, porque ele não fica "adivinhando" onde você roda os seus arquivos,
e/ou onde o BIND tem esses direitos a mais. Direcionando um diretório exclusivo aos
arquivos do BIND, você pode usar de formas administrativas no FreeBSD para não
permitir que alguns tipos de ações sejam feitas, ou executadas a partir daquele usuário.
Liberar direitos direcionados é uma forma de previnir problemas com espertinhos que
queiram brincar com seu sistema. Claro que estamos tratando aqui de situações raras,
mas, recentemente uma das versões mais distribuídas do BIND teve um probleminha, e
se tornou alvo desses tipos de exploits. Esse problema foi o bastante para tirar do ar
alguns dos servidores mais bem administrados do mundo, inclusive 3 Root Nameservers
ao mesmo tempo.

A forma mais segura de se garantir uma despreocupação, em relação à segurança, é

rodar o BIND CHRootado. CHRootar é algo bem usual no FreeBSD e que esta se tornando
usual em outros Unix ou até clones de Unix, como o Linux. Imagine que o BIND seja um
usuário apenas com acesso ao seu ROOT DIRECTORY, e mesmo com direitos a mais, ele
entendesse sempre que está no ponto mais alto do sistema de arquivos, o "/" mesmo não
estando. Então ele realmente teria todos os direitos do mundo, mas apenas daquele
diretório pra baixo, não podendo nem ver os outros diretórios do sistema. É mais ou
menos isso que você faz com os seus usuários, quando adiciona eles ao ftpchroot no
FreeBSD, ou seja, eles ficam presos ao seu HOME, sempre achando que lé é a raiz do
sistema...

Infelizmente fazer isso com o BIND não é tão fácil quanto em relação aos seus usuários
e o acesso FTP deles... Essa é a ação mais segura que se pode fazer, mas poucas pessoas
conseguem ou nem tentam fazer isso... Não vamos falar disso agoura, apenas foi
comentado porque, no início desse capítulo dissemos algo sobre segurança.

Bom, mas vamos voltar ao nosso DNS no FreeBSD. Agora você tem que dizer ao seu
FreeBSD que ele será um servidor de nomes, e tem que dizer que ele vai usar o NAMED
pra isso, e vai também permitir requisições do usuário BIND. Bom, pra isso basta você
adicionar 3 linhas no seu arquivo /etc/rc.conf

Essas linhas são:

named_enable="YES"
named_program="named"
named_flags="-u bind -g bind -c /etc/namedb/named.conf"

Para adicionar essas linhas, use um editor de texto, como o ee:

# ee /etc/rc.conf
e adicione as linhas.
 A Primeira linha (named_enable="YES") diz ao FreeBSD que ele será um servidor de
nomes, e faz também com que ele procure iniciar o servidor de nomes sempre que o
FreeBSD for iniciado.

A Segunda linha (named_program="named") diz que o Programa que vai ler os serviços
de nomes será o Name Daemon, ou o named. Apesar de existirem outras opções, o
named é o mais indicado.

A Última linha (named_flags="-u bind -g bind -c /etc/namedb/named.conf") são os

parâmentros para iniciar o servidor daemon de nomes. A opção -u diz pro sistema qual
usuário vai executar o named, o -g diz o grupo do usuário que vai faze-lo, e -c força a
leitura de determinado arquivo de configuração para iniciar o servidor de nomes.

Ou seja, com essas opções você esta dizendo ao FreeBSD que ele vai ser um servidor de
nomes, e que deve iniciar sempre esse serviço com o comando:

named -u bind -g bind -b /etc/namedb/named.conf

Agoura sim, o seu servidor de nomes está prontinho pra rodar. Para testar, você pode
digitar:

# named.restart
ou
# named.reload
ou
# ndc restart
ou
# named -u bind -b bind -g /etc/namedb/named.conf

Algumas considerações apenas: Normalmente o controlador do servidor de nomes, o

aplicativo ndc, é muito usado para administrar o serviço de nomes. A sintaxe mais
comum é ndc start, ndc stop, ndc restart, ndc status. Contudo ao iniciar seu servidor de
nomes com ndc start ele inicia o named rodando como root, o que, como já comentado,
pode ser arriscado à segurança do seu servidor. Portando é recomendado iniciar o named
sempre com usuário e grupo bind. Pra isso escreva um script pra automatizar esse
processo, ou reescreva o named.reload e named.restart.

Um exemplo muito simples de um script básico pra essa rotina:

#!/bin/sh
/sbin/killall -9 named
/bin/echo -n "Reiniciando servidor de nomes..."
/usr/sbin/named -u bind -g bind -c /etc/namedb/named.conf
/bin/echo " OK!"

Basta criar um script com esse nome e dar permissão de execussão à ele (chmod +x).
Coloca-lo na sua PATH é recomendado.

5.7 NSLOOKUP

Bom, depois de uma explicação tão detalhada, dificilmente você não conseguirá
configurar o seu servidor de nomes (DNS) no FreeBSD. Mas para ter certeza que o seu
servidor de nomes esta funcionando da forma correta, você pode usar uma ferramenta
muito boa. Essa ferramenta se chama nslookup e é usada para interrogar servidores de
nomes. Ela é distribuída juntamente com o software BIND, e faz parte das interfaces
cliente do serviço de nomes.

Ela permite a qualquer usuário consultar um servidor de nomes e recuperar qualquer

informação conhecida por este servidor. É extremamente útil para identificar problemas
com servidores de nomes, se estão configurados corretamente e também para obter
informações fornecidas por servidores remotos.

Para garantir que você estará usando o seu próprio servidor de nomes para se
comunicar com outros servidores, então configure o seu resolver para procurar apenas no
seu próprio servidor de nomes. Edite o seu arquivo /etc/resolv.conf e certifique-se que
existam as entradas DOMAIN, SEARCH, e NAMESERVER configuradas, e que a entrada
NAMESERVER aponte para o seu endereço IP, ou seja, faça com que o seu servidor de
nomes seja você mesmo. Garanta que não exista outra entrada NAMESERVER, assim,
não existindo um servidor de nomes secundário configurado, você garante que, se tudo
der certo é mesmo porque o seu servidor de nomes esta perfeito.

Para editar o /etc/resolv.conf use um editor, como o ee:

# ee /etc/resolv.conf
e adicione:

domain seudominio.com.br
search seudominio.com.br
nameserver IP do SEU SERVIDOR DE NOMES

no nosso exemplo, você adicionaria:

domain eeviac.com.br
search eeviac.com.br
nameserver 200.230.200.10

Agora sim, você está pronto para usar o NSLOOKUP para testar o seu servidor de
nomes.

Digite "nslookup" e a saída, se tudo ser certo, deve ser parecida com:

# nslookup
Default Server: eeviacbsd.eeviac.com.br
Address: 200.230.200.10
>

Se não der certo, aparecerá uma mensagem parecida com:

*** Couldn’t resolve for localhost

*** Couldn’t find a nameserver at 200.230.200.10

Então reveja os seus arquivos de configuração do named. Uma dica é, se não funcionar
na sua interface externa de rede (no nosso caso 200.230.200.10) tente colocar nameserver
127.0.0.1 no seu /etc/resolv.conf. Se dessa vez funcionar, então estamos diante de um
problema não muito comum. Para garantir que seja esse o problema, certifique-se que o
seu servidor de nomes esteja ouvindo na interface externa. Para isso, a saída do comando
netstat -an | grep -i list deve apontar o seu IP real (interface externa) ouvindo na porta 53.

Outra forma de certificar isso, é dar telnet na porta 53 da interface externa. (telnet
200.230.200.10 53 - no nosso exemplo). Se a conexão se estabelecer e o nslookup não
funcionar na interface externa, então é o nosso problema raro.

Isso acontece quando o seu reverso não esta configurado corretamente. Se seu reverso
não funcionar da forma certa, o BIND, por segurança, não responde a query nenhuma
feita na interface externa, apenas no loopback. Mesmo ouvindo na interface ele
simplesmente não responde. Esse problema com o reverso pode ser a entrada
xxx.xxx.xxx.in-addr.arpa no seu /etc/namedb/named.conf . Se você está usando BIND
acima do 8.2.4 tente não colocar a zona de abrangência (xxx-xxx) no seu named.conf

Se assim também não funcionar, reveja seus arquivos e reveja os exemplos dessa
documentação porque você deve ter configurado alguma informação imprecisa.

Mas se der certo, você pode ter certeza que o seu servido de nomes está se
comunicando com os outros servidores de nomes do mundo, da seguinte forma: ao digitar
"nslookup", a saída da resposta será uma prompt com um sinal de maior (>):

# nslookup
Default Server: eeviacbsd.eeviac.com.br
Address: 200.230.200.10
>

Então nessa prompt digite o nome de vários domínios, e também os endereços IP, para
testar os reversos. As saídas devem ser algo parecido com:

# nslookup
Default Server: eeviacbsd.eeviac.com.br
Address: 200.230.200.10
> www.fatectq.com.br

Default Server: eeviacbsd.eeviac.com.br

Address: 200.230.200.10

Non-authoritative answer:
Name: www.fatectq.com.br
Address: 200.210.2.10

> www.vitalogy.org
Default Server: eeviacbsd.eeviac.com.br
Address: 200.230.200.10

Non-authoritative answer:
Name: www.vitalogy.org
Address: XXX.XXX.XXX.XXX

> 200.230.200.11
Default Server: eeviacbsd.eeviac.com.br
Address: 200.230.200.10
Non-authoritative answer:
Address: 200.230.200.11
Name: corduroy.eeviac.com.br

5.7.1 Opções do NSLOOKUP

O nslookup tem uma série de opções de uso, para aprender como usa-las, digite set all
na prompt
>

# nslookup
Default Server: maquina1.eksffa.net
Address: 143.106.10.11
>set all

Default Server: maquina1.eksffa.net

Address: 143.106.10.11
Set options:
nodebug defname search recurse
nod2 novc noignoretc port=53
querytype=A class=IN timeout=6 retry=4
root=ns.nic.ddn.mil.
domain=eksffa.net
srchlist=maquina1.eksffa.net/eksffa.net
>

Veja agora uma peque lista das opções mais comuns do NSLOOPUP e sua descrição:

[no]debug Debugging é desativado por default. Se ativado, o servidor de nomes exibe

informações como timeout e exibe o pacote de resposta.

[no]defname Por default, o comando nslookup acrescenta o nome do domínio default a

nomes que não possuem um "." no final.

[no]search A opção search encobre o domínio default (opção defname). Ou seja, a opção
defname somente se aplica se a opção search está desligada. O comando nslookup
acrescenta os nomes dos domínios listados na lista de procura (srchlist) a nomes que não
terminam em "."

[no]recurse o programa nslookup solicita serviço recursivo por default.

[no]d2 O debug no nível 2 é desativado por default. Se ativado, são exibidos os pacotes
enviados em adição à saída do debug.

[no]vc Por default, o comando nslookup utiliza pacotes UDP ao invés de TCP (circuitos
virtuais ou virtual circuits - vc). A maior parte das perguntas (queries) são feitas utilizando
UDP. Da mesma forma que o resolver pode ser instruído a utilizar TCP, o nslookup também
oferece a mesma funcionalidade.

[no]ignoretc Por default, o nslookup não ignora pacotes truncados. Se é recebido um pacote
que possui o bit indicativo de pacote truncado ligado, indicando que o servidor de nomes
não conseguiu incluir toda a informação dentro de um pacote UDP, o nslookup não o ignora.
É repetida a pergunta utilizando-se uma conexão TCP ao invés de UDP.

port=53 O serviço DNS atende na porta 53. O DNS pode ser inicializado em outra porta
para fins de debug e o nslookup pode ser direcionado a utilizar esta nova porta.

querytype=A Por default, o nslookup tenta resolver endereços,registros do tipo A (address).

class=IN A única classe que importa é IN (Internet). Existem outras classes como por
exemplo HESIOD (HS).

Timeout=5 Se o servidor de nomes não responder em 5 segundos, o nslookup reenvia a

pergunta e dobra o timeout (para 10, 20 e 40 segundos). O resolver do BIND utiliza os
mesmos timeouts ao interrogar um único nameserver.

Retry=4 Envia a pergunta 4 vezes antes de desistir. Após cada pergunta o timeout é
dobrado.

root=ns.nic.ddn.mil Existe uma facilidade chamada root que chaveia o servidor de nomes
para o servidor identificado por esta opção.

Domain= Este é o domínio default acrescido ao nome fornecido caso a opção defname
esteja ligada.

Srchlist= Se a opção search estiver ativa, estes são os domínios acrescidos a nomes que
não se encerrem em "."

5.7.2 Exemplos de utilização do NSLOOKUP

% nslookup
Default Server: maquina1.eksffa.net
Address: 143.106.10.11
> acme.com
Server: maquina1.eksffa.net
Address: 143.106.10.11
Name: acme.com
Address: 206.86.3.110

> set type=ptr

> 206.86.3.110

Server: maquina1.eksffa.net

Address: 143.106.10.11

110.3.86.206.in-addr.arpa host name = jef.vip.best.com

3.86.206.IN-ADDR.ARPA nameserver = ns1.best.com

3.86.206.IN-ADDR.ARPA nameserver = ns2.best.com

3.86.206.IN-ADDR.ARPA nameserver = ns3.best.com

ns1.best.com inet address = 206.86.8.69

ns2.best.com inet address = 206.86.0.21

ns3.best.com inet address = 204.156.128.1

> set_ _q=mx

> acme.com

Server: maquina1.eksffa.net

Address: 143.106.10.11

acme.com preference = 20, mail exchanger = mail3.best.com

acme.com preference = 20, mail exchanger = mail4.best.com

acme.com preference = 10, mail exchanger = mail1.best.com

acme.com preference = 10, mail exchanger = mail2.best.com

acme.com nameserver = ns.best.com

mail3.best.com inet address = 206.86.0.21

mail4.best.com inet address = 206.86.8.69

mail1.best.com inet address = 206.86.8.14

mail2.best.com inet address = 206.86.8.14

ns.best.com inet address = 206.86.8.69

> set q=any

> acme.com

Server: maquina1.eksffa.net

Address: 143.106.10.11

Non-authoritative answer:

acme.com nameserver = NS.BEST.COM

acme.com nameserver = NS2.BEST.COM

acme.com nameserver = NS3.BEST.COM

acme.com inet address = 206.86.3.110

acme.com preference = 20, mail exchanger = mail3.best.com

acme.com preference = 20, mail exchanger = mail4.best.com

acme.com preference = 10, mail exchanger = mail1.best.com

acme.com preference = 10, mail exchanger = mail2.best.com

Authoritative answers can be found from:

acme.COM nameserver = NS.BEST.COM

acme.COM nameserver = NS2.BEST.COM

acme.COM nameserver = NS3.BEST.COM

NS.BEST.COM inet address = 204.156.128.1

NS.BEST.COM inet address = 206.86.8.69

NS2.BEST.COM inet address = 206.86.0.21

NS3.BEST.COM inet address = 204.156.128.20

NS3.BEST.COM inet address = 204.156.128.1

mail3.best.com inet address = 206.86.0.21

mail4.best.com inet address = 206.86.8.69

mail1.best.com inet address = 206.86.8.14

mail2.best.com inet address = 206.86.8.14

> set q=soa

> acme.com

Server: maquina1.eksffa.net

Address: 143.106.10.11

acme.com origin = ns.best.com

mail addr = root.best.com

serial=5, refresh=43200, retry=600, expire=604800, min=259200

>

5.7.3 Respostas Oficiais e Não Oficiais

% nslookup

Default Server: xffa.eksffa.net

Address: 143.106.10.54

mit.edu

Server: xffa.eksffa.net
Address: 143.106.10.54

Name: mit.edu
Address: 18.72.2.1

> mit.edu
Server: xffa.eksffa.net
Address: 143.106.10.54

Non-authoritative answer:
Name: mit.edu
Address: 18.72.2.1

>

5.7.4 Opções norec /nosearch

O nslookup pode se comportar tanto como um resolver ou como um servidor de nomes.

Quando um servidor de nomes recebe um pedido, ele verifica se possui a informação

em seu cache. Se não pode responder, e é a autoridade para o domínio, o servidor
responde informando que o nome não existe ou que não existem dados disponíveis para
aquele tipo de pergunta. Se o servidor não possui a resposta e não é o servidor oficial para
aquele domínio, ele começa a andar através da hierarquia do espaço global de nomes
buscando pela informação.

Se um servidor recebe uma pergunta não recursiva, ele responde ao cliente fornecendo
os registros NS que encontrou. Por outro lado, se a pergunta for recursiva, o servidor
encaminha perguntas aos servidores obtidos a partir dos registros NS que encontrar.
Quando o servidor recebe uma resposta de um dos servidores remotos, ele coloca a
informação no cache e repete o processo, se necessário. A resposta do servidor remoto irá
ou responder a pergunta original ou conterá uma lista de servidores mais embaixo na
hierarquia do espaço de informações do DNS que esteja mais próxima da resposta.

% nslookup -norec -nosearch

Default Server: localhost

Address: 127.0.0.1

> server ns.nasa.gov

Default Server: ns.nasa.gov

Served by:

- E.ROOT-SERVERS.NET

192.203.230.10

NASA.GOV

- NS.GSFC.NASA.GOV

128.183.10.134

NASA.GOV

- JPL-MIL.JPL.NASA.GOV

128.149.1.101

NASA.GOV

- MX.NSI.NASA.GOV

128.102.18.31

NASA.GOV

> acme.com

Server: ns.nasa.gov

Served by:

- E.ROOT-SERVERS.NET

192.203.230.10

NASA.GOV

- NS.GSFC.NASA.GOV

128.183.10.134
NASA.GOV

- JPL-MIL.JPL.NASA.GOV

128.149.1.101

NASA.GOV

- MX.NSI.NASA.GOV

128.102.18.31

NASA.GOV

Name: acme.com

Served by:

- NS.BEST.COM

204.156.128.1

acme.com

- NS2.BEST.COM

206.86.0.21

acme.com

- NS3.BEST.COM

204.156.128.20

acme.com

> server ns.best.com

Default Server: ns.best.com

Address: 204.156.128.1

> acme.com

Server: ns.best.com

Address: 204.156.128.1

Name: acme.com
Address: 206.86.3.110

5.7.5 Transferência de Zonas

O comando nslookup pode também ser utilizado para transferir uma zone inteira
utilizando-se o comando ls. Esta facilidade pode ser utilizada para resolução de
problemas, realizar contagem do número de hosts em determinado domínio, etc.

% nslookup

Default Server: maquina1.eksffa.net

Address: 143.106.10.11

> ls ad.eksffa.net

[maquina1.eksffa.net]

ad.eksffa.net. 143.106.10.2

ad.eksffa.net. server = ns.ca.eksffa.net

ns.ca.eksffa.net. 143.106.32.65

ns.ca.eksffa.net. 143.106.32.129

ad.eksffa.net. server = maquina1.eksffa.net

maquina1.eksffa.net. 143.106.10.11

maquina1.eksffa.net. 143.106.1.5

localhost 127.0.0.1

ftp 143.106.32.67

mail 143.106.32.65

www 143.106.32.126

> ls -t mx cenapad.eksffa.net

[maquina1.eksffa.net]

ad.eksffa.net. 0 ns.ca.eksffa.net

ad.eksffa.net. 5 maquina1.eksffa.net

ftp 0 ns.ca.eksffa.net
ftp 5 maquina1.eksffa.net

mail 0 ns.ca.eksffa.net

mail 5 maquina1.eksffa.net

www 0 ns.ca.eksffa.net

www 5 maquina1.eksffa.net

> ls -t dcc.eksffa.net > /tmp/dcc.zone

[maquina1.eksffa.net]

########

Received 413 records.

> view /tmp/dcc.zone

5.8 Sinais operacionais do BIND

O BIND name server, é manipulado através de sinais. A tabela abaixo lista os sinais
suportados pelo BIND e uma descrição resumida de sua função:

HUP - Reinicializa o servidor de nomes. Envie este sinal ao servidor primário após modificar
o arquivo de boot (/etc/namedb/named.conf) ou qualquer dos arquivos de seu banco de
dados. O comando named.reload também pode ser usado.

INT - Efetua um dump do banco de dados interno do servidor de nomes no arquivo

/usr/tmp/named_dump.db

ABRT - Apenda estatísticas do servidor de nomes ao arquivo /usr/tmp/named.stats. Este

sinal é chamado de IOT em alguns sistemas

USR1 - Apenda informações de debug ao arquivo /usr/tmp/named.run. Cada sinal

subsequente do mesmo tipo aumenta o nível de detalhe registrado.

USR2 - Desabilita o debugging

5.9 Mais informações importantes sobre SERVIDORES DE NOMES

Esse sub-capítulo pode ser entendido como um bônus do nosso capítulo sobre DNS.
Acontece que, Esse serviço de nomes é um dos mais nobres, senão o mais nobre serviço
realizado por um servidor na Internet. Pode-se com isso até mesmo configurar um
servidor para ter autoridade sobre outros domínios/zonas que não sejam de uma rede ou
máquina privada. São os chamados domínios virtuais. Domínios Virtuais serão tratados
logo mais em um capítulo seguinte.
 Por ser um serviço tão importante e tão usual na Internet e em redes em geral, vamos
obter e analisar algumas outras informações e vamos ver situações comuns para
administradores de redes e sistemas de informação via Internet.

5.9.1 EsteGlue Records

Estes registros aparecem do lado direito da definição de um servidor de nomes:

itd.umich.edu. IN NS dns2.itd.umich.edu.
dns2.itd.umich.edu. IN A 141.211.164.3

O segundo registro é uma "cola" para o registro NS anterior.

Registros "cola" são necessários quando se delega autoridade para um servidor de

nomes que reside dentro do domínio delegado.

Desta forma, no exemplo acima, o servidor de nomes dns2.itd.umich.edu precisa

possuir uma entrada com seu endereço no servidor que está delegando autoridade, pois
reside dentro do domínio itd.umich.edu. Caso contrário, como seriam encontradas as
informações relativas ao domínio itd.umich.edu se o próprio servidor está dentro deste
domínio? Já neste caso:

itd.umich.edu. IN NS dns.cs.wisc.edu.

Não existe a necessidade de um registro "cola"

5.9.1 Lame Delegation

Server *** was (ou IS) a lame server

Essa linha é bem comum hoje nos logs dos nossos serviços de nomes. Saiba que Lame
delegation ocorre quando, por exemplo, o servidor de nomes X é considerado fonte oficial
de informações para o domínio Y. Ao se perguntar ao servidor X sobre o domínio Y são
retornadas informações não oficiais, ou o servidor X não sabe nada sobre o domínio Y.

Para identificar servidores de nomes nesta condição, utilize o programa nslookup (ou
similar) para interrogar os servidores de nomes um nível acima do servidor suspeito.
Obtenha a lista dos servidores para o domínio desejado e por sua vez questione cada um
dos servidores obtidos e verifique se retornam informações oficiais.

O shell script lamers, escrito por Bryan Beecher faz esta verificação automaticamente.

5.9.2 Resolução de Problemas (uma pequena CheckList)

A maior parte dos problemas relativos ao DNS geralmente se enquadram em categorias

bastante comuns e podem ser resolvidos de modo razoavelmente simples. São eles (não
agrupados em ordem de importância ou de ocorrência):

Não alterar o número de série dos mapas

Processo named não está no ar
Não sinalizar ao named que algum mapa foi mudado
Servidores secundários não conseguem carregar os dados da zona
Criar a entrada de uma máquina no mapa direto e não fazer o mesmo para o mapa
reverso
Erro de sintaxe no arquivo de boot ou nos mapas do DNS
Não colocação do "." no final de um nome
Informações ausentes no mapa do cache (named.ca)
Falta de conectividade à rede
Delegação incorreta para subdomínios
Delegação de autoridade não efetivada
Erro de sintaxe no arquivo /etc/resolv.conf
Nome do domínio default não definido
Problema na sintaxe do named.conf
Má configuração da zona reversa

5.9.3 Ferramentas de Gerenciamento

- Diagnósticos Básicos

nslookup ? Ferramenta para interrogar servidores de nomes

dig é abrangente que nslookup, é usado por diversas outras ferramentas. Eu uso ele
para criar meus arquivos de cache local, pra usar em Intranet. Thanx ao Lint por ter me
dado a dica!

host é desenvolvido como uma evolução das ferramentas nslookup e dig.

5.9.4 Ferramentas Usadas Para Diagnósticos Gerais

Checker - Utilizado para uma análise, do lado do servidor, de servidores remotos mal
configurados.
DDT - Desenvolvido por Jorge Frazao e Artur Romao, para debugar dados no cache.
dnswalk - Desenvolvido por David Barr, verifica a árvore do DNS.
doc - Desenvolvido por Steve Hotz e Paul Mockapetris. Verifica a integridade de um
domínio.
lamers - De Bryan Beecher, verifica e avisa os administradores sobre servidores que estão
gerando informações
errôneas.
nslint - ? Desenvolvido por Craig Leres, identifica inconsistências em arquivos do DNS.
ZoneCheck - Faz verificação de zonas.
5.9.5 Gerenciamento de Zonas
Accugraph's IP Address Management - Ferramenta comercial
addhost - Realiza o gerenciamento de tabelas de hosts utilizando uma interface curses.
Por John Hardt.
GASH - Ferramenta de administração de sistemas que inclui o DNS.
gencidrzone - Gera zonas reversas CIDR .
h2n - Automatiza o procedimento de geração de arquivos DNS a partir do arquivo
/etc/hosts, descrito no livro
DNS and Bind .
makezones - Auxilia a manutenção de arquivos DNS.
NetID - Produto comercial para gerenciamento do DNS
QIP e QNS - Ferramentas comerciais para gerenciamento de endereços IP e DNS.
Quadritek, utilizando Sybase .
SENDS - Desenvolvida por Paul Vixie para o gerenciamento de bases DNS complexas.
Utah Tools - Conjunto de ferramentas para gerenciamento do DNS em uso na
Universidade de Utah.
webdns - Manutenção DNS através de um WWW browser.
zsu - Incrementa os números seriais das zonas de modo sensato.

6.0 Rodando o BIND em ambiente CHRootado (chroot() enviroment)

6.1 Uma visão do ambiente CHRootado.

Esse subcapítulo desse documento aborda uma das mais importantes e indicadas
precauções de segurança que se pode tomar em relação ao sofware BIND. Vamos
demonstrar aqui, de forma clara e prática, todo o procedimento para colocar o BIND
sendo executado em ambiente CHRootado. O Termo CHRoot significa Modificar a Raiz
(CHange Root). A analogia é simples, o ambiente unix segue uma estrutura de arquivos
em árvores hierárquicas, onde o nível mais baixo (raiz), representada nesse ambiente pelo
"/" pode (de acordo com as permissões do sistema) obter acesso à todos os níveis mais
altos da estrutura de arquivos do computador, portanto, todo o sistema local. Esse
conceito básico de ambiente Unix, portanto, pode ser modificado, criando assim um
ambiente virtual da estrutura raiz.

No FreeBSD, você pode implementar um sistema de prisão para um ambiente com o

diretório raiz modificado. Você pode até rodar um sistema operacional dentro de outro,
em ambiente de raiz modificada. A esse procedimento, damos o nome de "CHroot Jail".
Quando um sistema ou processo é executado em um ambiente desse tipo, o seu diretório
modificado passa a ser o seu diretório raiz, e, consequentemente, ele só passa a
enchergar a estrutura de diretórios existente acima do seu ambiente 'chrootado'.

Você provavelmente já teve ao menos um tipo de experiência com esse ambiente.

Sempre que você faz acesso FTP como cliente, em algum servidor público, como usuário
anônimo, ou mesmo com outro usuário válido, em um servidor que tenha algum nível de
segurança, você percebe que apenas encherga a estrutura de diretórios criadas a partir do
seu próprio diretório HOME, e consequentemente, só encherga o que você precisa, ou
criou. Se deslocar para um nível mais baixo na árvore do sistema é impossível,
simplesmente porque aquele é o nível mais baixo pra você. Você passa a enchergar o seu
'/usr/home/user' como o seu diretório '/'.

No FreeBSD, esse ambiente de FTP CHRootado já vem preparado, sendo necessário

apenas que você, como administrador do sistema, defina quais usuários, ou grupos de
usuários serão 'aprisionados', utilizando o arquivo '/etc/ftpchroot'. Mais informações
sobre como usar o ftpchroot pode ser encontrada nessa documentação.

As implementações de ambiente chrootado são permitidas a nível de Kernel, no

FreeBSD, contudo, aprisionar um usuário ou processo dessa forma, não é tão simples
quanto no caso do FTP (quem sabe com o TrustedBSD isso não se torne corriqueiro).

Mas também esta longe de ser uma implementação difícil.

6.2 A Segurança por trás da idéia.

Rodar o BIND como processo e usuário aprisionados em um ambiente chrootado, tem

por finalidade diminuir considerávelmente os riscos de acesso indevido de alguma pessoa
má intencionada. O BIND, historicamente apresenta relatos de várias explorações de seus
serviços. Esse tipo de abuso já tirou do ar vários sites grandes e servidores importantes
da Internet, e essa é uma das melhores e mais eficientes formas de se limitar esses
abusos.

É por esse mesmo motivo que nós executamos o BIND como usuário não privilegiado,
como visto anteriormente nesse mesmo capítulo. Lembre-se que, manter o seu BIND o
mais atualizado possível é tão importante quanto essas medidas de segurança, visto que
todos os problemas quando descobertos, são rapidamente corrigidos. Utilizar um BIND
inferior à versão 8.2.3 é desaconselhado, por motivos de segurança, especialmente se não
for implementado em ambiente chrootado.

Existem outras soluções de segurança relacionadas ao BIND, alguma são soluções

proprietárias, outras tem uma licença menos restrita, como o djbdns,
(http://cr.yp.to/djbdns.html). Rodar o BIND junto ao djbdns é uma ideia que deve ser
considerada, ao menos por experiência.

6.3 Preparando o Ambiente CHRootado

6.3.1 Criação de um usuário para ser dono do processo BIND.

O Primeiro passo para começarmos a implementar o nosso ambiente seguro pro BIND,
é termos em mente que nós queremos executar o servidor de nomes como usuário não
privilegiado, como fizemos anteriormente nesse capítulo. Se você já roda o BIND com um
usuário e grupo específicos, então pode aproveitar esse mesmo usuário existente, para
continuar sendo o responsável pelo processo BIND.

No nosso caso, nós utilizamos o usuário padrão que o BIND cria no nosso FreeBSD, o
usuário bind e o grupo bind. Se por algum motivo você ainda roda o BIND como root, e
não tem um usuário específico pra essa finalidade, pode criar agora (se já não existir) o
usuário e grupo bind. Alguns administradores de sistemas costumam criar o usuário e
grupos named, especialmente os da comunidade Linux. Em termos práticos, é indiferente,
mas vamos assumir o que estamos indicando.

Para criar o usuário e grupo bind você pode utilizar o 'adduser', 'addgroup' ou
adicionar com o 'vipw' a linha referente ao usuário. Lembre-se, no FreeBSD se você
simplesmente alterar, manualmente, os arquivos /etc/passwd e /etc/master.passwd a
Base de Dados de usuários não será atualizada, e portanto essa alteração não terá efeito.

Para criar o usuário bind com o vipw, adicione a seguinte linha no ambiente de edição
que o vipw abre:

bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin

E para criar o grupo BIND, (você pode faze-lo manualmente, ou até mesmo via
sysinstall) adicione a seguinte linha no arquivo /etc/group:

bind:*:53:

Ao criar o usuário bind, lembre-se de atribuir a ele uma shell não válida, e garanta que
o usuário não tenha uma senha definida, o que o impede de se logar no sistema. Você
pode tomar esses cuidados no momento da inclusão do usuário, ou posteriormente,
utilizando o 'chfn'.
 Para isso, digite, logado como super-usuário (Root):

# chfn bind

A saída para esse comando deverá ser parecida com a tela a seguir:

#Changing user database information for bind.

Login: bind
Password: *
Uid [#]: 53
Gid [# or name]: 53
Change [month day year]:
Expire [month day year]:
Class:
Home directory: /
Shell: /sbin/nologin
Full Name: Bind Sandbox
Office Location:
Office Phone:
Home Phone:
Other information:

Nesse ambiente, você pode modificar toda a informação de finger para o usuário bind,
usual em ambiente Unix, contudo, no FreeBSD esse comando (assim como o vipw)
atualiza as informações na Base de Dados do sistema, ou seja, as informações assim
modificadas se tornam válidas.

Preste atenção na informação 'Home directory' do usuário bind, apontando para o "/". É
indicado que ao criar o usuário bind, (ou alterar seus dados) você defina "/" como o seu
Home Directory, quando nós formos rodar o processo bind em ambiente CHRootado, visto
que onde quer que seja o seu diretório HOME verdadeiro, ao CHRootarmos, ele será
sempre interpretado como a raiz do sistema ("/").

Você pode também reparar o "*" no lugar da senha, tanto na linha do vipw quando no
ambiente do chfn, como dito, para evitar que o usuário se logue no sistema. Finalmente,
como já recomendado, o usuário deve não ter uma senha válida, no nosso caso, nos
mantemos utilizando a shell que foi criada automaticamente, a shell não válida
/sbin/nologin. Você pode criar qualquer arquivo para ser essa shell não válida, como por
exemplo /bin/false ou /bin/semsenha, onde esse arquivo pode ser até mesmo um script
que, por segurança, por exemplo, ao ser executado envie uma mensagem ao
administrador, avisando que na data e hora atual, o usuário específico tentou se logar no
sistema. Ótimas alternativas de segurança.

O que deve-se deixar claro, é que essas shells devem existir, de verdade, e no ambiente
do CHRoot Jail, mais especificamente. Em alguns sistemas Unix, ao usar o chroot()
também deve existir o arquivo /etc/shells no ambiente CHRootado, apontando a
existência da shell não válida. Como nosso caso é específico BSD Unix, não foi necessário
criar esse arquivo no FreeBSD, nem no OpenBSD. Segundo Diego Linke (GAMK) também
não existe a necessidade no NetBSD.

Bom, com usuário e grupo criados, nós já temos um usuário sem privilégios no sistema,
para ser o usuário responsável pelo processo bind. Agora precisamos criar a nossa
estrutura de arquivos, para servirmos nosso processo de tudo (e tão somente) que ele
precise.
6.3.2 Preparando a estrutura de arquivos para o ambiente em chroot()

Agora sim, vamos ter que criar todo o ambiente HOME para o BIND. Vamos lembrar
que, depois de chrootado, esse ambiente home será interpretado como a raiz do sistema,
para o BIND, ou seja, seu diretório home será mesmo o "/" (raiz) em um ambiente de
CHroot Jail. Com isso em mente, devemos então criar todos os arquivos, e numa estrutura
que atenda as necessidades do BIND, para apenas garantir que todos os arquivos
necessários, e "somente" o que for necessário esteja disponível ao BIND.

É muito importante lembrar que, deve-se ter muita atenção ao criar e alterar os
arquivos indicados. De forma alguma devemos alterar os arquivos principais do sistema, e
sim, somente os arquivos na arvore aprisionada do sistema. Ou seja, quando você for
alterar arquivo /etc/master.passwd do ambiente CHRootado, deve tomar cuidados para
não alterar o mesmo arquivo do sistema, esse tipo de engano pode resultar em sérios
problemas no seu sistema.

Bom, agora para começarmos a preparar essa estrutura de arquivos, vamos considerar
que, o diretório principal para o BIND seja o /usr/named, exatamente como tratamos ao
longo desse capítulo inteiro. Ou seja, o /usr/named é o arquivo onde estarão nossas
informações de zona, zona reversa e nossos db's de zonas pra todos os domínios nos
quais nós teremos autoridade. E agora, aplicando o conceito de chroot enviroment, o nosso
diretório /usr/named será interpretado pelo BIND como sendo o diretório /.

Portanto:

/usr/named ==> /

Então, agora toda a estrutura de arquivos deverá ser criada abaixo desse diretório.

Vamos então começar a criar essa estrutura, necessária ao BIND.

O primeiro diretório a ser criado é o diretório etc/ com o arquivo resolv.conf, passwd e
master.passwd; Abaixo desse diretório, devemos criar o namedb/ ou seja, o etc/namedb/
que é o nosso ponto de partida para o serviço BIND, no FreeBSD.

Agora devemos criar o /dev/null, que é um tipo especial de device nula a qual nós já
conhecemos bem.

Depois deveremos criar toda a estrutura usr/ exatamente da forma como o BIND vai
precisar, contendo os diretórios usr/lib/, usr/libexec/, sbin/, usr/share/ com o diretório
zoneinfo/ e zoneinfo/America e usr/sbin/. Finalmente o diretório bin/ caso seja necessário
(necessário no OpenBSD, no FreeBSD não). Depois, mais um diretório, que será utilizado
pelo bind para guardar as informações de log e informações que nós queiramos. Vale
lembrar que na série 9 do BIND, é o administrador que cria as regras e níveis de logging
data. Então vamos assumir esse diretório de informações diversas como o info/.

Para facilitar a vizualização da estrutura que nós precisamos, veja saída do comando
du:

# du -h /usr/named/
1.0K ./dev
11K ./etc/namedb
80K ./etc
1.4M ./usr/lib
2.0K ./usr/share/zoneinfo/America
3.0K ./usr/share/zoneinfo
4.0K ./usr/share
3.9M ./usr/sbin
83K ./usr/libexec
5.4M ./usr
649K ./bin
2.0K ./info

Desconsidere as informações do tamanho dos diretórios, e analise apenas a estrutura

do mesmo. No momento os seus diretórios devem estar vazios, já que ainda não criamos
nem copiamos nada pra dentro deles.

Agora sim, vamos finalmente garatir todos os arquivos que o bind vai precisar para ser
executado em chroot().

- Dentro do diretório dev/

Precisamos criar a device nula, que é um tipo de arquivo especial, absolutamente
comum em ambiente unix. Esse arquivo especial deve ser criado com o comando mknod e
devem ser especificadas duas directivas, a "minor number" e "major number". Essas
informações são apresentadas no lugar das informações de size (tamanho) do arquivo.

A sintaxe para criação desse do dev/null, logado como superusuário (root) deve ser:

# mknod null c mi mj

Assim o mknod interpreta que o null deve ser criado (opcao "c") com os Minor Number
(mi) e Major Number (mj). Para descobrir esses valores, você deve usar o comando "ls -l
/dev/null" então, no lugar do tamanho do arquivo null, serão mostrados, respectivamente
os valores "mi" e "mj" do seu sistema. Agora você pode criar esse arquivo no seu ambiente
de chroot jail com os mesmos valores.

Esses valores, normalmente são 2 e 2 (2=mi e 2=mj). Se no seu FreeBSD esses valores
também forem esses, então basta digitar os comandos:

# cd /usr/named/dev/
# mknod null c 2 2

Ou alterar para os valores correspondentes. Ponto, seu dev/null do ambiente chrootado já

está pronto.

- Dentro do diretório etc/:

Deve conter os arquivos passwd, master.passwd, resolv.conf, group, pwd.db e spwd.db.
Os arquivos passwd e master.passwd devem conter apenas as informações para dois
usuários: bind e root

As informações devem estar exatamente como no sistema, mas deve-se alterar a senha
para "*" para evitar que ambos se loguem no sistema, e apontar a shell para um
interpretador de comandos não válido, como /sbin/nologin.

Para isso, digite, logado como root:

 # cp /etc/master.passwd /etc/passwd /usr/named/etc/

E agora edite ambos os arquivos, apagando os usuários que não queiramos e

modificando a senha e shell da forma que nós queremos:

# ee /usr/named/etc/passwd

Para editarmos, usando o easy editor. Remova todos os users, deixando apenas o root e
o bind e alterando sua shell para uma não válida.

# ee /usr/named/etc/master.passwd

Para editarmos, usando o easy editor. Remova todos os users, deixando apenas o root e
o bind e alterando sua shell para uma não válida e alterando sua senha para "*".

As linhas nesse arquivo devem ficar parecidas com as alterações que você deve ter feito,
usando o vipw, como citado no subcapítulo anterior.

Agora o arquivo resolv.conf; Também deve ser copiado do sistema, e não precisa ser
alterado, imaginando-se que seu servidor de nomes já esteja ativo. Se precisar configura-
lo ainda, leia esse capítulo desde o início. Então copiemos:

# cp /etc/resolv.conf /usr/named/etc/

O arquivo group contém as informações de grupos do sistema, e para o nosso ambiente

chrootado precisamos apenas que conste dois grupos, o grupo bind para o dono do
processo BIND, e o grupo sys.

Então, vamos copiar o arquivo group do sistema para o ambiente chrootado, e editar,
para apagar todos os grupos não necessários ao BIND:

# cp /etc/group /usr/named/etc

# ee /usr/named/etc/group

Agora edite o arquivo, com o easy editor, e delete todos os grupos existentes, deixando
apenas o sys e o bind

Finalmente, os arquivos pwd.db e spwd.db. Esses arquivos são os Data Base em

formato Hesh DB de Berkeley (comando "file /etc/spwd.db"), que contém as informações
sobre os usuários do sistema. Por isso as alterações não podem ser feitas diretamente nos
arquivos /etc/passwd, /etc/master.passwd do sistema, para que tenham efeito. Editar
esses arquivos manualmente é tão pouco viável, já que não são em formato ascii como os
passwd e master.passwd. Diferente de outros Unix, nos BSD Unix esses arquivos são os
que são lidos pelo sistema, e não simplesmente arquivos de texto.

Então vamos precisar que no nosso ambiente chrootado, esses arquivos também
existam, contudo, com informações apenas dos nossos dois únicos usuários, o root e o
bind.

Para criarmos esses Data Bases de informações dos usuários do sistema, devemos
usar o comando pwd_mkdb; Ele pode criar os arquivos spwd.db e pwd.db em qualquer
diretório, e a partir de qualquer passwd e master.passwd contanto que tenham um
formato válido, interpretável pelo pwd_mkdb.

Portanto, para criar os Data Bases no nosso diretório dentro do ambiente chrootado,
vamos usar o comando, logados como root, da seguinte forma:

# pwd_mkdb -d /usr/named/etc /usr/named/etc/master.passwd

A opção "-d" indica ao pwd_mkdb qual o diretório onde os Database Files serão criados,
e o próximo parâmetro indica a partir de qual arquivo essas informações devem ser
criadas.

Pronto, assim você evita que quando for rodar o bind em ambiente chrootado, o
sistema indique o usuário bind como usuário desconhecido.

- Dentro do diretório etc/namedb/:

Deve conter o arquivo named.conf exatamente como você está usando com o seu
BIND8.2x. Ou o named.conf com as directivas necessárias para a utilização do mesmo no
BIND9x. Mais informações sobre o BIND9 na sequência desse mesmo capítulo.

- Dentro do diretório usr/lib/:

Aqui, você deve colocar todos as as libraries (Bibliotecas) usadas pelo Servidor de
Nomes, o named (name daemon). O programa (binário) named faz uso de algumas
bibliotecas, de acordo com a versão do seu BIND e de acordo com o sistema operacional.

Para descobrir quais bibliotecas um arquivo binário precisa, você deve usar o comando
ldd.

No BIND9, no FreeBSD, a saída para o comando "ldd /usr/sbin/named" deve ser

parecida com:

named
lcrypto.1 => /usr/lib/libcrypto.so.1 (0x40181000)
lc_r.5 => /usr/lib/libc_r.so.5 (0x4022a000)
lc.5 => /usr/lib/libc.so.5

Então vamos copiar essas bibliotecas, para o nosso ambiente chrootado, que é onde o
named vai procura-las. Como root, digite:

# cp /usr/lib/libcrypto.so.1 /usr/named/usr/lib/
# cp /usr/lib/libc_r.so.5 /usr/named/usr/lib/libc_r.so.5
# cp /usr/lib/libc.so.5 /usr/named/usr/lib/libc.so.5

Lembre-se, essas bibliotecas com certeza serão outras, de acordo com a versão do seu
sistema operacional, versão do BIND e forma como você o compilou.

Copiadas as bibliotecas necessárias, você já eliminou a maior dependência de se rodar

o BIND em ambiente chrootado.

- Dentro do diretório usr/share/zoneinfo/America/:

Aqui, nós vamos precisar copiar o arquivo de informações de localização, para
assegurarmos a precisão de hora e data para que o BIND possa logar essas informações
com precisão. Normalmente dentro desse diretório existe apenas o arquivo de ZoneInfo da
região que o seu FreeBSD já está configurado... para saber qual (ou quais) esse(s)
arquivo(s), liste o conteúdo desse diretório, e os copie (ls /usr/share/zoneinfo/America/).

No caso da área ser São Paulo (meu caso), então eu vou precisar compiar o arquivo:

/usr/share/zoneinfo/America/Sao_Paulo

Para:

/usr/named/usr/share/zoneinfo/America/Sao_Paulo

Faça o mesmo, de acordo com o seu sistema.

- Dentro do diretório usr/sbin/:

Você deve copiar o programa named. O binário responsável pelo serviço de nomes.
Você deve copiar esse programa a partir do diretório onde você acabou de compila-lo, ou a
partir do local que você esteja usando. Normalmente o caminho é /usr/sbin/named.

Para descobrir onde está o binário named, use o comando: 'whereis named'
E então copie-o para /usr/named/usr/sbin/

- Dentro do diretório usr/libexec/:

Aqui deve ficar a biblioteca que interpreta arquivos binários. Dependendo do sistema
operacional, essa biblioteca também fica no diretório /usr/lib junto às outras bibliotecas
que constituem dependência do named. No FreeBSD a biblioteca que interpreta binários,
a "ld.so" é a biblioteca "ld-elf.so.1". E o caminho dela é este.

Portanto, vamos copiar essa biblioteca pra dentro do ambiente seguro (chroot()
enviroment):

# cp /usr/libexec/ld-elf.so.1 /usr/named/usr/libexec/

- Dentro dos diretórios bin/ e sbin/:

Aqui devem constar os interpretadores de comandos não válidos. Caso você tenha
apontado seus usuários bind e root para ter uma shell não válida, e esta tenha sido
/sbin/nologin como indicada, ou /bin/false que é muito usada, então esses arquivos
devem constar no ambiente chrootado. Portanto crie ou copie o nologin ou o false para
seus respectivos diretórios.

Em alguns sistemas operacionais, você vai ter que criar o etc/shells e constar a
existencias dessas shells falsas nesse arquivo. No FreeBSD não foi preciso.

- Dentro do diretório info/:

No BIND8x não vai ter conteúdo, e pode ser descartado. No BIND9x é usado para
armazenar logs de informações, de acordo com as regras de logging{} que nós criemos.

Em síntese, o conteúdo usual do ambiente CHRootado, depois de criado e com os

respectivos arquivos copiados ou criados, deve ser parecido com a seguinte árvore:

------ CHRoot Enviroment - Eksffa------------

------ Árvore básica de exemplo ------------
/usr/named: chroot('/')

/dev/
null

/etc/namedb/
named.conf

/etc/
group
master.passwd
passwd
pwd.db
resolv.conf
spwd.db

/usr/lib/
libc.so.5
libc_r.so.5
libcrypto.so.1

/usr/share/zoneinfo/America/
Sao_Paulo

/usr/sbin/
named

/usr/libexec/
ld-elf.so.1

/bin/
false

/info/

Vale lembrar que, de acordo com a versão do BIND, você pode precisar criar outros
diretórios e arquivos, mas esses podem ser facilmente descobertos, ao ler os logs de
provaveis erros, no syslogd ou do daemon. No BIND9x é ainda mais fácil, acionando-se a
opção de debug (-g).

Finalmente, vamos definir o verdadeiro dono pro nosso ambiente seguro:

# chown -R bind.bind /usr/named

6.4 CHRootando o BIND.

Finalmente, vamos colocar o BIND rodando no nosso ambiente aprisionado. Agora que
você já satisfez todas as dependências de estrutura de arquivos e usuário, já podemos
assegurar nosso servidor de nomes.
 Para criar um ambiente de CHroot Jail, no FreeBSD você tem o comando chroot, que
utiliza a função chroot() implementada a nível de Kernel. Para aprender como usar esse
comando com mais detalhes, utilize o manual online:

# man chroot

Mas a sintaxe básica para a utilização do chroot com o BIND, deve ser:

# chroot /var/named /usr/sbin/named -u bind -g bind

No BIND 8x, onde ainda é necessário apontar o grupo, além de usuário, com a
directiva '-g'.

Ou:

# chroot /var/named /usr/sbin/named -u bind -g

No BIND9x, onde apenas o usuário deve ser indicado, e a opção -g habilita o debug-
mode, para se poder analizar erros, e não lança o processo como background.

Mas...

O named, desde as mais recentes versões da série 8 e obviamente na série 9, já vem

com uma opção que invoca a função chroot() do sistema operacional, para que você possa
automatizar o processo de lançar o BIND em ambiente CHRootado. Essa opção faz a
mesma coisa que a opção "-u" que lança a função setuid() do sistema operacional,
alterando o ID do usuário dono do processo, tão logo esse seja posto em execussão.

Essas opções são não viaveis em alguns Linux. O Kernel que você costuma encontrar
esse tipo de incapacidade estão listados no manual online do named (man named).

Felizmente nós estamos trabalhando com BSD Unix.

Para iniciar o named lançando-o em ambiente chrootado e com usuário não privilegiado,
devemos então inicia-lo da seguinte forma:

# /usr/named/usr/sbin/named -t /usr/named -u bind -g bind

No BIND8x, a opção "-t" lança o processo em ambiente chrootado (Troggle chroot()

directory), a opção -u e -g respectivamente fazem o named ser executado com o grupo de
usuário definido.

# /usr/named/usr/sbin/named -t /usr/named -u bind

No BIND9x, a opção "-t" (Troggle chroot() directory) é a mesma, contudo apenas a opção
"-u" deve ser usada para definir qual usuário deve ser o dono do processo. Nessa versão
do BIND, a opção "-g" inicia o Debug Mode, e mantém o processo em foreground.

Pronto, agora sim você já deve estar rodando o seu BIND em ambiente seguro. Se algo
der errado, você pode acompanhar pelos logs que você está acostumado, no BIND8, ou
pelo Debug Mode no BIND9, e descobrir qual foi o erro ou o que faltou no seu ambiente
seguro.
 Agora, devemos automatizar esse processo, no FreeBSD.
Para isso, vamos editar o arquivo /etc/rc.conf
Nesse arquivo, você deve alterar ou criar (caso não existam) as seguintes linhas:

named_enable="YES"
named_program="/usr/named/usr/sbin/named"
named_flags="-t /usr/named -u bind"

Agora você já avisou como o FreeBSD deve iniciar o named, quando necessário. Caso
você costume fazer alterações constantes no seu servidor de nomes e vai ser duro se
acostumar com ficar digitando "/usr/named/usr/sbin/named" toda vez que você quizer
chamar o processo, crie um symlink (link simbólico) apontando o /usr/sbin/named para
o named do seu ambiente seguro: /usr/sbin/named -> /usr/named/usr/sbin/named ;}

Última dica básica: consideramos que os seus arquivos de zona e de reveso já estivesse
no diretório /usr/named, que é onde eles foram indicados à serem criados ao longo desse
capítulo. Se esse não é o seu caso, copie os arquivos ou crie a estrutura de diretórios do
ambiente chrootado de acordo com a sua preferência.

E finalmente, se a localização desses mesmos arquivos de zona e reverso serão o

diretório onde o ambiente seguro foi criado, como no caso abordado durante toda a
documentação, então a opção directory{} dentro do named.conf deve apontar para "/" e
não mais para "/usr/named" como em ambiente não chrootado:

options {
directory "/";
query-source address * port 53;
};

Em alguns casos, o syslogd não vai mais conseguir logar as ações do bind, devido ao
fato do /dev/log não existir no ambiente chrootado. Como solução, devemos indicar ao
syslogd para criar um unix sock em /dev/log com a opção "-a"; Comando: "syslogd -a
/usr/named", estando logado como root.

Feitas essas ressalvas, você está pronto pra configurar seu próprio ambiente chroot()
para o BIND. Preparados da forma como melhor lhe convier. Se quiser, pode até apagar o
diretório /etc/namedb no sistema, visto que agora você vai usar somente o ambiente
chrootado. Mantenha um BACKUP atualizado sempre.

6.5 Configurando um SLAVE NameServer em ambiente CHRootado.

Muitas vezes, alguns administradores conseguem até rodar o BIND CHRootado,

seguindo esse tipo de instrução passo-a-passo. Contudo, algumas vezes eles encontram
problemas simples, mas por falta de experiência não conseguem assimilar o
funcionamento do ambiente ou não sabem quais arquivos estão faltando.

Esse tipo de incoerência acontece quando o atual servidor de nomes, é implementado

para ser servidor de nomes secundário para outras zonas, além de primário para algumas.
Para evitar esse tipo de problema, vamos fazer uma breve análise do que deve ser alterado
no nosso ambiente chrootado, caso o servidor de nomes exerça também papel de Slave
NameServer.
 Um servidor de nomes secundário (bind8), usa o binário named-xfer para prover a
transferência e atualização de seus dados, em relação ao servidor principal (master). Da
mesma forma que o named, o programa named-xfer também deve fazer parte da estrutura
do nosso ambiente chrootado.

Normalmente, no FreeBSD, o named-xfer é encontrado em /usr/libexec/named-xfer e

é esse o caminho também que ele deve ser localizado, no nosso Chroot Jail. Então copie o
programa de onde quer que você tenha compilado-o, ou do local original no sistema, para
o ambiente chroot():

# cp /usr/libexec/named-xfer /usr/named/usr/libexec/

Da mesma forma, o named-xfer também depende de algumas bibliotecas. Depende

também da versão do BIND e da versão do sistema operacional, exatamente como no caso
do named, e a forma de se descobrir quais as dependências é a mesma: utilizando o
comando ldd.

Então, para descobrir quais as bibliotecas requeridas pelo named-xfer, digite:

# ldd /usr/named/usr/libexec/named-xfer

A saída desse comando, no FreeBSD deve ser parecida com:

# ldd /usr/libexec/named-xfer
libc.so.4 => /usr/lib/libc.so.4 (0x2809c000)
lcrypto.1 => /usr/lib/libcrypto.so.1 (0x40181000)

Então, repita o procedimento, e copie as bibliotecas necessárias para satisfazer as

dependências do named-xfer, caso elas ainda não existam no nosso ambiente seguro:

# cp /usr/lib/libc.so.4 /usr/lib/libcrypto.so.1 /usr/named/usr/lib

Agora as dependências para a execussão do named-xfer já foram cumpridas. É

necessário apenas ser atencioso a alguns detalhes. Alguns sistemas operacionais e
versões do BIND precisam que exista o arquivo /etc/ld.so.conf. Não é o caso do FreeBSD,
mas se for necessário crie esse arquivo, vazio mesmo, com o comando "touch
/usr/named/etc/ld.so.conf".

Outro detalhe, esse um pouco menos banal. Diferente do named, o programa named-
xfer não faz apenas leituras nos nossos arquivos de zona e de reversos. Por ser o servidor
secundário, quando as informações primárias são atualizadas, ele precisa também
atualizar os DB's (databases) de informações secundárias, ou seja, temos então que
garantir permissão de escrita (write) nos arquivos que o servidor de nome terá que
atualizar. Os DB de zonas secundárias. Para isso, garanta os modos 755 para que o dono
dos arquivos (bind) possa ter totais permissões nos arquivos que forem zonas
secundárias:

# chmod 755 /usr/named/todas_as_zonas_secundarias.db

# chown -R bind.bind /usr/named
 Lembrando que estamos assumindo também, para o servidor de nomes secundário,
que o diretório /usr/named seja o diretório escolhido para ser o ambiente onde você vai
aplicar o chroot enviroment.

Feitas essas alterações, você já pode garantir a execussão do seu servidor de nomes
secundário, também em ambiente seguro. Qualquer erro pode facilmente ser descoberto,
analizando-se os logs usuais, os quais você já esta acostumado, e serem corrigidos.

7. BIND9x - Configuração e Introdução ás novas funções.

O BIND (Berkeley Internet Name Domain) é o software responsável pelo serviço de

nomes no mundo, quase que em sua total maioria. Atualmente o desenvolvimento desse
software está sob responsabilidade do ISC (Internet Software Consortium), e desde as
últimas versões do BIND8 até as novas versões do BIND9, o ISC já proveu diversas
melhorias no software. Contudo, o BIND, usado inclusive nos Root Name Servers, em sua
versão 8 mais recente, vem enfrentado diversas explorações, por parte de grupos de
usuários mal intencionados.

Essas explorações são sempre rapidamente corrigidas, mas não são tão rapidamente
atualizadas pelos administradores de sistemas, visto que a grande maioria não é ligada a
Security Advisories, ou em casos mais comuns, esses administradores tem funções
distintas dentro de uma empresa, e não são somente administradores do sistema,
resultando em uma falta de tempo iminente para cuidar de atualizações e correções de
software.

A forma como o BIND foi escrito até a série 8, é a principal razão dessas explorações.
Agora o BIND foi reescrito, em sua versão 9, e além da tendência a menor exploração e
abuso de seus serviços, o BIND9 incorporou diversas novas características, tanto
relacionadas à segurança do serviço, quanto à eficiência e maiores possibilidades de
configuração no servidor de nomes.

O Desenvolvimento da versão 9 do Servidor de Nomes de Berkeley foi dirigido pelo

Internet Software Consortium (www.ISC.org) e foi feito em conjunto com várias
organizações, que tem considerável e reconhecido "technical improvement" (digamos assim)
no ambiente computacional. Essas organizações são:

- Sun Microsystems, Inc. (http://www.sun.com/);

- Hewlett Packard (http://www.hp.com/);
- Compaq Computer Corporation (http://www.compaq.com/);
- IBM (http://www.ibm.com/);
- Process Software Corporation (http://www.process.com/);
- Silicon Graphics, Inc. (http://www.sgi.com/);
- Network Associates, Inc. (http://www.nai.com/);
- U.S. Defense Information Systems Agency (http://www.disa.mil/);
- USENIX Association (http://www.usenix.org/);
- Stichting NLNet - NLNet Foundation (http://www.nlnet.nl/).

7.1 Principais características do BIND9

O BIND9 é uma transcrição, onde todas as principais funções e características do

BIND foram reescritas, além de adicionadas novas funções e serviços. Toda a declaração
de autoridade sobre nomes, toda a arquitetura hierárquica de domínios e zonas, assim
como formas de cacheamento e transferência de zonas, presentes e melhoradas em todas
as versões anteriores do BIND foram mantidas e reescritas, e estão em constantes
melhorias.

Outras novas características de serviços foram implementadas, incluindo suportes

anteriormente não existentes, novos conceitos e funções de segurança, maior
escalabilidade e outras mudanças, como:

- Segurança no DNS:
DNSSEC (zonas autoritativamente assinadas);
TSIG (transações DNS assinadas) ;

- IPv6, Protocolo IP versão 6, próxima geração:

Responde por DNS utilizando unix sockets IPv6;
Resource Records (RRs) para IPv6: A6, DNAME, etc.;
Origens de Bitstring (ip6.arpa) para alocação dos bits;
Bibliotecas Experimentais de Resolução IPv6;

- Novas Características no protocolo de DNS:

IXFR, DDNS, Notify, EDNS0;
Conformidade comprovada de padronização;

- Views
Um processo do servidor pode diferenciar tipos distintos de "visões" (as views) das
informações de nomes, podendo dividir uma "visão interna" de nomes para alguns clientes,
e outra "visão externa" de nomes para outros clientes.

- Suporte a Multiprocessamento.
- Arquitetura comprovadamente portável.

Na nova versão 9.2 do BIND, ainda foram incluídas outras alterações:

- O tamanho do cache agora, pode ser limitado, usando a opção "max-cache-size";
- O servidor agora converte automaticamente as requisições recursivas do tipo RFC1886
em recurssões do tipo RFC2874, o que permite que os resolvers que utilizam as novas
funções IPv6 sejam respondidos por resolvers antigos, que trabalham apenas com
entradas AAAA (IPv4);
- O programa rndc agora tem a opção status, e o mesmo tem sua configuração automatica
agora;
- Outras alterações de menor importância, que melhoram o desenpenho do servidor de
nomes.

7.2 O que é necessário para configurar ou migrar para o BIND9?

A Finalidade desse capítulo 7 é orientar o administrador durante o processo de

migração do seu servidor de nomes, ou orientar a configuração a partir do ponto inicial.
Contudo, é extremamente importante e recomendada a leitura prévia dos capítulos 5 e 6
dessa documentação. Os conceitos de serviço de nomes, tipos de zonas e de serviços,
assim como uma configuração mais detalhada das zonas e domínios foram amplamente
explanadas nos dois capítulos anteriores, e portanto não serão revistas aqui.
 Para utilizar o servidor de nomes BIND9, é necessário uma configuração mínima de
hardware, que pode ser um computador com processor 386/486, e uma quantidade
mínima de memória, para poder cachear as informações necessárias, ainda que somente
as informações de zonas autoritativas.

A configuração básica indicada é o sulficiente pra responder por zonas estáticas de

forma autoritativa, sem um cacheamento grande de informações de nomes. O BIND9,
contudo, é escrito para poder responder por milhares de requisições de nomes por
segundo, cacheadas e/ou autoritativas. O poder de processamento e de memória deve ser
relativo a forma como você quer usar seu servidor de nomes. De forma geral o BIND9
provê uma melhor utilização dos recursos, se comparado à série 8 do mesmo software.

O BIND9 agora é arquitetado multithread e suporta multiprocessamento simétrico, ou

seja, é ideal para servir nomes em servidores com dois ou mais processadores. Os
sistemas operacionais suportados, são a maioria dos Unix, e os indicados são IBM-AIX,
Compaq Tru64 Unix,FreeBSD 3.4, 3.5, 4.0, 4.1 e -STABLEs, NetBSD 1.5, HP-UX 11, IRIX64
6.5, Red Hat Linux 6, 6.1, 6.2 e 7, e Solaris 2.6, 7 e 8. E são bem utilizados também em
outros sistemas operacionais, apesar de não serem oficialmente suportados.

7.2.1 Compilando o servidor de nomes BIND9x

O BIND9 assim como o BIND8 é distribuído em forma binária e em código fonte. O

formato binário, normalmente é distribuído de acordo com o fabricante e mantenedor do
sistema operacional, já o código fonte, pronto para ser construído, pode ser encontrado,
via FTP anônimo, no servidor do Internet Service Consortium: ftp.isc.org/isc/bind9/

Hoje, a versão mais recente é o BIND 9.2 Alfa, disponível em:

ftp://ftp.isc.org/isc/bind9/9.2.0a2/bind-9.2.0a2.tar.gz

e com sua assinatura digital, disponível em:

ftp://ftp.isc.org/isc/bind9/9.2.0a2/bind-9.2.0a2.tar.gz.asc

Pro FreeBSD, o binário disponível hoje, é a versão 9.1.3 do BIND, disponível em:

ftp://ftp5.freebsd.org/pub/FreeBSD/ports/i386/packages-4.3-stable/All/bind-
9.1.3rc1.tgz

Esses mesmos arquivos (exceto os binários), assim como as versões mais recentes do
BIND9 também estarão sempre disponíveis no mirror brasileiro da ISC, servido pela pop-
mg.com.br no endereço:

ftp://ftp.pop-mg.com.br/pub/isc/bind9/

Os pacotes disponíveis nesse endereço, já oferecem todo o conjunto de software BIND,

incluindo o daemon servidor de nomes, o named, todos os programas e os softwares
resolver. Assim como a biblioteca de critpografia openssl .As instruções de compilação da
documentação do BIND9 diz que, para construir o BIND a partir desse fonte, basta
executar o script configure e depois dar um make.
 Mas vamos antes fazer uma pequena consideração: As características de segurança,
DNSSEC e TSIG utilizam as bibliotecas de criptografia OpenSSL. Essas bibliotecas já
estão inclusas junto do pacote disponível nos endereços citados acima, contudo, é
recomendado que essa biblioteca seja instalada separadamente, especialmente em
ambientes que já utilizem a critpografia OpenSSL. Felizmente esse é o caso do FreeBSD.

Normalmente, você já deve ter a OpenSSL instalada e em uso no seu FreeBSD. Para
instala-la, você pode fazer via PORTS, via pkg_add ou pelo fonte, disponível em
www.openssl.org. Informações sobre como instalar software pelo ports ou com pkg_add
disponíveis nos capítulos anteriores dessa documentação.

A configuração da biblioteca OpenSSL externa, deve ser feita de forma automatizada

pelo BIND9. O script configure da conta dessa tarefa. Para ter acesso a todas as
informações que você pode passar para o configure digite ./configure --help.

No nosso caso, só nos interessam duas opções:

./configure --with-openssl=PATH
./configure --sysconfdir=PATH

Essas são as opções para indicar o caminho da biblioteca OpenSSL e para indicar qual
será o diretório de configuração do BIND9. O padrão para essa última opção, se não
alterada, é /etc/, mas como no FreeBSD o padrão é /etc/namedb e nosso capítulo de
configuração do servidor de nomes e capítulo de Chroot Enviroment tratou do caminho
padrão no FreeBSD, e sendo o FreeBSD nosso sistema operacional For Choice, vamos
optar pelo nosso /etc/namedb/.

Agora, começarmos a compilar o servidor de nomes, basta sabermos onde estão os

arquivos das bibliotecas OpenSSL. Se você instalou recentemente, deve-se lembrar do
caminho, senão basta procurar, com um find / -name "*openssl*"

Normalmente o caminho da OpenSSL no FreeBSD é /usr/include/openssl.

Possívelmente no seu FreeBSD deve ser esse mesmo caminho padrão. Então para
configurar o BIND, vamos usar o comando:

# cd bind-9.2xx/
# ./configure --with-openssl=/usr/include/openssl --sysconfdir=/etc/namedb

Agora sim, ao final das verificações e dos ajustes de configuração, o BIND9 já está
pronto pra ser compilado:

# make

É de prache recomendarmos que você tenha sempre um backup consistente e

atualizado dos arquivos mais importantes do seu sistema, e isso sempre inclui todos os
seus arquivos do servidor de nomes. Agora, por segurança, faça uma cópia também, além
dos arquivos de configuração, de zonas e reversos usuais, dos binários também,
especialmente os programas nslookup, named, named-xfer e outros que julgar
necessários.

Agora você pode acabar a instalação do seu BIND9. Logado como root, digite:

# make install
 Pronto, todos os programas já foram compilados e construidos, e estão acima do
diretório bin/ dentro do seu diretório de instalação do bind9. Normalmente parecido com
~/bind-9.xxx/bin/. Você pode copiar os programas ou criar links simbólicos, para onde
quer que você ache necessário, lembrando sempre que é ideal que esses programas
estejam no path do seu interpretador de comandos (shell), assim como as man pages
(páginas de manual online) também, criadas no diretório man/ do BIND9.

7.3 Configuração do BIND9 NameServer.

Agora vamos tratar de alguns exemplos e indicações para configuração de um servidor

de nomes, utilizando o BIND9. A maior parte das opções principais são equivalentes à
forma como eram aplicadas na versão 8 do BIND, e foram profundamente explicadas no
Capítulo 5 desse documento. As novas opções e/ou diferenças de sintaxe serão abordadas
aqui, sempre que as directivas a façam necessárias. Conhecimento básico do Capítulo 5 é
recomendado.

Já temos então todos os arquivos e programas do bind9 instalados. Então é hora de

começarmos a configurar o nosso servidor de nomes. O Primeiro arquivo a ser
configurado, exatamente como no bind8 é o arquivo named.conf, que deve estar localizado
onde nós mandamos ele ser compilado, com a opção --sysconfdir=PATH do configure.
Portanto no nosso caso, nos servidores FreeBSD, o diretório é o /etc/namedb/named.conf

O arquivo named.conf é o arquivo que mais ganhou novas opções, exatamente por ser o
arquivo mais importante para o servidor de nomes. Vamos então dar uma ênfase especial
nessas novas mudanças, e entendermos a utilização de todas as novas opções.

Lembrando que, para os nossos exemplos, vamos manter a configuração-exemplo

adotada no Capítulo 5:

Domínio: eeviac.com.br
Servidor Primário: eeviacbsd.eeviac.com.br
Servidor Secundário: xffa.eeviac.com.br
Segundo Secundário: corduroy.eeviac.com.br
Faixa de IPs da Rede: 200.230.200.0 até 200.230.200.63
Portanto Máscara: 255.255.255.192

7.4 named.conf no BIND9

No BIND9, as opções para o arquivo named.conf foram divididas em várias séries de

instruções distintas, com diferentes funções cada uma. As instruções existes hoje são:

- ACL: Definem uma série de lista de controles de acesso, baseadas em

endereço IP, para controle de nomes e outras utilizações.

- Controls: Define canais de controles, que devem ser usados junto ao

programa rndc que faz parte dos softwares contidos no novo BIND.

- Include: Directiva para inclusão de um arquivo.

- Key: Especifica uma chave, para ser usada nas Autenticações e Autorizações,
quando estivermos usando TSIG
 - Logging: Especifica que tipo de informação o servidor de nomes deve logar, e
para onde essas informações (e de que forma) devem ser logadas.

- Options: Controla todas as informações que o servidor de nomes vai prover.

Define como essas informações serão buscadas pelo BIND, e também cria informações
padrão para outras opções.

- Server: Permite ajustar uma série de configurações, baseadas nas

informações definidas de servidor por servidor.

- Trusted Keys: Define as chaves de acesso que o DNSSEC vai confiar.

- View: Define uma view, tipos de visões distintas de resolução de nomes, de

acordo com os clientes.

- Zone: Define uma zona. Zonas são as principais informações que um

servidor de nomes vai tratar, quando for configurando para ser servidor autoritativo de
determinados domínios (ou zonas).

7.4.1 Instruções ACL

As instruções ACL tem o objetivo de separarmos zonas de endereçamento IP específicas,

e fazer referências a essas zonas, sejam elas quantas forem, utilizando assim um nome
que nós definamos, e não mais uma série de endereços IPs ou de redes. Permite agrupar
definições de endereçamento IP por lista de acesso.

Por padrão, o BIND9 já traz algumas ACLs built-in, para facilitar o uso. São elas:
- any: Absolutamente todas as máquinas (hosts) de todas as redes;
- none: Nenhuma máquina (hosts) de nenhuma rede (net).
- localhosts: Todos os endereços IPs atribuídos às interfaces locais. Por
exemplo, interface de loopback lo0: 127.0.0.1; Interface ethernet xl0(placa de rede):
200.230.200.10 (exemplo).
- localnets: Toda a rede, a qual a máquia faz parte. Definida pelo endereço
atribuído a ela, e pelo endereço de broadcast ou máscara de subrede, no sistema
operacional.

Exemplo de Criação de ACLs:

acl internas {
192.168.0.0/24;
192.168.1.0/24;
192.168.2.0/24;
};

Nesse exemplo, nós criamos a ACL chamada internas, fazendo referência a nossas
redes internas. Definimos que internas agora quer dizer nossas 3 redes de intranet.
Sempre que o BIND9 se deparar com a palavra de controle 'internas', ele vai saber que
estamos falando dessas 3 redes definidas acima. Máscara /24 indica 24 bits, ou seja, a
rede inteira.

acl secundarios {
200.230.200.9/32;
 200.230.200.11/32;
};

Agora definimos que, sempre que dissermos secundários, o BIND deve interpretar como
sendo nossos servidores secundários, os dois endereços IPs que fazem parte da nossa
ACL. A máscara indica 32 bits, ou seja, é um host único.

acl nonsenseisp {
200.205.2.0/24;
200.205.3.0/24;
};

Essa ACL define que as duas redes (24 bits) nessa definição, devem ser compreendidas
sempre que mencionarmos a a expressão nonsenseisp. Caso você encontre algum ISP que
sempre mantém problemas como lamme delegations ou qualquer outra má configuração
nonsense ;}

Lembre-se que, os nomes para as ACLs e o conteúdo das mesmas são definidos
exclusivamente por você, nonsenseisp por exemplos é um tipo de expressão que não quer
dizer muita coisa, e deve ser compreendido apelas pelo administrador que criou essa ACL.

7.4.2 Instrução Controls:

Essa série de instruções tem a função de declarar canais de controle, a serem

utilizados junto ao programa rndc. O uso do rndc vai ser abordado ao decorrer desse
documento. Essas instruções permitem que se abra um socket TCP/IP comum à Internet,
criado na porta 'ip_port' em questão, no endereço 'ip_addr' declarado. Se não for declarada
uma porta em especial, a porta 953 é usada por padrão. A chave "*" pode ser usada, para
espeficiar todas as interfaces locais, contudo não pode ser usada para substituir a
declaração de uma porta específica.

A possibilidade de suprir comandos, utilizando o rndc através de um canal de controle,

só pode ser realizada quando as regras de permissão e de chave são equivalentes, e
consequentemente validadas. Os hosts que não tem permissão de acesso (allow) são
posteriormente ignorados, se a chave de indetificação (key) for conhecida, passando a
ordem de tratamento de controle apenas para as chaves. Essas chaves são então usadas
para autenticar todos os comandos e respostas de comandos, durante a transação,
criando assim uma assinatura digital entre os dois lados.

A sintaxe comum para utilização de um canal de controle é:

controls {
inet ( ip_addr | * ) ( port 'ip_port' ) allow endereços_permitidos
keys lista_de_chaves_permitidas;
inet [...];
};

Exemplo de criação de canais de controle:

Nos endereços permitidos, pode ser especificada uma ACL previamente declarada.
Vejamos o exemplo a seguir:
 controls {
inet 200.230.200.10
allow {
localhost;
internas;
}

keys {
chaves_rndc;
chaves_privadas;
}
};

Com essa regra, abrimos um canal de controle, na porta padrão (953) da interface
externa do servidor (endereço IP 200.230.200.10) e demos permissões para acesso nesse
canal de controle para localhost e para internas onde a segunda é uma ACL previamente
declarada no nosso arquivo de configurações. Definimos também duas chaves, as
chaves_rndc e chaves_privadas para serem as nossas atribuições de assinatura digital,
pra segurança das transações DNS.

As chaves usadas foram previamente criadas. Veja Instrução Keys. A sintaxe de canais
de controle não é mais compativel com as implementadas na série 8 do BIND.

7.4.3 Instrução Keys;

A instrução keys é usada para se criar assinaturas digitais durante as transações DNS,
ou seja, é a característica principal da nova função 'TSIG' do BIND9. A declaração dessa
chave é definida por um nome de chave, chamado também de key_id, seguido de um tipo
de algorítmo a ser seguido, e finalmente a chave, propriamente dita. Atualmente apenas o
algorítmo hmac-md5 é suportado para a autenticação TSIG.

A sintaxe para criação de Keys é:

key key_id {
algorithm algorítmo;
secret chave;
};

Exemplo de criação de chaves TSIG:

key servidores-externos {
algorithm hmac-md5;
secret "lZ12asdDfWwqqertTtys";
};

Foi criada então, uma chave de assinatura digital, com o nome servidores-externos. A
utilização dessa chave deve ser feita junto da instrução server, no arquivo de configuração
do BIND. Você vai ver mais detalhes na seção que aborda as Assinaturas de Transações
(Transaction SIGnatures, TSIGs) a seguir.

7.4.4 Instrução Include;

 As instruções include são simples e comumente usadas em arquivos de configurações
de aplicações específicas, como aplicações php, portanto já são conhecidas. A função
dessa instrução é simplesmente chamar um determinado arquivo, no ponto em que a
instrução é lida pelo arquivo de configurações. Por segurança, pode ser usado, por
exemplo, para chamar sequências de bits de base 64, e interpretadas com keys.

A sintaxe é simples:

include arquivo;

Um exeplo: A chave no exemplo acima, servidores-externos. Se ela estivesse dentro de um

arquivo externo, com o nome servidores-externos.key (como exemplo...), poderia ser
chamada com o comando:

include servidores-externos.key;

Dentro do arquivo de configurações do BIND9.

7.4.5 Instrução Logging;

As instruções logging implementam uma amplas possibilidades de logar os eventos no

servidor de nomes. Essa instrução, assim como a instrução options só pode ser usada
uma única vez, no arquivo de configurações do BIND. A função do logging é definir várias
classes e formas de se logar as atividades no BIND, assim como os níveis de importância
(severity) dessas informações. Essas instruções de logging são chamadas de canais de
logs ou logging channels. As formas de se logar tais informações podem ser, em arquivo
(file) ou utilizando um daemon de logs locais, como o syslogd.

Essa é uma das mais importantes e funcionais novidades do BIND9. Nessa nova versão,
as definições de logs apenas passam a funcionar quando o parsing de toda a declaração
das regras de logs são lidas, ou seja, apenas quando o BIND termina de ler as instruções
de logging é que o log começa a ser gravado. Até isso acontecer, as mensagens são
enviadas normalmente ao daemon de logs do sistema. Em casos extremos, para se
solucionar problemas deve-se usar a opção "-g" para iniciar o BIND. Essa opção inicia o
named em foreground e com o nível alto de debug para a saída de informações.

São utilizadas duas especificações de chamadas junto à instrução logging. Elas são
chamadas de "channel" e de "category".

Veja a sintaxe básica da instrução Logging:

logging {
channel {};
category{};
};

Onde as possibilidades de instruções são definidas da seguinte forma:

logging {
channel "nome_do_canal" {
file "path(caminho)";
 versions número_específico OU unlimited};
size tamanho;

syslog opção_syslog;
null;

severity critical | error | warning | notice | info | debug (nível) | dynamic;

print-category yes|no;
print-severity yes|no;
print-time yes|no;
};
category nome_da_categoria {
nome_do_canal1;
nome_do_canal2;
nome_do_canalX;
...
};
};

7.4.5.1 Especificação channel{};

Todas as espeficicações de logs tem sua saída definida em um ou mais canais de log,
chamados de channels. Você pode criar quantos canais quizer, para separar suas
definições de logs. Você vai indicar onde os logs serão armazenados, e de que forma, se
em forma de arquivo comum, ou um log criado por um daemon específico para isso. Ao
usar o Syslog a opção "local3" é comumente atribúida para informar o BIND da utilização
do daemon. Você vai também indicar o nível de informação que será logada, utilizando a
opção severity. Quando um nível não é aplicado, o padrão é a utilização do nível info.

A espeficiação null quando aplicada à um canal de logging, indica ao BIND para

destruir aquelas informações, sem grava-las em lugar algum.

A especificação file indica ao BIND para gravar todas as informações de acordo com o
nível definido no severity em um arquivo de texto, especificado no caminho dado. Em
ambientes seguros, utilizando ambiente chrootado, é recomendado uma definição
parecida com file info/tipo_de_log.log como foi tratado no nosso capítulo anterior. Esse
tipo de arquivo ainda pode ser controlado, pelo BIND, controlando que tamanho máximo
esse arquivo pode alcançar, e quantas versões do mesmo poderão existir. A opção size
define o tamanho máximo que esse arquivo vai ter. E a opção versions define quantos
arquivos de logs poderão automaticamente ser criados. Por exemplo, se você definir
versions 2; vão sempre existir os arquivos arquivo.log e arquivo.log.0 balanceados com o
tamanho especificado em size.

Se você espeficiar syslog como destino dos logs, então o sistema vai usar o syslogd
para prover todos os logs necessários, conforme especificados por severity. Contudo, é
requerido uma opção_do_syslog que define a forma como o syslogd vai logar essas
informações. A opção normalmente usada é a "local3". Para conhecer as outras opções
existentes, leia a man-page do syslogd (comando man syslog) ou os cometários no seu
arquivo "/etc/syslog.conf".
 A opção severity indica um nível de "prioridade" que definirá os tipos de informações
que serão lançadas como saída de log pelo BIND. Os níveis de prioridade existentes são:
critical | error | warning | notice | info | debug (nível) | dynamic que só pelo nome já dão
uma noção correta do tipo de informações que são logadas. A prioridade debug inicia o
servidor de nomes com a opção "-d <número inteiro>" onde o <número inteiro> em
questão é o nível de debug. Essa opção é diferente da opção "-g", especialmente por definir
um nível de informação e por não manter o processo em foreground. Já a opção dynamic
utiliza a nível de syslog as prioridades que já estão sendo usadas pelo sistema.

As outras possibilidades, por analogia, são facilmente compreendidas. Se necessário

uma descrição desses níveis de prioridades pode ser obtida na man-page do BIND ou do
NAMED (man bind ; man named).

7.4.5.2 Especificação category{};

São as categorias de logging do BIND9. A utilização dessa categoria pode ser feita de
duas formas, a primeira é utilizar categorias como agrupamentos de canais de logs. Dessa
forma, você pode criar um nome para uma categoria, e dizer que aquela categoria conterá
as informações dos vários canais de logs que você criou com a função channel{}; e usar
essa definição posteriormente.

E a outra forma de utilização, a ideal, é utilizar as categorias de logs existentes no

BIND9. As categorias mantém informações sobre segurança, transferência de zonas, e
outros tipos de informações. Por exemplo, se declararmos a categoria category "security"
{ "canal_seguranca"; }; vamos estar indicando ao BIND que queremos que ele logue todas
as informações relativas a segurança no canal canal_seguranca que possivelmente
declaramos com a especificação channel{}.

As categorias existentes são:

- default: é a definição de categoria padrão, que é utilizada quando não são definidas
categorias para um canal de log. É similar ao local3 do syslogd em níveis generalizados de
informações.

- general: é um amontoado 'geralzão' de informações. A documentação do BIND9 diz

que, é onde foi colocada todas as informações que ainda não foram divididas em
categorias específicas. São informações genéricas.

- database: são informações referentes as dbs internas, utilizadas pelo named para
controlar a autoridade sobre zonas, reversos e dados de cacheamento.

- security: informações de Negação ou Permissão de requisições sobre informações

feitas ao BIND.

- config: loga problemas e sucesso relacionado a leitura do arquivo de configurações. É

onde são armazenados os problemas de erro de sintaxe, por exemplo.

-resolver: resolução do serviço de nomes. São logadas informações sobre a resolução

de nomes, solicitadas por determinada requisição de algum cliente, como informações
recursivas feitas normalmente por servidores de cache (os caching name servers).
 - xfer-in: loga informações sobre a transferência de zonas que o servidor está
recebendo.

- xfer-out: loga informações sobre a transferência de zonas que o servidor está

enviando.

- notify: informações referentes ao protocolo NOTIFY do BIND.

- client: loga informações referentes ao processamento de requisições feitas pelos

clientes.

- network: loga atividade de operações na rede, em relação ao servidor de nomes.

- updates: informações sobre atualizações dinâmicas do servidor de nomes (dynamic

updates).

- queries: atividades pertinentes a todo tipo de requisição de informações.

Agora já sabemos como definir nossos canais de logging e quais tipos de categoria
podemos usar para definir os níveis de informações à serem logadas. Veja agora um
exemplo de configuração básica utilizando a instrução logging:

logging {
channel "named_log" {
file "info/named.logs";
severity info;
print-category yes;
print-severity yes;
print-time yes;
};

channel "named_erro" {
syslog local3;
severity error;
print-category yes;
print-severity yes;
print-time yes;
};

category "security" {
"named_log";
"named_erro";
};

category "xfer-out" {
"named_log";
};

category "xfer-in" {
"named_log";
};

};
 Foram criados então, dois canais de logging, um canal de logs gerais, chamado
named_log e um canal de logs específico para armazenarmos informações de erros, o
named_erro. No canal de logs mandamos gravar as informações em um arquivo,
localizado no caminho "info/named.logs" e no canal de erros, mandamos logar com o
daemon syslod. Definimos as prioridades de informações com severity nos dois canais, de
mandamos logar as informações definidas pela categoria, pela prioridade e a hora em
questão, com as opções print. Depois definimos as categorias, atribuindo uma a uma ao
canal que nós criamos.

7.4.6 Instrução Options;

É a mais importante instrução na configuração do named.conf. Assim como na série 8

do BIND, as instruções options são as responsáveis por definir informações necessárias
para a inicialização do servidor de nomes, e informações sobre o comportamento do
mesmo, em vários casos. Contudo, na série 9 do BIND essa instrução ganhou algumas
novas funções, como version que permite que você altere a informação de versão do seu
servidor de nomes. Ótimo para segurança, já que um "curioso" mal intencionado não terá
acesso a versão do bind que você estará usando, via query.

Outra novidade, a opção named-xfer ainda existe, no BIND9, mas ela se tornou
obsoleta e não usável, já que o novo bind incorpora essa função automaticamente em seu
servidor. Portanto o programa named-xfer não é mais necessário para os servidores de
nomes secundários. A opção notify por exemplo, avisa quando uma zona autoritativa foi
modifcada, e está pronta pra transferência ou atualização.

São inúmeras as opções, e tratam desde informações primoridiais, as quais o BIND

simplesmente não funciona se não existirem, até informações de níveis técnicos e de
importância administrativa, como por exemplo, estatísticas de uso da memória do
servidor pelo servidoço de nomes, topologias, estatísticas de número de queries que não
puderam ser respondidas, etc.

Mas, vamos analisar um arquivo de configuração com as options básicas para

colocarmos nosso servidor de nomes no ar e funcionando. Inicialmente, indicarmos o
working directory pro nosso BIND, com a opção directory ""; e uma interface para o
servidor ouvir já são informações o bastante. Contudo vamos ver um conjunto mais
ilustrado de opções:

options {
directory "/";
allow-transfer { 200.230.200.9; };
allow-recursion { 200.230.200.0/24; };
statistics-file "/info/named.stats";
dump-file "/info/dump.db";
pid-file "/info/named.pid";
version "Versao Indisponivel";
listen-on port 53 { 200.230.200.10; };
query-source address 200.230.200.10 port 53;
transfer-source 200.230.200.9 port 53;
auth-nxdomain no;
};

Vamos então entender essa nossa configuração básica.

 A opção directory define o working directory para o nosso servidor de nomes. Funciona
da mesma forma que na versão 8 do BIND. No exemplo acima fica claro que nosso
servidor de nomes vai estar rodando em ambiente seguro (CHRoot Enviroment), ou seja,
CHRootado, porque definimos a raiz "/" como diretório de configuração do nosso servidor
de nomes.

Normalmente em ambientes não CHRootados, o working directory costuma ser

"/var/named", "/etc/namedb" ou "/usr/named".

A seguir, a opção allow-transfer define o endereço dos nossos servidores secundários,

ou seja, aqueles que tem permissão para efetuar transferências. Lembrando que você
pode usar uma ACL criado por você mesmo, para representar esse tipo de informação no
BIND9.

Por exemplo: allow-transfer { secundarios; };

Onde "secundarios" é uma ACL que define quais são nossos servidores slaves.

A opção allow-recursion define quais endereços são autorizados a efetuar buscas

recursivas de nomes, no nosso servidor. No nosso exemplo, nós permitimos toda a nossa
rede: 200.230.200.0/24 Você poderia ter usado uma ACL pra isso também.

dump-file indica o caminho onde o named deve salvar os databases em dump,

quando o comando rndc dumpdb for especificado. O padrão é named_dump.db.

A opção pid-file indica onde o BIND deve criar seu arquivo de texto com o número de
Process IDentification.

A opção version substitui a string specificada pela informação de versão do servidor de

nomes.

As outras opções já são conhecidas do BIND8. Indicam a porta e interface onde o

servidor deverá rodar, ouvir requisições de nomes e fazer as transferências de zonas. Já a
opção auth-nxdomain faz tradução dos bits AA (IPv4) quando necessárias. Apenas
recomendado em casos extremos. O padrão é auth-nxdomain no; mesmo se não
especificado.

Com essas opções você já pode colocar o seu servidor de nomes no ar, rodando com
traquilidade. Lembre-se de usar ACLs sempre que possível, porque ajudam na
administração e consequente segurança do servidor de nomes.

7.4.7 Instrução Server;

As instruções server denotam características à serem atribuídas a servidores de nomes

remotos. Definem o comportamento do nosso servidor em relação à outros servidores. São
necessárias nas definições de keys ao serem utilizadas junto à algumas novas
características do BIND9, como TSIG, etc...

A sintaxe para utilização dessa instrução é:

server endereço_ip {
 bogus yes|no;

provide-ixfer yes|no;

request-xfer yes|no;

transfers número;

transfer-format one-answer | many-answers;

keys {strings [strings ...] };

};

A opção bogus da instrução server define um tipo de servidor que possivelmente está
dando informações errôneas sobre zonas e nomes. A palavra bogus pode ser livremente
traduzida como "bobo". Se um servidor for definido como bogus as informações providas
por eles serão consideradas com um nível mais baixo de prioridade. A padrão para essa
opção é "no". Até a data atual essa opção não havia sido implementada no BIND9.

A opção provide-ixfer define se o servidor, no caso um servidor primário (master) vai

delegar informação de atualização para um servidor secundário (slave) de forma
incremental. Prover essas informações de forma incremental significa dizer que o servidor
master vai apenas servir o slave com as informações que foram modificadas (novas
informações) em relação às informações que o servidor slave já possuia, ou seja, a
transferência não será mais da zona por completo, apenas dos trechos novos. Se essa
opção estiver desligada ("no") então a transferência de informações entre servidor primário
e secundário serão sempre não-incrementais, ou seja, sempre a zona inteira. Se não
especificada, essa opção assume o resultado global definido em options{};

A opção request-ixfer define que o servidor local vai estar agindo como servidor de
nomes secundário, e que vai tratar o servidor especificado na opção server como o
primário. Ao tentar atualizar suas zonas secundárias, ele sempre tentará que essas
requisições dejam incrementais, caso esteja definida opção yes. Se não especificada, essa
opção também assume o resultado global definido em options{};

A opção transfers define um número máximo de transferências concorrentes vindas do

servidor especificado. Se essa opção não for informada, o padrão é obedecer a cláusula
transfers-per-ns definida no options{};

A opção transfer-format define o método de transferência dos resource records. Podem

ser definidos dois formatos, de resposta única (one-answer) e várias respostas (many-
answers). O método de várias respostas é mais eficiente, contudo só são compatíveis com
o BIND9, BIND8 e algumas versões atualizadas do BIND.

A opção key é usada para definir um nome de chave, o key_id definido por uma
instrução key, para garantir transação segura quando dois servidores estiverem se
comunicando.

7.4.8 Instrução Trusted-Keys;

 Essa opção define uma trusted-key para um security-root do DNSSEC. DNSSEC vai ser
tratado ao longo dessa documentação, mas é necessário ter um conceito das trusted-keys.
Quando existe uma chave conhecida para um servidor de nomes remoto, mas essa chave
não pode ser obtida por transferência DNS porque o servidor não tem sua assinatura
digital corretamente configurada, então são definidas essas trusted-keys, com conteúdo
conhecido pelas keys, ou seja, chave de base 64, protocolo e agorítmo comuns, para
definir um security-root de confiança. Então a validação de requisições DNS são efeutadas
nos sub-domínios do security-root.

Você verá exemplos práticos de trusted-keys assim que abordarmos o DNSSEC.

7.4.9 Instrução Views;

Essa é uma nova e extremamente funcional característica do BIND9. A definição de

views permite diferentes visões e consequentes respostas distintas de nomes, de acordo
com quem esta fazendo essas requisições. Isso permite que a técnica de "DNS Spliting"
seja usada, sem a necessidade de rodar múltiplos servidores de nomes.

Cada instrução view permite a divisão das informações que o servidor de nome irá
responder, diferenciando pelos endereços IPs, que tipo de resposta cada cliente deverá ter.
Vale lembrar que a ordem das definições de views é importante, já que a resposta será
dada de acordo com a primeira cláusula view onde o endereço IP do cliente for
reconhecido.

A sintaxe para utilização de uma view é:

view nome_da_view {

match-clientes { lista_de_endereços };

conjunto_de_opções_da_view;

opção_de_zona;

};

As zonas definidas dentro de uma view, serão apenas vistas pelos clientes que tiverem
seu endereço reconhecido pela lista de acessos dessa view. As opções de view
(conjunto_de_opções_da_view) podem ser definidas quase em sua maioria, com as mesmas
instruções existentes na opção options{};. Quando não definidas, as opções globais
definidas em options{}; serão utilizadas.

Como uma zona comum de nomes, é necessário ter uma opção HINT para as zonas
definidas dentro de uma view. Se a opção "IN" for assumida como a classe da zona,
dentro da view, então uma HINT não precisa ser especificada, porque as classes 'IN' as
tem pré-configurada.

Veja um exemplo de configuração de views, que ajudará no entendimento das mesmas:

view "internet" IN {
 match-clients { any; };

zone-statistics yes;

recursion no;

zone "eeviac.com.br" {

type master;

file "db.eeviac.externo";

};

};

view "intranet" IN {

match-clients { 192.168.1.0/24; };

zone-statistics yes;

recursion no;

zone "eeviac.com.br" {

type master;

file "db.eeviac.interno";

};

};

Agora, nessas duas views nós definimos visões distintas para a mesma rede, de acordo
com os clientes. Fizemos um DNS Spliting com um mesmo servidor de nomes, e
separamos as informações que apenas a nossa intranet pode ter acesso, das informações
que toda a internet pode ter.

Usando a opção match-clients definimos quem pode ter acesso a qual zona (zone file)
definida com a instrução zone {}; que será explanada à seguir. Definimos opções de zona
estática e de recurssão. Note que, na primeira view foi usada uma ACL padrão, ou seja,
você pode fazer uso de ACLs que você criar para definir os acessos às views.

7.4.10 Instrução Zone;

Os arquivos de zonas são os mais importantes no servidor de nomes. São eles que
conterão as informações que o seu servidor de nomes deve responder. Esses arquivos de
Zone foram explicados em detalhes no Capítulo 5. No BIND9, esse arquivo ganhou
algumas características a mais que devem ser notadas. O número serial nos arquivos de
zonas agora devem ser do tipo "integer" ou seja, números inteiros. A cláusula $TTL (Time
to Live) se tornou obrigatória no cabeçalho de todos os arquivos de zonas.

As zonas podem ser definidas por classes, se não houver essa definição, por padrão o
servidor de nomes assumirá a classe "IN" indicando que essa é uma zona comum à
Internet. A zona CHAOS criada em 1970 pelo MIT também está implementada, assim
como a zona HESIOD (ou apenas HS), também criada pelo MIT para compartilhar
informações de usuários, grupos, impressoras, etc...

As demais características de zonas, como zona autoritativa, zona reversa, zona

secundária e as outras conhecidas devem seguir os mesmos moldes definidos no capítulo
5.

A zona do tipo HINT que define os Root NameServers (".") são obrigatórias na definição
do arquivo de configuração do BIND. A sintaxe de definição de uma zona dentro do
arquivo named.conf permanece igual. O conteúdo da zona agora assume novas
características, como informações "A6" para definição de endereçamento IPv6. Para
maiores informações sobre essas novas opções existentes, veja o manual online: man
named, man bind.

Uma declaração de zonas simples e similar a conhecida no BIND8:

zone "." {
type hint;
file "named.ca";
};

zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};

zone "eeviac.com.br"{
type master;
file "db.eeviac";

E um exemplo de como deve ser o conteúdo de um arquivo de zonas comum, do tipo

master:

$TTL 14400
@ IN SOA eeviac.com.br. root.eeviac.com.br. (
2000041003 ; serial
28800 ; refresh
14400 ; retry
3600000 ; expire
86400 ; default_ttl
)
@ IN NS eeviacbsd.eeviac.com.br.
@ IN NS ns.embratel.net.br.
@ IN NS xffa.eeviac.com.br.
@ IN MX 10 smtp.eeviac.com.br.
@ IN MX 20 xffa.eeviac.com.br.
@ IN A 200.230.200.10
rt IN A 200.230.200.1
ras IN A 200.230.200.2

Lembrando que as entradas "A" podem ser substituídas por "A6" se formos definir
endereçamento IPv6, e "DNAME" para delegar endereçamento reverso IPv6 de nomes.

Por enquanto exemplos práticos de construção de zonas autoritativas e reversas com

endereçamento IPv6 não é essencial, prometo adicionar essas adendas tão logo o
conhecimento de como faze-lo seja necessário. Você pode obter essas informações lendo
os documentos "Bv9ARM" contidos no diretório "docs" que acompanha o BIND9.

7.5 Serviço de Resolução de Nomes: LWRES;

Normalmente as pesquisas DNS sempre foram feitas através de resolvers internamente

linkados ao servidor de nomes. Devido à complexidade do endereçamento IPv6 e das
delegações DNAME de endereçamento IPv6 reverso, que sempre tem que ser simultâneas
as pesquisas IPv4 comuns, essa tarefa se tornou um pouco mais complexa, e então
optou-se por construir uma biblioteca de resolução separada.

Essa biblioteca se chama Lightweight Resolver Library, ou lwres.

A utilização dessa biblioteca, se tornou distinta do protocolo DNS comum, e a

utilização dela é feita através de uma simples comunicação utilizando o protocolo UDP.
Esse processo de comunicação entre a biblioteca e os clientes deve ser feita em conjunto
com um processo daemon, rodando na maquina local.

Esse processo local se chama Resolver Daemon (lwresd). Por padrão, as aplicações que
fazem uso da biblioteca lwres pra resolução de nomes, farão uma conexão UDP comum,
na porta 921 do endereço de loopback IPv4 (127.0.0.1), e é onde esse servidor de
resolução deve estar ouvindo. Essa definição de endereço e porta pode ser modificada,
usando a directiva "lwserver" no arquivo de configuração do resolver do sistema, o
"/etc/resolv.conf".

Devido ao fato que o lwres é uma solução alternativa ao cacheamento de nomes em

formatos comuns (IPv4/IPv6), o daemon lwresd é criado para ser usado com um mínimo
de configuração necessária, ou nenhuma configuração extra que seja, já que é desejável
que esse processo esteja sendo executado em cada máquina.

Uma configuração mais profunda do lwresd pode ser feita utilizando um arquivo de
configurações similar ao named.conf contendo os mesmos tipos de informações,
declaradas da mesma forma, porém com nome de "/etc/lwresd.conf". Para
implementações futuras e práticas, o servidor de nomes (named) também pode ser
configurado para agir como um daemon lwres, utilizando o parâmetro lwres no arquivo de
configurações named.conf, o que torna essa nova característica realmente funcional.

Contudo, em servidores de nomes de grande escala, não será, futuramente

aconselhável configurar o servidor de nomes named para agir como um servidor de
resolução devido ao número de requisições diversas que isso pode causar na mesma porta
do servidor. Implementações de servidores distintos respondendo por cada daemon
independentemente, no mesmo endereço também serão aplicáveis para suportar com
eficiência o tráfego e quantia de informações que terão que ser gerenciadas futuramente.

A sintaxe de definição dentro do named.conf que faria o servidor de nomes rodar

também como um servidor de resolução é:

lwres {

listen-on { lista_de_endereço/lista_ACL };

view nome_da_view;

search {domínio; endereço_IP; };

ndots número;

};

A partir disso, o named vai passar a agir como um lowresd, na porta 53, do endereço
de loopback (127.0.0.1) ou na porta e endereço especificados na directiva listen-on{}; Pode
ser utilizado também as views da mesma forma como foram descritas anteriormente. Se
não houver uma view especificada, a view padrão é utilizada. As directivas "search" e
"ndots" tem a mesma função de quando utilizadas dentro do arquivo "/etc/resolv.conf".

7.6 Remote Daemon Name Control: RNDC;

O rndc é um aplicativo de administração implementado no BIND9, que permite que

sejam realizadas administrações remotas e locais de servidores de nomes. O rndc é
similar ao conhecido ndc, contudo, agora incorpora novas características de segurança e
serviços, que tornam seu uso mais funcional.

As sintaxes para a utilização do rndc são:

- rndc reload: recarrega as informações dos arquivos de configuração e de zonas.

- rndc reload zone [class ] [ view ]: recarrega uma zona específica.

- rndc stats: mostra estatísticas do servidor.

- rndc querylog: inicia o o log de pesquisas.

- rndc stop: para o servidor de nomes, contudo, antes ele garante que alguma
tarefa em andamento (como transferências IXFR) sejam concluídas.

- rndc halt: para o servidor imediatamente, interrompendo qualquer tarefa que

esteja sendo executada.

O utilitário de administração rndc ainda pode ter várias outras funções futuramente
implementadas, em novas versões, de acordo com as necessidades. A utilização desse
aplicativo requer obrigatoriamente um arquivo de configuração, chamado de
/etc/rndc.conf.
 Esse arquivo de configuração é necessário, porque toda a trasação administrativa feita
com o rndc é digitalmente assinada, e uma key de segurança é utilizada para autenticar
essas transações. Um arquivo de configuração pode ser chamado em local alternativo,
utilizando a opção "-c" do rndc.

O formato do arquivo rndc.conf é similar ao formato do named.conf, contudo, apenas 3

cláusulas podem ser utilizadas. São elas, a cláusula options{};, key{}; e server{};. São
essas as opções que associam à chave de assinatura digital ao servidor que se
comunicarão com essa chave em comum.

A cláusula options{}; tem duas opções, a primeira, default-server indica um endereço

ou nome de host, que referencia qual servidor será conectado, se a opção "rndc -s" não for
usada. A segunda, default-key indica o nome da chave, ou key_id que contém o segredo
que estabelecerá a conexão entre ambas as pontas, autenticando-as. Prevê-se a
implementação de uma terceira opção, default-port, para se definir uma porta padrão para
a conexão.

Então, uma configuração mínima do arquivo /etc/rndc.conf seria:

--------------------------------- rndc.conf - exemplo -----------------------------

key chave_rndc {

algorithm hmac-md5;

secret "lZ12asdDfWwqqertTtys";

};

options {

default-server localhost;

default-key chave_rndc;

};

--------------------------------- rndc.conf - exemplo -----------------------------

Mas para que essa opção funcione, o servidor de nomes em questão (no caso 'localhost')
deveria ter uma regra de controle, permitindo essa conexão, e compartilhando uma chave
de assinatura digital idêntica no seu named.conf:

key chave_rndc {

algorithm hmac-md5;

secret "lZ12asdDfWwqqertTtys";

};
 controls {

inet 127.0.0.1allow { localhost; };

keys { chave_rndc; };

};

Agora sim, qualquer comando deferido com o programa rndc estabilizaria uma conexão
digitalmente assinada na porta 953 da máquina local, e efetuaria a transação ordenada.

7.7 Assinatura de Transações DNS: Transaction SIGnatures, TSIG;

TSIGs são assinaturas digitais de transações DNS. É uma característica incorporada

no bind 9 que provê forma segura de comunicação entre dois ou mais servidores de
nomes, e aplicações administrativas em relação aos nameservers. Vamos discutir aqui as
bases de configurações dessas assinaturas, assim como a melhor forma de criar suas
chaves de comunicação e como usar essa função de segurança no BIND.

O BIND incorporou primariamente as TSIGs em comunicação de servidor-pra-servidor,

mas já existe algum suporte (limitado) à TSIG nos resolvers atuais da série 8 do BIND. Por
segurança, uma série de lista de controles de acesso recomendavelmente deveria ser
criada, mas é comprovadamente mais seguro o uso de chaves-comum de comunicação,
do que simplesmente o controle de acesso por endereço.

Existem algumas formas de se gerar uma chave secreta de comunicação entre duas
máquinas, contudo, é importante que se satisfaçam duas dependências. A primeira, é
óbvio, deve ser que as chaves conhecidas em ambas as pontas sejam idênticas, e a
segunda, que essas chaves sejam tratadas pelo mesmo nome. Portanto devemos definir
um nome e um segredo para criarmos uma chave secreta de autenticação.

A geração dos segredos compartilhados entre as chaves podem ser efetuados de duas
formas. A primeira é automatica, e a segunda, manual.

AUTOMATICA:
Para gerar uma chave de forma automática, com 16 bytes (128 bits) e algorítmo hmac-
md5, você pode por exemplo utilizar o comando:

# dnssec-keygen -a hmac-md5 -b 128 -n HOST <nome_da_chave>

E então a chave é criada e armazenada em um arquivo com extensão ".private" no

diretório atual. O conteúdo do arquivo será uma chave de base-64, com no máximo 512-
bits, e essa chave poderá ser usada na criação de uma key.

MANUAL:
Para gerar uma chave de forma manual, você precisa apenas cumprir algumas
dependências. Basta saber que uma chave é apenas um conjunto randômico de
caracteres ascii, de base-64. A maioria dos caracteres ascii, contanto que não se inclua
caracteres especiais, são base-64, e portanto são caracteres válidos. O tamanho da chave
deve ter um número de caracteres múltiplo de 4. Portanto qualquer sequência de
caracteres ascii não especiais, com tamanho múltiplo de 4 é uma chave de segurança
válida. Ex: "IhQIU=ihIL-HLAui" é uma key válida.

Como ja dito, a chave deve ser conhecida por ambos os servidores que se comunicarão.
A chave deve ser definida com a opção key já descrita anteriormente, no arquivo
named.conf do servidor. Portanto é recomendado que esse arquivo não possa ser lido por
todos os usuários do sistema, apenas ao dono do processo (modo: 'chmod 700' ou
necessário), ou ainda que a chave esteja anunciada em um arquivo separado, com modos
de permissões seguros no sistema, e que pode ser chamado pelo arquivo named.conf com
a opção include.

Para instruir o servidor a utilizar aquela chave, deve-se usar a opção server{}; também
já descrita anteriormente. Existem ainda as opções de permissão para determinada
função à ser implementada. Essas opções são:

allow-query{};
allow-transfer{};
allow-update{};

Elas devem ser utilizadas no named.conf para definir regras de controle específicas
para as transações. São como ACLs do sistema, mas referente à comunicação baseada em
chaves. Por exemplo:

allow-update{ key chave_master_slave };

Essa definição portanto permite que sejam realizadas "Dynamic Updates" (atualizações
dinâmicas) apenas entre os hosts que tenham a chave "chave_master_slave" em comum.

Existem ainda outras formas de se gerar outras chaves, de forma automatizada,

chamadas TKEYs, mas as características importantes das TSIGs já foram cobertas. Para
informações adicionais, leia as documentações contidas no diretório docs/ que
acompanha o BIND.

7.8 DNS Seguro, DNSSEC;

O BIND9 agora conta com autenticação criptografada do DNS, utilizando o DNSSEC

(DNS Security). A definição de extensões criptografas de DNS são descritas na RFC 2535.

Basicamente, cria-se uma chave para a zona que se quer autenticar, e se especifica a
chave (de extensão .key) com a opção "$INCLUDE" no arquivo da zona que se quer
autenticar. Na prática, o BIND9 oferece várias ferramentas para a criação dessas chaves,
e para assinatura de zonas.

Ambos, dnssec-keygen e dnssec-signkkey são ferramentas desenvolvidas para a criação

de chaves públicas (.key) e privadas (.private) de criptografia, e para assinatura de zonas.

O programa dnssec-signzone assina a zona específica e cria uma zona assinada que
deve ser chamada pelo arquivo named.conf. A sintaxe dos comandos pode ser facilmente
assimilada, lendo-se as páginas de manuais dos mesmos. DNSSEC ainda não está
completamente implementado no BIND9, portanto possíveis modificações ocorrerão nas
próximas versões.
7.9 Leitura Recomendada;

Como forma complementar de informação, é altamente recomendada a leitura do

Manual de Referência do Administrador do BIND 9, disponível em
www.isc.org/products/BIND/, e especialmente os documentos contidos dentro do
diretório bind/arm/ do pacote fonte do BIND9, assim como todas as páginas de manuais
online, que oferecem informações detalhadas de sintaxe e configuração.

7.10 Nota Conclusoria;

O conteúdo do Capítulo 7 desse documento visa introduzir o administrador de sistemas

FreeBSD Unix à nova versão do BIND, o BIND9, oferecendo um conjunto de informações
que permita ao mesmo assimilar todas as novas características do servidor de nomes de
Berkeley, inclusive aplicando-as de forma prática, seguindo os exemplos oferecidos.

A migração de um servidor de nomes atualmente com BIND série 8, também se mostra

fácil ao decorrer desse documento. A intenção é também prover formas práticas de
auxiliar o administrador a fazer uso das novas características do BIND9 durante o
processo de migração, garantindo especialmente um nível maior de segurança ao serviço.

Existem alguns tópicos de funcionalidades do BIND9 que não foram abordados

profundamente, entre os quais encontra-se principalmente a implementação prática de
um servidor de nomes totalmente baseado em endereçamento IPv6. Uma documentação
mais completa sobre o IPv6 se faz necessária para garantir um conhecimento prévio do
que será abordado.

Outras informações, e algum detalhe que por ventura não tenha sido considerado aqui,
pode ser encontrado no diretório "doc/arm/" em formatos DocBook XML e HTML
distribuído junto ao fonte do BIND9 nos endereços citados no início do capítulo.

Excluindo DNS Security (DNSSEC), toda informação aqui tratada foi implementada de
forma prática antes de ser documentada, em dois servidores distintos, o servidor principal
de internet da Faculdade de Tecnologia de Taquaritinga, e o servidor primário do provedor
de serviços internet (ISP) Mac3, de Ibitinga.

Espero que esse documento auxilie o leitor e supra suas necessidades básicas.
Dúvidas que não surgiram durante o curso, serão respondidas à medida do possível,
desde que a leitura dos capítulos prévios sejam consideradas. Estou disponível para
ajudar no que for possível: eksffa@fatectq.com.br

Bibliografia dos Capítulos 5, 6 e 7.

DNS and BIND

Paul Albitz and Cricket Liu
O'Reilly & Associates
Chroot-BIND HOWTO
Scott Wunsch, scott @ wunsch.org
http://www.losurs.org/docs/howto/Chroot-BIND.html

BIND 9 Administrator Reference Manual

version 9.1, Nominum INC,
www.nominum.com

The FreeBSD Handbook

Domain Names - Concepts and Facilities - RFC 1034
Domain Names - Implementation and Specification - RFC 1035
DNS Extensions to support IP version 6 - RFC 1886
DNS Support for Load Balancing - RFC 1794
Tools for DNS debugging - RFC 1713
Incremental Zone Transfer in DNS - RFC 1995
Name Server Operations Guide for BIND
Dealing with Lame Delegations
A Survey of DNS Tools

.0 Rodando o BIND em ambiente CHRootado (chroot() enviroment)

6.1 Uma visão do ambiente CHRootado.

Esse subcapítulo desse documento aborda uma das mais importantes e indicadas
precauções de segurança que se pode tomar em relação ao sofware BIND. Vamos
demonstrar aqui, de forma clara e prática, todo o procedimento para colocar o BIND
sendo executado em ambiente CHRootado. O Termo CHRoot significa Modificar a Raiz
(CHange Root). A analogia é simples, o ambiente unix segue uma estrutura de arquivos
em árvores hierárquicas, onde o nível mais baixo (raiz), representada nesse ambiente pelo
"/" pode (de acordo com as permissões do sistema) obter acesso à todos os níveis mais
altos da estrutura de arquivos do computador, portanto, todo o sistema local. Esse
conceito básico de ambiente Unix, portanto, pode ser modificado, criando assim um
ambiente virtual da estrutura raiz.

No FreeBSD, você pode implementar um sistema de prisão para um ambiente com o

diretório raiz modificado. Você pode até rodar um sistema operacional dentro de outro,
em ambiente de raiz modificada. A esse procedimento, damos o nome de "CHroot Jail".
Quando um sistema ou processo é executado em um ambiente desse tipo, o seu diretório
modificado passa a ser o seu diretório raiz, e, consequentemente, ele só passa a
enchergar a estrutura de diretórios existente acima do seu ambiente 'chrootado'.

Você provavelmente já teve ao menos um tipo de experiência com esse ambiente.

Sempre que você faz acesso FTP como cliente, em algum servidor público, como usuário
anônimo, ou mesmo com outro usuário válido, em um servidor que tenha algum nível de
segurança, você percebe que apenas encherga a estrutura de diretórios criadas a partir do
seu próprio diretório HOME, e consequentemente, só encherga o que você precisa, ou
criou. Se deslocar para um nível mais baixo na árvore do sistema é impossível,
simplesmente porque aquele é o nível mais baixo pra você. Você passa a enchergar o seu
'/usr/home/user' como o seu diretório '/'.

No FreeBSD, esse ambiente de FTP CHRootado já vem preparado, sendo necessário

apenas que você, como administrador do sistema, defina quais usuários, ou grupos de
usuários serão 'aprisionados', utilizando o arquivo '/etc/ftpchroot'. Mais informações
sobre como usar o ftpchroot pode ser encontrada nessa documentação.

As implementações de ambiente chrootado são permitidas a nível de Kernel, no

FreeBSD, contudo, aprisionar um usuário ou processo dessa forma, não é tão simples
quanto no caso do FTP (quem sabe com o TrustedBSD isso não se torne corriqueiro).

Mas também esta longe de ser uma implementação difícil.

6.2 A Segurança por trás da idéia.

Rodar o BIND como processo e usuário aprisionados em um ambiente chrootado, tem

por finalidade diminuir considerávelmente os riscos de acesso indevido de alguma pessoa
má intencionada. O BIND, historicamente apresenta relatos de várias explorações de seus
serviços. Esse tipo de abuso já tirou do ar vários sites grandes e servidores importantes
da Internet, e essa é uma das melhores e mais eficientes formas de se limitar esses
abusos.

É por esse mesmo motivo que nós executamos o BIND como usuário não privilegiado,
como visto anteriormente nesse mesmo capítulo. Lembre-se que, manter o seu BIND o
mais atualizado possível é tão importante quanto essas medidas de segurança, visto que
todos os problemas quando descobertos, são rapidamente corrigidos. Utilizar um BIND
inferior à versão 8.2.3 é desaconselhado, por motivos de segurança, especialmente se não
for implementado em ambiente chrootado.

Existem outras soluções de segurança relacionadas ao BIND, alguma são soluções

proprietárias, outras tem uma licença menos restrita, como o djbdns,
(http://cr.yp.to/djbdns.html). Rodar o BIND junto ao djbdns é uma ideia que deve ser
considerada, ao menos por experiência.

6.3 Preparando o Ambiente CHRootado

6.3.1 Criação de um usuário para ser dono do processo BIND.

O Primeiro passo para começarmos a implementar o nosso ambiente seguro pro BIND,
é termos em mente que nós queremos executar o servidor de nomes como usuário não
privilegiado, como fizemos anteriormente nesse capítulo. Se você já roda o BIND com um
usuário e grupo específicos, então pode aproveitar esse mesmo usuário existente, para
continuar sendo o responsável pelo processo BIND.

No nosso caso, nós utilizamos o usuário padrão que o BIND cria no nosso FreeBSD, o
usuário bind e o grupo bind. Se por algum motivo você ainda roda o BIND como root, e
não tem um usuário específico pra essa finalidade, pode criar agora (se já não existir) o
usuário e grupo bind. Alguns administradores de sistemas costumam criar o usuário e
grupos named, especialmente os da comunidade Linux. Em termos práticos, é indiferente,
mas vamos assumir o que estamos indicando.

Para criar o usuário e grupo bind você pode utilizar o 'adduser', 'addgroup' ou
adicionar com o 'vipw' a linha referente ao usuário. Lembre-se, no FreeBSD se você
simplesmente alterar, manualmente, os arquivos /etc/passwd e /etc/master.passwd a
Base de Dados de usuários não será atualizada, e portanto essa alteração não terá efeito.
 Para criar o usuário bind com o vipw, adicione a seguinte linha no ambiente de edição
que o vipw abre:

bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin

E para criar o grupo BIND, (você pode faze-lo manualmente, ou até mesmo via
sysinstall) adicione a seguinte linha no arquivo /etc/group:

bind:*:53:

Ao criar o usuário bind, lembre-se de atribuir a ele uma shell não válida, e garanta que
o usuário não tenha uma senha definida, o que o impede de se logar no sistema. Você
pode tomar esses cuidados no momento da inclusão do usuário, ou posteriormente,
utilizando o 'chfn'.

Para isso, digite, logado como super-usuário (Root):

# chfn bind

A saída para esse comando deverá ser parecida com a tela a seguir:

#Changing user database information for bind.

Login: bind
Password: *
Uid [#]: 53
Gid [# or name]: 53
Change [month day year]:
Expire [month day year]:
Class:
Home directory: /
Shell: /sbin/nologin
Full Name: Bind Sandbox
Office Location:
Office Phone:
Home Phone:
Other information:

Nesse ambiente, você pode modificar toda a informação de finger para o usuário bind,
usual em ambiente Unix, contudo, no FreeBSD esse comando (assim como o vipw)
atualiza as informações na Base de Dados do sistema, ou seja, as informações assim
modificadas se tornam válidas.

Preste atenção na informação 'Home directory' do usuário bind, apontando para o "/". É
indicado que ao criar o usuário bind, (ou alterar seus dados) você defina "/" como o seu
Home Directory, quando nós formos rodar o processo bind em ambiente CHRootado, visto
que onde quer que seja o seu diretório HOME verdadeiro, ao CHRootarmos, ele será
sempre interpretado como a raiz do sistema ("/").

Você pode também reparar o "*" no lugar da senha, tanto na linha do vipw quando no
ambiente do chfn, como dito, para evitar que o usuário se logue no sistema. Finalmente,
como já recomendado, o usuário deve não ter uma senha válida, no nosso caso, nos
mantemos utilizando a shell que foi criada automaticamente, a shell não válida
/sbin/nologin. Você pode criar qualquer arquivo para ser essa shell não válida, como por
exemplo /bin/false ou /bin/semsenha, onde esse arquivo pode ser até mesmo um script
que, por segurança, por exemplo, ao ser executado envie uma mensagem ao
administrador, avisando que na data e hora atual, o usuário específico tentou se logar no
sistema. Ótimas alternativas de segurança.

O que deve-se deixar claro, é que essas shells devem existir, de verdade, e no ambiente
do CHRoot Jail, mais especificamente. Em alguns sistemas Unix, ao usar o chroot()
também deve existir o arquivo /etc/shells no ambiente CHRootado, apontando a
existência da shell não válida. Como nosso caso é específico BSD Unix, não foi necessário
criar esse arquivo no FreeBSD, nem no OpenBSD. Segundo Diego Linke (GAMK) também
não existe a necessidade no NetBSD.

Bom, com usuário e grupo criados, nós já temos um usuário sem privilégios no sistema,
para ser o usuário responsável pelo processo bind. Agora precisamos criar a nossa
estrutura de arquivos, para servirmos nosso processo de tudo (e tão somente) que ele
precise.

6.3.2 Preparando a estrutura de arquivos para o ambiente em chroot()

Agora sim, vamos ter que criar todo o ambiente HOME para o BIND. Vamos lembrar
que, depois de chrootado, esse ambiente home será interpretado como a raiz do sistema,
para o BIND, ou seja, seu diretório home será mesmo o "/" (raiz) em um ambiente de
CHroot Jail. Com isso em mente, devemos então criar todos os arquivos, e numa estrutura
que atenda as necessidades do BIND, para apenas garantir que todos os arquivos
necessários, e "somente" o que for necessário esteja disponível ao BIND.

É muito importante lembrar que, deve-se ter muita atenção ao criar e alterar os
arquivos indicados. De forma alguma devemos alterar os arquivos principais do sistema, e
sim, somente os arquivos na arvore aprisionada do sistema. Ou seja, quando você for
alterar arquivo /etc/master.passwd do ambiente CHRootado, deve tomar cuidados para
não alterar o mesmo arquivo do sistema, esse tipo de engano pode resultar em sérios
problemas no seu sistema.

Bom, agora para começarmos a preparar essa estrutura de arquivos, vamos considerar
que, o diretório principal para o BIND seja o /usr/named, exatamente como tratamos ao
longo desse capítulo inteiro. Ou seja, o /usr/named é o arquivo onde estarão nossas
informações de zona, zona reversa e nossos db's de zonas pra todos os domínios nos
quais nós teremos autoridade. E agora, aplicando o conceito de chroot enviroment, o nosso
diretório /usr/named será interpretado pelo BIND como sendo o diretório /.

Portanto:

/usr/named ==> /

Então, agora toda a estrutura de arquivos deverá ser criada abaixo desse diretório.

Vamos então começar a criar essa estrutura, necessária ao BIND.

O primeiro diretório a ser criado é o diretório etc/ com o arquivo resolv.conf, passwd e
master.passwd; Abaixo desse diretório, devemos criar o namedb/ ou seja, o etc/namedb/
que é o nosso ponto de partida para o serviço BIND, no FreeBSD.
 Agora devemos criar o /dev/null, que é um tipo especial de device nula a qual nós já
conhecemos bem.

Depois deveremos criar toda a estrutura usr/ exatamente da forma como o BIND vai
precisar, contendo os diretórios usr/lib/, usr/libexec/, sbin/, usr/share/ com o diretório
zoneinfo/ e zoneinfo/America e usr/sbin/. Finalmente o diretório bin/ caso seja necessário
(necessário no OpenBSD, no FreeBSD não). Depois, mais um diretório, que será utilizado
pelo bind para guardar as informações de log e informações que nós queiramos. Vale
lembrar que na série 9 do BIND, é o administrador que cria as regras e níveis de logging
data. Então vamos assumir esse diretório de informações diversas como o info/.

Para facilitar a vizualização da estrutura que nós precisamos, veja saída do comando
du:

# du -h /usr/named/
1.0K ./dev
11K ./etc/namedb
80K ./etc
1.4M ./usr/lib
2.0K ./usr/share/zoneinfo/America
3.0K ./usr/share/zoneinfo
4.0K ./usr/share
3.9M ./usr/sbin
83K ./usr/libexec
5.4M ./usr
649K ./bin
2.0K ./info

Desconsidere as informações do tamanho dos diretórios, e analise apenas a estrutura

do mesmo. No momento os seus diretórios devem estar vazios, já que ainda não criamos
nem copiamos nada pra dentro deles.

Agora sim, vamos finalmente garatir todos os arquivos que o bind vai precisar para ser
executado em chroot().

- Dentro do diretório dev/

Precisamos criar a device nula, que é um tipo de arquivo especial, absolutamente
comum em ambiente unix. Esse arquivo especial deve ser criado com o comando mknod e
devem ser especificadas duas directivas, a "minor number" e "major number". Essas
informações são apresentadas no lugar das informações de size (tamanho) do arquivo.

A sintaxe para criação desse do dev/null, logado como superusuário (root) deve ser:

# mknod null c mi mj

Assim o mknod interpreta que o null deve ser criado (opcao "c") com os Minor Number
(mi) e Major Number (mj). Para descobrir esses valores, você deve usar o comando "ls -l
/dev/null" então, no lugar do tamanho do arquivo null, serão mostrados, respectivamente
os valores "mi" e "mj" do seu sistema. Agora você pode criar esse arquivo no seu ambiente
de chroot jail com os mesmos valores.

Esses valores, normalmente são 2 e 2 (2=mi e 2=mj). Se no seu FreeBSD esses valores
também forem esses, então basta digitar os comandos:
# cd /usr/named/dev/
# mknod null c 2 2

Ou alterar para os valores correspondentes. Ponto, seu dev/null do ambiente chrootado já

está pronto.

- Dentro do diretório etc/:

Deve conter os arquivos passwd, master.passwd, resolv.conf, group, pwd.db e spwd.db.
Os arquivos passwd e master.passwd devem conter apenas as informações para dois
usuários: bind e root

As informações devem estar exatamente como no sistema, mas deve-se alterar a senha
para "*" para evitar que ambos se loguem no sistema, e apontar a shell para um
interpretador de comandos não válido, como /sbin/nologin.

Para isso, digite, logado como root:

# cp /etc/master.passwd /etc/passwd /usr/named/etc/

E agora edite ambos os arquivos, apagando os usuários que não queiramos e

modificando a senha e shell da forma que nós queremos:

# ee /usr/named/etc/passwd

Para editarmos, usando o easy editor. Remova todos os users, deixando apenas o root e
o bind e alterando sua shell para uma não válida.

# ee /usr/named/etc/master.passwd

Para editarmos, usando o easy editor. Remova todos os users, deixando apenas o root e
o bind e alterando sua shell para uma não válida e alterando sua senha para "*".

As linhas nesse arquivo devem ficar parecidas com as alterações que você deve ter feito,
usando o vipw, como citado no subcapítulo anterior.

Agora o arquivo resolv.conf; Também deve ser copiado do sistema, e não precisa ser
alterado, imaginando-se que seu servidor de nomes já esteja ativo. Se precisar configura-
lo ainda, leia esse capítulo desde o início. Então copiemos:

# cp /etc/resolv.conf /usr/named/etc/

O arquivo group contém as informações de grupos do sistema, e para o nosso ambiente

chrootado precisamos apenas que conste dois grupos, o grupo bind para o dono do
processo BIND, e o grupo sys.

Então, vamos copiar o arquivo group do sistema para o ambiente chrootado, e editar,
para apagar todos os grupos não necessários ao BIND:

# cp /etc/group /usr/named/etc

# ee /usr/named/etc/group
 Agora edite o arquivo, com o easy editor, e delete todos os grupos existentes, deixando
apenas o sys e o bind

Finalmente, os arquivos pwd.db e spwd.db. Esses arquivos são os Data Base em

formato Hesh DB de Berkeley (comando "file /etc/spwd.db"), que contém as informações
sobre os usuários do sistema. Por isso as alterações não podem ser feitas diretamente nos
arquivos /etc/passwd, /etc/master.passwd do sistema, para que tenham efeito. Editar
esses arquivos manualmente é tão pouco viável, já que não são em formato ascii como os
passwd e master.passwd. Diferente de outros Unix, nos BSD Unix esses arquivos são os
que são lidos pelo sistema, e não simplesmente arquivos de texto.

Então vamos precisar que no nosso ambiente chrootado, esses arquivos também
existam, contudo, com informações apenas dos nossos dois únicos usuários, o root e o
bind.

Para criarmos esses Data Bases de informações dos usuários do sistema, devemos
usar o comando pwd_mkdb; Ele pode criar os arquivos spwd.db e pwd.db em qualquer
diretório, e a partir de qualquer passwd e master.passwd contanto que tenham um
formato válido, interpretável pelo pwd_mkdb.

Portanto, para criar os Data Bases no nosso diretório dentro do ambiente chrootado,
vamos usar o comando, logados como root, da seguinte forma:

# pwd_mkdb -d /usr/named/etc /usr/named/etc/master.passwd

A opção "-d" indica ao pwd_mkdb qual o diretório onde os Database Files serão criados,
e o próximo parâmetro indica a partir de qual arquivo essas informações devem ser
criadas.

Pronto, assim você evita que quando for rodar o bind em ambiente chrootado, o
sistema indique o usuário bind como usuário desconhecido.

- Dentro do diretório etc/namedb/:

Deve conter o arquivo named.conf exatamente como você está usando com o seu
BIND8.2x. Ou o named.conf com as directivas necessárias para a utilização do mesmo no
BIND9x. Mais informações sobre o BIND9 na sequência desse mesmo capítulo.

- Dentro do diretório usr/lib/:

Aqui, você deve colocar todos as as libraries (Bibliotecas) usadas pelo Servidor de
Nomes, o named (name daemon). O programa (binário) named faz uso de algumas
bibliotecas, de acordo com a versão do seu BIND e de acordo com o sistema operacional.

Para descobrir quais bibliotecas um arquivo binário precisa, você deve usar o comando
ldd.

No BIND9, no FreeBSD, a saída para o comando "ldd /usr/sbin/named" deve ser

parecida com:

named
lcrypto.1 => /usr/lib/libcrypto.so.1 (0x40181000)
lc_r.5 => /usr/lib/libc_r.so.5 (0x4022a000)
lc.5 => /usr/lib/libc.so.5
 Então vamos copiar essas bibliotecas, para o nosso ambiente chrootado, que é onde o
named vai procura-las. Como root, digite:

# cp /usr/lib/libcrypto.so.1 /usr/named/usr/lib/
# cp /usr/lib/libc_r.so.5 /usr/named/usr/lib/libc_r.so.5
# cp /usr/lib/libc.so.5 /usr/named/usr/lib/libc.so.5

Lembre-se, essas bibliotecas com certeza serão outras, de acordo com a versão do seu
sistema operacional, versão do BIND e forma como você o compilou.

Copiadas as bibliotecas necessárias, você já eliminou a maior dependência de se rodar

o BIND em ambiente chrootado.

- Dentro do diretório usr/share/zoneinfo/America/:

Aqui, nós vamos precisar copiar o arquivo de informações de localização, para
assegurarmos a precisão de hora e data para que o BIND possa logar essas informações
com precisão. Normalmente dentro desse diretório existe apenas o arquivo de ZoneInfo da
região que o seu FreeBSD já está configurado... para saber qual (ou quais) esse(s)
arquivo(s), liste o conteúdo desse diretório, e os copie (ls /usr/share/zoneinfo/America/).

No caso da área ser São Paulo (meu caso), então eu vou precisar compiar o arquivo:

/usr/share/zoneinfo/America/Sao_Paulo

Para:

/usr/named/usr/share/zoneinfo/America/Sao_Paulo

Faça o mesmo, de acordo com o seu sistema.

- Dentro do diretório usr/sbin/:

Você deve copiar o programa named. O binário responsável pelo serviço de nomes.
Você deve copiar esse programa a partir do diretório onde você acabou de compila-lo, ou a
partir do local que você esteja usando. Normalmente o caminho é /usr/sbin/named.

Para descobrir onde está o binário named, use o comando: 'whereis named'
E então copie-o para /usr/named/usr/sbin/

- Dentro do diretório usr/libexec/:

Aqui deve ficar a biblioteca que interpreta arquivos binários. Dependendo do sistema
operacional, essa biblioteca também fica no diretório /usr/lib junto às outras bibliotecas
que constituem dependência do named. No FreeBSD a biblioteca que interpreta binários,
a "ld.so" é a biblioteca "ld-elf.so.1". E o caminho dela é este.

Portanto, vamos copiar essa biblioteca pra dentro do ambiente seguro (chroot()
enviroment):

# cp /usr/libexec/ld-elf.so.1 /usr/named/usr/libexec/

- Dentro dos diretórios bin/ e sbin/:

Aqui devem constar os interpretadores de comandos não válidos. Caso você tenha
apontado seus usuários bind e root para ter uma shell não válida, e esta tenha sido
/sbin/nologin como indicada, ou /bin/false que é muito usada, então esses arquivos
devem constar no ambiente chrootado. Portanto crie ou copie o nologin ou o false para
seus respectivos diretórios.

Em alguns sistemas operacionais, você vai ter que criar o etc/shells e constar a
existencias dessas shells falsas nesse arquivo. No FreeBSD não foi preciso.

- Dentro do diretório info/:

No BIND8x não vai ter conteúdo, e pode ser descartado. No BIND9x é usado para
armazenar logs de informações, de acordo com as regras de logging{} que nós criemos.

Em síntese, o conteúdo usual do ambiente CHRootado, depois de criado e com os

respectivos arquivos copiados ou criados, deve ser parecido com a seguinte árvore:

------ CHRoot Enviroment - Eksffa------------

------ Árvore básica de exemplo ------------

/usr/named: chroot('/')

/dev/
null

/etc/namedb/
named.conf

/etc/
group
master.passwd
passwd
pwd.db
resolv.conf
spwd.db

/usr/lib/
libc.so.5
libc_r.so.5
libcrypto.so.1

/usr/share/zoneinfo/America/
Sao_Paulo

/usr/sbin/
named

/usr/libexec/
ld-elf.so.1

/bin/
false

/info/

Vale lembrar que, de acordo com a versão do BIND, você pode precisar criar outros
diretórios e arquivos, mas esses podem ser facilmente descobertos, ao ler os logs de
provaveis erros, no syslogd ou do daemon. No BIND9x é ainda mais fácil, acionando-se a
opção de debug (-g).

Finalmente, vamos definir o verdadeiro dono pro nosso ambiente seguro:

# chown -R bind.bind /usr/named

6.4 CHRootando o BIND.

Finalmente, vamos colocar o BIND rodando no nosso ambiente aprisionado. Agora que
você já satisfez todas as dependências de estrutura de arquivos e usuário, já podemos
assegurar nosso servidor de nomes.

Para criar um ambiente de CHroot Jail, no FreeBSD você tem o comando chroot, que
utiliza a função chroot() implementada a nível de Kernel. Para aprender como usar esse
comando com mais detalhes, utilize o manual online:

# man chroot

Mas a sintaxe básica para a utilização do chroot com o BIND, deve ser:

# chroot /var/named /usr/sbin/named -u bind -g bind

No BIND 8x, onde ainda é necessário apontar o grupo, além de usuário, com a
directiva '-g'.

Ou:

# chroot /var/named /usr/sbin/named -u bind -g

No BIND9x, onde apenas o usuário deve ser indicado, e a opção -g habilita o debug-
mode, para se poder analizar erros, e não lança o processo como background.

Mas...

O named, desde as mais recentes versões da série 8 e obviamente na série 9, já vem

com uma opção que invoca a função chroot() do sistema operacional, para que você possa
automatizar o processo de lançar o BIND em ambiente CHRootado. Essa opção faz a
mesma coisa que a opção "-u" que lança a função setuid() do sistema operacional,
alterando o ID do usuário dono do processo, tão logo esse seja posto em execussão.

Essas opções são não viaveis em alguns Linux. O Kernel que você costuma encontrar
esse tipo de incapacidade estão listados no manual online do named (man named).

Felizmente nós estamos trabalhando com BSD Unix.

Para iniciar o named lançando-o em ambiente chrootado e com usuário não privilegiado,
devemos então inicia-lo da seguinte forma:

# /usr/named/usr/sbin/named -t /usr/named -u bind -g bind

 No BIND8x, a opção "-t" lança o processo em ambiente chrootado (Troggle chroot()
directory), a opção -u e -g respectivamente fazem o named ser executado com o grupo de
usuário definido.

# /usr/named/usr/sbin/named -t /usr/named -u bind

No BIND9x, a opção "-t" (Troggle chroot() directory) é a mesma, contudo apenas a opção
"-u" deve ser usada para definir qual usuário deve ser o dono do processo. Nessa versão
do BIND, a opção "-g" inicia o Debug Mode, e mantém o processo em foreground.

Pronto, agora sim você já deve estar rodando o seu BIND em ambiente seguro. Se algo
der errado, você pode acompanhar pelos logs que você está acostumado, no BIND8, ou
pelo Debug Mode no BIND9, e descobrir qual foi o erro ou o que faltou no seu ambiente
seguro.

Agora, devemos automatizar esse processo, no FreeBSD.

Para isso, vamos editar o arquivo /etc/rc.conf
Nesse arquivo, você deve alterar ou criar (caso não existam) as seguintes linhas:

named_enable="YES"
named_program="/usr/named/usr/sbin/named"
named_flags="-t /usr/named -u bind"

Agora você já avisou como o FreeBSD deve iniciar o named, quando necessário. Caso
você costume fazer alterações constantes no seu servidor de nomes e vai ser duro se
acostumar com ficar digitando "/usr/named/usr/sbin/named" toda vez que você quizer
chamar o processo, crie um symlink (link simbólico) apontando o /usr/sbin/named para
o named do seu ambiente seguro: /usr/sbin/named -> /usr/named/usr/sbin/named ;}

Última dica básica: consideramos que os seus arquivos de zona e de reveso já estivesse
no diretório /usr/named, que é onde eles foram indicados à serem criados ao longo desse
capítulo. Se esse não é o seu caso, copie os arquivos ou crie a estrutura de diretórios do
ambiente chrootado de acordo com a sua preferência.

E finalmente, se a localização desses mesmos arquivos de zona e reverso serão o

diretório onde o ambiente seguro foi criado, como no caso abordado durante toda a
documentação, então a opção directory{} dentro do named.conf deve apontar para "/" e
não mais para "/usr/named" como em ambiente não chrootado:

options {
directory "/";
query-source address * port 53;
};

Em alguns casos, o syslogd não vai mais conseguir logar as ações do bind, devido ao
fato do /dev/log não existir no ambiente chrootado. Como solução, devemos indicar ao
syslogd para criar um unix sock em /dev/log com a opção "-a"; Comando: "syslogd -a
/usr/named", estando logado como root.

Feitas essas ressalvas, você está pronto pra configurar seu próprio ambiente chroot()
para o BIND. Preparados da forma como melhor lhe convier. Se quiser, pode até apagar o
diretório /etc/namedb no sistema, visto que agora você vai usar somente o ambiente
chrootado. Mantenha um BACKUP atualizado sempre.
6.5 Configurando um SLAVE NameServer em ambiente CHRootado.

Muitas vezes, alguns administradores conseguem até rodar o BIND CHRootado,

seguindo esse tipo de instrução passo-a-passo. Contudo, algumas vezes eles encontram
problemas simples, mas por falta de experiência não conseguem assimilar o
funcionamento do ambiente ou não sabem quais arquivos estão faltando.

Esse tipo de incoerência acontece quando o atual servidor de nomes, é implementado

para ser servidor de nomes secundário para outras zonas, além de primário para algumas.
Para evitar esse tipo de problema, vamos fazer uma breve análise do que deve ser alterado
no nosso ambiente chrootado, caso o servidor de nomes exerça também papel de Slave
NameServer.

Um servidor de nomes secundário (bind8), usa o binário named-xfer para prover a

transferência e atualização de seus dados, em relação ao servidor principal (master). Da
mesma forma que o named, o programa named-xfer também deve fazer parte da estrutura
do nosso ambiente chrootado.

Normalmente, no FreeBSD, o named-xfer é encontrado em /usr/libexec/named-xfer e

é esse o caminho também que ele deve ser localizado, no nosso Chroot Jail. Então copie o
programa de onde quer que você tenha compilado-o, ou do local original no sistema, para
o ambiente chroot():

# cp /usr/libexec/named-xfer /usr/named/usr/libexec/

Da mesma forma, o named-xfer também depende de algumas bibliotecas. Depende

também da versão do BIND e da versão do sistema operacional, exatamente como no caso
do named, e a forma de se descobrir quais as dependências é a mesma: utilizando o
comando ldd.

Então, para descobrir quais as bibliotecas requeridas pelo named-xfer, digite:

# ldd /usr/named/usr/libexec/named-xfer

A saída desse comando, no FreeBSD deve ser parecida com:

# ldd /usr/libexec/named-xfer
libc.so.4 => /usr/lib/libc.so.4 (0x2809c000)
lcrypto.1 => /usr/lib/libcrypto.so.1 (0x40181000)

Então, repita o procedimento, e copie as bibliotecas necessárias para satisfazer as

dependências do named-xfer, caso elas ainda não existam no nosso ambiente seguro:

# cp /usr/lib/libc.so.4 /usr/lib/libcrypto.so.1 /usr/named/usr/lib

Agora as dependências para a execussão do named-xfer já foram cumpridas. É

necessário apenas ser atencioso a alguns detalhes. Alguns sistemas operacionais e
versões do BIND precisam que exista o arquivo /etc/ld.so.conf. Não é o caso do FreeBSD,
mas se for necessário crie esse arquivo, vazio mesmo, com o comando "touch
/usr/named/etc/ld.so.conf".
 Outro detalhe, esse um pouco menos banal. Diferente do named, o programa named-
xfer não faz apenas leituras nos nossos arquivos de zona e de reversos. Por ser o servidor
secundário, quando as informações primárias são atualizadas, ele precisa também
atualizar os DB's (databases) de informações secundárias, ou seja, temos então que
garantir permissão de escrita (write) nos arquivos que o servidor de nome terá que
atualizar. Os DB de zonas secundárias. Para isso, garanta os modos 755 para que o dono
dos arquivos (bind) possa ter totais permissões nos arquivos que forem zonas
secundárias:

# chmod 755 /usr/named/todas_as_zonas_secundarias.db

# chown -R bind.bind /usr/named

Lembrando que estamos assumindo também, para o servidor de nomes secundário,

que o diretório /usr/named seja o diretório escolhido para ser o ambiente onde você vai
aplicar o chroot enviroment.

Feitas essas alterações, você já pode garantir a execussão do seu servidor de nomes
secundário, também em ambiente seguro. Qualquer erro pode facilmente ser descoberto,
analizando-se os logs usuais, os quais você já esta acostumado, e serem corrigidos.

7. BIND9x - Configuração e Introdução ás novas funções.

O BIND (Berkeley Internet Name Domain) é o software responsável pelo serviço de

nomes no mundo, quase que em sua total maioria. Atualmente o desenvolvimento desse
software está sob responsabilidade do ISC (Internet Software Consortium), e desde as
últimas versões do BIND8 até as novas versões do BIND9, o ISC já proveu diversas
melhorias no software. Contudo, o BIND, usado inclusive nos Root Name Servers, em sua
versão 8 mais recente, vem enfrentado diversas explorações, por parte de grupos de
usuários mal intencionados.

Essas explorações são sempre rapidamente corrigidas, mas não são tão rapidamente
atualizadas pelos administradores de sistemas, visto que a grande maioria não é ligada a
Security Advisories, ou em casos mais comuns, esses administradores tem funções
distintas dentro de uma empresa, e não são somente administradores do sistema,
resultando em uma falta de tempo iminente para cuidar de atualizações e correções de
software.

A forma como o BIND foi escrito até a série 8, é a principal razão dessas explorações.
Agora o BIND foi reescrito, em sua versão 9, e além da tendência a menor exploração e
abuso de seus serviços, o BIND9 incorporou diversas novas características, tanto
relacionadas à segurança do serviço, quanto à eficiência e maiores possibilidades de
configuração no servidor de nomes.

O Desenvolvimento da versão 9 do Servidor de Nomes de Berkeley foi dirigido pelo

Internet Software Consortium (www.ISC.org) e foi feito em conjunto com várias
organizações, que tem considerável e reconhecido "technical improvement" (digamos assim)
no ambiente computacional. Essas organizações são:

- Sun Microsystems, Inc. (http://www.sun.com/);

- Hewlett Packard (http://www.hp.com/);
- Compaq Computer Corporation (http://www.compaq.com/);
- IBM (http://www.ibm.com/);
- Process Software Corporation (http://www.process.com/);
- Silicon Graphics, Inc. (http://www.sgi.com/);
- Network Associates, Inc. (http://www.nai.com/);
- U.S. Defense Information Systems Agency (http://www.disa.mil/);
- USENIX Association (http://www.usenix.org/);
- Stichting NLNet - NLNet Foundation (http://www.nlnet.nl/).

7.1 Principais características do BIND9

O BIND9 é uma transcrição, onde todas as principais funções e características do

BIND foram reescritas, além de adicionadas novas funções e serviços. Toda a declaração
de autoridade sobre nomes, toda a arquitetura hierárquica de domínios e zonas, assim
como formas de cacheamento e transferência de zonas, presentes e melhoradas em todas
as versões anteriores do BIND foram mantidas e reescritas, e estão em constantes
melhorias.

Outras novas características de serviços foram implementadas, incluindo suportes

anteriormente não existentes, novos conceitos e funções de segurança, maior
escalabilidade e outras mudanças, como:

- Segurança no DNS:
DNSSEC (zonas autoritativamente assinadas);
TSIG (transações DNS assinadas) ;

- IPv6, Protocolo IP versão 6, próxima geração:

Responde por DNS utilizando unix sockets IPv6;
Resource Records (RRs) para IPv6: A6, DNAME, etc.;
Origens de Bitstring (ip6.arpa) para alocação dos bits;
Bibliotecas Experimentais de Resolução IPv6;

- Novas Características no protocolo de DNS:

IXFR, DDNS, Notify, EDNS0;
Conformidade comprovada de padronização;

- Views
Um processo do servidor pode diferenciar tipos distintos de "visões" (as views) das
informações de nomes, podendo dividir uma "visão interna" de nomes para alguns clientes,
e outra "visão externa" de nomes para outros clientes.

- Suporte a Multiprocessamento.
- Arquitetura comprovadamente portável.

Na nova versão 9.2 do BIND, ainda foram incluídas outras alterações:

- O tamanho do cache agora, pode ser limitado, usando a opção "max-cache-size";
- O servidor agora converte automaticamente as requisições recursivas do tipo RFC1886
em recurssões do tipo RFC2874, o que permite que os resolvers que utilizam as novas
funções IPv6 sejam respondidos por resolvers antigos, que trabalham apenas com
entradas AAAA (IPv4);
- O programa rndc agora tem a opção status, e o mesmo tem sua configuração automatica
agora;
- Outras alterações de menor importância, que melhoram o desenpenho do servidor de
nomes.
7.2 O que é necessário para configurar ou migrar para o BIND9?

A Finalidade desse capítulo 7 é orientar o administrador durante o processo de

migração do seu servidor de nomes, ou orientar a configuração a partir do ponto inicial.
Contudo, é extremamente importante e recomendada a leitura prévia dos capítulos 5 e 6
dessa documentação. Os conceitos de serviço de nomes, tipos de zonas e de serviços,
assim como uma configuração mais detalhada das zonas e domínios foram amplamente
explanadas nos dois capítulos anteriores, e portanto não serão revistas aqui.

Para utilizar o servidor de nomes BIND9, é necessário uma configuração mínima de

hardware, que pode ser um computador com processor 386/486, e uma quantidade
mínima de memória, para poder cachear as informações necessárias, ainda que somente
as informações de zonas autoritativas.

A configuração básica indicada é o sulficiente pra responder por zonas estáticas de

forma autoritativa, sem um cacheamento grande de informações de nomes. O BIND9,
contudo, é escrito para poder responder por milhares de requisições de nomes por
segundo, cacheadas e/ou autoritativas. O poder de processamento e de memória deve ser
relativo a forma como você quer usar seu servidor de nomes. De forma geral o BIND9
provê uma melhor utilização dos recursos, se comparado à série 8 do mesmo software.

O BIND9 agora é arquitetado multithread e suporta multiprocessamento simétrico, ou

seja, é ideal para servir nomes em servidores com dois ou mais processadores. Os
sistemas operacionais suportados, são a maioria dos Unix, e os indicados são IBM-AIX,
Compaq Tru64 Unix,FreeBSD 3.4, 3.5, 4.0, 4.1 e -STABLEs, NetBSD 1.5, HP-UX 11, IRIX64
6.5, Red Hat Linux 6, 6.1, 6.2 e 7, e Solaris 2.6, 7 e 8. E são bem utilizados também em
outros sistemas operacionais, apesar de não serem oficialmente suportados.

7.2.1 Compilando o servidor de nomes BIND9x

O BIND9 assim como o BIND8 é distribuído em forma binária e em código fonte. O

formato binário, normalmente é distribuído de acordo com o fabricante e mantenedor do
sistema operacional, já o código fonte, pronto para ser construído, pode ser encontrado,
via FTP anônimo, no servidor do Internet Service Consortium: ftp.isc.org/isc/bind9/

Hoje, a versão mais recente é o BIND 9.2 Alfa, disponível em:

ftp://ftp.isc.org/isc/bind9/9.2.0a2/bind-9.2.0a2.tar.gz

e com sua assinatura digital, disponível em:

ftp://ftp.isc.org/isc/bind9/9.2.0a2/bind-9.2.0a2.tar.gz.asc

Pro FreeBSD, o binário disponível hoje, é a versão 9.1.3 do BIND, disponível em:

ftp://ftp5.freebsd.org/pub/FreeBSD/ports/i386/packages-4.3-stable/All/bind-
9.1.3rc1.tgz
 Esses mesmos arquivos (exceto os binários), assim como as versões mais recentes do
BIND9 também estarão sempre disponíveis no mirror brasileiro da ISC, servido pela pop-
mg.com.br no endereço:

ftp://ftp.pop-mg.com.br/pub/isc/bind9/

Os pacotes disponíveis nesse endereço, já oferecem todo o conjunto de software BIND,

incluindo o daemon servidor de nomes, o named, todos os programas e os softwares
resolver. Assim como a biblioteca de critpografia openssl .As instruções de compilação da
documentação do BIND9 diz que, para construir o BIND a partir desse fonte, basta
executar o script configure e depois dar um make.

Mas vamos antes fazer uma pequena consideração: As características de segurança,

DNSSEC e TSIG utilizam as bibliotecas de criptografia OpenSSL. Essas bibliotecas já
estão inclusas junto do pacote disponível nos endereços citados acima, contudo, é
recomendado que essa biblioteca seja instalada separadamente, especialmente em
ambientes que já utilizem a critpografia OpenSSL. Felizmente esse é o caso do FreeBSD.

Normalmente, você já deve ter a OpenSSL instalada e em uso no seu FreeBSD. Para
instala-la, você pode fazer via PORTS, via pkg_add ou pelo fonte, disponível em
www.openssl.org. Informações sobre como instalar software pelo ports ou com pkg_add
disponíveis nos capítulos anteriores dessa documentação.

A configuração da biblioteca OpenSSL externa, deve ser feita de forma automatizada

pelo BIND9. O script configure da conta dessa tarefa. Para ter acesso a todas as
informações que você pode passar para o configure digite ./configure --help.

No nosso caso, só nos interessam duas opções:

./configure --with-openssl=PATH
./configure --sysconfdir=PATH

Essas são as opções para indicar o caminho da biblioteca OpenSSL e para indicar qual
será o diretório de configuração do BIND9. O padrão para essa última opção, se não
alterada, é /etc/, mas como no FreeBSD o padrão é /etc/namedb e nosso capítulo de
configuração do servidor de nomes e capítulo de Chroot Enviroment tratou do caminho
padrão no FreeBSD, e sendo o FreeBSD nosso sistema operacional For Choice, vamos
optar pelo nosso /etc/namedb/.

Agora, começarmos a compilar o servidor de nomes, basta sabermos onde estão os

arquivos das bibliotecas OpenSSL. Se você instalou recentemente, deve-se lembrar do
caminho, senão basta procurar, com um find / -name "*openssl*"

Normalmente o caminho da OpenSSL no FreeBSD é /usr/include/openssl.

Possívelmente no seu FreeBSD deve ser esse mesmo caminho padrão. Então para
configurar o BIND, vamos usar o comando:

# cd bind-9.2xx/
# ./configure --with-openssl=/usr/include/openssl --sysconfdir=/etc/namedb

Agora sim, ao final das verificações e dos ajustes de configuração, o BIND9 já está
pronto pra ser compilado:

# make
 É de prache recomendarmos que você tenha sempre um backup consistente e
atualizado dos arquivos mais importantes do seu sistema, e isso sempre inclui todos os
seus arquivos do servidor de nomes. Agora, por segurança, faça uma cópia também, além
dos arquivos de configuração, de zonas e reversos usuais, dos binários também,
especialmente os programas nslookup, named, named-xfer e outros que julgar
necessários.

Agora você pode acabar a instalação do seu BIND9. Logado como root, digite:

# make install

Pronto, todos os programas já foram compilados e construidos, e estão acima do

diretório bin/ dentro do seu diretório de instalação do bind9. Normalmente parecido com
~/bind-9.xxx/bin/. Você pode copiar os programas ou criar links simbólicos, para onde
quer que você ache necessário, lembrando sempre que é ideal que esses programas
estejam no path do seu interpretador de comandos (shell), assim como as man pages
(páginas de manual online) também, criadas no diretório man/ do BIND9.

7.3 Configuração do BIND9 NameServer.

Agora vamos tratar de alguns exemplos e indicações para configuração de um servidor

de nomes, utilizando o BIND9. A maior parte das opções principais são equivalentes à
forma como eram aplicadas na versão 8 do BIND, e foram profundamente explicadas no
Capítulo 5 desse documento. As novas opções e/ou diferenças de sintaxe serão abordadas
aqui, sempre que as directivas a façam necessárias. Conhecimento básico do Capítulo 5 é
recomendado.

Já temos então todos os arquivos e programas do bind9 instalados. Então é hora de

começarmos a configurar o nosso servidor de nomes. O Primeiro arquivo a ser
configurado, exatamente como no bind8 é o arquivo named.conf, que deve estar localizado
onde nós mandamos ele ser compilado, com a opção --sysconfdir=PATH do configure.
Portanto no nosso caso, nos servidores FreeBSD, o diretório é o /etc/namedb/named.conf

O arquivo named.conf é o arquivo que mais ganhou novas opções, exatamente por ser o
arquivo mais importante para o servidor de nomes. Vamos então dar uma ênfase especial
nessas novas mudanças, e entendermos a utilização de todas as novas opções.

Lembrando que, para os nossos exemplos, vamos manter a configuração-exemplo

adotada no Capítulo 5:

Domínio: eeviac.com.br
Servidor Primário: eeviacbsd.eeviac.com.br
Servidor Secundário: xffa.eeviac.com.br
Segundo Secundário: corduroy.eeviac.com.br
Faixa de IPs da Rede: 200.230.200.0 até 200.230.200.63
Portanto Máscara: 255.255.255.192

7.4 named.conf no BIND9

No BIND9, as opções para o arquivo named.conf foram divididas em várias séries de

instruções distintas, com diferentes funções cada uma. As instruções existes hoje são:
 - ACL: Definem uma série de lista de controles de acesso, baseadas em
endereço IP, para controle de nomes e outras utilizações.

- Controls: Define canais de controles, que devem ser usados junto ao

programa rndc que faz parte dos softwares contidos no novo BIND.

- Include: Directiva para inclusão de um arquivo.

- Key: Especifica uma chave, para ser usada nas Autenticações e Autorizações,
quando estivermos usando TSIG

- Logging: Especifica que tipo de informação o servidor de nomes deve logar, e

para onde essas informações (e de que forma) devem ser logadas.

- Options: Controla todas as informações que o servidor de nomes vai prover.

Define como essas informações serão buscadas pelo BIND, e também cria informações
padrão para outras opções.

- Server: Permite ajustar uma série de configurações, baseadas nas

informações definidas de servidor por servidor.

- Trusted Keys: Define as chaves de acesso que o DNSSEC vai confiar.

- View: Define uma view, tipos de visões distintas de resolução de nomes, de

acordo com os clientes.

- Zone: Define uma zona. Zonas são as principais informações que um

servidor de nomes vai tratar, quando for configurando para ser servidor autoritativo de
determinados domínios (ou zonas).

7.4.1 Instruções ACL

As instruções ACL tem o objetivo de separarmos zonas de endereçamento IP específicas,

e fazer referências a essas zonas, sejam elas quantas forem, utilizando assim um nome
que nós definamos, e não mais uma série de endereços IPs ou de redes. Permite agrupar
definições de endereçamento IP por lista de acesso.

Por padrão, o BIND9 já traz algumas ACLs built-in, para facilitar o uso. São elas:
- any: Absolutamente todas as máquinas (hosts) de todas as redes;
- none: Nenhuma máquina (hosts) de nenhuma rede (net).
- localhosts: Todos os endereços IPs atribuídos às interfaces locais. Por
exemplo, interface de loopback lo0: 127.0.0.1; Interface ethernet xl0(placa de rede):
200.230.200.10 (exemplo).
- localnets: Toda a rede, a qual a máquia faz parte. Definida pelo endereço
atribuído a ela, e pelo endereço de broadcast ou máscara de subrede, no sistema
operacional.

Exemplo de Criação de ACLs:

acl internas {
192.168.0.0/24;
 192.168.1.0/24;
192.168.2.0/24;
};

Nesse exemplo, nós criamos a ACL chamada internas, fazendo referência a nossas
redes internas. Definimos que internas agora quer dizer nossas 3 redes de intranet.
Sempre que o BIND9 se deparar com a palavra de controle 'internas', ele vai saber que
estamos falando dessas 3 redes definidas acima. Máscara /24 indica 24 bits, ou seja, a
rede inteira.

acl secundarios {
200.230.200.9/32;
200.230.200.11/32;
};

Agora definimos que, sempre que dissermos secundários, o BIND deve interpretar como
sendo nossos servidores secundários, os dois endereços IPs que fazem parte da nossa
ACL. A máscara indica 32 bits, ou seja, é um host único.

acl nonsenseisp {
200.205.2.0/24;
200.205.3.0/24;
};

Essa ACL define que as duas redes (24 bits) nessa definição, devem ser compreendidas
sempre que mencionarmos a a expressão nonsenseisp. Caso você encontre algum ISP que
sempre mantém problemas como lamme delegations ou qualquer outra má configuração
nonsense ;}

Lembre-se que, os nomes para as ACLs e o conteúdo das mesmas são definidos
exclusivamente por você, nonsenseisp por exemplos é um tipo de expressão que não quer
dizer muita coisa, e deve ser compreendido apelas pelo administrador que criou essa ACL.

7.4.2 Instrução Controls:

Essa série de instruções tem a função de declarar canais de controle, a serem

utilizados junto ao programa rndc. O uso do rndc vai ser abordado ao decorrer desse
documento. Essas instruções permitem que se abra um socket TCP/IP comum à Internet,
criado na porta 'ip_port' em questão, no endereço 'ip_addr' declarado. Se não for declarada
uma porta em especial, a porta 953 é usada por padrão. A chave "*" pode ser usada, para
espeficiar todas as interfaces locais, contudo não pode ser usada para substituir a
declaração de uma porta específica.

A possibilidade de suprir comandos, utilizando o rndc através de um canal de controle,

só pode ser realizada quando as regras de permissão e de chave são equivalentes, e
consequentemente validadas. Os hosts que não tem permissão de acesso (allow) são
posteriormente ignorados, se a chave de indetificação (key) for conhecida, passando a
ordem de tratamento de controle apenas para as chaves. Essas chaves são então usadas
para autenticar todos os comandos e respostas de comandos, durante a transação,
criando assim uma assinatura digital entre os dois lados.
 A sintaxe comum para utilização de um canal de controle é:

controls {
inet ( ip_addr | * ) ( port 'ip_port' ) allow endereços_permitidos
keys lista_de_chaves_permitidas;
inet [...];
};

Exemplo de criação de canais de controle:

Nos endereços permitidos, pode ser especificada uma ACL previamente declarada.
Vejamos o exemplo a seguir:

controls {
inet 200.230.200.10
allow {
localhost;
internas;
}

keys {
chaves_rndc;
chaves_privadas;
}
};

Com essa regra, abrimos um canal de controle, na porta padrão (953) da interface
externa do servidor (endereço IP 200.230.200.10) e demos permissões para acesso nesse
canal de controle para localhost e para internas onde a segunda é uma ACL previamente
declarada no nosso arquivo de configurações. Definimos também duas chaves, as
chaves_rndc e chaves_privadas para serem as nossas atribuições de assinatura digital,
pra segurança das transações DNS.

As chaves usadas foram previamente criadas. Veja Instrução Keys. A sintaxe de canais
de controle não é mais compativel com as implementadas na série 8 do BIND.

7.4.3 Instrução Keys;

A instrução keys é usada para se criar assinaturas digitais durante as transações DNS,
ou seja, é a característica principal da nova função 'TSIG' do BIND9. A declaração dessa
chave é definida por um nome de chave, chamado também de key_id, seguido de um tipo
de algorítmo a ser seguido, e finalmente a chave, propriamente dita. Atualmente apenas o
algorítmo hmac-md5 é suportado para a autenticação TSIG.

A sintaxe para criação de Keys é:

key key_id {
algorithm algorítmo;
secret chave;
};

Exemplo de criação de chaves TSIG:

 key servidores-externos {
algorithm hmac-md5;
secret "lZ12asdDfWwqqertTtys";
};

Foi criada então, uma chave de assinatura digital, com o nome servidores-externos. A
utilização dessa chave deve ser feita junto da instrução server, no arquivo de configuração
do BIND. Você vai ver mais detalhes na seção que aborda as Assinaturas de Transações
(Transaction SIGnatures, TSIGs) a seguir.

7.4.4 Instrução Include;

As instruções include são simples e comumente usadas em arquivos de configurações

de aplicações específicas, como aplicações php, portanto já são conhecidas. A função
dessa instrução é simplesmente chamar um determinado arquivo, no ponto em que a
instrução é lida pelo arquivo de configurações. Por segurança, pode ser usado, por
exemplo, para chamar sequências de bits de base 64, e interpretadas com keys.

A sintaxe é simples:

include arquivo;

Um exeplo: A chave no exemplo acima, servidores-externos. Se ela estivesse dentro de um

arquivo externo, com o nome servidores-externos.key (como exemplo...), poderia ser
chamada com o comando:

include servidores-externos.key;

Dentro do arquivo de configurações do BIND9.

7.4.5 Instrução Logging;

As instruções logging implementam uma amplas possibilidades de logar os eventos no

servidor de nomes. Essa instrução, assim como a instrução options só pode ser usada
uma única vez, no arquivo de configurações do BIND. A função do logging é definir várias
classes e formas de se logar as atividades no BIND, assim como os níveis de importância
(severity) dessas informações. Essas instruções de logging são chamadas de canais de
logs ou logging channels. As formas de se logar tais informações podem ser, em arquivo
(file) ou utilizando um daemon de logs locais, como o syslogd.

Essa é uma das mais importantes e funcionais novidades do BIND9. Nessa nova versão,
as definições de logs apenas passam a funcionar quando o parsing de toda a declaração
das regras de logs são lidas, ou seja, apenas quando o BIND termina de ler as instruções
de logging é que o log começa a ser gravado. Até isso acontecer, as mensagens são
enviadas normalmente ao daemon de logs do sistema. Em casos extremos, para se
solucionar problemas deve-se usar a opção "-g" para iniciar o BIND. Essa opção inicia o
named em foreground e com o nível alto de debug para a saída de informações.

São utilizadas duas especificações de chamadas junto à instrução logging. Elas são
chamadas de "channel" e de "category".
Veja a sintaxe básica da instrução Logging:

logging {
channel {};
category{};
};

Onde as possibilidades de instruções são definidas da seguinte forma:

logging {
channel "nome_do_canal" {
file "path(caminho)";
versions número_específico OU unlimited};
size tamanho;

syslog opção_syslog;
null;

severity critical | error | warning | notice | info | debug (nível) | dynamic;

print-category yes|no;
print-severity yes|no;
print-time yes|no;
};
category nome_da_categoria {
nome_do_canal1;
nome_do_canal2;
nome_do_canalX;
...
};
};

7.4.5.1 Especificação channel{};

Todas as espeficicações de logs tem sua saída definida em um ou mais canais de log,
chamados de channels. Você pode criar quantos canais quizer, para separar suas
definições de logs. Você vai indicar onde os logs serão armazenados, e de que forma, se
em forma de arquivo comum, ou um log criado por um daemon específico para isso. Ao
usar o Syslog a opção "local3" é comumente atribúida para informar o BIND da utilização
do daemon. Você vai também indicar o nível de informação que será logada, utilizando a
opção severity. Quando um nível não é aplicado, o padrão é a utilização do nível info.

A espeficiação null quando aplicada à um canal de logging, indica ao BIND para

destruir aquelas informações, sem grava-las em lugar algum.

A especificação file indica ao BIND para gravar todas as informações de acordo com o
nível definido no severity em um arquivo de texto, especificado no caminho dado. Em
ambientes seguros, utilizando ambiente chrootado, é recomendado uma definição
parecida com file info/tipo_de_log.log como foi tratado no nosso capítulo anterior. Esse
tipo de arquivo ainda pode ser controlado, pelo BIND, controlando que tamanho máximo
esse arquivo pode alcançar, e quantas versões do mesmo poderão existir. A opção size
define o tamanho máximo que esse arquivo vai ter. E a opção versions define quantos
arquivos de logs poderão automaticamente ser criados. Por exemplo, se você definir
versions 2; vão sempre existir os arquivos arquivo.log e arquivo.log.0 balanceados com o
tamanho especificado em size.

Se você espeficiar syslog como destino dos logs, então o sistema vai usar o syslogd
para prover todos os logs necessários, conforme especificados por severity. Contudo, é
requerido uma opção_do_syslog que define a forma como o syslogd vai logar essas
informações. A opção normalmente usada é a "local3". Para conhecer as outras opções
existentes, leia a man-page do syslogd (comando man syslog) ou os cometários no seu
arquivo "/etc/syslog.conf".

A opção severity indica um nível de "prioridade" que definirá os tipos de informações

que serão lançadas como saída de log pelo BIND. Os níveis de prioridade existentes são:
critical | error | warning | notice | info | debug (nível) | dynamic que só pelo nome já dão
uma noção correta do tipo de informações que são logadas. A prioridade debug inicia o
servidor de nomes com a opção "-d <número inteiro>" onde o <número inteiro> em
questão é o nível de debug. Essa opção é diferente da opção "-g", especialmente por definir
um nível de informação e por não manter o processo em foreground. Já a opção dynamic
utiliza a nível de syslog as prioridades que já estão sendo usadas pelo sistema.

As outras possibilidades, por analogia, são facilmente compreendidas. Se necessário

uma descrição desses níveis de prioridades pode ser obtida na man-page do BIND ou do
NAMED (man bind ; man named).

7.4.5.2 Especificação category{};

São as categorias de logging do BIND9. A utilização dessa categoria pode ser feita de
duas formas, a primeira é utilizar categorias como agrupamentos de canais de logs. Dessa
forma, você pode criar um nome para uma categoria, e dizer que aquela categoria conterá
as informações dos vários canais de logs que você criou com a função channel{}; e usar
essa definição posteriormente.

E a outra forma de utilização, a ideal, é utilizar as categorias de logs existentes no

BIND9. As categorias mantém informações sobre segurança, transferência de zonas, e
outros tipos de informações. Por exemplo, se declararmos a categoria category "security"
{ "canal_seguranca"; }; vamos estar indicando ao BIND que queremos que ele logue todas
as informações relativas a segurança no canal canal_seguranca que possivelmente
declaramos com a especificação channel{}.

As categorias existentes são:

- default: é a definição de categoria padrão, que é utilizada quando não são definidas
categorias para um canal de log. É similar ao local3 do syslogd em níveis generalizados de
informações.

- general: é um amontoado 'geralzão' de informações. A documentação do BIND9 diz

que, é onde foi colocada todas as informações que ainda não foram divididas em
categorias específicas. São informações genéricas.

- database: são informações referentes as dbs internas, utilizadas pelo named para
controlar a autoridade sobre zonas, reversos e dados de cacheamento.
 - security: informações de Negação ou Permissão de requisições sobre informações
feitas ao BIND.

- config: loga problemas e sucesso relacionado a leitura do arquivo de configurações. É

onde são armazenados os problemas de erro de sintaxe, por exemplo.

-resolver: resolução do serviço de nomes. São logadas informações sobre a resolução

de nomes, solicitadas por determinada requisição de algum cliente, como informações
recursivas feitas normalmente por servidores de cache (os caching name servers).

- xfer-in: loga informações sobre a transferência de zonas que o servidor está

recebendo.

- xfer-out: loga informações sobre a transferência de zonas que o servidor está

enviando.

- notify: informações referentes ao protocolo NOTIFY do BIND.

- client: loga informações referentes ao processamento de requisições feitas pelos

clientes.

- network: loga atividade de operações na rede, em relação ao servidor de nomes.

- updates: informações sobre atualizações dinâmicas do servidor de nomes (dynamic

updates).

- queries: atividades pertinentes a todo tipo de requisição de informações.

Agora já sabemos como definir nossos canais de logging e quais tipos de categoria
podemos usar para definir os níveis de informações à serem logadas. Veja agora um
exemplo de configuração básica utilizando a instrução logging:

logging {
channel "named_log" {
file "info/named.logs";
severity info;
print-category yes;
print-severity yes;
print-time yes;
};

channel "named_erro" {
syslog local3;
severity error;
print-category yes;
print-severity yes;
print-time yes;
};

category "security" {
"named_log";
"named_erro";
};
 category "xfer-out" {
"named_log";
};

category "xfer-in" {
"named_log";
};

};

Foram criados então, dois canais de logging, um canal de logs gerais, chamado
named_log e um canal de logs específico para armazenarmos informações de erros, o
named_erro. No canal de logs mandamos gravar as informações em um arquivo,
localizado no caminho "info/named.logs" e no canal de erros, mandamos logar com o
daemon syslod. Definimos as prioridades de informações com severity nos dois canais, de
mandamos logar as informações definidas pela categoria, pela prioridade e a hora em
questão, com as opções print. Depois definimos as categorias, atribuindo uma a uma ao
canal que nós criamos.

7.4.6 Instrução Options;

É a mais importante instrução na configuração do named.conf. Assim como na série 8

do BIND, as instruções options são as responsáveis por definir informações necessárias
para a inicialização do servidor de nomes, e informações sobre o comportamento do
mesmo, em vários casos. Contudo, na série 9 do BIND essa instrução ganhou algumas
novas funções, como version que permite que você altere a informação de versão do seu
servidor de nomes. Ótimo para segurança, já que um "curioso" mal intencionado não terá
acesso a versão do bind que você estará usando, via query.

Outra novidade, a opção named-xfer ainda existe, no BIND9, mas ela se tornou
obsoleta e não usável, já que o novo bind incorpora essa função automaticamente em seu
servidor. Portanto o programa named-xfer não é mais necessário para os servidores de
nomes secundários. A opção notify por exemplo, avisa quando uma zona autoritativa foi
modifcada, e está pronta pra transferência ou atualização.

São inúmeras as opções, e tratam desde informações primoridiais, as quais o BIND

simplesmente não funciona se não existirem, até informações de níveis técnicos e de
importância administrativa, como por exemplo, estatísticas de uso da memória do
servidor pelo servidoço de nomes, topologias, estatísticas de número de queries que não
puderam ser respondidas, etc.

Mas, vamos analisar um arquivo de configuração com as options básicas para

colocarmos nosso servidor de nomes no ar e funcionando. Inicialmente, indicarmos o
working directory pro nosso BIND, com a opção directory ""; e uma interface para o
servidor ouvir já são informações o bastante. Contudo vamos ver um conjunto mais
ilustrado de opções:

options {
directory "/";
allow-transfer { 200.230.200.9; };
allow-recursion { 200.230.200.0/24; };
statistics-file "/info/named.stats";
 dump-file "/info/dump.db";
pid-file "/info/named.pid";
version "Versao Indisponivel";
listen-on port 53 { 200.230.200.10; };
query-source address 200.230.200.10 port 53;
transfer-source 200.230.200.9 port 53;
auth-nxdomain no;
};

Vamos então entender essa nossa configuração básica.

A opção directory define o working directory para o nosso servidor de nomes. Funciona
da mesma forma que na versão 8 do BIND. No exemplo acima fica claro que nosso
servidor de nomes vai estar rodando em ambiente seguro (CHRoot Enviroment), ou seja,
CHRootado, porque definimos a raiz "/" como diretório de configuração do nosso servidor
de nomes.

Normalmente em ambientes não CHRootados, o working directory costuma ser

"/var/named", "/etc/namedb" ou "/usr/named".

A seguir, a opção allow-transfer define o endereço dos nossos servidores secundários,

ou seja, aqueles que tem permissão para efetuar transferências. Lembrando que você
pode usar uma ACL criado por você mesmo, para representar esse tipo de informação no
BIND9.

Por exemplo: allow-transfer { secundarios; };

Onde "secundarios" é uma ACL que define quais são nossos servidores slaves.

A opção allow-recursion define quais endereços são autorizados a efetuar buscas

recursivas de nomes, no nosso servidor. No nosso exemplo, nós permitimos toda a nossa
rede: 200.230.200.0/24 Você poderia ter usado uma ACL pra isso também.

dump-file indica o caminho onde o named deve salvar os databases em dump,

quando o comando rndc dumpdb for especificado. O padrão é named_dump.db.

A opção pid-file indica onde o BIND deve criar seu arquivo de texto com o número de
Process IDentification.

A opção version substitui a string specificada pela informação de versão do servidor de

nomes.

As outras opções já são conhecidas do BIND8. Indicam a porta e interface onde o

servidor deverá rodar, ouvir requisições de nomes e fazer as transferências de zonas. Já a
opção auth-nxdomain faz tradução dos bits AA (IPv4) quando necessárias. Apenas
recomendado em casos extremos. O padrão é auth-nxdomain no; mesmo se não
especificado.

Com essas opções você já pode colocar o seu servidor de nomes no ar, rodando com
traquilidade. Lembre-se de usar ACLs sempre que possível, porque ajudam na
administração e consequente segurança do servidor de nomes.
7.4.7 Instrução Server;

As instruções server denotam características à serem atribuídas a servidores de nomes

remotos. Definem o comportamento do nosso servidor em relação à outros servidores. São
necessárias nas definições de keys ao serem utilizadas junto à algumas novas
características do BIND9, como TSIG, etc...

A sintaxe para utilização dessa instrução é:

server endereço_ip {

bogus yes|no;

provide-ixfer yes|no;

request-xfer yes|no;

transfers número;

transfer-format one-answer | many-answers;

keys {strings [strings ...] };

};

A opção bogus da instrução server define um tipo de servidor que possivelmente está
dando informações errôneas sobre zonas e nomes. A palavra bogus pode ser livremente
traduzida como "bobo". Se um servidor for definido como bogus as informações providas
por eles serão consideradas com um nível mais baixo de prioridade. A padrão para essa
opção é "no". Até a data atual essa opção não havia sido implementada no BIND9.

A opção provide-ixfer define se o servidor, no caso um servidor primário (master) vai

delegar informação de atualização para um servidor secundário (slave) de forma
incremental. Prover essas informações de forma incremental significa dizer que o servidor
master vai apenas servir o slave com as informações que foram modificadas (novas
informações) em relação às informações que o servidor slave já possuia, ou seja, a
transferência não será mais da zona por completo, apenas dos trechos novos. Se essa
opção estiver desligada ("no") então a transferência de informações entre servidor primário
e secundário serão sempre não-incrementais, ou seja, sempre a zona inteira. Se não
especificada, essa opção assume o resultado global definido em options{};

A opção request-ixfer define que o servidor local vai estar agindo como servidor de
nomes secundário, e que vai tratar o servidor especificado na opção server como o
primário. Ao tentar atualizar suas zonas secundárias, ele sempre tentará que essas
requisições dejam incrementais, caso esteja definida opção yes. Se não especificada, essa
opção também assume o resultado global definido em options{};

A opção transfers define um número máximo de transferências concorrentes vindas do

servidor especificado. Se essa opção não for informada, o padrão é obedecer a cláusula
transfers-per-ns definida no options{};
 A opção transfer-format define o método de transferência dos resource records. Podem
ser definidos dois formatos, de resposta única (one-answer) e várias respostas (many-
answers). O método de várias respostas é mais eficiente, contudo só são compatíveis com
o BIND9, BIND8 e algumas versões atualizadas do BIND.

A opção key é usada para definir um nome de chave, o key_id definido por uma
instrução key, para garantir transação segura quando dois servidores estiverem se
comunicando.

7.4.8 Instrução Trusted-Keys;

Essa opção define uma trusted-key para um security-root do DNSSEC. DNSSEC vai ser
tratado ao longo dessa documentação, mas é necessário ter um conceito das trusted-keys.
Quando existe uma chave conhecida para um servidor de nomes remoto, mas essa chave
não pode ser obtida por transferência DNS porque o servidor não tem sua assinatura
digital corretamente configurada, então são definidas essas trusted-keys, com conteúdo
conhecido pelas keys, ou seja, chave de base 64, protocolo e agorítmo comuns, para
definir um security-root de confiança. Então a validação de requisições DNS são efeutadas
nos sub-domínios do security-root.

Você verá exemplos práticos de trusted-keys assim que abordarmos o DNSSEC.

7.4.9 Instrução Views;

Essa é uma nova e extremamente funcional característica do BIND9. A definição de

views permite diferentes visões e consequentes respostas distintas de nomes, de acordo
com quem esta fazendo essas requisições. Isso permite que a técnica de "DNS Spliting"
seja usada, sem a necessidade de rodar múltiplos servidores de nomes.

Cada instrução view permite a divisão das informações que o servidor de nome irá
responder, diferenciando pelos endereços IPs, que tipo de resposta cada cliente deverá ter.
Vale lembrar que a ordem das definições de views é importante, já que a resposta será
dada de acordo com a primeira cláusula view onde o endereço IP do cliente for
reconhecido.

A sintaxe para utilização de uma view é:

view nome_da_view {

match-clientes { lista_de_endereços };

conjunto_de_opções_da_view;

opção_de_zona;

};

As zonas definidas dentro de uma view, serão apenas vistas pelos clientes que tiverem
seu endereço reconhecido pela lista de acessos dessa view. As opções de view
(conjunto_de_opções_da_view) podem ser definidas quase em sua maioria, com as mesmas
instruções existentes na opção options{};. Quando não definidas, as opções globais
definidas em options{}; serão utilizadas.

Como uma zona comum de nomes, é necessário ter uma opção HINT para as zonas
definidas dentro de uma view. Se a opção "IN" for assumida como a classe da zona,
dentro da view, então uma HINT não precisa ser especificada, porque as classes 'IN' as
tem pré-configurada.

Veja um exemplo de configuração de views, que ajudará no entendimento das mesmas:

view "internet" IN {

match-clients { any; };

zone-statistics yes;

recursion no;

zone "eeviac.com.br" {

type master;

file "db.eeviac.externo";

};

};

view "intranet" IN {

match-clients { 192.168.1.0/24; };

zone-statistics yes;

recursion no;

zone "eeviac.com.br" {

type master;

file "db.eeviac.interno";

};

};

Agora, nessas duas views nós definimos visões distintas para a mesma rede, de acordo
com os clientes. Fizemos um DNS Spliting com um mesmo servidor de nomes, e
separamos as informações que apenas a nossa intranet pode ter acesso, das informações
que toda a internet pode ter.
 Usando a opção match-clients definimos quem pode ter acesso a qual zona (zone file)
definida com a instrução zone {}; que será explanada à seguir. Definimos opções de zona
estática e de recurssão. Note que, na primeira view foi usada uma ACL padrão, ou seja,
você pode fazer uso de ACLs que você criar para definir os acessos às views.

7.4.10 Instrução Zone;

Os arquivos de zonas são os mais importantes no servidor de nomes. São eles que
conterão as informações que o seu servidor de nomes deve responder. Esses arquivos de
Zone foram explicados em detalhes no Capítulo 5. No BIND9, esse arquivo ganhou
algumas características a mais que devem ser notadas. O número serial nos arquivos de
zonas agora devem ser do tipo "integer" ou seja, números inteiros. A cláusula $TTL (Time
to Live) se tornou obrigatória no cabeçalho de todos os arquivos de zonas.

As zonas podem ser definidas por classes, se não houver essa definição, por padrão o
servidor de nomes assumirá a classe "IN" indicando que essa é uma zona comum à
Internet. A zona CHAOS criada em 1970 pelo MIT também está implementada, assim
como a zona HESIOD (ou apenas HS), também criada pelo MIT para compartilhar
informações de usuários, grupos, impressoras, etc...

As demais características de zonas, como zona autoritativa, zona reversa, zona

secundária e as outras conhecidas devem seguir os mesmos moldes definidos no capítulo
5.

A zona do tipo HINT que define os Root NameServers (".") são obrigatórias na definição
do arquivo de configuração do BIND. A sintaxe de definição de uma zona dentro do
arquivo named.conf permanece igual. O conteúdo da zona agora assume novas
características, como informações "A6" para definição de endereçamento IPv6. Para
maiores informações sobre essas novas opções existentes, veja o manual online: man
named, man bind.

Uma declaração de zonas simples e similar a conhecida no BIND8:

zone "." {
type hint;
file "named.ca";
};

zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};

zone "eeviac.com.br"{
type master;
file "db.eeviac";

E um exemplo de como deve ser o conteúdo de um arquivo de zonas comum, do tipo

master:
$TTL 14400
@ IN SOA eeviac.com.br. root.eeviac.com.br. (
2000041003 ; serial
28800 ; refresh
14400 ; retry
3600000 ; expire
86400 ; default_ttl
)
@ IN NS eeviacbsd.eeviac.com.br.
@ IN NS ns.embratel.net.br.
@ IN NS xffa.eeviac.com.br.
@ IN MX 10 smtp.eeviac.com.br.
@ IN MX 20 xffa.eeviac.com.br.
@ IN A 200.230.200.10
rt IN A 200.230.200.1
ras IN A 200.230.200.2

Lembrando que as entradas "A" podem ser substituídas por "A6" se formos definir
endereçamento IPv6, e "DNAME" para delegar endereçamento reverso IPv6 de nomes.

Por enquanto exemplos práticos de construção de zonas autoritativas e reversas com

endereçamento IPv6 não é essencial, prometo adicionar essas adendas tão logo o
conhecimento de como faze-lo seja necessário. Você pode obter essas informações lendo
os documentos "Bv9ARM" contidos no diretório "docs" que acompanha o BIND9.

7.5 Serviço de Resolução de Nomes: LWRES;

Normalmente as pesquisas DNS sempre foram feitas através de resolvers internamente

linkados ao servidor de nomes. Devido à complexidade do endereçamento IPv6 e das
delegações DNAME de endereçamento IPv6 reverso, que sempre tem que ser simultâneas
as pesquisas IPv4 comuns, essa tarefa se tornou um pouco mais complexa, e então
optou-se por construir uma biblioteca de resolução separada.

Essa biblioteca se chama Lightweight Resolver Library, ou lwres.

A utilização dessa biblioteca, se tornou distinta do protocolo DNS comum, e a

utilização dela é feita através de uma simples comunicação utilizando o protocolo UDP.
Esse processo de comunicação entre a biblioteca e os clientes deve ser feita em conjunto
com um processo daemon, rodando na maquina local.

Esse processo local se chama Resolver Daemon (lwresd). Por padrão, as aplicações que
fazem uso da biblioteca lwres pra resolução de nomes, farão uma conexão UDP comum,
na porta 921 do endereço de loopback IPv4 (127.0.0.1), e é onde esse servidor de
resolução deve estar ouvindo. Essa definição de endereço e porta pode ser modificada,
usando a directiva "lwserver" no arquivo de configuração do resolver do sistema, o
"/etc/resolv.conf".

Devido ao fato que o lwres é uma solução alternativa ao cacheamento de nomes em

formatos comuns (IPv4/IPv6), o daemon lwresd é criado para ser usado com um mínimo
de configuração necessária, ou nenhuma configuração extra que seja, já que é desejável
que esse processo esteja sendo executado em cada máquina.
 Uma configuração mais profunda do lwresd pode ser feita utilizando um arquivo de
configurações similar ao named.conf contendo os mesmos tipos de informações,
declaradas da mesma forma, porém com nome de "/etc/lwresd.conf". Para
implementações futuras e práticas, o servidor de nomes (named) também pode ser
configurado para agir como um daemon lwres, utilizando o parâmetro lwres no arquivo de
configurações named.conf, o que torna essa nova característica realmente funcional.

Contudo, em servidores de nomes de grande escala, não será, futuramente

aconselhável configurar o servidor de nomes named para agir como um servidor de
resolução devido ao número de requisições diversas que isso pode causar na mesma porta
do servidor. Implementações de servidores distintos respondendo por cada daemon
independentemente, no mesmo endereço também serão aplicáveis para suportar com
eficiência o tráfego e quantia de informações que terão que ser gerenciadas futuramente.

A sintaxe de definição dentro do named.conf que faria o servidor de nomes rodar

também como um servidor de resolução é:

lwres {

listen-on { lista_de_endereço/lista_ACL };

view nome_da_view;

search {domínio; endereço_IP; };

ndots número;

};

A partir disso, o named vai passar a agir como um lowresd, na porta 53, do endereço
de loopback (127.0.0.1) ou na porta e endereço especificados na directiva listen-on{}; Pode
ser utilizado também as views da mesma forma como foram descritas anteriormente. Se
não houver uma view especificada, a view padrão é utilizada. As directivas "search" e
"ndots" tem a mesma função de quando utilizadas dentro do arquivo "/etc/resolv.conf".

7.6 Remote Daemon Name Control: RNDC;

O rndc é um aplicativo de administração implementado no BIND9, que permite que

sejam realizadas administrações remotas e locais de servidores de nomes. O rndc é
similar ao conhecido ndc, contudo, agora incorpora novas características de segurança e
serviços, que tornam seu uso mais funcional.

As sintaxes para a utilização do rndc são:

- rndc reload: recarrega as informações dos arquivos de configuração e de zonas.

- rndc reload zone [class ] [ view ]: recarrega uma zona específica.

- rndc stats: mostra estatísticas do servidor.

- rndc querylog: inicia o o log de pesquisas.

 - rndc stop: para o servidor de nomes, contudo, antes ele garante que alguma
tarefa em andamento (como transferências IXFR) sejam concluídas.

- rndc halt: para o servidor imediatamente, interrompendo qualquer tarefa que

esteja sendo executada.

O utilitário de administração rndc ainda pode ter várias outras funções futuramente
implementadas, em novas versões, de acordo com as necessidades. A utilização desse
aplicativo requer obrigatoriamente um arquivo de configuração, chamado de
/etc/rndc.conf.

Esse arquivo de configuração é necessário, porque toda a trasação administrativa feita

com o rndc é digitalmente assinada, e uma key de segurança é utilizada para autenticar
essas transações. Um arquivo de configuração pode ser chamado em local alternativo,
utilizando a opção "-c" do rndc.

O formato do arquivo rndc.conf é similar ao formato do named.conf, contudo, apenas 3

cláusulas podem ser utilizadas. São elas, a cláusula options{};, key{}; e server{};. São
essas as opções que associam à chave de assinatura digital ao servidor que se
comunicarão com essa chave em comum.

A cláusula options{}; tem duas opções, a primeira, default-server indica um endereço

ou nome de host, que referencia qual servidor será conectado, se a opção "rndc -s" não for
usada. A segunda, default-key indica o nome da chave, ou key_id que contém o segredo
que estabelecerá a conexão entre ambas as pontas, autenticando-as. Prevê-se a
implementação de uma terceira opção, default-port, para se definir uma porta padrão para
a conexão.

Então, uma configuração mínima do arquivo /etc/rndc.conf seria:

--------------------------------- rndc.conf - exemplo -----------------------------

key chave_rndc {

algorithm hmac-md5;

secret "lZ12asdDfWwqqertTtys";

};

options {

default-server localhost;

default-key chave_rndc;

};

--------------------------------- rndc.conf - exemplo -----------------------------

 Mas para que essa opção funcione, o servidor de nomes em questão (no caso 'localhost')
deveria ter uma regra de controle, permitindo essa conexão, e compartilhando uma chave
de assinatura digital idêntica no seu named.conf:

key chave_rndc {

algorithm hmac-md5;

secret "lZ12asdDfWwqqertTtys";

};

controls {

inet 127.0.0.1allow { localhost; };

keys { chave_rndc; };

};

Agora sim, qualquer comando deferido com o programa rndc estabilizaria uma conexão
digitalmente assinada na porta 953 da máquina local, e efetuaria a transação ordenada.

7.7 Assinatura de Transações DNS: Transaction SIGnatures, TSIG;

TSIGs são assinaturas digitais de transações DNS. É uma característica incorporada

no bind 9 que provê forma segura de comunicação entre dois ou mais servidores de
nomes, e aplicações administrativas em relação aos nameservers. Vamos discutir aqui as
bases de configurações dessas assinaturas, assim como a melhor forma de criar suas
chaves de comunicação e como usar essa função de segurança no BIND.

O BIND incorporou primariamente as TSIGs em comunicação de servidor-pra-servidor,

mas já existe algum suporte (limitado) à TSIG nos resolvers atuais da série 8 do BIND. Por
segurança, uma série de lista de controles de acesso recomendavelmente deveria ser
criada, mas é comprovadamente mais seguro o uso de chaves-comum de comunicação,
do que simplesmente o controle de acesso por endereço.

Existem algumas formas de se gerar uma chave secreta de comunicação entre duas
máquinas, contudo, é importante que se satisfaçam duas dependências. A primeira, é
óbvio, deve ser que as chaves conhecidas em ambas as pontas sejam idênticas, e a
segunda, que essas chaves sejam tratadas pelo mesmo nome. Portanto devemos definir
um nome e um segredo para criarmos uma chave secreta de autenticação.

A geração dos segredos compartilhados entre as chaves podem ser efetuados de duas
formas. A primeira é automatica, e a segunda, manual.

AUTOMATICA:
Para gerar uma chave de forma automática, com 16 bytes (128 bits) e algorítmo hmac-
md5, você pode por exemplo utilizar o comando:

# dnssec-keygen -a hmac-md5 -b 128 -n HOST <nome_da_chave>

 E então a chave é criada e armazenada em um arquivo com extensão ".private" no
diretório atual. O conteúdo do arquivo será uma chave de base-64, com no máximo 512-
bits, e essa chave poderá ser usada na criação de uma key.

MANUAL:
Para gerar uma chave de forma manual, você precisa apenas cumprir algumas
dependências. Basta saber que uma chave é apenas um conjunto randômico de
caracteres ascii, de base-64. A maioria dos caracteres ascii, contanto que não se inclua
caracteres especiais, são base-64, e portanto são caracteres válidos. O tamanho da chave
deve ter um número de caracteres múltiplo de 4. Portanto qualquer sequência de
caracteres ascii não especiais, com tamanho múltiplo de 4 é uma chave de segurança
válida. Ex: "IhQIU=ihIL-HLAui" é uma key válida.

Como ja dito, a chave deve ser conhecida por ambos os servidores que se comunicarão.
A chave deve ser definida com a opção key já descrita anteriormente, no arquivo
named.conf do servidor. Portanto é recomendado que esse arquivo não possa ser lido por
todos os usuários do sistema, apenas ao dono do processo (modo: 'chmod 700' ou
necessário), ou ainda que a chave esteja anunciada em um arquivo separado, com modos
de permissões seguros no sistema, e que pode ser chamado pelo arquivo named.conf com
a opção include.

Para instruir o servidor a utilizar aquela chave, deve-se usar a opção server{}; também
já descrita anteriormente. Existem ainda as opções de permissão para determinada
função à ser implementada. Essas opções são:

allow-query{};
allow-transfer{};
allow-update{};

Elas devem ser utilizadas no named.conf para definir regras de controle específicas
para as transações. São como ACLs do sistema, mas referente à comunicação baseada em
chaves. Por exemplo:

allow-update{ key chave_master_slave };

Essa definição portanto permite que sejam realizadas "Dynamic Updates" (atualizações
dinâmicas) apenas entre os hosts que tenham a chave "chave_master_slave" em comum.

Existem ainda outras formas de se gerar outras chaves, de forma automatizada,

chamadas TKEYs, mas as características importantes das TSIGs já foram cobertas. Para
informações adicionais, leia as documentações contidas no diretório docs/ que
acompanha o BIND.

7.8 DNS Seguro, DNSSEC;

O BIND9 agora conta com autenticação criptografada do DNS, utilizando o DNSSEC

(DNS Security). A definição de extensões criptografas de DNS são descritas na RFC 2535.

Basicamente, cria-se uma chave para a zona que se quer autenticar, e se especifica a
chave (de extensão .key) com a opção "$INCLUDE" no arquivo da zona que se quer
autenticar. Na prática, o BIND9 oferece várias ferramentas para a criação dessas chaves,
e para assinatura de zonas.
 Ambos, dnssec-keygen e dnssec-signkkey são ferramentas desenvolvidas para a criação
de chaves públicas (.key) e privadas (.private) de criptografia, e para assinatura de zonas.

O programa dnssec-signzone assina a zona específica e cria uma zona assinada que
deve ser chamada pelo arquivo named.conf. A sintaxe dos comandos pode ser facilmente
assimilada, lendo-se as páginas de manuais dos mesmos. DNSSEC ainda não está
completamente implementado no BIND9, portanto possíveis modificações ocorrerão nas
próximas versões.

7.9 Leitura Recomendada;

Como forma complementar de informação, é altamente recomendada a leitura do

Manual de Referência do Administrador do BIND 9, disponível em
www.isc.org/products/BIND/, e especialmente os documentos contidos dentro do
diretório bind/arm/ do pacote fonte do BIND9, assim como todas as páginas de manuais
online, que oferecem informações detalhadas de sintaxe e configuração.

7.10 Nota Conclusoria;

O conteúdo do Capítulo 7 desse documento visa introduzir o administrador de sistemas

FreeBSD Unix à nova versão do BIND, o BIND9, oferecendo um conjunto de informações
que permita ao mesmo assimilar todas as novas características do servidor de nomes de
Berkeley, inclusive aplicando-as de forma prática, seguindo os exemplos oferecidos.

A migração de um servidor de nomes atualmente com BIND série 8, também se mostra

fácil ao decorrer desse documento. A intenção é também prover formas práticas de
auxiliar o administrador a fazer uso das novas características do BIND9 durante o
processo de migração, garantindo especialmente um nível maior de segurança ao serviço.

Existem alguns tópicos de funcionalidades do BIND9 que não foram abordados

profundamente, entre os quais encontra-se principalmente a implementação prática de
um servidor de nomes totalmente baseado em endereçamento IPv6. Uma documentação
mais completa sobre o IPv6 se faz necessária para garantir um conhecimento prévio do
que será abordado.

Outras informações, e algum detalhe que por ventura não tenha sido considerado aqui,
pode ser encontrado no diretório "doc/arm/" em formatos DocBook XML e HTML
distribuído junto ao fonte do BIND9 nos endereços citados no início do capítulo.

Excluindo DNS Security (DNSSEC), toda informação aqui tratada foi implementada de
forma prática antes de ser documentada, em dois servidores distintos, o servidor principal
de internet da Faculdade de Tecnologia de Taquaritinga, e o servidor primário do provedor
de serviços internet (ISP) Mac3, de Ibitinga.

Espero que esse documento auxilie o leitor e supra suas necessidades básicas.
Dúvidas que não surgiram durante o curso, serão respondidas à medida do possível,
desde que a leitura dos capítulos prévios sejam consideradas. Estou disponível para
ajudar no que for possível: eksffa@fatectq.com.br
Bibliografia dos Capítulos 5, 6 e 7.

DNS and BIND

Paul Albitz and Cricket Liu
O'Reilly & Associates

Chroot-BIND HOWTO
Scott Wunsch, scott @ wunsch.org
http://www.losurs.org/docs/howto/Chroot-BIND.html

BIND 9 Administrator Reference Manual

version 9.1, Nominum INC,
www.nominum.com

The FreeBSD Handbook

Domain Names - Concepts and Facilities - RFC 1034
Domain Names - Implementation and Specification - RFC 1035
DNS Extensions to support IP version 6 - RFC 1886
DNS Support for Load Balancing - RFC 1794
Tools for DNS debugging - RFC 1713
Incremental Zone Transfer in DNS - RFC 1995
Name Server Operations Guide for BIND
Dealing with Lame Delegations
A Survey of DNS Tools

V.0.3br_pt

Se existirem perguntas ou comentários, por favor, envie-os para

walt@erudition.net. A versão mais recente desse documento vai estar sempre disponível
em www.freebsd-howto.com. Os direitos de reprodução desse documento são reservados.
Versão em português desse documento sob responsabilidade de Patrick Tracanelli
(eksffa@free.bsd.com.br) e Maurício Goto (freebsd-brasil@uol.com.br). A versão mais
recente do mesmo estará sempre disponível em
http://free.bsd.com.br/~eksffa/freebsd/ipfw.php

Sumário.

1. Informacoes gerais sobre a Filtragem de Pacotes de Rede.

2. Acionando o Ipfirewall(4).

2.1. O /etc/rc.firewall e firewalls com política aberta (OPEN

firewalls);
2.2. Carregando Rulesets (conjunto de regras);

2.2.1. Tipos de Firewall pré-definidos;

2.2.2. Tipos de Firewall Personalizado.

3. Sintaxe de regras básicas do Ipfw(8).

3.1. Listando Regras Ativas;

3.2. Comandos básicos e suas funções;
 3.3. Especificando Protocolos;
3.4. Especificando endereços de Origem e de Destino;

3.4.1. Uma introdução à Netmask e Bitmask;

3.4.2. Especificando Portas e Faixas de Portas.

4. Sintaxe de regras avançadas do ipfw(8).

4.1. A ação "unreach";

4.2. Controle de Interface e de Fluxo;
4.3. Combinando tipos de pacotes ICMP e TCP específicos;

4.3.1. icmptypes;
4.3.2. tcpflags, setup & established;
4.3.3. ipoptions;

4.4. Reconhecendo Pacotes Fragmentados;

4.5. Filtragem baeada em UID e GID.

5. Logs (Logging).

5.1. Propriedades de Logs;

5.2. Configurações de Logs do sistema;

5.2.1. Opções do Kernel;

5.2.2. Configurando o syslog(8);
5.2.3. Configuração do newsyslog(8) pra fazer
rotacionamento de logs (log rotation);

5.3. Configuração de log nas regras.

6. Introdução à filtragem 'Stateless' e 'Stateful' de pacotes.

6.1. Configurações 'Stateful' Iniciais;

6.2. Configurações 'Stateful' Avançadas;
6.3. Anatomia de uma Regra Dinâmica.

7. Traffic Shapping (controle de tráfego).

7.1. Probabilidade de Ocorrências (Probability Matching);

7.2. Dummynet;

7.2.1. Enfileiramento de pipes (Pipe Queues);

7.2.2. Máscaras de pipes (Pipe Masks);
7.2.3. Remanejamento de pacotes por pipes (Packet
Reinjection).

8. Fluxo do Tráfego pelo Firewall.

Apêndice A: Exemplos de Configurações de Firewall.

 1. Informacoes gerais sobre a Filtragem de Pacotes de Rede.

IPFW(8), a interface de comando do IPFIREWALL(4) é o utilitário mais

comum e mais popular pra implementar a filtragem de pacotes IP e controle de tráfego de
rede no FreeBSD, e é a ferramenta de FIREWALL nativa com a qual o FreeBSD trabalha
por padrão (mesmo considerando que, inicialmente o firewall é desabilitado a nível de
kernel). A forma lógica como o IPFW trabalha suas regras é parecida com a adotada em
muitos outros filtros de pacotes (Packet Filters), com excessão do IPFilter, que opera com
um padrão pra tratar as regras que é menos eficiente e requer bem mais cuidado na hora
de ajustar o firewall (se você tem familiaridade com o ipf(8), por exemplo, perceba a
utilização da chave 'quick', necessária para que o ipf(8) não traverse a regra inteira, todas
as vezes que ela é lida; entre outros fatores particulares de utilização do IPFilter). Mas
isso não tira a qualidade e o poder de implementação de firewalls do ipf(8), que tem
também suas próprias vantagens. A escolha final em relação a qual ferramenta de
Filtragem de Pacotes utilizar, é uma decisão pessoal, a não ser que você tenha
necessidade de alguma característica de um Firewall que o outro não possua, contudo,
nós vamos abordar uma comparação entre as duas ferramentas posteriormente.

Como já dito antes, ipfirewall(4) é um firewall por filtragem de pacotes, o

que significa que ele atua monitorando pacote-a-pacote todas as conexões, e a partir da
série 4.x do FreeBSD (FreeBSD 4.0), o ipfirewall(4) também pode gerenciar uma filtragem
por estado (stateful) de conexões mais rudimentares, de acordo com estados de conexão.
Esse comportamento é sempre transparente pros usuários, ou seja, ninguém vai notar
que existe um firewall presente, até que um evento aguardado seja bloqueado.

Um firewall costuma ser arquitetado de diversas formas, mas todas as

maneiras podem ser simplificadas com base em duas políticas de filtragem: aberto e
fechado. O Firewall que segue uma política aberta permite que todos os pacotes sejam
roteados por padrão, e bloqueia aqueles que pertencem a um tipo de conexão que não é
desejado, ou seja, "abre tudo e bloqueia os indesejados". Já o firewall que segue uma
política fechada, faz o inverso, bloqueando todo o roteamento de pacotes, e libera um a
um o tráfego de conexões permitidas. Essa segunda implementação proporciona um
firewall muito mais rígido, contudo sua configuração é bem mais trabalhosa, porque você
pode facilmente bloquear o tráfego de algum serviço que esteja sendo utilizado na rede.
Alguns protocolos estabelecem conexões dinâmicas, que são bem mais difíceis de se
prever, mas você tem como estar atento a esse tipo de situação.

2. Acionando o Ipfirewall(4);

O ipfirewall(4) pode ser iniciado de duas formas: você pode adicionar as

opções apropriadas no seu kernel através do seu arquivo de configurações, e compilar um
novo kernel pro seu sistema; ou você pode usar o kldload(8) pra carregar dinâmicamente
o módulo base do ipfw(8), o ipfw.ko, no kernel. As duas abordagens funcionam bem pra
adicionar um firewall(4) com configurações básicas, contudo, a compilação estática
proporciona, com pouca diferença, uma melhor performance, mas permite ainda que se
adicione opções mais detalhadas de configuração, como por exemplo, a geração e
limitação de logs.

Pra carregar o ipfw de forma dinâmica, simplesmente use o comando:

 root@eeviac~# kldload ipfw
root@eeviac~#

Pra acionar o ipfirewall(4) de forma estática, o equivalente seria adicionar a

seguinte linha no arquivo de configurações do seu kernel:

options IPFIREWALL

Em seguida a compilação e instalação acionaria o ipfirewall(4) estático no

kernel, logo após a próxima inicialização do sistema.

Contudo, as coisas não são tão simples quanto parecem, se você

simplesmente seguir os passos descritos acima quando estiver na frente da máquina, vai
perceber que existe a necessidade de algumas opções adicionais pra poder usar a estação.
Se você prestar atenção nos conceitos de política de firewall citados acima (aberto e
fechado), vai entender porque o uso do equipamento vai se complicar muito, se você não
perceber que o firewall usa uma política padrão fechada. Se você simplesmente adicionar
o ipfirewall(4) sem nenhuma configuração posterior, todo o tráfego de rede vai ser
bloqueado, ou seja, nenhum pacote será roteado. Isso fatalmente pode se tornar um
tormento se você for adicionar o firewall remotamente. É claro que esse tipo de dor de
cabeça pode ser evitada, mesmo considerando que não é recomendado acionar o
ipfirewall(4) remotamente, tanto de forma estática quanto dinâmica.

Se, de qualquer maneira, você quiser carregar o ipfirewall(4) de um

computador remoto, então recomendados que se faça da seguinte forma:

root@eeviac~# kldload ipfw && \

ipfw -q add 65000 allow all from any to any
root@eeviac~#

Assim você vai automaticamente adicionar uma regra pra permitir todo o
tráfego da rede, ao invés de bloquea-lo, evitando assim que você perca a conexão com a
máquina remota. De qualquer forma, é recomendável que se carregue o ipfirewall(4) dessa
maneira em máquinas locais também, especialmente se elas estiverem conectadas em
rede, pra não perder uma conexão em andamento.

Acionar o ipfirewall(4) no kernel, de forma estátita em uma máquina remota,

contudo, requer um pouco mais de trabalho. O motivo é simples, quando você termina de
instalar um novo kernel, você é obrigado a rebootar a sua máquina, ai sim, a partir da
próxima inicialização ela irá utilizar o novo kernel. Contudo se você somente adicionar o
ipfirewall(4) no kernel, assim que o sistema estiver no ar, ele não vai estar roteando os
pacotes, ou seja, você não vai conseguir estabelecer uma conexão remota novamente com
a máquina. Então antes de inicializar o sistema com um novo kernel você tem que definir
alguma maneira pra máquina aceitar a sua conexão, pra que assim você não seja
bloqueado pelo seu próprio firewall.

Pra você fazer isso, basta adicionar duas linhas no seu rc.conf, uma que vai
acionar o firewall na inicialização da máquina, e outra pra definir o tipo de firewall que vai
ser iniciado. No caso firewall do tipo aberto (OPEN). Então basta adicionar as seguintes
entradas no seu /etc/rc.conf:

firewall_enable="YES"
firewall_type="OPEN"
 Existem ainda outros tipos de firewall previamente definidos no
/etc/rc.firewall, mas nós vamos tratar deles posteriormente. Por enquanto vamos
começar com uma política de firewall aberta (OPEN). Ainda existe uma alternativa muito
boa pra se definir uma política aberta como padrão pro ipfw(8) no kernel. Você pode
simplesmente adicionar a seguinte linha no arquivo de configuração do seu kernel:

options IPFIREWALL_DEFAULT_TO_ACCEPT

Nesse caso, as opções que nós adicionamos no rc.conf anteriormente não

serão *necessárias*, porque nós não vamos *precisar* do /etc/rc.firewall pra configurar
uma política aberta de firewall, porque essa política já vai ser iniciada por padrão no
kernel. Contudo, ainda que você escolha definir uma política de firewall padrão no kernel,
é interessante adicionar aquelas opções ao /etc/rc.conf porque posteriormente nós vamos
usar o /etc/rc.firewall pra carregar nossas próprias regras de configurações de firewall.
Adicionar essas opções ao /etc/rc.conf também é válido se você vai carregar o kernel
dinâmicamente, porque se eventualmente seu sistema for reinicializado, o módulo ipfw.ko
não vai ser carregado de forma automática. As funções de carregamento do firewall pelo
/etc/rc.conf permite-nos carregar o módulo ipfw.ko automaticamente.

Ainda existem outras opções pro ipfirewall(4) que são possíveis se nós
formos acionar o firewall de forma estática no kernel, até o início da série 4.x do FreeBSD
algumas dessas opções não podiam ser acionadas se não fosse de forma estática no
kernel, mas nas versões mais recentes foram definidas algumas variávies do kernel,
mutáveis via sysctl(8), que não restringem mais essas opções ao kernel estático. Além do
IPFIREWALL_DEFAULT_TO_ACCEPT nós ainda temos as seguintes opções:

options IPFIREWALL_VERBOSE
options IPFIREWALL_FORWARD
options IPFIREWALL_VERBOSE_LIMIT=#

A opção IPFIREWALL_VERBOSE permite logar o tráfego de pacotes com o

ipfirewall(4), ecoando informações sobre atividade dos pacotes pro syslogd(4), em cada
regra que tiver a opção "log" definida. Vamos aborda-la com mais detalhes posteriormente.

A opção IPFIREWALL_FORWARD permite que os pacotes sejam

redirecionados para outros hosts, utilizando o comando "fwd" do ipfirewall(4).
Redirecionar o pacote (FORWARD) é fazer com que ele siga de um ponto específico (host,
rede, porta) para outro. Vamos tratar desse assunto com mais detalhes ao longo do
documento.

A opção IPFIREWALL_VERBOSE_LIMIT=# define um limite de pacotes que

serão logados para uma regra específica. Dessa forma, o syslogd(8) não será
sobrecarregado com mensagens relativas à atividades do ipfirewall(4), os comentários do
kernel para essa opção diz que isso é uma forma de evitar negação de serviço com os logs
gerados para algumas regras de firewall, caso um possível ataque gere muitas ocorrências
da mesma regra. O "#" deve ser substituído com o número de vezes que se deseje que as
atividades de cada regra seja logada. Dessa forma, se definirmos, por exemplo
IPFIREWALL_VERBOSE_LIMIT=100 (padrão), quando existirem 100 ocorrências da
mesma regra, as informações sobre a atividade de pacotes daquela regra deixará de ser
logada.
 Se você usa IPv6, as seguintes opções no kernel terão efeito correspondente
sobre as ações do firewall quanto a pacotes IPv6:

options IPV6FIREWALL
options IPV6FIREWALL_VERBOSE
options IPV6FIREWALL_VERBOSE_LIMIT=100
options IPV6FIREWALL_DEFAULT_TO_ACCEPT

Pra habilitar as mesmas opções do ipfirewall(4) sem recompilar o seu kernel,

você vai definir as variáveis correspondentes por meio do sysctl(8), por exemplo:

eksffa@eeviac~# sysctl -w net.inet.ip.fw.verbose=1

eksffa@eeviac~# sysctl -w net.inet.ip.fw.verbose_limit=100
eksffa@eeviac~# sysctl -w net.inet.ip.forwarding=1

Ainda existem mais quatro opções relacioadas ao ipfirewall(4) que podem

ser definidas no kernel, mas não serão discutidas no momento, porque não são
necessárias para a implementação básica de um firewall. Essas opções envolvem
situações mais complexas e específicas de roteamento de pacotes, e vamos tratar delas
assim que começarmos a tratar essas configurações.

2.1. O /etc/rc.firewall e firewalls com política aberta (OPEN

firewalls);

Ainda que você defina ou não o tipo de firewall que você vai estar
trabalhando, sempre que a opção firewall_enable="YES" é adicionada no rc.conf e o
sistema é iniciado, o /etc/rc.firewall é lido e executado também, a partir das
configurações definidas no rc.conf, e os seguintes comandos são sempre adicionados ao
ipfw(8):

${fwcmd} add 100 pass all from any to any via lo0
${fwcmd} add 200 deny all from any to 127.0.0.0/8

A variável ${fwcmd} é definida anteriormente no rc.firewall, implicando

quando o ipfw(8) vai ser executado de forma silenciosa (opção -q) ou não. A primeira regra
em questão, permite todo tráfego proveniente da interface de loopback (a lo0), e a segunda
regra bloqueia todo o tráfego direcionado à rede localhost (127.0.0.0). A primeira regra é
necessária pra permitir comunicação inter-processos locais (local IPC), e a segunda regra
evita que qualquer pacote externo adentre o endereço de host local (localhost address),
que é o endereço de loopback, protegendo assim o tráfego local. Se essas regras não
existirem e o firewall tiver uma política padrão fechada, você vai encontrar problemas na
inicialização de alguns serviços, especialmente serviços RPC(3), entre outros problemas.

Por isso vale ressaltar a impostância de se definir o firewall da forma correta,

onde o uso do /etc/rc.firewall via rc.conf é altamente recomendável. Se você fizer a opção
por um script shell que carregue todas as suas regras e que seja executado sempre que o
sistema iniciar, você deve ficar atento a essas e outras regras que não devem faltar ao seu
firewall.

Em seguida, quando você define um firewall do tipo "OPEN" (aberto) no

rc.conf, o rc.firewall ativa a seguinte regra no firewall:
 ${fwcmd} add 65000 pass all from any to any

Essa regra permite que todo tráfego externo seja aceito como entrada (com
excessão pro loopback, já que a rede localhost é previamente bloqueada) e todo o tráfego
interno seja aceito como saída. A mesma função do IPFIREWALL_DEFAULT_TO_ACCEPT
no kernel. Se a política aberta é definida no kernel, a regra número 65535 vai ser
automaticamente carregada como "allow ip from any to any" no lugar de "deny ip from
any to any", posteriormente adicionando a regra número 65000. Isso cria uma
redundância de política de firewall aberta. Então, é mais indicado definir o tipo de firewall
como "UNKNOWN" (desconhecido) se você adicionou a política aberta
(IPFIREWALL_DEFAULT_TO_ACCEPT) no kernel, e não quer permitir mais nenhuma
regra do rc.firewall. Para isso, inclua as seguintes linhas no seu /etc/rc.conf:

firewall_enable="YES"
firewall_type="UNKNOWN"

Se você quer simplesmente habilitar o firewall para trabalhar algumas

regras e ver como o ipfirewall(4) do FreeBSD funciona, ou ainda, apenas bloquear alguns
hosts específicos, e manter as suas configurações propícias às suas próprias regras, então
você pode seguramente pular pra nossa seção 3.

Contudo, se sua intenção é usar algum dos conjuntos de regras nativas já

existentes no rc.firewall, ou criar seu próprio conjunto de regras, então as opções "OPEN"
ou "UNKNOWN" não são suficientes. Então não pule pra seção 3 (lol).

2.2. Carregando Rulesets (conjunto de regras);

Existem duas opções distintas em relação à um comjunto de regras pro seu

firewall: a primeira opção é usar uma das definições de firewall já existentes no rc.firewall,
e a segunda é criar sua própria definição, com seu próprio conjunto de regras. Os autores
do firewwall nativo do FreeBSD, ipfirewall(4), recomendam o segundo caso, por duas
rasões simples:

- Você pode customizar suas regras de firewall pra satisfazerem da melhor

forma as suas necessidades, sem nunca tocar no rc.firewall, que pode ser mantido como
uma referência geral sempre que você precisar.

- Você vai ser obrigado a se familiarizar com o uso do ipfw(8) e sua sintaxe,
se tornando mais experiente na definição de firewall, e ficando mais a vontade com o
ipfw(8).

2.2.1. Tipos de Firewall pré-definidos;

É óbvio que a decisão final é a do administrador da rede, ou do responsável

pelo firewall, no caso você que está lendo esse documento. Se você preferir usar os
conjuntos de regras de firewall pré-definidos no rc.firewall, então é recomendado que você
leia todas elas, pra se tornar familiar e saber exatamente como cada tipo de firewall
funciona, antes de ativar qualquer um dos tipos pré-definidos. O controle que gerencia
qual definição de firewall carregar é feito pela opção firewall_type="" no rc.conf. Além de
"OPEN" existem ainda mais 3 tipos de firewall disponíveis:
 "CLIENT" - Essa definição de tipo de firewall (firewall_type) permite todo o
tráfego proveniente da rede local (por exemplo, uma rede interna atrás de NAT) pra ela
mesma. Bloqueia pacotes fragmentados, permite que mensagens de email, resoluções de
nomes (DNS) e NTP sejam enviadas pra dentro e fora da rede, e não permite nenhuma
máquina que esteja fora da rede interna iniciar conexões TCP com máquinas dentro da
rede. Se a rede estiver por trás de uma implementação básica de NAT sem nenhuma
opção de proxie carregada isso já seria impossível. Esse tipo de firewall funciona com
política aberta ou fechada, definida no kernel, ou seja, não faz diferença se você colocou
IPFIREWALL_DEFAULT_TO_ACCEPT ou IPFIREWALL_DEFAULT_TO_DENY como padrão.

"SIMPLE" - Esse tipo de firewall é uma contradição. Apesar do nome

SIMPLE, ele é muito mais complexo que a definição CLIENT, e requer que o usuário tenha
algum conhecimento nos padrões RFC de Internet pra poder entender suas definições de
regras de firewall. Essa regra vai evitar spoofing (técnica onde uma máquina se faz passar
por outra, alterando seu endereçamento IP) não permitindo a entrada de nenhum pacote
que tenha um endereço de retorno igual ao endereço de qualquer host dentro da rede
interna. Vai bloquear todos os pacotes endereçados como de redes privadas, conforme
definido na RFC 1928, evitando o tráfego pra dentro ou fora da rede, e vai bloquear ainda
todas as redes não-roteaveis, conforme definido no Internet-Drafts da IETF (disponível em
http://www.ietf.org/internet-drafts/draft-manning-dsua-03.txt). Esse tipo de firewall vai
permitir tráfego de e-mail, de WWW, de DNS, e NTP, e vai permitir também pacotes
fragmentados, e em relação às conexões TCP iniciadas por hosts fora da rede, o firewall
não vai apenas bloquear, como na definição CLIENT, vai também logar todas essas
tentativas.

"CLOSED" - Tecnicamente essa definição não é um conjunto de regras de

firewall, porque não adiciona nenhuma regra. Na verdade, aqui acontece tudo que nós
insistimos que você deve evitar, ou seja, estabelece uma política fechada, negando todo e
qualquer tráfego da rede (exceto o tráfego via lo0 que nós vimos anteriormente que é
controlado por padrão). Essa definição simplesmente desabilita todos os serviços IP na
rede, a não ser que no seu kernel você tenha adicionado a regra de política aberta. Então,
ajustar o firewall pra CLOSED vai ser necessário em casos *extremos* onde você prefere
(ainda que temporariamente) tirar toda a sua rede de funcionamento. Ou seja, não defina
como padrão no rc.conf.

2.2.2. Tipos de Firewall Personalizado;

Se você decidiu estabelecer um conjunto de regras customizado, então é

recomendável que você especifique um arquivo, ao invés de um dos tipos de firewall
abordados acima. A maneira de se estabelecer esse tipo personalizado de firewall é a
mesma, utilizando a opção firewall_type no rc.conf, contudo, basta indicar o caminho
(path) pro seu arquivo de regras:

firewall_enable="YES"
firewall_type="/etc/rc.firewall.rules"

Dessa forma você vai poder definir sua própria configuração de firewall no
arquivo /etc/rc.firewall.rules, o qual será carregado sempre que seu firewall for iniciado.
Se você preferir ainda que seu firewall seja iniciado de forma silenciosa, basta incluir no
rc.conf:

firewall_quiet="YES"
 O formato do seu conjunto de regras será apresentado de forma um
pouquinho diferente nesse arquivo, em relação ao que você encontra no rc.firewall. O
motivo é simples, o rc.firewall é um 'shell script' sh(1) escrito de forma que possa rodar
por si próprio, enquanto o arquivo que define as suas regras personalizadas estão ali
simplesmente para serem processadas pelo ipfw(8). A principal diferença é que você não
vai usar nada correspondente à variável ${fwcmd} usada no rc.firewall. Simplesmente as
regras. Posteriormente, vamos construir um arquivo de regras próprio, e então vamos ver
isso passo-a-passo.

3. Sintaxe de regras básicas do Ipfw(8);

A sintaxe das regras de firewall no FreeBSD são simples. Qualquer regra

pode ser adicionada pelo console, com o comando ipfw(8). Antes de nos aprofundarmos
nas sintaxes das regras do ipfirewall(4), contudo, vamos verificar como podemos listar as
regras que estão ativas no momento.

3.1. Listando Regras Ativas;

A forma mais simples possível de se listar as regras ativas no firewall:

root@eeviac~# ipfw list

Dessa forma, você vai estar listando todas as regras ativas no momento,
seguindo a ordem do número da regra.
Por exemplo:

root@eeviac~# ipfw list

00101 deny log logamount 100 tcp from any to 192.168.1.0/24
12345
00102 deny log logamount 100 tcp from any to 192.168.1.0/24 21
00103 allow tcp from any any
65535 deny all from any to any

Dessa forma, ainda que, a regra número 00103 tenha sido adicionada antes
da regra 00101, a de número menor será mostra antes, porque a ordem das regras
também influi na forma como o ipfirewall(4) vai se comportar.

Pra mostrar a data e hora da última vez que um pacote coincidiu com uma
regra basta usar a opção timestamp do ipfw(8):

root@eeviac~# ipfw -t list

00101 Fri Sep 21 06:31:23 2001 deny log logamount 100 tcp from
any to 192.168.1.0/24 12345
00102 Tue Sep 18 00:33:12 2001 deny log logamount 100 tcp
from any to 192.168.1.0/24 21
00103 Sat Sep 22 19:12:15 2001 allow tcp from any any
65535 deny all from any to any

root@eeviac~# date
Sat Sep 22 19:12:24 GMT 2001
 Ou seja, nesse caso, a última vez que a regra 00101 bloqueou um pacote foi
na madrugada do dia anterior, a regra 00102 bloqueou um pacote também aos 33
minutos de 2 dias atrás, e o último pacote permitido pelo firewall foi há 9 segundos.
Detalhe no comando date posterior que ilustra a data corrente.

Por último, se nós queremos listar o número de vezes que um pacote

passou (ou foi bloqueado) por uma regra, e o número de bytes que esse tráfego gerou,
podemos fazer o seguinte:

root@eeviac~# ipfw -a list

ou
root@eeviac~# ipfw show

Os dois comandos vão apresentar as mesmas informações, dispostas da

mesma maneira. A primeira coluna é o número da regra, em ordem como ela é verificada.
A segunda coluna informa quantas vezes aquela regra coincidiu com um pacote, seguido
do (terceira coluna) número de bytes que trafegaram pela regra, e finalmente a regra em sí.
Existem algumas sintaxes curtas pra esses comandos. Por exemplo, "ipfw s" tem o mesmo
efeito que "ipfw show"; "ipfw l" o mesmo que "ipfw list", etc.

3.2. Comandos básicos e suas funções;

A partir de agora nós vamos, gradualmente, analisarmos cada opção e

comandos disponíveis pra se construir um conjunto de regras de firewall. Por enquanto
não vamos abordar regras com as opções de stateful, ou seja, estaremos trabalhando com
regras stateless. Durante os nossos exemplos, não vamos estar utilizando o programa de
controle do firewall (o /sbin/ipfw), que deve preceder cada um dos nossos comandos,
caso estejamos configurando as regras de forma manual, pelo console do FreeBSD. O
padrão abordado é como deve ser quando estamos trabalhando com um arquivo de regras
pra ser passado pro ipfw(8) via firewall_type="/caminho/pro/arquivo.firewall" no rc.conf.

add 1000 allow all from any to any

Esse é o exemplo mais simples de uma regra. Nós já encontramos a mesma

regra anteriormente, com uma única diferença, que era o número da regra. Lembre-se
que, na seção 2.1 quando nós discutimos sobre tipos de firewall "OPEN" (aberto) nós
trabalhamos com o parâmetro "pass", que é como ele foi usado no rc.firewall. Bom,
acontece que "pass", "allow" e "permit" são sinônimos pro ipfirewall(4), eles tem o mesmo
efeito, contudo as variações permitem que o administrador fique o mais a vontade
possível para escrever as suas regras quase que de forma literal. Nessa regra, "all" (todos)
os pacotes vindos de "any" (qualquer) lugar para "any" (qualquer) destino são permitidos
("allow").

No ipfirewall(4), grande parte das vezes, sempre que um pacote combinar

com uma regra, o ipfirewall(4) pára de examinar as outras regras pra aquele pacote, ou
seja, a ordem como as regras são processadas no firewall do FreeBSD são do tipo "first
match wins" onde, a primeira constatação do pacote evita que as outras sejam lidas. Por
isso é extremamente importante estar atento a ordem (número) das regras. Sob
circunstâncias especiais as outras regras podem ser procesadas.

Então, de forma geral, a sintaxe mais simples pro ipfw(4) é:

 <comando> [<número da regra>] <ação> <protocolo> from <origem> to <destino>

Os <comandos> mais importantes são "add" e "delete". Uma simples

tradução seria o suficiente pra explicar que "add" adiciona uma regra e "delete" a exclui.
O <número da regra> varia de 0 até 65535, e indica a ordem que essas regras serão
processadas no firewall, portanto a última regra sempre define a política padrão do
firewall no kernel. Mesmo se você tiver uma política de firewall aberta (OPEN) definida no
seu /etc/rc.conf, a última regra vai sempre indicar a política do kernel. Isso é ótimo
porque, como a ordem de busca das regras para de processar ao encontrarem uma regra
que combina com o pacote, e se a penúltima regra é a de número 65000, definida pelo
rc.firewall pra permitir todo o tráfego da rede, então todo tráfego vai ser liberado, mesmo
que a última regra (65535) negue todos os pacotes, já que essa regra nunca vai ser
processada.

"<ação>" na sintaxe do ipfw(8) pode ser uma das seguintes:

"allow" | "pass" | "permit" | "accept" - Quando uma regra define essa ação,
sempre que um pacote combinar com essa regra, será permitido seu roteamento pelo
firewall, e o processamento das regras *pra esse pacote* termina.

"deny" | "drop" - Qualquer pacote que combinar com uma regra cuja ação
seja "deny" ou "drop" são silenciosamente bloqueados pelo firewall, e o processamento das
regras pra esse pacote termina.

add 1100 deny all from any to any

Essa regra nega todos os pacotes vindos de qualquer origem e indo pra
qualquer destino.

"reset" - Quando um pacote encontra uma regra com essa ação, o pacote é
bloqueado, e o ipfirewall(4) tenta enviar um sinal (flag) de TCP Reset (RST) pro endereço
de origem do pacote. O processamento das regras pra esse pacote termina. Como esse
tipo de regra apenas se aplica pra pacotes TCP, o protocolo especificado na regra deve ser
"tcp", para que apenas tais pacotes sejam processados por essa regra, e não todos (proto
"all") os protocolos de pacotes IP.

Vale notar que o uso do "reset" pode ser muito interessante pra enganar
ferramentas que escaneiam as redes (network scanners), já que normalmente podem
detectar um serviço por trás de uma porta filtrada, mesmo que ele esteja por trás de um
firewall de bloqueio. Por outro lado, se alguém estiver praticando um ataque do tipo
"network flood" em uma porta específica a qual o ipfirewall(4) está configurado para
responder com pacotes RST, isso duplicaria o uso da sua banda de rede. Uma solução
simples é bloquear, com uma regra prévia o endereço da máquina que está agindo dessa
forma, endereço esse obtido de forma dinâmica por monitoramento.

add 1200 reset tcp from any to any

Essa regra 'precária' (risos) bloquearia todas as conexões TCP vindas de

qualquer destino, indo para qualquer origem, e responderia com um pacote RST para
cada uma delas.
 "count" - Todos os pacotes que combinarem com uma regra cuja ação seja
"count", determinará que o ipfirewall(4) incremente o contagem de pacotes, ou seja, a
saída de "ipfw show" indicará mais uma ocorrência de pacotes nessa regra. Motivos
estatísticos óbvios. O processamento das regras do firewall continuam a buscar por
outras regras que combinem com os pacotes.

add 1300 count all from any to any

add 1310 count all from 200.230.50.0/24 to 192.168.1.0/24

Essa (primeira) regra incrementa o número de vezes que um pacote passou

pelo firewall, vindo de qualquer lugar e indo pra onde quer que seja. Já a segunda regra
conta quantos pacotes, dentre todos, estariam sendo enviados da rede 200.230.50.0/24
(origem) pra rede 192.158.1.0/24 (destino). Uma observação aqui: se o processamento
das regras fosse terminado quando um pacote encontra uma regra cuja ação seja "count",
então, no exemplo acima a regra 1310 não teria serventia alguma.

"skipto <número da regra>" - Todos os pacotes que combinem com uma

regra cuja ação seja "skipto <número>" vão fazer com que o ipfirewall(4) continue
processando esse pacote e buscando ocorrência nas regras que sejam de ordem maior ou
igual ao <número da regra> indicado pela ação.

add 1400 skipto 1800 all from 192.168.1.0/24 to any

Essa regra faria com que todo o tráfego vindo da rede 192.168.1.0/24 e
indo pra qualquer destino seja processado pelas regras a partir da regra de número 1800

"reject" - Essa ação é pouco utilizada atualmente. Quando um pacote

combina com uma regra cuja ação seja "reject", então o ipfirewall(4) bloqueia esse pacote
e responde com uma mensagem ICMP do tipo "host unreachable", dando a impressão que
a máquina se encontra fora da rede. Essa é uma forma não silenciosa de negar o tráfego
pelo firewall, contudo, assim como a ação "reset", essa ação também aumenta o uso da
sua banda de rede.

3.3. Especificando Protocolos;

Protocolo (proto) em "protocolo" na sintaxe básica de uso do ipfw(8), é o

protocolo de comunicação que você quer que aquela regra combine. Definições de
protocolos do tipo "ip" ou "all" são especificações gerais que englobam todos os protocolos.
Os protocolos mais comuns são "icmp", "udp" e "tcp", mas a relação de protocolos com os
quais o ipfirewall(4) trabalha é enorme. Na verdade são todos os protocolos possíveis de
uma rede. Para uma lista completa das possibilidades, fique a vontade:

root@eeviacbsd~# cat /etc/protocols

3.4. Especificando endereços de Origem e de Destino;

O endereço de destino e de origem de um pacote tem o mesmo formato em

uma regra de firewall. Eles podem ser um nome, definido no /etc/hosts e resolvido por
DNS, pode ser um endereço IP, um endereço de rede com máscara de rede
(bitmask/netmask) e, ainda podem definir uma ou várias portas, se o protocolo for tcp ou
udp. Usar nomes ou endereços IP é indiferente, basta atentar ao fato que a resolução de
nomes via DNS pode mudar sem seu conhecimento prévio.

add 1000 allow all from minhamaquina to outramaquina

add 1100 deny all from 10.0.0.5 to any

A primeira regra permite todo o tráfego vindo da "minhamaquina" para a

"outramaquina", e a segunda regra nega toda conexão da máquina 10.0.0.5 para qualquer
outra estação. Sempre que um pacote coincidir com uma regra do firewall, o
processamento pra aquele pacote termina, e o pacote é permitido ou negado, de acordo
com a ação definida pela regra. Esse é um exemplo muito simples de um filtro baseado
em estações, ou "host-based filtering", que filtra de acordo com o destino ou origem do
pacote. Um firewall por filtragem de redes funciona de forma similar, distinguindo-se
apenas a notação de redes, onde é necessário definir a máscara de subrede (netmask) ou
ainda o bitmask. Vejamos:

add 2000 allow all from 192.168.0.0/16 to any

add 2100 deny all from any to 10.0.0.0:255.0.0.0

A primeira regra permite todo o tráfego de pacotes vindo da rede cujo

conjunto de endereços IP começa em 192.168.0.0 até 129.168.255.255. A regra usa uma
máscara (bitmask) pra indicar a abrangência do endereçamento da rede. A máscara em
bits também conhecida como bitmask especifica quantos bits do endereço de rede
(192.168.0.0) devem permanecer o mesmo pra cada pacote. Nesse caso, os primeiros 16
bits dos 32 bits do endereço vão continuar os mesmos. Como os primeiros 16 bits são os
primeiros dois octetos do endereçamento da rede, então todos os endereços cuja origem
seja a indicada nos dois primeiros octetos (ou nos 16 bits iniciais), nesse caso a rede
192.168, serão permitidos por essa regra.

A segunda regra tem uma função similar, utilizando as máscaras de rede. A

máscara de rede (netmask) indica quantos bits do endereço de rede deve ser monitorado
pelo regra do firewall. No exemplo acima, a segunda regra (número 2100) tem a máscara
de rede 255.0.0.0. O primeiro octeto dessa regra é definido como 'bits altos', ou seja, os
primeiros 8 bits são 'bits altos', o que indica pro firewall que apenas os pacotes cujos
primeiros 8 bits do endereço da rede devem ser filtrados. Como os primeiros 8 bits da
rede é igual a 10, então todos os pacotes cujo endereço de destino seja 10 no primeiro
octeto (ou seja, toda a faixa de 10.0.0.0 até 10.255.255.255) vão combinar com essa regra,
e então serão bloqueados, como indicado na ação da regra (deny).

O firewall do FreeBSD oferece ainda a possibilidade de inverter a expressão

apresentada na regra com o comando "not". Por exemplo, para que o ipfirewall(4) bloqueie
todos os pacotes que não seja da estação 192.168.0.3:

add 1000 deny all from not 192.168.0.3

3.4.1. Uma introdução à Netmask e Bitmask;

O princípio básico que envolve máscaras de rede e bits de rede (netmask e

bitmask) são simples, mas frequentemente confundidos por pessoas que não tenham
muito conhecimento em redes, e ainda requer um pouco de noção de números binários. É
muito mais prático se nós trabalharmos com endereço IP em sua forma binária, contudo,
a confusão que existe entre os conceitos binários e decimais costuma ser decisiva pra
alguém sem muitos conhecimentos em rede. De qualquer forma, para uma referência
rápida, a seguinte tabela ilustra que faixa de endereçamento IP corresponde a qual
bitmask e respectivo netmask em uma classe C de rede. Alguns breves exemplos de
bitmask e netmask adicionais são ilustradas, denotando algumas definições pra redes
maiores.

Bitmask Netmask Total de Ips IPs Usáveis

32 255.255.255.255 1 1
31 255.255.255.254 2 1
30 255.255.255.252 4 2
29 255.255.255.248 8 6
28 255.255.255.240 16 14
27 255.255.255.224 32 30
26 255.255.255.192 64 62
25 255.255.255.128 128 126
24 255.255.255.0 256 254
...
22 255.255.192.0 16320 16318
20 255.255.128.0 32768 32766
16 255.255.0.0 65536 65534
12 255.128.0.0 8.388608+e6 8.388606+e6
8 255.0.0.0 256^3 (256^3)-2
0 0.0.0.0 (todos IPs) 256^4 (256^4)-2

Como você pode ver existe um padrão definido. O número de endereço total
de uma rede sempre sobra a partir da máscara que lhe foi atribuida, e o número total de
Ips disponíveis (que podem ser usados por estações) é sempre o total disponível na rede
menos 2 (total – 2). O motivo também é simples, para cada rede/subrede existem dois
endereços IP reservados para o endereço da rede e para o endereço de broadcast da rede.
O último octeto da máscara de rede (netmask) começa com 255 e sempre se decrementa
em valores múltiplos de 2, enquanto o bitmask se decrementa em múltiplos de 1.

Vamos ver, de forma sucinta como usar a tabela acima. Vamos descobrir
então qual é a faixa de IPs que compõe uma subrede cujo endereço seja:

172.16.100.32/28

O primeiro detalhe ao qual atentamos é que o endereço da rede é

172.16.100.32, então sabemos que a subrede inicia nesse valor, ou seja, o endereço de
rede é 192.16.100.32. Então percebemos que o bitmask do endereço é 28. Isso quer dizer
que todos os primeiros 28 bits do endereço são 'bits altos', ou seja, são endereços que não
mudam. Portanto, concluímos de forma lógica que temos apenas 4 bits ajustados como
'bits baixos', já que um endereço completo de rede tem 32 bits, e 28 são altos (conforme
indicado pela bitmask) subtraindo 28 de 32 restam-nos 4 bits (os bits baixos). Sabemos
agora que existem apenas 2 valores possíveis para cada bit, já que o endereçamento não
decimal é binário. Então elevamos dois (possibilidades binárias) à quatro (bits): 2^4.
Agora sim já temos o número de estações que aquele bitmask está indicando: 2^4 = 16.

Agora basta somar: 172.16.100.32 + 16 = 172.16.100.48, portanto a faixa

de endereçamento IP varia de 172.16.100.32 até 172.16.100.48; Se olharmos na tabela
apresentada cima, veríamos que 16 endereços IP corresponde a um bitmask de 28, que é
o nosso caso. Dessa forma poderíamos ter evitado todo esse cálculo matemático para
encontrarmos o valor exato. Mas, vale lembrar que, nem sempre essa tabela vai estar
disponível pra você consultar, a menos que você a imprima e ande com ela na carteira,
portanto é muito mais valioso aprender como o endereçamento funciona e aplicar os
cálculos necessários. Aprenda uma vez e use sempre.

3.4.2. Especificando Portas e Faixas de Portas;

Você pode também controlar o tráfego de conexões baseando-se em

filtragem de portas. Isso possibilita que você permita ou negue acesso a um serviço em
específico ao invés de controlar o tráfego das estações todas. A definição das portas em
uma regra de firewall com ipfw(8) é feita após a declaração do endereço de origem ou do
endereço de destino, simplesmente definindo a porta após o endereço. Uma faixa de
portas pode ser especificada com um hífen, podem ser separadas por vírgula, ou ainda,
em casos mais elaborados, pode-se usar um netmask pra definir a faixa de portas. É
importante lembrar que você não pode definir "all" como protocolo na regra que especifica
portas, porque nem todos os protocolos trabalham com portas.

add 1000 allow tcp from any to 172.16.0.5 25

add 1100 allow tcp from any to 172.16.0.5 1021-1023
add 1200 allow tcp from any to 172.16.0.5 21,22,23
add 1300 deny udp from any to 192.168.0.5 1024:8

Na primeira regra, todos os pacotes TCP cujo destino é a porta 25 da

estação 172.16.0.5 são permitidos pelo firewall. Na segunda regra todas as conexões TCP
cujo destino seja qualquer porta da faixa 1021 até 1023 da estação 172.16.0.5 também
são permitidas pelo ipfirewall(4). Na terceira regra, todos os pacotes TCP destinados às
portas 21, 22 ou 23 na estação 172.16.0.5 é permitida. E, finalmente na quarta regra,
todos os pacotes UDP destinados pra faixa de portas de 1024 à 1028 na estação
172.16.0.5 são bloqueados. A apresentação da faixa de portas na última regra é
interessante, porque faz uso de uma netmask pra declarar a mesma. Mas a matemática
também é bem simples. Como agora estamos tratando de Bitmask pra porta 1024, o valor
pra ela é 10 bits, e como a máscara indica 8 bits, tiramos 8 possibilidades de 10,
restando-nos apenas 2 bits. Como o valor de cada bit é binário, elevamos os bits
disponíveis (2) aos valores possíveis (binário = 2): 2^2, então temos 4 portas que compõe a
faixa de endereçamento da porta 1024, ou seja, de 1024 até 1024+4 = 1024 até1028.

O uso de máscaras para definição de faixas de portas são raramente usadas,

mas são bem mais interessantes do que o uso de bitmask ou netmask pra endereços IP,
já que o número de bits de uma porta varia dependendo da porta em questão. Por isso o
uso de hífen é recomendado pra se definir uma faixa de portas, e vírgulas quando se
deseja definir várias portas em uma mesma regra. Mas a declaração de máscaras para as
portas indica que o firewall foi construído por alguém que domina completamente as
definições de endereçamento de redes, e é estétitamente mais proveitoso.

4. Sintaxe de regras avançadas do ipfw(8);

Embora o overview anterior sobre as criações de regras do ipfw(8) seja o

bastante pra cobrir a maioria dos cenários e necessidades simples de um firewall, ele se
mostra solenimente curto pra muitas situações mais complexas, como por exemplo,
quando o sistema possui mais de uma interface de rede é possível que se queira definir
ações especiais para algumas combinações de pacotes, ou então que se queira um maior
controle sobre o direcionamento do tráfego. Então, vamos expandir o modelo de sintaxe
que estávamos trabalhando no ipfw(8) para o seguinte:
 <comando> [<número da regra>] <ação> [log [logamount <número>]] <proto>
from <origem> to <destino> [<interface-spec>] [<opções>]

Todas as opções entre colchetes fazem menção à novas funcionalidades que

iremos discutir nessa seção. Nós vamos inclusive cobrir uma nova "ação" que não foi
relatada anteriormente. A Sintaxe pode parecer inicialmente confusa, mas nós vamos com
calma, e montaremos as regras aos poucos.

4.1. A ação "unreach";

Primeiramente, vamos introduzir uma nova "ação":

"unreach <código>" - Qualquer pacote que combine com uma regra cuja
ação seja "unreach", serã respondido com um código 'ICMP unreach' (código ICMP de
indisponibilidade), e posteriormente a leitra do conjunto de regras será terminada. As
possibilidades de códigos pro 'ICMP unreach' pode ser indicada por número ou por nome.
Segue agora uma breve lista de 'ICMP unreach codes' (os códigos em questão) e seus
nomes correspondentes. Se você não sabe onde esses códigos são utilizados, não tem
porque você tentar usa-los:

net 0 net-prohib 9
host 1 host-prohib 10
protocol 2 tosnet 11
port 3 toshost 12
needfrag 4 filter-prohib 13
srcfail 5 host-precedence 14
net-unknown 6 precedence-cutoff 15
host-unknown 7
isolated 8

4.2. Controle de Interface e Fluxo;

Uma das mais importantes funcionalidades do ipfw(8), que não foi

comentada anteriormente na seção 3 desse documento é o controle de fluxo e de interface,
ou seja, a possibilidade de criar regras que verifiquem os pacotes de acordo com uma
interface em especial (aplicável quando você tem um sistema com múltiplas interfaces de
rede). Essas regras podem identificar de onde esses pacotes estão vindo, e em que direção
estão indo. Até agora o senso de direção que nós adotamos simplesmente definia os
endereços de origem e de destino, mas usar apenas essas opções pra definir de onde um
pacote está vindo ou pra onde ele está indo via firewall não é muito confiável. Quando
você quer filtrar pacotes que estão apenas entrando ou saindo pela rede, as opções "in" e
"out" podem ser utilizadas com precisão. Ambas opções ("in" e "out") correspondem ao
campo "interface-spec" no modelo de sintaxe dado anteriormente, e normalmente, são
definidas próximas ao final de cada regra, antecedendo qualquer possível opção extra.
Dessa forma, quando decidirmos filtrar todos os pacotes vindos de qualquer lugar e indo
pra qualquer lugar, poderíamos definir:

add 1000 allow all from any to any in

Pra filtrar pacotes indo através de uma interface em particular, podemos

usar a opção literal "via", seguida do nome da interface. Dessa forma, se estivermos
usando uma placa de rede 3Com 3c59x PCI, sua interface será "xl0". Pra filtrarmos
qualquer pacote, vindos especialmente dessa interface, com origem e destinos
quaisqueres, o seguinte seria o suficiente:

add 1100 allow all from any to any in via xl0

Ou talvez, se você tiver um sistemas com múltiplas interfaces, e quiser

filtrar todos os pacotes vindos de qualquer lugar e indo pra qualquer lugar, mas que
esteja ao menos saindo via *alguma* interface, pode fazer o seguinte:

add 1200 allow all from any to any out via any

Você vai notar que, quando você listar as regras de firewall, as entradas que
estiverem usando "in" ou "out" combinadas com "via", não apresentarão a utilização do
"via" mas apresentará a citação "recv" ou "xmit", dependendo da definição de um "in" ou
um "out" respectivamente. Veja só:

root@eeviac~# ipfw add 7000 allow all from any to any out via xl0
root@eeviac~# ipfw list | grep 7000
07000 allow ip from any to any out xmit xl0
root@eeviac~#

Portanto, você pode usar "recv" ou "xmit" no lugar de "via" quando você for
criar alguma regra que faça uso de "in" e "out", contudo isso não é preciso, o ipfirewall(4)
distingui se a interface está recebendo o transmitindo o dado, e, além do que, essa
definição pode confundir usuários não experientes.

No geral, essas opções oferecem muito mais controle sobre o tráfego da rede
em um sistema de interfaces múltiplas, e qualquer outro sistema em geral, visto que elas
permitem a filtragem de pacotes específicos vindo para o firewall, saindo por ele, e se
deslocando através de uma interface especificada.

4.3. Combinando tipos de pacotes ICMP e TCP específicos;

Pacotes ICMP, TCP e IP são apresentados em vários formatos distintos.

Esses tipos de pacotes são definidos por várias _flags_ (opções de identificação). Nós
podemos filtrar cada um desses tipos usando uma das seguintes opções do ipfw(8), ao
final de cada regra:

4.3.1. icmptypes (tipos icmp);

"icmptypes <tipo>" - Essa opção filtra o pacote ICMP do <tipo> definido, e

inverte a opção se uma '!' (exclamação) for devinida antes do <tipo>, ou seja, todos os
pacotes que não forem desse tipo serão combinados. Existe, atualmente 15 tipos
diferentes de pacotes ICMP que podem ser filtrados; cada um é definido por um número.
Você pode ainda especificar faixas de 'icmptypes' utilizando hífen ou separando-os por
vírgula. Os 15 tipos de pacotes ICMP são:

0 - Echo Reply (Resposta de Echo)

3 - Destination Unreachable (Destino Indisponível)
4 - Source Quench (Origem extinta)
 5 - Redirect (Redireção)
8 - Echo Request (Pedido de Echo)
9 - Router Advertisement (SPAM de roteamento? :-))
10 - Router Solicitation (Pedido de Roteamento)
11 - Time-to-Live Exceeded (TTL Excedido)
12 - IP header bad (Cabeçalho IP malformado)
13 - Timestamp Request (Pedido de Timestamp)
14 - Timestamp Reply (Resposta de Timestamp)
15 - Information Request (Pedido de Informação)
16 - Information Reply (Resposta de Informação)
17 - Address Mask Request (Pedido de Máscara de Rede)
18 - Address Mask Reply (Resposta de Máscara de Rede)

Se você ficou curioso pra saber como esses tipos ICMP, especialmente o tipo
3, correspondem aos códigos de indisponibilidade que podem ser criados com a opção
"unreach", então, saiba simplesmente que o tipo 3 identifica qualquer um desses códigos,
ou seja, todos. Usar filtros de pacotes ICMP é muito útil, especialmente pra controlar
ping; por exemplo, você pode permitir que qualquer cliente dentro da sua rede interna
pingue qualquer estação pra fora da rede, enquanto você bloqueia que qualquer estação
externa pingue o seu gateway, ou qualquer outro cliente interno. As três regras a seguir
definem isso facilmente:

add 1000 allow icmp from any to any out icmptypes 8

add 1100 allow icmp from any to any in icmptypes 0
add 1200 deny icmp from any to any in icmptypes 8

A primeira regra permite que todos os pacotes icmp do tipo 8 (pedido de

echo) possam trafegar pra fora do firewall. A segunda permite que todos os pacotes icmp
do tipo 0 (resposta de echo) entrem pelo firewall, e a regra seguinte bloqueia todos os
pacotes icmp do tipo 8 de entrarem. Em resumo, permite que qualquer cliente faça um
pedido de echo pra fora, e permite a entrada da resposta pra dentro do firewall, e não
permite que ninguém de fora faça um pedido de echo pra dentro do firewall, ou seja,
todomundo protegido pelo firewall pode pingar qualquer estação externa, mas ninguém de
fora pode pingar dentro. Naturalmente essas opções só podem ser definidas quando o
protocolo da regra for "icmp".

4.3.2. tcpflags, setup & established;

"tcpflags <flag>" - Essa opção filtra qualquer pacote TCP cujo cabeçalho
contenha alguma das flags (opções) identificadas. Uma definição inversa também pode ser
utilizada se colocarmos uma '!' (exclamação) antes da <flag>, dessa forma filtrando todos
os pacotes TCP que não possuam a <flag> em questão. Veja as opções de 'flags':

fin - Request for connexion termination (pedido de finalização da conexão)

syn - Request for connexion initiation (pedido de inicialização da conexão)
rst - Reset Connexion (Redefinição da Conexão)
psh - Push Flag (opção Push)
ack - Acknowledgement (conhecimento, concordância com a conexão)
urg - Indicate Urgent OOB data (indica um OOB de dados urgentes)

A <flag> SYN é a mais interessante, visto que ela é enviada quando uma
conexão TCP é iniciada. Por ser tão importante, existe inclusive uma opção separada do
ipfw(8) dedicada especialmente pra definir pacotes TCP cujo cabeçalho tenha a flag SYN
ajustada. Essa opção se chama "setup". É claro que só podemos trabalhar com a opção
"setup" quando o protocolo indicado é o "tcp".

"setup" - Qualquer regra contendo essa opção vai filtrar todos os pacotes
TCP cujo cabeçalho indique a flag SYN ajustada. Dessa forma, se quizermos
simplesmente negar todos os pacotes TCP que estiverem entrando no firewall com o
cabeçalho SYN definido, temos duas opções:

add deny tcp from any to any in tcpflags syn

OU SIMPLESMENTE:

add deny tcp from any to any in setup

Em cada uma dessas regras, a mesma ação é tomada: todos os pacotes TCP
SYN vindos de qualquer (any) origem para qualquer (any) destino serão negados. Vale a
pena ilustrarmos a necessidade do protocolo ser "tcp" quando trabalharmos essas regras.

"established" - Exatamente como existe uma opção especial que identifica

um pedido de inicialização de conexão TCP ("setup"), existe também uma opção que
identifica quando uma conexão já está estabelecida, ou seja, ja foi iniciada. Pela grande
importância de facilitar o controle de conexões TCP, as opções "established" e "setup"
foram disponibilizadas, dessa forma oferecendo facilidade na criação de regras. Utilizando
estas opções (ou mesmo suas definições nativas correspondentes às "tcpflags") podemos
ter inicialmente um controle de conexões TCP mais simples. Essa é a base de
implementações "stateful" de um firewall. Vamos trabalhar com elas de forma mais
detalhada depois.

4.3.3. ipoptions;

"ipoptions <flag>" - Finalmente podemos trabalhar com alguns pacotes IP

específicos. A <flag> que define um tipo de pacote IP é nomeada SSRR (para: Strict Source
Route), LSRR (para: Loose Source Route), RR (para: Record Packet Route), e TS (para:
Timestamp). Se você não sabe pra que serve cada uma dessas flags, então não haverá
necessidade de construir regras que façam uso delas.

4.4. Reconhecendo Pacotes Fragmentados;

Pacotes fragmentados podem ser filtrados com a opção "frag" do ipfw(8). Na

grande maioria dos casos, os pacotes fragmentados devem ser bloqueados pelo firewall.
Receber um número grande de pacotes fragmentados pode indicar a eminência de um
ataque do tipo DoS (Denial of Service - ou Negação de Serviço). Mesmo considerando que
o FreeBSD, e a maioria dos outros sistemas UNIX de verdade não são sucetíveis a esse
tipo de ataque, os sistemas Windows são frequentemente muito vulneráveis. Dessa forma,
se você tem clientes Windows por trás do firewall, dentro da sua rede, é recomendável
bloquear pacotes fragmentados pra protege-los.

Quando você for usar a opção "frag" pra filtrar (e bloquear) os pacotes
fragmentados, tem duas regrinhas básicas que você deve seguir. A primeira é que você
não pode usar "frag" quando também estiver usando a opção "tcpflags"; você define
qualquer pacote fragmentado, ou não define nenhum. A segunda: você também não pode
utilizar o "frag" se estiver especificando portas TCP ou UDP; você bloqueia todos os
pacotes fragmentados, não importando pra qual porta ou serviço eles estejam sendo
enviados. Dito isso, podemos facilmente definir uma regra pra negar todos os pacotes
fragmentados que estiverem entrando na rede:

add deny all from any to any in frag

4.5. Filtragem baeada em UID e GID;

Uma poderosa função que outros firewall (como o IPFilter) não possuem é a
filtragem de pacotes baseada em GID/UID. O Ipfirewall(4) tem a capacidade de filtrar
pacotes de acordo com o UID ou GID do dono do processo o qual originou uma conexão.
Por motivos lógicos só se pode filtrar pacotes que tenham sido gerados por processos
locais. As opções a serem utilizadas são "gid" ou "uid" seguidos do GID/UID ou do nome
do usuário/grupo que estivermos filtrando.

Um uso em potencial dessa função é restringir o número de IPs virtuais em

um servidor de shell. Se você quer se assegurar que um ou mais Hosts Virtuais não
poderão ser usados por ninguém mais que o dono do IP virtual, você pode definir uma
regra baseada em filtragem de UID, para que, dessa forma, todo o tráfego do host virtual
que não seja do próprio usuário seja bloqueado:

add allow tcp from any to 172.16.0.10 in

add allow tcp from 172.16.0.10 to any out uid patrick
add deny tcp from 172.168.0.10 to any

Essas regras permitem que apenas o usuário 'patrick' vai poder utilizar a
alias de IP (Apelido de IP, IP-Alias ou IP vhost) 172.168.0.10 pra estabelecer conexões TCP
pra fora da rede. Ninguém mais será permitido pendurar Bots, Clientes de IRC ou
qualquer outra coisa que precise estabelecer conexão TCP (quase tudo) nesse endereço IP.
O protocolo UDP também pode ser usado para filtragem de pacotes baseada em UID/GID,
contudo nenhum outro protocolo fora esses dois podem.

Outra utilização possível pra UID/GID seria habilitar limitação de uso de

banda para cada usuário, ao invés de limitar pra cada estação ou rede. Por exemplo, você
pode definir um grupo de usuários que tenham contas rápidas de FTP, definindo uma
regra pro GID em questão, e em contrapartida ter um grupo de usuários de shell que não
precisam de muita banda. Vamos ilustrar outras limitações de bandas definidas por GID
posteriormente, quando estivermos cobrindo o "traffic shaping" com ipfirewall(4).

Por motivos de segurança, talvez seja necessário voce logar o tráfego de rede
de um usuário em particular, e nesse caso o filtro baseado em UID/GID também viria
bem a acalhar. Na verdade sempre que se queira definir um comportamente distinto do
firewall com base no usuário que acessa o serviço, o UID/GID do ipfw(8) sempre vem bem
a acalhar. Uma pequena dica é sempre definir as regras baseadas em UID/GID antes das
outras regras, visto que o ipfirewall(4) termina a verificação da lista das regras quando
um pacote combina com alguma das regras em uso. Isso garante desempenho e evita que
se bloqueie ou permita um pacote antes de verificar qual usuário originou o tráfego.

5. Logs (Logging);
 5.1. Propriedades de Logs;

As vantagens de manter os logs do firewall ativo são óbvias. A possibilidade

de verificar posteriormente quais conexões foram negadas, de que endereços elas vieram,
pra que rede ou estação elas estavam indo, se o conteúdo dos pacotes eram fragmentados
(indicantivo de muitos ataques de negação de serviço – DoS), enfim, possibilita saber onde
as conexões estão sendo feitas, por quem e quando. Em especial, os logs de firewall são
importantes pra rastrear crackers ou pessoas má intencionadas.

Mas logar também tem o seu lado negativo, se você não for cuidadoso.
Dependendo do tipo de dado que você está logando você pode se perder com a
abundância de mensagens, e também utilizar muito espaço em disco pros arquivos de
logs. Ataques de negação de serviço que tendem a sobrecarregar discos rígidos é um dos
tipos mais antigos de atividade má intencionada, e por incrível que pareça ainda é
sinônimo de perigo pra administradores imprudentes. Por isso a importância de se definir
que tipos de regras serão logadas. Normalmente logar pacotes permitidos de serviços
públicos (como WWW) não é uma boa indéia, visto que o próprio serviço (servidor WWW)
também mantém logs das atividades de acesso, e a frequência de pacotes em um serviço
como esse é muito grande.

Por outro lado, o que a maioria dos novos administradores que

experimentam quando eles habilitam o ipfirewall(4) pra logar, é o seu terminal abarrotado
com mensagens sobre a atividade de pacotes. Esse pequeno inconveniente é o resultado
da combinação de:

- estar logando regras que combinam com pacotes muito frequentes;

- não ter desabilitado logs pro console e pros terminais de root (péssima
idéia);
- não estar controlando limite de logs com o IPFIREWALL_VERBOSE_LIMIT;

5.2. Configurações de Logs do sistema;

5.2.1. Opções do Kernel;

Pra habilitar os logs do ipfirewalll(4) no FreeBSD, você tem que incluir ao

menos as seguintes opções no kernel (não se esqueça de iniciar seu sistema com o novo
kernel após a compilação do mesmo):

options IPFIREWALL_VERBOSE

Você ainda pode habilitar a seguinte opção:

options IPFIREWALL_VERBOSE_LIMIT=#

Nós já mencionamos essas opções anteriormente, quando estavamos

revendo a ativação do firewall. Essa segunda opção do kernel limita o número de
mensagens consecutivas enviados ao sistema de logs do FreeBSD, o syslogd(8), quando
dada regra do firewall é ativada. Portanto, quando você aciona essa opção no kernel, o
número de mensagens consecutivas relacionada a uma conexão em particular é limitada
ao valor (número) específico. Considere o seguinte:

options IPFIREWALL_VERBOSE_LIMIT=10
 Com essa entrada definida no seu kernel, apenas 10 mensagens
consecutivas a respeito de determinada conexão serão logadas no syslogd(8), e todas as
outras ocorrências seriam identificadas sob uma expressão genérica como por exemplo:

Jan 29 03:26:55 meuservidor last message repeated 45 times

Normalmente essas mensagens são logadas em /var/log/messages além de

serem impressas no console do sistema também. Se você quiser modificar esse
comportando do syslogd(8), você terá que editar o /etc/syslog.conf. O syslog.conf(5)
oferece uma flexibilidade considerável em relação à configuração sobre as formas com que
o syslogd(8) vai tratar as mensagens do sistema. O limite definido pra
IPFIREWALL_VERBOSE_LIMIT fica à critério do administrador, mas valores acima de 10
já proporciona um tráfego alto de mensagens em servidores muito requisitados. Mas se
você quer definir um arquivo separado pra logar tudo de forma distinta, ao invés de
simplesmente logar no arquivo padrão (/var/log/messages), isso pode ser feito também, e
ainda, se você julgar ter espaço em disco o bastante pra trabalhar com rotacionamento de
logs (Log Rotation) você não precisa definir a opção de limite de verbosidade no Kernel.

5.2.2. Configurando o syslog(8).

Você pode configurar o syslogd(8) pra logar as atividades do ipfirewall(4) em

um arquivo separado, seguindo três passos relativamente simples:

1) Crie o seu novo arquivo de log para o ipfw(8) e, como alternativa, crie
também o diretório de logs que você achar conveniente. Vamos assumir então que você
quer que todos os logs relativos ao ipfirewall(4) sejam armazenados em
/var/log/ipfw/ipfw.log. Dessa forma você vai ter que criar o diretório em questão
(/var/log/ipfw) e em seguida o arquivo de log (ipfw.log) sob tal diretório, pra isso vai
utilizar o comando touch(1):

eksffa@eeviac~# mkdir /var/log/ipfw && touch /var/log/ipfw/ipfw.log

eksffa@eeviac~#

Tenha certeza que o diretório e arquivo em questão não tenham permissões

de leitura pra outros usuários senão o dono do arquivo, por questões óbvias de segurança.

2) Configure o syslog.conf(5) pra enviar todas as mensagens relativas ao

ipfirewall(4) pro arquivo /var/log/ipfw/ipfw.log. A forma mais fácil de fazer isso é
adicionar as seguintes linhas no final do syslog.conf(5):

!ipfw
*.* /var/log/ipfw/ipfw.log

Atente pra usar <TAB> (tecla tab) nesse arquivo ao invés de espaços
simplesmente. Mesmo assumindo que usar "tabs" não é obrigatório no FreeBSD pro
arquivo /etc/syslog.conf, é de bom costume fazê-lo, caso você trabalhe também com
outros UNIX, cuja maioria não aceita espaços no syslog.conf(5). Portanto mesmo você
podendo ignorar a mensagem de advertência no início do /etc/syslog.conf, é sempre bom
manter o bom hábito seguro de usar o syslog.conf(5) da forma indicada por ele.
 Você vai reparar que as mensagnes do tipo "last messages repeated # times"
(ou seja: últimas mensagens repetidas # vezes) serão também logadas, além desse arquivo,
pra qualquer outro cujo syslog.conf(5) aponte as seguintes entras:

*.err, kern.debug, *.notice

E ainda, o console também irá receber todas essas mensagens, como definido
na linha:
*.err;kern.debug;auth.notice;mail.crit /dev/console

Lembre-se que o console na verdade é apenas o ttyv0 (ALT+F1). Os consoles

virtuais e pseudo terminais se comportarão de forma distinta em relação à mensagens.
Por padrão as seguintes linhas definirão quando as mensagens forem enviadas pra outros
terminais:

*.err root
*.notice;news.err root
*.alert root
*.emerg *

As linhas *.err e *.notice irão logar mensagens do kernel e também as

exibirão no terminal onde o usuário especificado estiver logado. Note que o usuário em
questão é o 'root', então, como por padrão você não deve logar como root a toa, o usuário
root será sempre alertado. Não se recomenda de forma alguma que essas linhas sejam
comentadas, informações de log para o root e pro terminal são extremamente importantes
pra se manter atento a qualquer coisa errada que estiver acontecendo com o servidor. Se
por bom senso você costuma estar muito logado com outro usuário que não seja o root,
também é considerável configurar o syslogd(8) pra alertar o seu usuário.

Então vamos resumir o que deve ser feito quando você for configurar seus
logs pelo arquivo de configuração syslog.conf(5):

Insira a linha com "!ipfw" e indique o caminho pra onde as informações

referentes às atividades do Firewall devem ser logadas.

Não altere as mensagens que serão enviadas ao usuário Root se ele estiver
logado. Indique os mesmos alertas pra um usuário que você usa com mais frequência.

3) Envie um sinal de reinicialização pro processo do syslogd(8). A forma

mais fácil é usando o comando:

eksffa@eeviac~# killall -HUP syslogd

eksffa@eeviac~#

5.2.3. Configuração do newsyslog(8) pra fazer Rotação (ou

Rotacionamento) de Logs (log rotation);

Agora que o ipfirewall(4) está configurado pra logar todas suas atividades,
você deveria pensar seriamente em configurar o newsyslog.conf(5) de forma a garantir que
o newsyslog(8) vá rotacionar os logs do ipfirewall(4), ou, como alternativa, optar por algum
outro mecanismo de rotacionamento de logs. Pra se ter uma boa noção de todas as
configurações possíveis do newsyslog.conf(5) é recomendado que você leia a página de
manual (man newsyslog.conf) do arquivo. Essa é uma poderosa ferramenta de logs, mas
não tem porque nós explicarmos ela aqui, isso é tarefa pra um capítumo sobre
administração do sistema FreeBSD, pro nosso caso de Firewall específico a seguinte
entrada deve ser o bastante:

/var/log/ipfw/ipfw.log 600 10 * $W0D2 Z

Essa linha pode ser adicionada no final do arquivo newsyslog.conf(5). A

primeira entrada é um tanto quanto óbvia, ela indica qual arquivo vai ser rotacionado. A
segunda indica os bits de permissões pros arquivos rotacionados. A terceira parte é o
número de arquivo de logs que se deseja manter rotacionando até que o mais antigo seja
apagado. O seguinte é o tamanho do arquivo quando ele deve ser rotacionado, não
estamos usando essa opção. A quintar parte é quando (tempo) nós devemos rotacionar o
arquivo, e finalmente a última opção, é uma opção especial. Como você já deve ter
concluído, rotação de logs são definidas por dois critérios: tamanho ou data. No nosso
caso, nós indicamos que queremos que o arquivo de log seja rotacionado às duas da
manhã de todo domingo, não importando o tamanho do arquivo de log. Depois definimos
(a última opção especial, "Z") que o arquivo deve ser comprimido com gzip(1) sempre que
rotacionar, e definimos que vamos manter um histórico arquivado de 10 semanas. Se
você deseja manter seus logs por mais que 10 semanas basta alterar o valor 10 pra
qualquer um que você queira. Ou o ideal, criar uma rotina que faça backup em uma
máquina separada (um LogHost) a cada 10 semanas, ou então gravar seus Logs em CD
ou qualquer outra mídia barata e de grande capacidade quando for necessário.

Uma vez configurado, o newsyslog.conf(5) vai cuidar do rotacionamento dos

logs do ipfirewall(4). O newsyslog.conf(5) é ativado pelo cron(8) do FreeBSD, e por isso não
precisa de um Daemon rodando, consequentemente você não tem que reiniciar nenhum
processo. Você pode criar seu próprio script pra rotacionar logs ou usar de terceiros, com
tanto que você confie. De qualquer forma é bom decidir uma maneira de controlar o
crescimento dos logs dentro do seu sistema. Lembre-se, não existe nada que o cron(8) e
um script não possa fazer nesse caso.

5.3. Configuração de Log nas Regras;

Uma vez que tudo esteja pronto pra utilizar as funções de logs do
ipfirewall(4), vamos começar a definir quais regras nós queremos logar quando elas forem
filtradas. Existem dois parâmetros básicos pra usarmos em conjunto com nossas regras
pra definirmos que queremos logar *aquela* regra. Vejamos:

"log" – É o parâmetro mais comum. Toda vez que uma regra que for definida
o "log" for acionada, então a ação definida ("action") por aquela regra será logada todas as
vezes que um pacote coincidir a regra. Por isso tome muito cuidado pra não defnir "log"
pra uma regra que a terão pacotes frequentementes assimilados a ela, como por exemplo:

add 0500 allow log all from any to any

Essa é uma regra que permite todo o tráfego de todos os tipos de pacotes de
todas as redes pra todas as redes, então imagine a frequência de informações que serão
logadas sempre que cada pacote for permitido pelo seu firewall. Esse tipo de regra pode
facilmente proporcionar problemas pro seu disco local ;-)

Por outro lado, definir "log" pra uma regra geral de negação é uma pedida
considerável:
 add 65000 deny log all from any to any

Essa regra é mais considerável, porque é uma das últimas, em uma política
clara de firewall do tipo "CLOSED" ou seja, tudo que deve ser permitido já o foi nas regras
anteriores que suponhamos existir, portanto nos interessa manter logs das conexões
negadas. Além do que o número da regra é 6500, o que, em relação à regra anterior (500)
é muito mais seletiva, visto que é uma das últimas regras a serem checadas. Preste muita
atenção pra escolher quais regras você quer logar e quais você não quer.

"logamount <número>" - Esse parâmetro em seguida ao "log" define o

número máximo de vezes que uma regra vai ser logada. Esse parâmetro é análogo à
entrada de limite de verbosidade no kernel, e da muito mais controle ao administrador
que pode, por exemplo, definir um número baixo pra uma determinada regra, e zerar a
mesma uma vez ao dia, dessa forma só deixando de logar o período que um possível
ataque ocorrer. Essa definição é possível no FreeBSD 4.x, FreeBSD 2.2.x e FreeBSD série
3 acina de 3.4.x. Nas versões anteriores à 3.4 no FreeBSD 3.x o padrão do "logamount"
era 10.

Sempre que uma regra é logada, as informações geradas pra tal pacote são:

- Data & Hora

- Número da Regra
- Ação
- Endereços IP do Destino & Origem
- Portas de Origem & Destino
- Direção do Fluxo
- A Device onde o tráfego aconteceu.

Por definição, uma regra de firewall sua, quando logada, deve parecer com o
seguinte:

Oct 09 18:59:31 SuaMaquina /kernel: ipfw: 65000 Deny TCP

172.16.0.1:62307 192.168.0.1:23 in via xl0

6. Introdução à filtragem 'Stateless' e 'Stateful' de pacotes;

A filtragem de pacotes do tipo 'Statefull' e 'Stateless' são dois termos

frequentemente encontrados em discussões cujo assunto seja ipfilter(4) e ipfirewall(4). O
modo de filtragem 'Stateless' tende a tratar cada pacote roteado pelo firewall como pacotes
individuais, que não tenham associação alguma com qualquer outro tráfego que também
estiver passando pela dada interface do firewall. Esse tipo de filtragem é o mais comum e
o mais fácil de implementar, e tem vantagens efetivas quando se pretende:

- filtrar pacotes corrompidos (fragmentados)

- filtrar pacotes de protocolos específicos (icmp, udp, igmp, etc)
- fazer um firewall baseado em host (ou seja filtrando de acordo com o
destino e/ou origem do pacote)

Já uma filtragem do tipo 'Stateful' é mais complexa de ser implementada;

esse tipo de filtro trata o tráfego como sendo composto de determinadas conexões, ou seja
os pacotes pertencem a uma dada conexão, negada ou permitida, e não trata pacotes
como individuais. Toda a comunicação através de qualquer protocolo usa números de
sequência que indicam em que ordem os pacotes serão lidos em um socket(2). Esse é o
primeiro princípio básico das informações que um firewall 'Stateful' precisa conhecer. O
segundo é que, conexões orientadas à protocolos como TCP, geram tráfego de pacotes
especiais que indicam o início de uma conexão (SYN) e o fim da mesma (FIN). Esse ponto
também é essencial a um firewall do tipo 'Stateful'. No geral, você deve:

- saber à que estado pertence uma conexão (iniciada, não iniciada, em

negociação, terminada, etc)
- ser capaz de determinar se uma conexão esta se comportando de forma
esperada, com procedimentos validos, ou se ela está se comportando de forma indevida.
Você deve ser capaz de filtrar os pacotes que se comportarem de forma indevida.

Um firewall do tipo 'Stateful' cria regras dinâmicas pras conexões que

estiverem em andamento, e elimina essas regras quando a conexão foi terminada. Isso
permite ficarmos atento de forma mais inteligente às atividades da rede. Por outro lado
um firewall do tipo 'stateful' são incapazes de filtrar cada pacote individualmente,
exatamente pelo fato dele criar regras dinâmicas especiais que permitem uma conexão em
sua totalidade, examinando se o comportamento dessa conexão está aceitável. Em
compensação, é muito fácil juntar regras de firewall do tipo 'stateful' e do tipo 'stateless'
em um mesmo firewall, dependendo apenas do quanto o administrador do sistema é bom.
E normalmente administradores de FreeBSD já são muito bons por natureza, portanto
podem se beneficiar dos dois tipos de firewall.

Quase todas as regras que nós apresentamos anteriormente eram 'stateless'.

As unicas excessões foram as regras a respeito das opções "tcpflags," "setup," e
"established" que permitiam que nós checassemos o estado de uma conexão TCP. Vamos
então usar uma combinação dessas regras pra um primeiro exemplo prático de regras
'stateful'. Antes um pouquinho de história. Esse tipo de verificação primitiva de estado de
conexão (tcpflags, etc) existe no ipfirewall(4) faz muito tempo, contudo essas opções eram
as únicas, o que fazia a capacidade do ipfirewall(4) de criar regras 'stateful' muito limitada.
Por isso anteriormente à versão 4.x do FreeBSD o ipfirewall(4) era chamado de
tipicamente 'stateless', enquanto o ipfilter era a opção 'stateful' disponível. A partir do
FreeBSD 4.0 o ipfirewall(4) foi habilitado a trabalhar com funcionalidades 'stateful' mais
extensivas, e mais desenvolvimento a respeito disso está em andamento no ipfirewall(4).

6.1. Configurações 'Stateful' Iniciais;

Pro nosso primeiro exemplo, vamos estar usando as características mais

básicas e conhecidas do ipfirewall(4) pra tratar filtragem 'stateful'. A maioria dos
administradores mais atentos que costumam ler as regras de firewall pré definidas no
/etc/rc.firewall, costumaram fazer largo uso das funções "setup" e "established", que
compõe a maiora das regras nesse arquivo. Mesmo essas regras podendo ser usadas
exclusivamente pra controlar conexões TCP de forma 'stateful', o que demonstra certa
limitação, vamos criar no nosso primeiro exemplo um conjunto simples de regras que
filtram conexões ao serviço SSH de forma 'stateful':

add 1000 allow tcp from any to any established

add 2000 allow tcp from any to any 22 in setup

Vamos assumir que estamos usando uma política de firewall fechado (ou
seja, firewall_type no /etc/rc.conf não está definido como "OPEN" e não existe a entrada
IPFIREWALL_DEFAULT_TO_ACCEPT no kernel do sistema). Nesse caso, as duas regras
anteriores vão permitir o roteamento dos pacotes desejados. A regra número 1000 vai
permitir todos os pacotes que sejam parte de uma conexão TCP já estabelecida, e então a
verificação das regras subsequentes vai cessar para aqueles pacotes. Se, por outro lado
algum pacote não fizer parte de uma conexão iniciada, a regra 1000 não será assumida, e
então a verificação passa pra regra seguinte. Na regra número 2000, se o pacote for do
tipo TCP SYN, e for destinado à porta 22 (serviço SSH), a regra vai permitir que ele seja
roteado. Nesse caso, pacotes TCP SYN iniciam uma conexão TCP, por isso a importância
de deixa-los passar. Os pacotes subsequentes relacionados ao serviço SSH serão
permitidos pela regra 1000, já que eles farão parte de uma conexão já estabelecida. Você
pode experimentar uma configuração parecida usando 'stateless':

add 1000 allow tcp from any to any out

add 2000 allow tcp from any to any 22 in

Nesse exemplo, todos os pacotes saindo pelo firewall, vindos de qualquer

fonte pra qualquer destino serão permitidos, e todos os pacotes entrando pela porta 22
também serão permitidos. Nesse caso você vai perceber que as regras não ficam
monitorando os pacotes TCP pra verificarem de que tipo eles são, se são de inicialização
de uma conexão ou de uma conexão já estabelecida, e em contra-partida permitem que
todos os pacotes TCP saiam pelo firewall ou entrem pela porta 22, sem verificar que
pacotes são esses.

Essa é a essência de um firewall do tipo 'stateful' utilizando "setup" e

"stablished": Deixa passar pedidos de inicialização de conexões de um serviço (porta)
específico, e depois da conexão estar estabelecidade permite que todo o tráfego funcione
normalmente.

Vamos dar uma olhada em um exemplo memos simples, que envolve

conexões ssh, email, FTP e DNS pra rede 172.16.0.0/27:

add 1000 allow tcp from any to any established

add 2000 allow tcp from any to 172.16.0.0/27 21,22,25 setup
add 3000 allow udp from 172.16.0.0/27 to any 53
add 3100 allow udp from any 53 to 172.16.0.0/27

Nesse exemplo, o pedido de inicio de conexão (usando "setup") é permitido

pras portas 21, 22, 25 (FTP, SSH e SMTP respectivamente) quando os pacotes são
destinados à rede 172.16.0.0. Consequentemente todas as conexões TCP estabelecidas
serão permitidas na regra anterior. As regras 3000 e 3100 permitem pacotes UDP pra
porta 53 de outros hosts, e permite pacotes UDP vindos da porta 53 de qualquer lugar
entrarem pelo firewall. Essas duas últimas regras são 'stateless'. A porta 53 é a porta
onde o serviço de nomes (DNS) roda. A regra 1000 deve ser "from any to any" porque os
pacotes TCP de conexões já estabelecidas devem ser permitidas vindo de qualquer origem
pra qualquer destino. Lembre-se sempre que existe o fluxo em duas direços, os pacotes
vindos de algum lugar e as suas respostas pra outro lugar.

Vamos analizar um caso especial: FTP. Se você fosse fazer um firewall cujas
regras fossem exclusivamente 'stateless', você teria que manter todas as portas entre a
1024 e a 65000 abertas. O motivo é simples, o protocolo FTP é um protocolo revoltadinho
que estabelece suas conexões em qualquer porta não reservada, ou seja qualquer porta
acima da 1024. Uma solução não muito prática é liberar as portas 21 e 22 de forma
'stateless' e forçar seus clientes FTP a estabelecerem conexões exclusivamente não-
passivas (FTP Modo Passivo). O problema é que nem todos os seus clientes (como os que
usam Windows por exemplo) tem muita noção de FTP a ponto de coloca-lo em modo nãp-
passivo, por mais simples que isso seja. Nesse caso, portanto, permitimos a inicialização
de uma conexão na porta 21 (onde todas as requisições FTP iniciam) e posteriormente
permitimos o roteamento de pacotes pertencentes à essa conexão por qualquer porta
(utilizando "stablished"). Essa é a forma mais eficiente de se controlar FTP via firewall, e
essa prática pode ser adotada pra outros serviços que tenham comportamente similar a
esse.

6.2. Configurações 'Stateful' Avançadas;

Como já foi dito, configurações de firewall 'stateful' usando apenas "setup" e

"established" são muito limitadas. Exatamente por permitir controle de conexões stateful
apenas sobre o protocolo TCP, essa filtragem é a mais simples existente. Desde a versão
4.0 do FreeBSD, o ipfirewall(4) adotou características 'stateful' baseada em ótimos
argumentos; agora pode-se controlar conexões TCP, UDP e ICMP de forma 'stateful', além
de outros tipos de pacotes, usando o que nós chamamos de regras dinâmicas.

Regras dinâmicas é uma característica recente do ipfirewall(4) no FreeBSD

4.x; como seu próprio nome sugeste, são regras dinâmicamente criadas pra conexões
independentes. Cada regra dinâmica depois de um certo período de tempo sem serem
utilizadas são descarregadas. O tempo que uma conexão TCP leva pra ser terminada pode
ser controlada por inúmeras variávels do sysctl(8), ou seja, de certa forma um conjunto de
regras monitora não somente o início de uma conexão, mas também quando essa conexão
é terminada, e ajusta suas ações de acordo a configuração utilizada.

Uma opção e um comando são utilizados pra controlar esse comportamente

'stateful' avançado:

"keep-state" – Quando um pacote é combinado com uma regra que tenha

essa opção ajustada, então uma regra dinâmica é iniciada.

"check-state" - Esse comando define que a verificação das regras pelo

firewall vai primeiro checar as regras dinâmicas. Se não existir uma regra com esse
comando em todo o conjunto de regras do seu firewall, ai as regras dinâmicas serão
verificadas no momento em que a opção "keep-state" for definida. Se uma regra com esse
comando combinar com um pacote, a verificação das regras é terminada, do contrário a
verificação continua.

Vamos então voltar ao nosso exemplo anterior, onde tínhamos regras

destinadas à permitir apenas conexões SSH, mas dessa vez vamos usar regras mais
avançadas de 'stateful':

add 1000 check-state

add 2000 allow tcp from any to any 22 in setup keep-state

Só lembrando, essa regra presume que a política do seu firewall seja

fechada. Nas regras acina, a primeira regra faz com que o ipfirewall(4) verifique as regras
dinâmicas. Se o pacote não pertence a nenhuma conexão já estabelecida (ou seja, não
fazem parte de nenhuma regra dinâmica) então a verificação continua na regra 2000,
onde, se o pacote for do tipo TCP SYN entrando pela porta 22 (SSH), aí a função "keep-
state" ordena a criação de uma regra dinâmica, que será sempre verificada na
constatação da regra 1000. Todos os outros pacotes seriam bloqueados pela sua regra
padrão de firewall fechado.
 Bom, nós já havíamos trabalhado com regras desse tipo utilizando as
outras funções de 'stateful' e também utilizando 'stateless'. Agora, essa nossa nova
abordagem, utilizando a opção "keep-state" e o comando "check-state" proporciona
algumas vantagens sobre as outras configurações de firewall. Antes, a opção "stablished"
permitia a ocorrência de qualquer pacote TCP vindo de uma conexão TCP previamente
estabelecida, ainda que esse pacote fosse spoofado e não fosse um pacote legítimo dessa
conexão TCP. A expressão "spoof" define um tipo de pacote que traz consigo informações
de origem manipulada, ou seja o pacote não legítimo se faz passar por um pacote que na
verdade não é ele. É uma técnica não muito simples e que pode ser evitada de várias
formas, uma delas é a verificação pelo firewall. Nessa nossa nova abordagem, cada regra
dinâmica é criada para uma conexão específica entre duas pontas (dois hosts) e suas
respectivas portas, ou seja, um pacote TCP spoofado poderia manipular seu endereço de
destino e de origem, mas não manipularia a porta (a não ser com muita sorte) onde a
conexão foi efetivada, e onde a conexão TCP legítima está sendo mantida. Dessa forma a
regra 1000 ("check-state") falha, não permitindo o roteamento do pacote, e posteriormente
a regra seguinte (2000) também falharia, a não ser que o pacote fosse do tipo TCP SYN, e
dessa forma o pacote é negado pra regra final da política padrão fechada do firewall.

Resumindo, os critérios que definem a permissão ou não de um pacote

passando por uma regra dinâmica são:

- Protocolo
- Endereço & Porta IP
- Destino & Porta IP
- Tempo da regra esgotado

Como já foi dito, a regra dinâmica é descarregada depois de certo tempo

sem ser utilizada. Dependendo de como uma regra dinâmica é utilizada, podemos definir
um período fixo de tempo até que a regra se esgote. Esse tempo de duração pra cada tipo
de regra dinâmica pode ser verificado utilizando as variáveis corretas do sysctl(8).
Posteriormente podemos modificar esses valores. Eis a listagem dos valores padrões
dessas variáveis do sysctl:

eksffa@eeviac~# sysctl -a | grep 'dyn.*lifetime'

net.inet.ip.fw.dyn_ack_lifetime: 300
net.inet.ip.fw.dyn_syn_lifetime: 20
net.inet.ip.fw.dyn_fin_lifetime: 20
net.inet.ip.fw.dyn_rst_lifetime: 5
net.inet.ip.fw.dyn_short_lifetime: 5
eksffa@eeviac~#

A primeira variável do sysctl(8) indica que o tempo de vida padrão pra cada
regra dinâmica que use um pacote do tipo TCP ACK é 300 segundos. A variável seguinte
indica que o tempo de vida de uma regra dinâmica cujo pacote seja TCP SYN é 20
segundos. Na regra seguinte, 20 segundos também de vida pra regras com pacotes TCP
FIN. Depois 5 segundos de vida pras regras que encontrarem pacotes do tipo TCP RST ou
outros pacotes (UDP, ICMP, etc), conforme indica as duas últimas variáveis do sysctl(8).

Vamos usar um exemplo pra demonstrar como isso funciona na prática:

1) – Uma conexão TCP legítima é iniciada da máquina 172.16.0.1 na porta

1234 pra porta 22 do servidor 192.168.0.1 que fica por trás do firewall. Esse pedido de
inicialização de conexão se consiste de um pacote de sincronização TCP, ou seja, um TCP
SYN.
 2) – A regra 1000 do firewall faz com que o ipfirewall(4) verifique as regras
dinâmicas, onde ele não vai encontrar nenhuma regra referente à pacotes TCP vindos de
72.15.0.1:1234 para 192.168.0.1:22.

3) – A regra 2000 é verificada e combinada, então o "keep-state" ordena que

se crie uma regra dinâmica pras conexões TCP entre as máquinas172.16.0.1:1234 e
192.168.0.1:22, e que essa regra tenha um tempo de vida de 20 segundos (que é o padrão
pra pacotes TCP SYN).

4) – Depois de um segundo, um pacote TCP ACK é enviado pro servidor

192.168.0.1:22 em resposta ao pacote TCP ACK enviado pro cliente, pra confirmar o
pedido de uma conexão TCP.

5) – Em seguida o pacote vai encontrar a regra 1000 do firewall de novo, que

vai verificar pelas regras dinâmicas e encontrar uma regra cujo tempo de vida não tenha
terminado, e que esteja permitindo o roteamento dos pacotes cujo IP e porta de origem
sejam conhecidos, assim como IP e porta do destino. Dessa forma a regra dinâmica
permite que o pacote trafegue com segurança pelo firewall.

6) – Um pacote TCP ACK spoofado, vindo de um possível ataque que, em

circunstâncias normais danificaria os recursos de rede de uma máquina Windows não
preparada, que estivesse por trás do firewall.

7) – A regra 1000 verifica as regras dinâmicas e encontra o pacote spoofado

com IP e portas de destino que pertencem a uma regra dinâmica existente, contudo o IP e
porta pra onde o pacote deve voltar não corresponde ao da regra (porque foi gerado de
forma randômica pelo ataque). Dessa forma a regra 1000 falha, e a filtragem pelo firewall
continua pra regra seguinte.

8) – A regra seguinte (2000) verifica que o pacote não é do tipo TCP SYN,
então não define regra dinâmica praquele pacote.

9) – Consequentemente o pacote é bloqueado pela regra padrão do firewall

que é do tipo fechado.

No nosso primeiro exemplo de regra 'stateful' esse pacote spoofado teria sido
aceito, porque a regra que continha "established" como dependência teria sido cumprida,
pois aceitava todo pacote com um destino em particular, que tivesse ao menos a 'flag'
ACK definida, e o pacote Spoofado cumpriria esse critério. Já a regra dinâmica criada
exclusivamente para as duas pontas em comunicação, verificou pela porta de origem e
consequente resposta da conexão, informação que é gerada aleatóriamente, ou seja, não
existe uma forma lógica de se manipular. Esses são exemplos e rasões primários, contudo
poderosos em relação à vantagens das operações avançadas de 'stateful' do ipfirewall(4).
Esse tipo de vantagem o IPFilter também possui.

No exemplo anterior poderíamos ter assumido um ataque diferente se o

pacote spoofado fosse do tipo TCP SYN, mas antes de explicarmos isso, vamos dar uma
olhada em um tipo de ataque popular utilizando TCP SYN, ataque esse conhecido como
SYN FLOODs.

Pacotes TCP SYN spoofados são usados com muita frequência em taques de
rede. A ação mais comum desse tipo de ataque consiste em enviar inúmeros pacotes TCP
SYN (SYN FLOODs) pra uma determinada estação na rede, de modo que toda a conexão
fique em estado de espera, por estarem esperando suas respostas em fila. Dessa forma o
tráfego de rede controlado pelo kernel fica saturado, evitando o roteamento de novas
conexões legítimas. Mesmo considerando que o Stack TCP/IP do FreeBSD é desenvolvido
de forma à eliminar randomicamente conexões TCP que estiverem em fila de espera de
forma inativa, esse tipo de ataque pode ser devastador dependendo da política de
eliminação das filas adotado no sistema (via sysctl(8)) e dependendo também da largura
de banda da rede. Vamos assumir que, se os pacotes TCP SYN chegarem ao servidor de
forma muito rápida, eles vão fazer pedidos falsos de conexões de forma mais rápida do
que eles podem ser eliminados da fila, não sobrando recursos o suficiente pra tratarmos
todas as conexões legítimas que também estiverem chegando.

Os primeiros pontos em questão, relacionado à esse tipo de ataque, é a

velocidade do ataque e velocidade com que esses pacotes podem chegar até o servidor
(definido por quão larga seja a banda do atacante) e depois a velocidade e poder de
processamento do servidor que está processando os pacotes que estão chegando pelo
Stack TCP/IP. Felizmente, nós estamos trabalhando com FreeBSD, e o Stack TCP/IP do
FreeBSD é mais poderoso do que o de qualquer outro sistema, sejam até mesmo Unix,
Linux, ou alguns outros BSD Unix. De qualquer forma, dependendo do número de
atacantes ao mesmo tempo, e da largura da banda dos mesmos, essa velocidade nem
sempre é o bastante.

Como podemos concluir na nossa ilustração prévia de um ataque TCP ACK

Spoofado, qualquer outro ataque com pacotes de qualquer tipo, SYN ou ACK também
seriam evitados pelo Firewall, porque cada novo pacote com porta de IP randomicamente
criada não encontraria uma regra dinâmica que o permitisse. Mas de qualquer forma
devemos ficar muito atentos em relação ao número de regras dinâmicas que poderíamos
abrir por pacotes TCP SYN spoodados. Mesmo tendo certeza que o Stack TCP/IP do
FreeBSD não seria sobrecarregado por tantas tentativas de conexões, a criação das regras
dinâmicas do ipfirewall(4) poderiam ser saturadas, de forma a colocar pacotes em espera.
A melhor forma de evitar isso é diminuindo o tempo de vida das regras dinâmicas
iniciadas por pacotes TCP SYN, utilizando sysctl(8), como foi mostrado anteriormente, e
ainda, aumentar o número máximo de regras dinâmicas, através de uma outra variável
do sysctl(8):

net.inet.ip.fw.dyn_max: 1000 (default)

Como o seu firewall 'stateful' em plena atividade, você pode verificar

quantas regras dinâmicas existem criadas no exato momento, verificando a variável do
sysctl(8):

net.inet.ip.fw.dyn_count

A melhor forma de evitar que pacotes spoofados utilizem todas as suas

regras dinâmicas é evitar que qualquer máquina fora da sua rede inicie uma conexão TCP.
Isso pode ser feito facilmente com as seguintes regras, assumindo que a rede
192.168.0.0/27 está por trás do firewall:

add 1000 check-state

add 2000 allow tcp from 192.168.0.0/27 to any out setup \
keep-state

Dessa forma só os pacotes TCP SYN que saírem pelo seu firewall poderão
ser roteados, ou seja, os pedidos que entrarem serão automaticamente negados. Esse é o
mesmo tipo de proteção que o NAT e proxies transparentes de forma geral oferecem pras
máquinas internas.

Até agora nós trabalhamos essencialmente com regras 'stateful' que

manipulavam conexões TCP. É claro, não é pra menos, conexões TCP representam a
grande maioria do tráfego gerado em rede, contudo você se lembra que nós comentamos
que o ipfirewall(4) poderia manipular também filtragem 'stateful' de outro protocolos. Bom,
então de uma olhada nas regras que nós usamos pra permitir que nossos clientes
internos pudessem pingar qualquer máquina pra fora da rede, enquanto ninguém poderia
nos pingar, quando estudamos a seção referente ao "icmptypes". Agora vamos fazer a
mesma coisa usando "check-state" e "set-state":

add 1000 check-state

add 2000 allow icmp from any to any out icmptypes 8 keep-state

Já podemos entender facilmente essa regra, que cria uma regra dinâmica
pra cada pedido de echo que nossas estações internas façam pra fora. Quando a resposta
chega ela é permitida pela regra dinâmica que estabeleceu a conexão entre as duas
pontas, e se alguém de fora tenta pingar uma máquina interna, a regra padrão nega essa
ação. O protocolo ICMP usa a variável net.inet.ip.fw.dyn_short_lifetime do sysctl(8). Se a
resposta do ping demorar mais que 5 segundos pra chegar a regra vai ser descarregada e
o pacote não vai poder ser roteado. Se você considera que as respostas de ping levarão
mais que 5 segundos pra acontecer, então você, como administrador da rede deve elevar o
valor da variável no sysctl(8). De qualquer forma a maioria dos atrasos de rede levam
menos de 1 segundo, a não ser que seja IRC ;-)

A regra 2000 ainda poderia ter definido uma faixa de rede com permissão
pra fazer o ping, caso existisse mais de uma rede por trás do firewall, e apenas uma delas
poderiam pingar máquinas externas. Na verdade escolhemos a regra assim porque é a
forma que mais se aproxima do nosso exemplo inicial de controle do ping.

6.3. Anatomia de uma Regra Dinâmica;

Vamos dar uma olhada na saída que você devei encontrar quando listar as
regras dinâmicas de um firewall 'stateful' no seu FreeBSD:

00100 allow ip from any to any via lo0

00200 deny ip from any to 127.0.0.0/8
01000 check-state
02000 allow tcp from any to any keep-state
65535 deny ip from any to any
## Dynamic rules:
02000 9 1255 (T 54, # 0) ty 0 tcp, 192.168.0.1 2007 <->
204.71.200.245 80

Nós já conhecemos as regras estáticas apresentadas, contudo, essa é a

primeira vez que nós estamos encontrando uma regra dinâmica listada pelo nosso firewall.
Vamos examina-la com mais atenção:

A primeira citação de uma regra dinâmica é o número da regra estática que

a gerou, no nosso caso, a regra número 2000, que tem a opção "keep-state" ajustada,
conforme aprendemos anteriormente. A segunda parte é o número de vezes que aquela
regra foi utilizada, ou seja o número de vezes que um pacote saiu pelo firewall através
daquela regra, ou o número de incidências da regra, seguido do número total de bytes
que os pacotes que passaram por aquela regra rotearam. Entre parênteses encontramos o
valor "T" que indica o "timeout" (o tempo de vida) daquela regra, em segundos. Nesse caso
ainda existem 54 segundos de vida para essa regra. A cerquilha (#) indica o número da
regra, nesse caso essa é a nossa regra número 0. O 'ty 0' indica o tipo de regra dinâmica
em questão. Os tipos de regras correspondem ao fluxo do roteamento de pacotes através
daquela regra, ou seja, se ela permite apenas tráfego da origem pro destino, do destino
pra origem, ou se a regra é bidirecional. No nosso caso temos apenas um tipo indicado,
que é o padrão: bidirecional. Podemos verificar essa afirmação visualmente, indicado pelo
símbolo "<->" entre a Porta/IP de origem e de destino. Depois do tipo da regra dinâmica
podemos constatar o protocolo que a regra ta usando, seguidos do IP/porta de origem, o
símbolo de fluxo dos pacotes (no caso "<->") e finalmente o IP/porta do destino da
conexão.

Mesmos depois que uma regra dinâmica foi descarregada, você ainda pode
lista-la com o comando "ipfw list", contudo a regra inativa vai ter um valor de tempo de
vida ("T") igual a zero (T 0, #). Uma vez descarregada, a regra não vai mais aceitar pacotes,
simplesmente porque ela não existe mais, até que a mesma regra seja reiniciada, ou
ressucitada pela mesma entrada "keep-state" da regra que a originou inicialmente. Uma
vez descarregadas, as regras também podem ser substituídas por novas regras
dinâmicamente ativadas. A não ser que todas as regras dinâmicas continuem em pleno
uso, elas serão continuamente substituídas por novas regras, especialmente se o número
de regras dinâmicas alcançou o máximo permitido pelas variáveis do sysctl(8).

Veja o seguinte exemplo de listagem das regras do ipfw(8):

00100 0 0 allow ip from any to any via lo0

00200 0 0 deny ip from any to 127.0.0.0/8
01000 0 0 check-state
02000 462 71516 allow tcp from any to any keep-state
65000 186 16464 deny ip from any to any
65535 56146 6054724 allow ip from any to any
## Dynamic rules:
02000 125 22084 (T 300, # 48) ty 0 tcp, 200.210.70.151 1180 <->
200.210.42.45 22
02000 31 1828 (T 217, # 55) ty 0 tcp, 200.210.70.151 1176 <->
200.210.42.45 21
02000 15 1372 (T 0, # 58) ty 0 tcp, 200.210.70.151 1174 <->
200.210.42.45 22

Não vamos comentar a listagem acima, cabe a você entender o que está
acontecendo com o firewall. Note que existe conexões cujo tempo de vida já se esgotou, e
ainda assim a mesma foi listada.

Bom, quando você começar usar regras 'stateful' em grande escala, você vai
perceber o quanto a saída de um comando pra listar as regras do ipfw(8) vão se tornar
perturbadoras, devido ao enorme número de regras dinâmicas criadas. O ipfw(8) lista
todas as regras dinâmicas, mesmo que já descarregadas pra oferecer controle total do
firewall ao administrador, contudo nem sempre você quer analisar as regras dinâmicas, e
apenas as estáticas, já que são essas que criam as dinâmicas. Nesse caso uma solução
óbvia do mundo Unix seria:

eksffa@eeviac~# ipfw list | grep -v '[<->#]'

 Ou se você quer analisar com cuidado todas as regras, sejam estáticas dou
dinâmicas, uma solução é utilizar um paginador:

eksffa@eeviac~# ipfw list | less

OU
eksffa@eeviac~# ipfw list | more

7. Traffic Shape (controle de tráfego);

Controle de Tráfego (Traffic Shaping) se refere à possibilidade de controlar

todo o roteamento de pacotes pelo seu firewall de diversas maneiras, entre as quais as
mais importantes são: limitação de banda, atrasos no roteamento (delays), criação de filas
de fluxo, entre outros. Ele permite que você controle a intensidade, direção e
disponibilidade do tráfego. Até agora a gente entendia como controlar roteamento, a
escolha e definição de políticas de permissões ou restrições de acesso; agora controlar
tráfego passa a significar mais do que simplesmente filtrar quem e quando pode acessar
determinado serviço, rede e/ou estações. A inclusão do dummynet(4) no FreeBSD
possibilitou um controle de tráfego extensivo, funcionalida essa que o IPFilter também
não pode oferecer.

Todo gerenciamento mais rudimentar de uma rede, em relação à sua infra

estrutura básica de tráfego e roteamento pode ser implementado utilizando-se
ipfirewall(4) e dummynet(4). Existem apenas duas restrições: probabilidade de
ocorrências e a utilização de regras dinâmicas. Nenhuma regra de 'Traffic Shapping' pode
ser criada de forma dinânica, simplesmente porque é inviável, em relação à performance,
a verificação da capacidade de banda, atrasos e filas de fluxo em cada regra à ser criada
de forma não estática.

7.1. Probabilidade de Ocorrências (Probability Matching).

O ipfirewall(4) possui uma ferramenta incrivelmente funcional pra auditar e

testar uma rede. Essa ferramenta permite que o administrador simule a restrição de
pacotes de forma aleatória sob várias taxas de probabilidade. Essa ferramenta estatística
faz uso da opção "prob" nas regras do firewall, opção essa, seguida de um número entre 0
e 1, o qual corresponde à probabilidade estatística dos pacotes que serão liberados pelo
firewall. Dessa forma, uma probabilidade 0.9 (indicada pelo comando "prob 0.9") vai
permitir o tráfego de 90% dos pacotes que passaram por aquela regra, da mesma forma
que uma "prob 0.1" permitirá apenas 10% de probabilidade. Segue então uma pequena
extensão da sintaxe do ipfw(8) que nós estávamos acostumados:

<comando> [<no. regra>] [prob <prob_ocorrencia>] <acão> [log [logamount

<número>]]
<proto> from <origem> to <destino> [<interface-spec>] [<opcoes>]

Por exemplo, se nós quisermos restringir 20% dos pedidos de echo (echo
requests) do ICMP, poderíamos usar a seguinte regra:

add 1000 prob 0.8 allow icmp from any to any in icmptypes 8

Podemos também querer negar 50% dos pacotes TCP SYN pro servidor web,
dessa forma simulando um tráfego pesado na interface ep0. Faríamos da seguinte forma:
 add 1000 prob 0.5 allow tcp from any to any in setup via ep0

A utilização de probabilidade de ocorrências é uma função nativa do

ipfirewall(4).

7.2. Dummynet;

Todas as outras funcionalidades pra se implementar Traffic Shapping

requer o uso do dummynet(4), que foi incorporado na versão 2.2.8 do FreeBSD. Pra isso
precisamos adicionar uma opção ao nosso Kernel:

options DUMMYNET

Depois de compilado o nosso kernel com mais essa opção (além das opções
típicas do ipfirewall(4)), o administrador do sistema vai poder especificar a criação de
túneis (chamados "pipes") pra controle do tráfego. Um túnel nada mais é do que uma
regra de Traffic Shapping que controla o roteamento, canalizando as informações que
posteriormente irão trafegar por endereços específicos de rede. A criação desses túneis é
feita com o comando "pipe" do ipfw(8). O tráfego é redirecionado à esses tuneis por meio
do comando "pipe <pipe #>" no ipfw(8). Vamos então criar um túnel simples:

pipe 10 config bw 100Kbit/s

Note que, assim como nas regras de firewall, o "pipe" é apenas mais uma
ação pro ipfw(8), exatamente como "add" ou "delete", portanto antes de cada comando é
feita uma chamada ao ipfw(8) (/sbin/ipfw pipe 10... por exemplo).

Esse túnel simples que criamos logo acima vai limitar o fluxo de
informações pra uma velocidade máxima de 100 Kilobits por segundo. Existem várias
maneiras distintas de indicarmos as medidas de velocidade de tráfego: bit/s, Byte/s,
Kbit/s, Kbyte/s, Mbit/s, Mbyte/s. Cada túnel de limitação de banda deve usar a opção
"bw" (de bandwidth – banda).

Uma outra maneira de controlar tráfego é usar a opção "delay" que força um
atraso na comunicação, simulando o que se conhece como "lag" do sistema:

pipe 10 config delay 100

O valor que segue a opção "delay" é o tempo de atraso que nós desejamos,
definido em milisegundos. Nesse exemplo todo o tráfego roteado através desse túnel terá
um atraso de 100ms.

Existe ainda a possibilidade de proporcionarmos uma taxa de perca de

pacotes, função essa igual à "prob" que comentalos logo acima. Por exemplo, pra
conseguirmos uma taxa de 20% de pacotes perdidos (equivalente a "prob 0.8") podemos
criar o seguinte túnel:

pipe 10 config plr 0.2

"plr" significa "packet loss rate" (taxa de perca de pacotes), portanto o valor
indica à que taxa os pacotes não serão roteados, oposto da opção "prob" do ipfw(8), que
indica a taxa dos pacotes que serão roteados. Pra evitar qualquer confusão com a
utilização de "prob" ou ®plr", aconselhamos que o administrador assuma uma escolha
pessoal entre as duas possibilidades. Ambas são igualmente efetivas, e co-existem porque
a primeira é nativa do ipfirewall(4) enquanto a segunda faz parte do dummynet(4).

7.2.1. Filas de Túneis (Pipe Queues);

Bom, a necessidade seguinte é definir o tamanho das filas dos

túneis gerados, especialmente se a MTU da interface de rede em questão é relativamente
grande. A MTU de uma 'device' de rede define o tamanho máximo que um pacote vai ter
naquela interface. MTU = Maximum Transmission Unit, ou Unidade Máxima de
Transmissão. Pra se obter o valor da MTU em uma interface de rede é necessário o uso do
ifconfig(8):

eksffa@eeviac~# ifconfig xl0

xl0:
flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.0.1 netmask 0xffffffe0 broadcast 192.168.0.31
ether 00:70:18:d4:a4:ac
media: 10baseT/UTP (10baseT/UTP <half-duplex>)
supported media: 10base5/AUI 10baseT/UTP <full-duplex>
10baseT/UTP
<half-duplex> 10baseT/UTP
eksffa@eeviac~#

Verificamos portanto que na interface xl0 em questão, a MTU da placa de

rede é 1500 (bytes). Por padrão esse valor é comum entre as placas de rede.

As filas são utilizadas pelos túneis pra forçar as limitações e atrasos de

banda. Elas podem ser configuradas especificando-se o seu temanho em "Kbytes" ou por
"slots". Cada 'slot' corresponde a um pacote, ou seja definir que uma fila tem 10 'slots'
significa que aquela fila vai suportar apenas 10 pacotes simultâneos. O tamanho máximo
de cada pacote, por ser definido pela MTU da interface, equivale a multiplicação do
mesmo pelo número de pacotes na fila, ou seja se você criar uma fila (queue) com 10
'slots', o tamanho dela será 10 x 1500 bytes, portanto 15Kbytes.

É importante entender a definição de tamanho das filas (queue) porque o

padrão pra cada fila é 50 'slots', que pode ser muito pra determinadas interfaces de rede
com MTU grande e pouca banda disponível. O padrão 50 'slots' foi definido por ser o
tamanho médio de uma fila nas devices de rede. Normalmente esse valor é o ideal,
contudo quando se tem uma banda pequena, a requisição pelas interfaces é maior do que
o tráfego possível na rede, isso gera gargalo e consequente atrasos na rede. Façamos o
seguinte então: vamos criar um túnel em uma rede que simule a velocidade máxima de
um modem de 56K:

pipe 10 config bw 56Kbit/s

... mas não vamos definir uma MTU menor pra device, com o ifconfig(8),
nem vamos diminuir o tamanho da fila (queue), que seria nossa melhor opção. A fila pros
pacotes então seria 1500 bytes (12000 bits) x 50, ou seja, 600Kbits de fila. Pra um túnel
que esta limitando a banda à 56Kbit por segundo, levaria aproximadamente 10.7
segundos pra uma fila de 600Kbit ser preenchida. Esse é um atraso inaceitável pra por o
tráfego em andamento. Pra evitar esse tipo de problema é recomendável ajustar
manualmente o tamanho das filas (queue), em 'slots' que é mais fácil pra uma
comparação com o padrão (que sabemos ser 50) ou em ®Kbits" que é uma melhor
atribuição à quantidade de dados. A segunda opção é a melhor, porque além de ser um
valor mais compreensível, o uso de 'slots' requer que o administrador também defina o
valor pra MTU da interface, utilizando o ifconfig(8), já que esse valor equivale à variável de
multiplicação no tamanho da queue (fila). Lembre-se, quanto menor a banda disponível,
menor deve ser a fila. No nosso exemplo acima, uma configuração rasoável pra fila seria:

pipe 10 config bw 56Kbit/s queue 5Kbytes

7.2.2. Máscaras de Túneis (Pipe Masks);

Uma poderosa característica dos túneis é permitir múltiplas filas por fluxo.
Por exemplo, imagine que você tenha várias máquinas atrás do seu firewall, e você quer
limitar a banda pra 100Kbits/s pra cada máquina, ou seja, não vai agregar um valor
somatório à banda pra todas as máquinas, vai definir individualmente a banda. Existem
duas formas de se fazer isso, a mais óbvia e primeira conclusão que um administrador
tomaria seria criar túneis e regras individuais pra cada máquina, com o ipfw(8). Mas
agora considere que você pode definir máscaras pra identificar um subconjunto de
estações que pertencem ao mesmo túnel, exatamente como netmasks e bitmasks
identificam subconjuntos de estações que pertencem a mesma rede.

As máscaras podem ser de seis tipos distintos:

"dst-ip" – máscara pro IP de destino do pacote que esta sendo enviado pelo
túnel.
"src-ip" – máscara da origem
"dst-port" – máscara da porta de destino
"src-port" – máscara pra porta de origem
"proto" – máscara do protocolo
"all" - máscara geral, que especifica todos os bits nos campos (dst-ip, src-ip,
etc) como importantes e válidos.

Por exemplo, vamos assumir a mesma idéia anterior de uma rede atrás de
um firewall onde cada estação deve ter uma banda de 100Kbit/s. Se nós simplesmente
direcionarmos todo o tráfego pra um túnel, o valor do tráfego será a somatória de todas as
estações, e não valores individuais. Pra utilizar máscaras pras estações às quais o tráfego
deve ser separado por filas específicas, dessa maneira limitando a banda de forma
separada, faremos o seguinte:

pipe 10 config mask src-ip 0x000000ff bw 100Kbit/s queue 10Kbytes

pipe 20 config mask dst-ip 0x000000ff bw 100Kbit/s queue
10Kbytes
add 1000 add pipe 10 all from 192.168.0.0/16 to any out via
<device>
add 2000 add pipe 20 all from 192.168.0.0/16 to any in via
<device>

No primeiro instante as definições acima parecem confusas, especialmente

porque essa também é a primeira vez que nós incluimos as regras do ipfw(8) pra
direcionar os pacotes pros túneis. Assumimos que apenas a definição dos túneis sem o
direcionamento com ipfw(8) não faz mais sentido. No túnel (pipe) 10 nós criamos uma
limitação de banda de 100Kbit/s e fila de 10Kbytes pro endereço de origem do nosso
conjunto de estações. O túnel (pipe) 20 definiu os mesmos valores de bandas e fila (queue)
pro nosso conjunto de endereços de destinos. A regra 1000 definiu que todo o tráfego
entre a nossa rede sairia pelo túnel 10, e a regra 2000 definiu que todo o tráfego entre a
nossa rede interna entraria pelo túnel 20, sempre (nas duas regras) o tráfego ocorreria
pela interface <device>.

Existem dois motivos pra termos túneis pra entrada e pra saída do tráfego,
mas uma delas nós vamos discutir posteriormente. A primeira questão que deve nos
prender atenção no momento é que cada túnel define uma máscara diferente. O túnel 10
define a máscara 0x000000ff pros endereços de origem, simplesmente porque a regra
1000 direciona todo o tráfego que sai (out) pela rede interna, ou seja a máscara *deve*
fazer menção ao endereço de origem, porque cada origem faz diferença quando queremos
filas distintas pra cada estação que origina o fluxo. Da mesma forma o tráfego que está
chegando (in) deve ser separado em filas (queue) disntas de acordo com cada endereço de
destino.

Você deve ter percebido que nós especificamos as máscaras em hexadecimal

ao invés de decimal nos túneis. As duas notações funcionam perfeitamente. As máscaras
pros túneis funcionam exatamente da mesma forma que as 'netmasks', mas a utilização
delas se torna muito mais clara quando nós percebemos que sua aplicação é definida de
forma reversa, se comparadas. Quando nós utilizamos 'netmask' nós estamos dividindo a
rede em subgrupos, de forma que os bits iniciais são os bits altos, ou seja, os bits
imutáveis da subrede. Aqui nós definimos os bits altos como os últimos bits da máscara,
porque cada túnel roteia os dados de trás pra frente em relação à rede. O valor em
hexadecimal que nós especificamos corresponde à mascara decimal 0.0.0.255. Bem
simples portanto: o último octeto indica que apenas uma estação será atribuída por fila
(256 menos 255 = 1). Dessa forma é atribuida uma fila específica por controle de banda
pra cada endereço de estação com número distinto (no seu último octeto). É claro que
estamos supondo aqui que a rede em questão não deverá ter mais que 254 estações, mas
caso existam, a máscara deverá ser redefinida. Então se você quer definir 254^2 estações
na rede que o firewall vai estar controlando, aí a máscara teria que ser 0.0.255.255
(0000ffff). Isso define que qualquer endereço com um único bit diferente entre os dois
últimos octetos (ou seja os 16 últimos bits baixos) deverá ter sua própria fila de pacotes.

7.2.3. Remanejamento de Pacotes por Túneis (Packet

Reinjection);

Em 99% dos casos, assim que um pacote é direcionado à um

túnel (pipe), é a configuração definida pro túnel que toma parte do pacote, e nesse
momento a busca nas regras termina, como de costume no ipfirewall(4). Contudo você
pode forçar que o pacote seja reinjetado (ou remanejado) no firewall, a partir da regra
seguinte, mesmo depois de ter sido direcionado pro túnel. Pra fazer isso basta desativar a
seguinte opção no sysctl(8):

net.inet.ip.fw.one_pass: 1

Essa opção é booleana. Só pra constar ;-)

8. Fluxo do Tráfego pelo Firewall.

 Vamos lembrar que as regras que não especificam se o pacote deve ser
examinado na entrada ou saída pelo firewall (usando as opções "in" e "out"), serão sempre
verificadas pro tráfego de entrada *E* de saída. Isso implica em algumas consequências.
Quando uma regra redireciona o tráfego pra um túnel sem usar "in" ou "out", a regra será
duplicada, um túnel pros pacotes que saem e um pros que entram. Outra coisinha,
quando as regras não são definidas por interface (usando "via") todas as regras são
aplicadas à todas as interfaces, mesmo se definidos entrada e saída ("in", "out"),
simplesmente porque, imagine seu gateway com múltiplas interfaces de rede, uma pra
rede verdadeira (Internet) e duas pra redes internas. Todo tráfego definido como "in" é o
que entra pelas interfaces pra máquina firewall, ou seja, se vem da internet pro gateway,
ENTRA pelo firewall; Se vem das redes locais pro gateway, ENTRA pelo firewall.

Devemos também notar os conceitos de half-duplex e de full-duplex pras

conexões. Se o tráfego de entrada e saída são direcionaos pro mesmo túnel, então ele vai
adotar um coportamento half-duplex, simplesmente porque o túnel não pode rotear o
tráfego em ambas as direções ao mesmo tempo. Se você esta trabalhando com conexões
de rede que sejam full-duplex portanto é sempre recomendado criar túneis distintos, pro
tráfego que entra e pro que sai, dessa forma podendo rotear as duas direções ao mesmo
tempo. Eis a segunda rasão que nós estávemos devendo pra se ter duas regras, uma pra
controlar cada direção de fluxo.

Apêndice A: Exemplos de Configurações de Firewall;

Vamos ilustrar aqui alguns cenários onde é necessário implementar um

firewall. Cada um é exemplificado com regras de firewall e uma explicação breve de como
a regra funciona. Nos nossos exemplos vamos adotar a rede 12.18.123.0/24 como a local,
xl0 será a interface de rede externa e xl1 será a interna.

P) Como eu bloqueio pings externos, mas permito que eu possa pingar

qualquer estação externa?

R) A solução Stateful. As regras dinâmicas pros pacotes ICMP usam as

definiçoes do net.inet.ip.fw.dyn_short_lifetime no sysctl(8), que é de 5 segundos de vida
pra cada regra. A vantagem da solução Stateful é que as respostas de echo são permitidas
apenas das máquinas que você pingou.

add 1000 deny icmp from any to 12.18.123.0/24 in via xl0

icmptypes 8
add 1010 check-state
add 1020 allow icmp from 12.18.123.0/24 to any out via xl0
icmptypes 8 keep-state
add 1030 deny icmp from any to any

O motivo pra regra de negação antes da regra com check-state é que as

regras dinâmicas são bi-direcionais, ou seja, os pedidos de echo podem vir de estações
externas que serão permitidos, durante a vida últil da regra. Por isso filtramos os pings
externos antes de verificarmos as regras dinâmicas.

A solução Stateless. A vantagem é que sobrecarrega menos o firewall,

porque existe um número menor de regras à serem processadas; mas, elas sobrecarregam
o firewall quando não existem muitas ocorrências de tentativas de pings, então a
vantagem de uma solução ou outra depende de uma análise da frequência que os pings
ocorrem.

add 1000 deny icmp from any to 12.18.123.0/24 in via xl0 icmptypes 8
add 1010 allow icmp from 12.18.123.0/24 to any out via xl0
icmptypes 8
add 1020 allow icmp from any to 12.18.123.0/24 in via xl0
icmtypes 0

Outra desvantagem da solução Stateless é que ela vai sempre aceitar

respostas de echo (Echo Reply) de qualquer estação, enquando a solução Stateful permite
resposta apenas das estações que foram pingadas.

P) Como eu bloqueio que as redes privadas, conforme definidas na RFC

1918, sejam roteadas pra dentro ou pra fora da minha rede?

R)

add 1000 deny all from 192.168.0.0/16 to any via xl0

add 1010 deny all from any to 192.168.0.0/16 via xl0
add 1020 deny all from 172.16.0.0/12 to any via xl0
add 1030 deny all from any to 172.16.0.0/12 via xl0
add 1040 deny all from 10.0.0.0/8 to any via xl0
add 1050 deny all from any to 10.0.0.0/8 via xl0

P) Como eu posso forçar a limitação de taxas de cada estação na minha

rede de forma individual? Eu quero forçar um limite de UpStream de 64Kbit por segundo
e DownStream de 384 Kbit por segundo pra cada estação; ainda, quero também evitar
que qualquer estação externa inicie conexões com as estações na minha rede, dessa
forma ninguém vai poder rodar nenhum tipo de servidor.

R) Essa é a solução adotada em uma universidade:

pipe 10 config mask src-ip 0x000000ff bw 64kbit/s queue 8Kbytes

pipe 20 config mask dst-ip 0x000000ff bw 384kbit/s queue 8Kbytes
add 100 deny icmp from any to 12.18.123.0/24 in via xl0 icmptypes 8
add 110 check-state
add 1000 pipe 10 all from 12.18.123.0/24 to any out via xl0
add 1100 pipe 20 all from any to 12.18.123.0/24 in via xl0
add 1200 allow tcp from 12.18.123.0/24 to any out via xl0 setup keep-state
add 1200 allow udp from 12.18.123.0/24 to any out via xl0 keep-state
add 1300 allow icmp from 12.18.123.0/24 to any out icmptypes 8 keep-
state
add 65535 deny all from any to any