Treinamento Linux Network Administrator

MANUAL DE TREINAMENTO LINUX NETWORK ADMINISTRATOR
MANUAL DE TREINAMENTO M.CURY

LINUX NETWORK ADMINISTRATOR PÁGINA 1

CARACTERÍSTICAS DO LINUX NETWORK ADMINISTRATOR:
O curso de Linux Network Administrator é uma preparação para as provas do Linux Professional
Institute (LPI) de Nível 2. As provas 117-201 e 117-202 são provas voltadas para o Administrador de Linux Pleno
com foco principalmente em serviços e na resolução de problemas (troubleshooting).
Além de ser voltado para as provas de Certificação o objetivo do curso é preparar Administradores
capazes de:
 Instalar e configurar os principais serviços utilizados nas empresas;

 Gerenciar contas e domínios híbridos;
 Analisar Logs e informações do sistema a fim de resolver problemas e evitar possíveis falhas de
funcionamento;
 Melhorar a segurança de serviços a fim de garantir um melhor funcionamento;
 Estar apto a entender o funcionamento dos serviços e desenvolver soluções para integração dos
mesmos.
Alguns dos tópicos vistos neste curso são visões mais aprofundadas de serviços vistos no Curso de
Linux System Administrator, fortalecendo assim conhecimentos adquiridos no curso anterior e ampliando a
aplicação dos mesmos.
O Manual visa orientar o aluno em relação à matéria que será passada em sala de aula e permitir que o
aluno adicione suas próprias impressões e comentários do Instrutor para complementar o conteúdo escrito.

Índice
Tópico Página
01- Processo de Inicialização do Linux 05

02- Kernel e Módulos 20
03- Manutenção e Reparo de Sistemas de Arquivos 39
04- Hardware e Arranjos 50
05- Backup 64
06- Gerenciamento de Rede 69
07- Gerenciamento de Domínios 89
08- DHCP 106
09- Compartilhamento de diretórios em Linux 111
10- Gerenciamento de Log 116
11- Agendamentos 125
12- Samba 132
13- LDAP 142
14- SuperDaemons 158
15- OpenSSH 164
16- Servidor FTP 172
17- Servidor HTTP 186
18- Servidor Proxy 196
19- Servidor de Email 205
20- Firewall 227
21- Autenticação PAM 237

1- PROCESSO DE INICIALIZAÇÃO DO LINUX
1.1
A inicialização do computador e o Init
O Processo Init é o mais importante de todo o sistema já que é ele que inicia todos os outros processos
e permite que cada runlevel seja executado corretamente, fazendo assim o papel de processo “pai” de todos os
processos e é o processo de número 1.
Desde o momento em que é ligado o computador executa várias tarefas e processos que vão desde
verificação do hardware presente, execução de códigos obrigatórios até o carregamento do Sistema
Operacional propriamente dito.
Abaixo segue um resumo de como é iniciado o computador:
 Ao ser ligado o computador executa o POST (Auto Teste de Ativação) (Power On Self-Test), onde ele
verifica se todo hardware mapeado se encontra nos locais indicados;
 Após isso ele executa o BIOS que foi configurado via SETUP;
 Carrega o BOOTLOADER (GRUB/LILO) que está gravado na MBR (Registro Principal de Inicialização);
 O BOOTLOADER carrega o KERNEL que está mapeado, endereçado fisicamente no disco, em seu
arquivo de configuração;
 Após carregar o KERNEL, ele carrega se existir o INITRD, que é um arquivo que geralmente contém
módulos adicionais ao kernel e uma estrutura chamada ROOTFS que cria um pseudo / (raiz) na
memória, após carregar o INITRD, o KERNEL o converte em um RAMDISK e libera a memória que o
initrd ocupava;
 Após o carregamento do INITRD é executado o script LINUXRC, que monta o raiz no / (real) com o
comando pivot_root;
 É iniciado o processo INIT que carrega o RUNLEVEL corretamente configurado no /etc/inittab;
 No final da execução do INIT, é carregado geralmente o primeiro comando interativo

(GETTY/MINGETTY/AGETTY) que cria os terminais e disponibiliza o prompt de login.
O funcionamento do initrd e as características do kernel serão estudadas em capítulos adiante.

Resumindo o mapeamento de hardware é feito pelo kernel e o carregamento do sistema operacional e

serviço é feito pelo init.
1.2
Tipos de Init
Existem, basicamente, dois tipos de init usado pelas distribuições Linux: A maioria usa o SysV Init e
outras como o Slackware usam uma variante do BSD Init, e temos os novos candidatos a substituir o SysV Init
que são o Upstart e o SystemD.
As principais características destes sistemas de inicialização são:
 O SysV é dividido em runlevels, configurado pelo arquivo /etc/inittab e possui diretórios próprios para
os scripts e para os links simbólicos que os executam, ele é mais complexo e mais flexível em termos
de configuração;
 O BSD init é configurado pelo arquivo /etc/rc, não possui runlevels e não tem diretórios específicos
para scripts, ele é mais simples e mais enxuto termos de configuração.
1.3
A configuração do INIT
Estudaremos o SysV Init que é o padrão da maioria das distribuições Linux.

O processo init é configurado através do arquivo /etc/inittab. Onde são configurados o runlevel, os
terminais, scripts principais de inicialização e algumas teclas de controle e funções de gerenciamento de
energia. Cada linha do arquivo segue a seguinte estrutura:
id:runlevel:action:process
Onde:
id = sigla de identificação da linha, geralmente está relacionada com a ação configurada, uma
contração das palavras que definem a ação;
runlevel = em que nível o processo será executado;
action = ação do init para aquele processo;
process = qual comando/script será executado.
As principais ações do init são:
initdefault - define o nível padrão do sistema
sysinit - define o principal script do sistema, é executado antes das outras ações
boot - ação prioritária, é executada depois da sysinit e antes das outras
wait - define que cada script deve ser iniciado e terminado antes de executar o próximo
respawn - define que se o processo for morto ele deve ser reiniciado
ctrlaltdel - define a ação associada às teclas control + alt + del
kbrequest - define a ação associada às teclas alt + seta para cima
powerfailnow
powerokwait - ações relativas a gerenciamento de energia
powefail
Estas ações de gerenciamento de energia funcionam quando o computador está ligado a sistemas UPS
de energia (no-break inteligente).
Os níveis de execução (RUNLEVEL) são:
0 – Desligamento (Halt)
1 – Monousuário (Single User)
2 – Multiusuário sem NFS
3 – Multiusuário com NFS
4 – Multiusuário
5 – Multiusuário com NFS e Servidor X
6 – Reinício (Reboot)
Existem outros níveis de execução que não são documentados pela maioria das distribuições Linux,
como os níveis S ou s que na verdade são usados para entrar no nível de monousuário e não precisam do
inittab.

Os Runlevels são definições de quais serviços o sistema deve ou não executar em uma determinada
configuração. Assim determinados scripts tem ordem para iniciar em um runlevel e ordem para fechar em
outro. Por exemplo:
 No runlevel 6 ele deve fechar todos os serviços que estiverem abertos, fechar todos os processos e no
final reiniciar o computador;
 No runlevel 1 ele deve fechar quase todos os serviços, fechar os terminais e permitir apenas login de
root no tty1;
 No runlevel 3 ele deve carregar todos os serviços, todos os compartilhamentos, permitir múltiplos
logins de usuários e não executar o servidor gráfico;
Portanto o que diferencia um runlevel de outro é a decisão que é tomada (iniciar ou fechar) com os
scripts de inicialização.
O init executa, sempre que é carregado, o script configurado com a ação sysinit (geralmente rc.sysinit),
e após carregar os scripts do nível configurado na ação initdefault ele executa o script rc.local.
Em distribuições baseadas em Debian o script principal se chama rcS, geralmente pequeno e usado
apenas em personalizações administrativas. Em distribuições baseadas em Red Hat o script principal é o
rc.sysinit e geralmente carrega as principais funções do sistema, como RAID, LVM, serviços de boot, etc.
Exemplo de inittab padrão Red Hat para o runlevel 5:
1.3.1
Upstart
O upstart é um daemon baseado em evento e um substituto do /sbin/init (pai de todos os processos).

Ele assegura o começo e parada das tarefas e serviços durante o boot, bem como uma parada programada,
além de supervisionar os sistemas em execução.
Foi originalmente desenvolvida para a distribuição Ubuntu, mas é adequado para ser implantado em
todas as distribuições Linux como um substituto para o venerável init System-V.
Destaques do upstart:
 As tarefas e os serviços são começados e parados por eventos (Signal);

 Os eventos são gerados enquanto as tarefas e os serviços estão funcionando ou parados;
 Os eventos podem também ser gerados em intervalos programados, ou quando os arquivos de
configuração forem alterados;
 Os eventos podem ser recebidos de qualquer um ou de processos do sistema;
 Os serviços podem ser reiniciados se morrerem inesperadamente;
 Comunicação bidirecional com o daemon do init, para descobrir se os serviços estão funcionando,
porque falharam etc.
Você pode começar a utilizar o upstart através dos comandos de controle.
# stop portmap
Para o portmap.
# initctl list
Lista todos os serviços em execução e seu estado (start, stop, waiting). Se você executou o comando
acima para o portmap, verá que ele irá aparecer como waiting.
# start portmap
Inicia o portmap.
# status portmap
Verifica o status do portmap.
Onde configurar as opções que tinham no inittab?

Ao contrário do System V, que concentrava todas as configurações em um único arquivo (/etc/inittab),
agindo na forma serial de inicialização, o upstart utiliza um arquivo para cada item, antes contido no inittab.
Os arquivos ficam dentro do diretório /etc/init.
Dentro deste diretório você irá encontrar os arquivos que habilitam as opções antes encontradas no
inittab, como os terminais TTY, control-alt-delete, udev e etc.
Exemplo: Para habilitar o tty2 apenas no runlevel 3 edite o arquivo abaixo:
# vim /etc/init/tty2.conf
start on runlevel [2]

stop on runlevel [!23]
respawn
exec /sbin/getty -8 38400 tty2
Com o upstart as configurações ficaram bem mais flexíveis. Coloque start para inicializar ou stop para
desligar um processo no runlevel desejado.
Alterando o seu runlevel default

Para alterar o initdefault é necessário alterar o arquivo rc-sysinit.conf. Altere a variável

DEFAULT_RUNLEVEL=2 pelo runlevel que deseja inicializar.
No antigo init (SysV init) qualquer alteração no arquivo /etc/inittab, para que as novas configurações
fossem carregadas, é necessário rodar o comando “init q” sem a necessidade de reiniciar a máquina, e para o
upstart o procedimento é o mesmo.
Finalizando
O conteúdo de um arquivo dentro do /etc/init tem as seguintes características:
 Os arquivos contidos em /etc/init executam um comando sempre após o "exec".

 Outro ponto interessante é colocar o parâmetro "respawn". Esse parâmetro monitora o comando
executado. Caso o mesmo termine inesperadamente, um novo programa é inicializado
automaticamente. É empregado normalmente para os terminais virtuais (tty’s)
 Nos arquivos, além das execuções acima é possível também executar um script.
1.3.2
Systemd
O sistema de supervisão e inicialização de serviços Systemd foi anunciado como o novo, revolucionário
e totalmente inovador substituto do venerável SysVinit. De fato, na descrição teórica ele parece ser muito
poderoso, embora menos flexível do que uma série de scripts de shell.
Distribuições que utilizam o systemd por padrão:
 Fedora 15 e superior;
 Mageia 2 utiliza systemd por padrão;
 Mandriva 2011 tem o systemd habilitado por padrão;
 OpenSUSE usa systemd por padrão a partir da versão 12.1 e superior.
Distribuições onde o systemd está disponível:
 Arch Linux tem pacotes para o system;

 Debian GNU/Linux tem pacotes para systemd no repositório "testing";
 Gentoo oferece pacotes com systemd.
Entre suas características especiais está o de garantir que determinado serviço foi parado e, com ele,
todos os processos filhos que este havia gerado. O subsistema que permite esse recurso é conhecido como
Cgroups (Control Groups, ou grupos de controle) e reside no kernel. Os Cgroups permitem atribuir rótulos (ou
tags) a cada processo que for iniciado no sistema, além de registrar tais informações (processos e seus
respectivos rótulos) num pseudo-sistema de arquivos, o que facilita imensamente sua consulta por qualquer
programa ou usuário.
Outra característica é em relação a montagem de sistemas de arquivos. O Systemd é dotado de
inteligência onde necessário. Ele lê o arquivo /etc/fstab durante a inicialização do sistema, e cria as políticas de
montagem automática dos sistemas de arquivos descritos no arquivo. O Systemd não faz uso do serviço autofs.
Ele utiliza o suporte do kernel ao autofs, mas implementa internamente as montagens automáticas, de forma
totalmente independente do serviço autofs.
Arquitetura do Systemd
O Systemd visa a agir nos dois principais pontos problemáticos do SysVinit: shell e paralelismo.
Para eliminar o uso do shell, o Systemd realiza todas as chamadas redundantes — isto é, aquelas
presentes na maioria dos scripts — de forma embutida no binário /sbin/systemd. E para permitir o paralelismo,
o Systemd abre sockets para comunicação entre os serviços, de forma que todos os serviços marcados pelo

administrador como desejados possam iniciar em paralelo e, caso dependam de outros serviços, estes também
sejam iniciados sob demanda.
Diretórios do Systemd
Instalar o Systemd, no momento, é uma tarefa restrita a algumas distribuições, como Fedora,
openSUSE, Debian, Gentoo, Arch e Ubuntu (este utiliza upstart por padrão).
Os arquivos responsáveis pelos serviços no Systemd se localizam em /lib/systemd/system/. No
entanto, como cada administrador pode — e deve como no caso das montagens de sistemas de arquivos —
criar os seus próprios serviços, há um diretório específico para esse tipo de personalização:
/etc/systemd/system/.
Ou seja: não mexa no /lib/systemd/system/. Mexa somente em /etc/systemd/system/. Não se espera
que o diretório /lib/ tenha arquivos de configuração alterados pelo administrador.
Uma listagem do diretório /lib/systemd/system/ logo após a instalação revela algo em torno de 140
arquivos e diretórios. Estes são serviços que o pacote já traz configurados e instalados para você. Você pode se
basear neles para escrever os seus próprios serviços.
Arquivos de serviços
Um fato muito positivo sobre o Systemd é que a documentação já está muito bem feita. O pacote do
Systemd já traz as páginas de manual de cada tipo de serviço. Experimente:
# man -k systemd
systemd.automount (5) - systemd automount configuration files
systemd.conf (5) - systemd manager configuration file
systemd.device (5) - systemd device configuration files
systemd.exec (5) - systemd execution environment configuration
systemd.mount (5) - systemd mount configuration files
systemd.path (5) - systemd path configuration files
systemd.service (5) - systemd service configuration files
systemd.snapshot (5) - systemd snapshot units
systemd.socket (5) - systemd socket configuration files
systemd.special (7) - special systemd units
systemd.swap (5) - systemd swap configuration files
systemd.target (5) - systemd target configuration files
systemd.timer (5) - systemd timer configuration files
systemd.unit (5) - systemd unit configuration files
Há uma página de manual para os arquivos de serviços (systemd.service), e é ela que devemos
consultar para entender ou desenvolver arquivos de serviços.
Gerenciar serviços com o comando “systemctl”:
# systemctl status irqbalance.service

Verifica o estado atual do serviço irqbalance.
# systemctl enable httpd.service

Habilita o serviço httpd.
# systemctl restart httpd.service

Reinicia o serviço httpd.
# systemctl stop httpd.service

Para o serviço httpd.

# systemctl disable telnet.service

Desativa o serviço telnet.
# systemctl list-units --type=service

Lista todos os serviços ativos.
1.4
O gerenciamento dos scripts de inicialização
Os scripts de inicialização ficam no diretório /etc/init.d (Debian) ou /etc/rc.d/init.d (Red Hat), no Red
Hat existe um link para redirecionamento do rc.d para init.d.
Para não ser preciso modificar o script em cada runlevel, existem diretórios onde são criados links
simbólicos apontando para os scripts em /etc/init.d.
De /etc/rc0.d até /etc/rc6.d de acordo com o runlevel desejado. Os links simbólicos para os scripts são
tratados da seguinte forma:
 Os scripts que começam com K recebem a instrução de fechar naquele nível (stop);
 Os scripts que começam com S recebem a instrução de iniciar naquele nível (start);
A ordem de execução é determinada pelos números de 00 a 99 que estão juntos da letra (K ou S) no

nome do link simbólico. Os links simbólicos com a letra K são executados antes dos links com a letra S (ordem
alfabética).
Como no exemplo abaixo:
K20nomedoscript – fechar o script na ordem 20

S35nomedoscript – iniciar o script na ordem 35
Para verificar é só listar os diretórios dos runlevels:
debian:~# ls -l /etc/rc0.d

ou
debian:~# ls -l /etc/rc2.d
Os scripts que são carregados na verdade estão em /etc/init.d e são utilizados da seguinte forma:
Em qualquer Linux:
/etc/init.d/nome_do_script <parâmetro>
Onde o parâmetro pode ser no mínimo start ou stop, para iniciar e parar o script respectivamente.
Alguns scripts possuem outras instruções de execução como: restart, reload, status, etc.
De acordo com a distribuição utilizada existem ferramentas para lidar com os scripts de inicialização:
Em distribuições baseadas em Red Hat:

service <nome_do_script> <parâmetro>
Em distribuições baseadas em Debian:

invoke-rc.d <nome_do_script> <parâmetro>
Segue abaixo um exemplo de script que acata as instruções de stop, start e restart para realizar
funções diferentes:
debian:~# vi /etc/init.d/teste.sh
#!/bin/bash
# Script de teste de inicialização
# Função que escreve quando o script recebe a instrução de start
inicia () {
echo -e “\n ” “Iniciando script” “\n ”
sleep 3
}
# Função que escreve quando o script recebe a instrução de stop
para () {
echo -e “\n ” “Fechando script” “\n ”
sleep 3
}

# case para testar os parâmetros passados ao scripts

case $1 in
start) inicia ;;
stop) para ;;
restart) para ; inicia ;;
*) echo “Use: /etc/init.d/teste.sh (start|stop|restart)” ;;
esac
### FIM
debian:~# chmod -v 755 /etc/init.d/teste.sh
O próximo passo seria criar os links simbólicos para todos os runlevels com o comando ln, da seguinte
forma:
debian:~# ln -s /etc/init.d/teste.sh /etc/rc0.d/K20teste.sh

debian:~# ln -s /etc/init.d/teste.sh /etc/rc2.d/S80teste.sh
Mas cada distribuição tem sua própria ferramenta de ativar scripts de inicialização:
Em Debian temos o update-rc.d que independente se o script tem a estrutura certa ou não ele cria os
links, geralmente ele utiliza um cabeçalho para estar de acordo com os padrões LSB, apesar de que este
cabeçalho não é obrigatório para o correto funcionamento do script ele complementa as informações do
mesmo:
update-rc.d <script> <opções>
Criando os links simbólicos:
debian:~# update-rc.d teste.sh defaults 80 20
Ele irá criar os links simbólicos para runlevel com a seguinte ordem irá fechar como 20 e iniciar como
80.
Assim fechará no início do processo de desligamento e iniciará como um dos últimos scripts já que ele
depende que outros serviços do sistema estejam carregados.
No comando abaixo removemos os links para o script:
debian:~# update-rc.d -f teste.sh remove

Em Red Hat temos o chkconfig, para adicionar o script ao runlevel:
red-hat:~# chkconfig --add <nome_do_script>
Para remover o script:
red-hat:~# chkconfig --del <nome_do_script>
Mas o chkconfig trabalha apenas com scripts que tenham as seguintes linhas no início do arquivo, após
a linha #!/bin/bash :
# chkconfig: 2345 80 20
# description: Script para teste de inicialização
As linhas acima especificam que o script será iniciado do nível 2 ao 5 com a posição 80 e fechado nos
outros níveis na posição 20. A descrição facilita na hora de listar o script para identificar sua função.
Se adicionarmos essas duas linhas no início de nosso script e utilizarmos o chkconfig no Red Hat
teremos o seguinte resultado:
red-hat:~# chkconfig --add teste.sh
red-hat:~# chkconfig --list teste.sh
Desabilitando o script em um determinado runlevel:
Existem outros comandos que auxiliam na configuração de quais scripts devem ser executados pelos
runlevels, como:

NTSYSV
Usado em distribuições Red Hat ele usa uma interface em modo texto para ativar ou desativar scripts
no nível de execução em que o administrador estiver naquele momento.
Exemplo:
red-hat:~# ntsysv
RCCONF
Usado em distribuições Debian ele usa uma interface em modo texto para ativar ou desativar scripts
no nível de execução em que o administrador estiver naquele momento.
Exemplo:
debian:~# rcconf
1.5
Comandos úteis
Alguns comandos serão úteis para manipular o init durante o uso do sistema, como:
INIT
O comando init tem como função manipular o daemon do INIT, mudando o runlevel do sistema ou
simplesmente recarregando o arquivo inittab sem reiniciar o computador.

Exemplo:
debian:~# init q
Reexecuta o init relendo o inittab
debian:~# init 6
Muda o runlevel do sistema para o nível 6 (reboot)
debian:~# init 5
Muda o runlevel do sistema para o nível 5 (X)
debian:~# init u
Reexecuta o init sem reler o inittab
debian:~# init S
Muda o runlevel para o nível S
TELINIT
Este comando geralmente tem a mesma função do comando init.
RUNLEVEL
Mostra o nível de execução anterior e o atual. Se não houver nível anterior será mostrada a letra N.
Exemplo:
debian:~# runlevel
N2
WHO
O comando who mostra informações além de apenas quem está logado. Como por exemplo o nível de
execução atual, a data e hora em que foi executado, e o nível anterior.
Exemplo:
debian:~# who -r
run-level 2 2009-05-03 17:17 last=S
1.6
Contornando o INIT
A idéia de contornar o processo init é alcançar o prompt de comandos sem ter que iniciar os serviços e
restrições que são impostas na inicialização normal ou porque o init está falhando em algum momento.
Usamos este tipo de procedimento tanto para corrigir erros de inicialização, ou erros de scripts, quanto
para “quebrar” a senha do root.
1.6.1
Para contornar o processo de inicialização através do gerenciador de boot, por problemas durante a
execução do init, ou na montagem das partições (erros no fstab).
Digite na tela de edição do gerenciador de boot o seguinte:

init=/bin/bash
Onde você está indicando para o sistema que o processo que inicializa o Linux não é o /sbin/init e sim o
/bin/bash iniciando assim direto no shell.
Após iniciar basta remontar o raiz como leitura/escrita e utilizar o comando desejado, presumindo que
o seu sistema raiz seja /dev/sda1:
debian:~# mount /dev/sda1 / -o remount,rw
debian:~# passwd
O problema deste método é que como não foi feita a inicialização completa pelo processo init não
temos outros terminais e nem sinais de controle, sendo assim se algum comando for digitado errado pode ser
que não tenha como interrompê-lo.
Pode-se desta forma: editar o fstab, corrigir o inittab, mudar uma senha de root que foi esquecida, etc.
1.6.2
Quando o erro for no sistema de arquivos (filesystem), impossibilidade de carregar o init ou ter perdido
o gerenciador de boot (instalando outro sistema por cima) basta iniciar o sistema com um CD de instalação ou
um LiveCD de Linux e seguir os seguinte passos:
 executar o sistema de instalação até carregar o particionador, ou o LiveCD até o ter um shell
 criar um diretório para montar o disco do sistema;
 executar o comando de chroot para mudar o raiz do sistema para o diretório montado;
 executar o reparo do sistema;
 sair do chroot;
 reiniciar o computador.
Já estando com o sistema no CD executado e o disco identificado, veja o seguinte exemplo:
debian:~# mkdir /mnt/sistema
debian:~# mount /dev/sda1 /mnt/sistema
debian:~# chroot /mnt/sistema /bin/bash
debian:~# mount /proc /proc -bind
debian:~# grep -v rootfs /proc/mounts > /etc/mtab
debian:~# grub-install /dev/sda
debian:~# umount /proc
debian:~# exit

debian:~# umount /mnt/sistema
debian:~# reboot
Resumo do que foi feito:
1 – Criou o ponto de montagem;
2 – Montou a partição no ponto de montagem;
3 – Transferiu o sistema raiz do CD para a partição montada;
4 – Montou o /proc para ter acesso às informações do kernel;
5 – Colocou no mtab a informação da partição raiz montada;
6 – Instalou o Grub na MBR no modo não interativo;
7 – Desmontou o /proc;
8 – Saiu do ambiente de chroot;
9 – Desmontou a partição do sistema;
10 – Reiniciou o computador.
Apesar de usar o método no exemplo para regravar a MBR é possível executar quase todos os
comandos e serviços em um computador que foi inicializado a partir do CD e transportado para o sistema
instalado em disco.

2- KERNEL E MÓDULOS
2.1
Compilação de Kernel
Compilar o kernel é um passo importante para a otimização e suporte a hardware que um

administrador deve conhecer. O que é cobrado nas provas é o conhecimento de como compilar e o que está
relacionado ao kernel no sistema.
A localização do código fonte do kernel é /usr/src e independente de qual versão do kernel está sendo
utilizada o sistema procura /usr/src/linux como caminho para o código fonte. Este link simbólico é utilizado
principalmente por drivers que serão compilados posteriormente para esta versão de kernel.
A compilação de kernel pode gerar dois tipos de imagens (arquivo do kernel já compilado), o zImage e
o bzImage. A diferença entre essas imagens é que a zImage é uma imagem de kernel que será executada em
memória baixa (menos que 640kb) e é muito pequena, incompatível com a maioria do hardware atual que pede
muitos drivers e suportes no kernel. A bzImage é uma imagem que roda acima de 640kb podendo ter um
tamanho muito maior e também um número muito grande de suporte embutido do kernel.
2.2
Patch
O código fonte do kernel pode precisar de modificações antes de compilar. Isto geralmente é feito
aplicando um patch ao kernel, esse patch é um arquivo que foi gerado na comparação do código fonte do
kernel original e um código fonte de kernel modificado, tornando assim desnecessário o download de outro
arquivo de kernel completo.

Para aplicar um patch utilizamos o comando patch com a sintaxe:

patch <opções> <arquivo de patch>
Onde:
-i = arquivo de entrada;
-R = reverter um patch aplicado;
--dry-run = testar a aplicação de um patch;
-N = ignora se um patch já foi aplicado;
-p = em qual nível de diretório o patch deve ser aplicado
A opção -p varia de p0 à p4. Por exemplo -p0 indica que deve ser aplicado no próprio diretório, -p1
indica que o patch deve ser aplicado em ../ , -p2 indica que o patch deve ser aplicado em ../.. , -p3 ../../.. , etc.
O arquivo de patch geralmente é criado com o comando diff, que compara estruturas, arquivos ou
diretórios, e mostra em tela apenas as diferenças entre elas.
Exemplo:
Tendo o diretório /usr/src/codigo-fonte1 com o kernel original, copio e modifico o que eu achar
necessário em /usr/src/codigo-fonte2, depois utilizo o comando diff para comparar os dois diretório e mostrar
apenas o que está diferente entre eles. Assim eu distribuo apenas as partes que modifiquei, não sendo
obrigado a disponibilizar o código fonte todo. Quem desejar modificar seu kernel com as minhas alterações
deve apenas usar o arquivo gerado pelo diff.
Testar a aplicação do patch, estando dentro do diretório do código fonte com:
debian:/usr/src/linux# patch --dry-run -p1 -i arquivo-de-patch.diff
Aplica-se o patch, estando dentro do diretório do código fonte com:

debian:/usr/src/linux# patch -p1 -i arquivo-de-patch.diff

Para remover um patch basta digitar o seguinte:

debian:/usr/src/linux# patch -p1 -R arquivo-de-patch.diff
2.3
Make
Após a aplicação ou não de um patch precisamos escolher o que queremos de suporte no kernel e para
isso utilizamos o comando make. O comando make é uma ferramenta de compilação, na verdade o trabalho
dele consiste, basicamente, em instruir o compilador de acordo com as instruções contidas em arquivos
Makefile. Ele é usado tanto para gerar o arquivo com as configurações desejadas do kernel, quanto para
compilá-lo usando gcc.
Exemplo:
make <opções>
Dentro do diretório do código fonte devemos gerar o arquivo .config (arquivo que configura os
suportes e funções que queremos ou não no kernel) com algum dos seguintes comandos:
make config - configuração com perguntas em modo texto para cada item do kernel, muito usado no
início do Linux.
make xconfig - configuração com interface gráfica (qt).
make gconfig - configuração com interface gráfica (gtk).
make menuconfig - configuração com menus em modo texto, método mais utilizado para escolha de
opções do kernel.
make cloneconfig - gera um .config a partir do arquivo /proc/config.gz do kernel em execução.

make oldconfig - seleciona apenas as opções que são diferentes das de um .config existente.
Exemplo:
Se você tiver um .config pronto de um kernel anterior ao que eu vou compilar, basta colocá-lo no
diretório do código fonte atual que com o comando oldconfig o make irá escolher apenas as opções que são
diferentes das marcadas no .config.
make defconfig - seleciona as opções básicas de hardware.
Exemplo de make menuconfig:
Após criar o. config e escolher o que precisamos no kernel, que geralmente é o passo que mais
demora, devemos compilá-lo com um dos seguintes comandos:
make zImage – compila um kernel que terá menos que 512kb.
make bzImage – compila um kernel que terá mais que 512kb (big zImage).
make all – compila o kernel e o módulos.
make modules – compila os módulos apenas.
make modules_install – instala os módulos no sistema em /lib/modules/<versão do kernel>.
make deb-pkg – gera um pacote para Debian com o kernel e os módulos, para facilitar a instalação em
outras máquinas.
make rpm-pkg – gera um pacote para Red Hat com o kernel e os módulos, para facilitar a instalação em
outras máquinas.
make clean – limpa arquivos resultantes de compilações anteriores.
make mrpropper – retorna ao padrão os valores nos arquivos de configuração do kernel.
Exemplo de linhas de compilação de kernel:

A ordem das opções do make é muito importante, e cobrada nas provas, portanto:
debian:~# make dep clean bzImage modules modules_install
Após compilado o kernel ele fica no subdiretório arch/x86/boot/ com o nome de bzImage,
dependendo da sua arquitetura 32 bits (x86) ou 64 bits (x86_64).
Após instalado o kernel e módulos teremos as seguintes estruturas no sistema:
/boot/<kernel> - o nome geralmente usado para kernel é vmlinuz

/boot/System.map - o arquivo System.map é um 'mapa' da tabela de nome e símbolos usados pelo

kernel, pois a cada compilação eles podem mudar.
/boot/config-<versão do kernel> - arquivo com todos os suporte, serviços e módulos compilados neste
kernel (.config)
/lib/modules/<versão do kernel> - onde ficam os arquivos de módulos para o kernel.
2.4
Initial RamDisk
O initrd é um arquivo que é iniciado junto com o kernel, isto é ele também é configurado no
gerenciador de boot. A função principal deste arquivo é carregar os módulos que o kernel precisa para iniciar o
sistema, e também pode carregar um sistema de arquivos como um raiz (/) reduzido com alguns comandos e
scripts que podem ser úteis na hora do boot.
Para criar o ramdisk podemos utilizar o comando mkinitrd ou mkinitramfs que é um formato mais
novo.
A sintaxe dos comandos é:
mkinitrd <opções> <arquivo de initrd> <diretório de módulos do kernel>
mkinitramfs <opções> <arquivo de initrd> <diretório de módulos do kernel>
Para verificar um initrd existente faremos o seguinte:
1 – Copiar o initrd do kernel para o diretório /mnt com o nome de initrd.gz

2 - Criar um diretório init e entrar nele
3 – Descompactar o initrd utilizando o gunzip
4 – Abrir o arquivo initrd com o cpio
5 – Entrar no diretório initrd
Exemplo:

Após abrir o initrd podemos modificá-lo se necessário, podendo até alterar os executáveis ou scripts
que ele usa. Isto porém não é recomendado, já que geralmente não há necessidade de mudanças no initrd.
2.5
Módulos
Os módulos são os arquivos (geralmente compilados junto com o kernel) que fornecem ao kernel
suporte para hardware, serviços, protocolos, etc. A localização dos módulos fica em /lib/modules/<versão do
kernel>/kernel onde são divididos por categoria.
Para saber a versão do kernel em uso basta utilizar o seguinte comando:
debian:~# uname -r
O diretório dos módulos é /lib/modules/<versão do kernel>, onde tantos os módulos como os arquivos
de mapas e dependências estão. No subdiretório kernel é onde ficam os módulos, propriamente ditos,
separados em subdiretórios de acordo com a categoria.
Exemplo:

Para gerenciar os módulos usaremos os seguintes comandos:
depmod – cria/atualiza o arquivo modules.dep que contém a lista de todos os módulos e suas
respectivas dependências
lsmod – lista os módulos carregados em memória (em uso)
modinfo – exibe informações de um módulo (descrição, autor, versão)
insmod – carrega um módulo em memória
modprobe – carrega um módulo em memória e suas dependências
rmmod – descarrega um módulo da memória
Os arquivos do sistema que configuram os módulos são:
/etc/modules – nomes dos módulos que serão carregados automaticamente no boot, em distribuições
mais novas utiliza-se o arquivo /etc/modprobe.d/autoload
/etc/modprobe.d/aliases – apelidos para os módulos

Exemplo:
/etc/modprobe.d/blacklist – módulos que não serão carregados automaticamente
Exemplo:

2.6
Gerenciador de Boot
GRUB
Para que o kernel compilado entre em uso é preciso que seja configurado no gerenciador de boot. O
GRUB é um aplicativo que gerencia o boot tanto de Linux quanto de outros sistemas operacionais.
Seus arquivos de configuração ficam em /boot/grub. O GRUB funciona em estágios e a execução destes
permite que o GRUB seja gravado na MBR e ainda assim possa iniciar vários kernels e sistemas diferentes.
O MBR contém o estágio 1 do GRUB. Como a MBR só tem 512 bytes de tamanho para iniciar um
sistema, estágio 1 é bem pequeno, sua função é carregar o próximo estágio do GRUB, que está gravado em
outro setor do disco. O estágio 1 pode carregar o estágio 1.5 ou diretamente o estágio 2.
O estágio 1 fica nos 30 primeiros Kb do disco imediatamente após o MBR. O estágio 1.5 geralmente
contém funcionalidades específicas para sistemas de arquivos (ext3, reiserfs, xfs,fat).
É carregado o estágio 2 que exibe a tela de menu com as opções de sistemas operacionais
configurados no arquivo do GRUB.
O GRUB carrega na memória o kernel ou o sistema operacional escolhido, assim o GRUB deixa a cargo
do processo INIT ou do sistema de boot o resto da inicialização.
O GRUB utiliza uma nomeclatura própria para discos IDE e SCSI, portanto tanto os hda e das para o
grub tem o mesmo nome hd0, segue uma pequena tabela de referência:
hda e sda = hd0

hda1 e sda1 = hd0,0
hda2 e sda2 = hd0,1
hda3 e sda3 = hd0,2
hdb e sdb = hd1
hdb1 e sdb1 = hd1,0
hdb2 e sdb2 = hd1,1
hdc e sdc = hd2
hdd e sdd = hd3

O arquivo onde são configurados os sistemas e as opções do GRUB é /boot/grub/menu.lst . Onde são
especificados cada kernel, fundo de tela, tempo de espera, opções para segurança do boot, etc.
As principais variáveis deste arquivo são:
default – define o sistema padrão a ser carregado;
password – senha para o GRUB;
lock – define que a senha é para editar o GRUB;
timeout – tempo de espera até carregar o sistema padrão;
title – nome que aparece na tela do grub;
root – em que partição está gravado o kernel;
rootnoverify – em que partição está o sistema, esta partição não será montada;
kernel – qual o kernel e com quais opções ele será iniciado;
initrd – qual o initrd que será carregado com o kernel;
chainloader – qual o carregador de boot que o GRUB vai chamar, se for para chamar o que está no
início do disco basta colocar +1;
Exemplo do arquivo do GRUB, utilizando a UUID no lugar do dispositivo:
default 0
fallback 1
timeout 5
uuid d7a687a9-3b05-45be-bff1-8aded9e5e42b
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
title Linux 2.6.26

kernel /boot/vmlinuz-2.6.26 root=UUID=d7a687a9-3b05-45be-bff1-8aded9e5e42b ro noapic nolapic quiet
splash vga=792
initrd /boot/initrd.img-2.6.26
quiet
title Linux 2.6.26 (recovery mode)

kernel /boot/vmlinuz-2.6.26 root=UUID=d7a687a9-3b05-45be-bff1-8aded9e5e42b ro noapic nolapic single
initrd /boot/initrd.img-2.6.26
Para gravar o GRUB na MBR podemos utilizar o comando grub-install ou gravá-lo pelo shell do grub.
Exemplo de disco sda com a partição do boot sendo sda1:
Pelo prompt:
debian:~# grub-install /dev/das

ou
debian:~# grub-install “hd0”
Pelo shell do grub:
debian:~# grub
grub> root (hd0,0)
grub> setup (hd0)
grub> quit
debian:~#
2.6.1
GRUB2
O GNU GRUB2 É derivado de GRUB, the GRand Unified Bootloader, que foi originalmente concebido e
implementado por Erich Stefan Boleyn.
Esta atualmente em diversas distribuições GNU/Linux. As melhorias em relação ao GRUB incluem:
 apoio de scripts;
 módulo de carregamento dinâmico;
 modo de recuperação;
 menus personalizados;
 temas;
 Entre outras funcionalidades.
Formato
No antigo GRUB, os arquivos ficam localizados em /boot/grub/, inclusive o arquivo menu.lst que é lido
durante a inicialização, sendo exibido ao usuário na forma de menu do GRUB.
O Grub2 desmembra em uma nova hierarquia de arquivos e diretórios:

/boot/grub/grub.cfg – Este é o principal arquivo de configuração que substitui o menu.lst, e o mesmo

não pode ser editado diretamente.
Exemplo do arquivo /boot/grub/grub.cfg
Por padrão, sempre que o comando update-grub é executado, este arquivo é refeito como “somente
leitura”. Isto porque a intenção é que o arquivo não seja editado manualmente. O usuário também verá uma
infinidade de arquivos *. mod na pasta /boot/grub. Esses arquivos são de natureza modular do GRUB 2 e são
carregados pelo mesmo durante a inicialização.
/etc/grub.d/ – Este novo diretório contém os scripts do GRUB. Esses scripts são blocos de construção a
partir do qual o arquivo grub.cfg é construído. Arquivos com numeral no início são executados primeiro
começando pelo menor, exemplo: o 10_linux é executado antes do 20_mentest, que é executado antes do
40_custom. Entradas personalizadas podem se criadas no arquivo 40_custom ou num outro recém-criado.
/etc/default/grub – Este arquivo contém as configurações do menu do GRUB que são lidos pelos scripts
do GRUB e escritos em grub.cfg. É a famosa parte de “personalização” do GRUB.
2.7
Controle do Kernel
O kernel pode ser modificado não só em sua compilação, mas também em sua execução. O diretório
/proc/sys contém arquivos que podem ser editados com o kernel em uso e imediatamente mudam o
comportamento do kernel para aquele item. Muitos utilizam o comando “echo” e o redirecionador “>” para
isso, mas existe um comando específico para esta função, o comando sysctl.
Para mostrar todos os valores do kernel:

debian:~# sysctl -a
Para reler o arquivo de configuração:

debian:~# sysctl -p
Para modificar um valor devemos saber o endereço do arquivo e depois modificá-lo, exemplo:
/proc/sys/net/ipv4/ip_forward
debian:~# sysctl -w net.ipv4.ip_forward=1
Estaremos alterando o valor de ip_forward de 0 para 1, ligando assim o roteamento em ipv4.

Para que a alteração seja definitiva devemos alterar o arquivo /etc/sysctl.conf. Existem várias outras
funcionalidades que podemos ativar ou desativar pelo sysctl como ignorar ping, evitar redirecionamento de
pacotes, ataques de syn flood, ataques de MITM, ataque de spoof, máximo de swap usada por processos,
tamanho dos buffers usados nas conexões, etc.

3- SISTEMAS DE ARQUIVOS E MONTAGEM
3.1
Sistemas de Arquivos
Os sistemas de arquivos são as estruturas usadas em dispositivos de armazenamento a fim de que

estes possam: receber dados, gerenciar os dados, e recuperá-los quando necessário.
Utilizamos sistemas de arquivos em todos os sistemas operacionais, alguns já são nossos conhecidos,
outros nem tanto:
 msdos
 fat16
 fat32
 ntfs
 iso9660
 udf
Cada sistema de arquivos tem características específicas que os diferem entre si. Os sistemas de
arquivos usados no Linux também, apesar de serem “todos pra Linux” ele tem pontos em comum e diferenças
que os fazem ser incompatíveis para migração (a mudança só pode ser feita formatando). O primeiro sistema
de arquivos usado no Linux foi o do minix, o primeiro sistema de arquivos criado para Linux foi o ext (sistema
extendido).
Todos os sistemas de arquivos usados hoje em dia (até os em desenvolvimento) usam journaling para
evitar perdas de dados.
O Journaling é um serviço de log de atividade do sistema arquivos, ele registra as mudanças que serão
feitas no sistema de arquivos e depois grava as mudanças no disco. Ele utiliza arquivos que guardam
informações sobre outros arquivos (metadados) e arquivos com as mudanças que serão escritas no disco. Com
isso mesmo que haja um desligamento indevido ou trava do sistema, o journal mantém informações suficientes
para que o sistema de arquivos possa ser iniciado e posto quase no mesmo estado de quando foi fechado. Com
isso quase não há perda de dados e diminui muito a necessidade de uso da ferramenta de checagem.
O journaling pode utilizar métodos diferentes de gravação:
 Journal: grava o conteúdo na área de metadados e quais mudanças serão feitas no sistema de
arquivos antes de fazer a alteração na área de dados, por isso ele demora mais nas operações
de escrita que os outros métodos, mas é o mais confiável;
 Writeback: grava os metadados no journal, mas não as alterações que serão feitas no
conteúdo dos arquivos. Assim ele é o método mais rápido de journal, mas é o mais vulnerável
em caso de reinicio indevido de sistema, pois por deixar a gravação das alterações em disco
para depois ele pode ter muitos dados aguardando na fila de gravação e não recuperá-los
corretamente;
 Ordered: grava as mudanças em arquivos de metadados, mas força que os dados sejam
gravados em disco logo após serem escritos nos metadados do journal. É o método padrão de
journaling em sistemas ext3, não tão rápido como o writeback e não tão confiável como o
journal, mas com uma relação segurança/velocidade aceitável.
O principais sistemas de arquivos utilizados em Linux são:

 ext2 – Armazena arquivos de até 2gb, mapeia discos de até 16tb; sofre muito com inconsistência dos
dados;
 ext3 – Basicamente é um ext2 mais journaling, mais veloz que o ext2 e com melhores opções de hash e
acesso a diretórios;
 ext4 – Sucessor do EXT3, este sistema de arquivos suporta arquivos de até 16TB de tamanho e 1
exabyte de blocos no total. Um recurso muito interessante neste filesystem é o de verificação de
integridade de Journaling, o que incrementa mais confiabilidade para o recurso, que foi melhorado. A
gravação atrasada de dados também pode ser considerada como um recurso muito útil deste sistema
de arquivos, pois aumenta a velocidade de leitura e gravação, apenas gravando um dado quando ele
realmente for sair de cache. O tamanho do inode também é maior do que no EXT3 (256bytes ao invés
de 128bytes de EXT3), isso é necessário para que o inode possa armazenar informações extras, como
versão do inode ou data de modificação do mesmo.
 reiserfs – Projetado inteiramente com journaling, é mais rápido com arquivos pequenos, aloca blocos
de tamanho variável para minimizar o desperdício de espaço, usa btree (balanced tree) para buscar
metadados, informações e arquivos de forma mais eficiente;
 xfs – Criado pela SGI para o IRIX, pode usar discos de até 16tb em sistemas de 32 bits e 8eb em
sistemas de 64 bits, possui journaling e tem velocidade de 300mb/s;
Existem outros sistemas de arquivos criados para Linux, porém as provas pedem apenas os mais
utilizados.
Cada um dos sistemas de arquivos tem características específicas conforme mostrado acima, mas
todos com a mesma estrutura básica: Superbloco, Tabela de Inodos e Área de Dados.
1. Superbloco: Área de gerenciamento dos blocos, ele que sabe os blocos livres, ocupados e defeituosos;
2. Tabela de Inodos: Área onde residem os inodos (nós índices), são pequenas áreas de dados (128 bytes)
que indexam um arquivo e têm informações como: dono, grupo, blocos onde está gravado, data de
acesso, data de modificação, permissões, atributos;
3. Área de Dados: Área onde são gravados os arquivos em disco.
A manipulação de sistemas de arquivos consiste em criar, formatar, corrigir e ajustar as estruturas

empregadas nas partições para gravar dados. O conhecimento destas ferramentas não é necessário apenas
para fazer as provas, mas principalmente para fazer a manutenção necessária do sistema.
3.2
Particionamento
O primeiro passo para manipular sistemas de arquivos (filesystems) é criar o local onde será utilizado o
sistema de arquivos, ou seja a partição. O principais particionadores do Linux são: fdisk, cfdisk e parted.
FDISK
É um particionador em modo texto que utiliza letras para executar comandos dentro de um shell
(interpretador de comandos) próprio. Sua sintaxe é:
fdisk <opções> <dispositivo>
Onde será listada a tabela de partições do disco sda.

debian:~# fdisk -l /dev/sda
Para manipular partições de um dispositivo é preciso iniciar o fdisk e utilizar seus comandos internos.
debian:~# fdisk /dev/sda
Com o fdisk podemos criar partições, remover partições, alterar o tipo da partição, etc.
Para apagar todas as partições de um disco, criar 3 partições primárias tipo Linux com 10gb cada uma e
uma partição extendida com todo o espaço restante em disco, com 1 partição lógica de 2gb para swap, usamos
a seguinte seqüência de letras:
o, n, p, 1, enter, +10000M
n, p, 2, enter, +10000M
n, p, 3, enter, +10000M

n, e, enter, enter
n, enter, +2048M
t, 5, 82
w, q
CFDISK
Com o cfdisk temos uma interface onde vemos todos os comandos e todas as partições em uma única
tela:
Isto nos permite ter um controle maior sobre o particionamento é mais fácil de usar, pois o cfdisk
utiliza MB como padrão para tamanho de partições e GB para multiplicador de tamanho.
Apesar de não possuir a função de editar o rótulo BSD de uma partição, o cfdisk cumpre com
simplicidade o papel de gerenciar partições.
Onde as setas (cima e baixo) navegam entre as partições e as setas (esquerda e direita) pelas opções
do cfdisk.
3.3
Reparticionamento
Os reparticionadores tem como função criar e modificar partições assim como o fdisk ou cfdisk, mas
também trabalham modificando partições existentes sem ter que removê-la como faria o cfdisk ou o fdisk. Um
dos principais reparticionadores do Linux é o parted, que além de trabalhar em linha de comando é utilizado
por ferramentas gráficas como o gparted.
PARTED
Pode-se trabalhar com o parted de duas maneiras: utilizando comandos internos do parted ou pela
linha de comando.
Sintaxe:
parted <opções> <dispositivos> <comandos>
Para ver os comandos internos do parted basta digitar parted na linha de comando:
debian:~# parted

Para visualizar as partições na linha de comando:
debian:~# parted -s /dev/sda print
Para criar uma partição na linha de comando usando o parted:
debian:~# parted -s /dev/sda mkpartfs logical ext2 9950 11000

writing per-group metadata... 71% (time left 00:00)
Onde foi criada um partição lógica, formatando com sistema de arquivos ext2 do tamanho 9950 até o
11000 (tamanho aproximado em mb). Para visualizar a nova partição:
debian:~# parted -s /dev/sda print
Foi criada /dev/sda5 uma partição ext2, para mudá-la para ext3 use o comando abaixo:
debian:~# tune2fs -j /dev/sda5
Para manipular partições pela linha de comandos, e não pelo shell do parted usamos a seguinte
estrutura:
parted -s /dev/sda <comandos>

Onde a opção -s (script) é para não ser interativo.
Para apagar uma partição:
debian:~# parted -s /dev/sda rm 5

Onde 5 é o número da partição que será removida.
Para redimensionar a partição:
debian:~# parted -s /dev/sda resize 5 11000 11900
Para mover um partição
debian:~# parted -s /dev/sda move 5 12000 12900
Para não precisar reiniciar o computador após manipular partições basta utilizar o comando:
debian:~# partprobe
Para acessar o shell do parted digitamos parted, teremos as seguintes opções:

debian:~# parted
3.4
Manipulando partições
3.4.1
Formatação
O passo seguinte é preparar a estrutura da partição para receber os dados, ou seja formatá-la.
MKFS
A sintaxe do comando de formatação é a seguinte:
mkfs -t <sist.arq> <opções> <dispositivo>
mkfs.<sist.arq> <opções> <dispositivo>
Além de criar a estrutura de armazenamento o mkfs também pode checar ou atribuir valores
personalizados a partição através de suas opções. Entre as opções possíveis estão: definir a quantidade de
inodos, o tipo de uso do journal, tamanho dos blocos, tamanho dos inodos, o label da partição, etc.
Exemplo de formatação de uma partição ext3 com checagem de disco, especificando a quantidade de
inodos e com blocos de 4kb.
debian:~# mkfs -t ext3 -c -N 1600000 -b 4096 /dev/sda5
Cada tipo de sistema de arquivo tem características próprias, e as opções podem ser diferentes de um
tipo para outro. Portanto consulte o manual de cada tipo de sistema de arquivos para saber as características
de cada tipo de formatação.
Utilize o man para saber:

debian:~# man mkfs.ext3

ou
debian:~# man mke2fs
debian:~# man mkfs.reiserfs

ou
debian:~# man mkreiserfs
debian:~# man mkfs.xfs
Exemplo:
MKSWAP
Para dispositivos de swap o comando que faz a formatação é mkswap.
debian:~# mkswap -c /dev/sda2
3.4.2
Checagem
FSCK
A checagem do disco também faz parte do processo de manipulação de partições.
A sintaxe do comando de checagem é a seguinte:
fsck -t <sist.arq> <opções> <dispositivo>
fsck.<sist.arq> <opções> <dispositivo>
Entre as opções possíveis estão: checagem de blocos defeituosos, checagem com reparo automático,
etc.

Cada tipo de sistema de arquivo tem características próprias, e as opções podem ser diferentes de um
tipo para outro. Portanto consulte o manual de cada tipo de sistema de arquivos para saber as características
de cada tipo de checagem.
Utilize o man para saber:
debian:~# man fsck.ext3

ou
debian:~# man e2fsck
debian:~# man fsck.reiserfs

ou
debian:~# man reiserfsck
debian:~# man mkfs.xfs

ou
debian:~# man xfs_check
Lembrando que formatar e checar um sistema de arquivos não deve ser feito com o mesmo montado.
Pois a ferramenta de checagem pode considerar os blocos em uso (leitura/escrita) como inconsistentes e tentar
corrigi-los, levando a uma perda dos dados.
Para checar um sistema de arquivos montado deve-se usar o comando badblocks, que verifica com
teste não-destrutivo (padrão) o conteúdo de uma partição e exibe o número dos blocos defeituosos ou grava
em arquivo.
debian:~# badblocks -o lista /dev/sda1
Gerando assim um arquivo chamado lista contendo (se existir) o número dos blocos defeituosos. Assim
o fsck pode marcar os blocos defeituosos sem alterar os outros blocos do disco.
debian:~# fsck.ext3 -l lista /dev/sda1
3.4.3
Ajuste de Partições
Algumas características das partições podem ser ajustadas mesmo após a formatação, veremos alguns
comandos com as principais opções para isso.
TUNE2FS
Modifica opções de funcionamento de partições ext2/ext3. Sua sintaxe é:
tune2fs <opções> <dispositivo>
Exemplos:
debian:~# tune2fs -l /dev/sda1

Onde listamos as opções usadas pela partição /dev/sda1.
debian:~# tune2fs -c 35 /dev/sda1

Onde a quantidade máxima de montagens sem passar o fsck durante o boot foi alterada para 35.

debian:~# tune2fs -c 0 /dev/sda1

Onde a quantidade máxima de montagens sem passar o fsck durante o boot foi desabilitada. Isto pode
ocorrer em perda de dados caso o sistema de journaling não esteja funcionando corretamente.
debian:~# tune2fs -L Sistema /dev/sda1

Onde é adicionado um rótulo (label) na partição.
debian:~# tune2fs -i 12m /dev/sda1

Onde o período de intervalo entre as checagens é modificado de 6 meses para 12 meses.
debian:~# tune2fs -m 1 /dev/sda1

Onde a porcentagem de espaço em disco reservada para o root passa de 5% (padrão) para 1%.
debian:~# tune2fs -r 65536 /dev/sda1

Onde a quantidade de blocos reservados passa a ser de 65536 blocos (256MB).
debian:~# tune2fs -u user1 /dev/sda1

Onde os blocos reservados da partição deixam de ser para o root e passam a ser para o usuário user1.
Isto é útil em sistemas onde não é permitido login de root.
debian:~# tune2fs -j /dev/sda5

Onde é acrescentado a característica de journaling a uma partição ext2 transformando-a em partição
ext3.
debian:~# tune2fs -O extents,uninit_bg,dir_index /dev/sda6

Configura uma partição ext3 para suporte a extents,uninit_bg,dir_index (ext4).
debian:~# tune2fs -I 256 /dev/sda6

Se o sistema de arquivos foi criado com inodos de 128 bytes, esse comando converte para 256 bytes.
debian:~# fsck -fp /dev/sda6

É obrigatório realizar o fsck para que as novas configurações entrem em vigor.
Obs.: Não há no momento ferramentas para converter de ext4 devolta para ext3, portanto não tente
fazer isso em um sistema de arquivos em produção. Caso seja a partição de boot do sistema não se esqueça de
passar o parâmetro “rootfstype=ext4” para o kernel Linux no gerenciador de boot (lilo ou grub).
Seguem algumas telas do tune2fs:

REISERFSTUNE
As partições em reiserfs podem ter suas características ajustadas pelo comando reiserfstune. Sua
sintaxe é:
reiserfstune <opções> <dispositivo>
Exemplo:
debian:~# reiserfstune –urandom /dev/sda3
Onde é criada uma nova UUID, randomicamente, para a partição.

debian:~# reiserfstune -l Sistema /dev/sda1
Onde o novo label da partição é Sistema.
Outras ferramentas de manipulação de filesystem mais avançadas são: debugfs (ext2/ext3),

debugreiserfs. Que manipulam desde tabela de inodos até estrutura blocos, sendo que a opção de recuperar
arquivos apagados do debugfs não funciona em ext3. Já que o ext3 apaga os registros do arquivo para facilitar o
trabalho do journaling.
SWAP
Para arquivos de swap temos os seguintes utilitários:
Ativar e desativar:
swapon <opções> <dispositivo>
debian:~# swapon /dev/sda2
Ativa a partição /dev/sda2 para ser utilizada.
debian:~# swapon -s
Mostra o status das partições de swap. Mesmo resultado produzido por cat /proc/swaps
A prioridade das partições de swap determina a ordem em que serão utilizadas. A memória RAM tem
prioridade 0, portanto é usada em primeiro lugar, a partição que tiver prioridade -1 será usada em seguida, a
que tiver prioridade -2 será usada em seguida e assim sucessivamente.
swapoff <opções> <dispositivo>
debian:~# swapoff /dev/sda2

Desativa a swap em /dev/sda2
3.5
Montagem
A montagem de uma partição é tornar os seus dados acessíveis para leitura ou leitura/escrita através
de algum diretório do sistema. O diretório se torna o ponto de montagem da partição e através dele temos
acesso a todo o conteúdo do dispositivo. Pode ser um dispositivo local como uma partição ou outro disco, pode
ser um dispositivo remoto como um compartilhamento, pode até ser um arquivo como de um ISO para verificar
a integridade do mesmo.
O comando que faz as montagens é o comando mount, e sua sintaxe é a seguinte:
mount <opções> <dispositivo> <ponto_de_montagem>
Montando um pendrive com partição em /dev/sdb:
debian:~# mount -t vfat /dev/sdb1 /mnt/pen
Montando um cdrom em /dev/hdc:
debian:~# mount -t iso9660 /dev/hdc /media/cdrom
Montando uma partição /dev/sda3 em ntfs:
debian:~# mount -t ntfs /dev/sda3 /mnt/windows
Para ter suporte a escrita em ntfs, é preciso ter o pacote ntfs-3g instalado.
debian:~# mount -t iso9660 -o loop /tmp/arquivo.iso /mnt/iso
Monta um arquivo, como o arquivo não possui mapeamento de hardware (tipo bloco ou caractere,
major e minor), é utilizado (-o) para o comando mount aceitar opções, a opção loop faz com que o sistema use
o dispositivo /dev/loop? para mapear o arquivo e montá-lo.
A montagem de um dispositivo pode ser feita pela linha de comando, o que a torna temporária pois ao
desligar a máquina a montagem se perde ou pelo arquivo que configura as montagens. Para torná-la definitiva
devemos configurar a montagem no arquivo /etc/fstab.
A estrutura do arquivo /etc/fstab é a seguinte:
<dispositivo> <ponto de montagem> <filesystem> <opções> <dump> <passo>
Exemplo de fstab:

Onde:
dispositivo – é quem será montado

ponto de montagem – onde será montado
filesystem – em qual tipo de estrutura de dados foi formatado aquele dispositivo
opções – quais características de montagem serão utilizadas
dump – se irá ou não executar o comando dump na inicialização
passo – prioridade da ferramenta de checagem (0, 1, 2)
As principais opções de montagem são:

defaults → Que significa: auto,rw,exec,async,suid,dev,nouser
auto → Monta automaticamente a durante o boot
noauto → Não monta automaticamente durante o boot
rw → Direitos de leitura e escrita no sistema de arquivos
ro → Direito de somente leitura
exec → Permite executar arquivos por este sistema de arquivos
noexec → Não permite executar arquivos
async → Escrita assíncrona em disco (usa o buffer de escrita)
sync → Escrita síncrona (grava direto no disco, sem buffer)
suid → Permite o uso do bit suid
nosuid → Não permite o uso do bit suid
atime → Grava a hora de acesso dos arquivos (access time)
noatime → Não grava a hora de acesso dos arquivos
owner → Permite que um usuário (não root) possa montar o dispositivo se ele for o dono do mesmo
user → Permite que um usuário comum possa montar o dispositivo e possa desmontá-lo depois
nouser → Não permite que nenhum usuário possa montar o dispositivo
acl → Permite o uso de ACL para o sistema de arquivos
usrquota → Permite o uso de cotas para usuários
grpquota → Permite o uso de cotas para grupos
errors=continue / errors=remount-ro / errors=panic → Define o comportamento em caso de erros
Exemplo:
/dev/sda1 / ext3 defaults,acl,erros=continue 0 0
No lugar do dispositivo é possível também especificar a UUID (Unique Universally Identification) que é
o número de identificação de um dispositivo. Com isso mesmo que o dispositivo mude de barramento ele será
identificado e montado no mesmo ponto de montagem.
Para descobrir uma UUID (Universally Unique Identifier) basta utilizar o seguinte comando:
debian:~# vol_id --uuid /dev/sda1

Com isso basta colocar no fstab no lugar de /dev/sda1 a UUID.
De:
/dev/sda1 / ext3 defaults 0 0
Para:
UUID=eed1c6f5-28f6-4c28-b015-275b1ca42551 / ext3 defaults 0 0
E assim mesmo que outro dispositivo seja colocado como sda1 o /(raiz) será montado com o
dispositivo com aquela UUID.
Exemplo de fstab com UUID:
A montagem não se limita apenas a dispositivos, é possível também montar arquivos (que não
possuem mapeamento de hardware) como arquivos.iso.
Com o comando dd copiamos direto de dispositivo para dispositivo ou arquivo.
Exemplo:
debian:~# dd if=/dev/zero of=/root/arq1 bs=1M count=1600
Criando um arquivo que copia dados do dispositivo /dev/zero para /root/arq1 com blocos de 1 Mb e
repete esses blocos 1600 vezes, ocupando 1.6Gb de espaço e após formatar basta montar com o comando:
debian:~# mount -t ext2 -o loop /root/arq1 /mnt/dados
O dispositivo de loopback (/dev/loop?), empresta seu mapeamento de hardware para o arquivo

permitindo que ele seja montado como se fosse um dispositivo.
Montando uma iso para verificação de conteúdo:
debian:~# mount -t iso9660 /root/arquivo.iso /mnt/cdrom
Lembrando que montar um arquivo de iso não é suficiente para alterar seu conteúdo.
3.5.1
Auto Montagem

O autofs é um serviço que possibilita que dispositivos sejam montado independente do arquivo
/etc/fstab e apenas quando forem acessados, é a montagem sob demanda tanto de dispositivos locais quanto
remotos.
Basta acessar o diretório do configurado como ponto de montagem e a montagem acontece

imediatamente.
O autofs utiliza 2 arquivos de configuração:
/etc/auto.master – Arquivo principal onde ficam o ponto de montagem e o arquivo associado a ele.
/etc/auto.<nome> - Arquivo onde será configurado cada dispositivo que será montado naquele ponto
de montagem.
O autofs pode ser configurado com o sistema em uso e não precisa ser reiniciado porque ele lê o
arquivo toda vez que for acessado o ponto de montagem.
O autofs pode também desmontar uma partição por tempo de ociosidade, diminuindo assim o uso de
recursos do sistema, utilizando a opção --timeout=<tempo> no arquivo auto.master.
Exemplo do arquivo auto.master para montar sob demanda, utilizando o /misc como ponto de
montagem e desmontando caso fique mais de 5 minutos sem atividade:
#
# $Id: auto.master,v 1.4 2005/01/04 14:36:54 raven Exp $
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
/misc /etc/auto.misc --timeout=300
Exemplo do arquivo auto.misc usado para montar um pendrive sob demanda:

#
# cd -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom
pen -fstype=vfat,defaults,sync :/dev/sda1
Lembrando que apenas o /misc precisa existir, o diretório pen será criado dentro do /misc no
momento da montagem.

3.6
Manipulação de ISO e CD
Para gravar arquivos em cd é preciso preparar os dados em um arquivo no formato que o programa de
gravação consiga interpretar. O comando que faz isso é o mkisofs.
MKISOFS
A sintaxe do comando é:
mkisofs <opções> -o <arquivo.iso> <diretório de origem>
Exemplo:
debian:~# mkisofs -T -r -l -ldots -J -o /root/backup.iso /root/backups
Onde:
-T = cria o arquivo trans.tbl, que era usado para mapear nomes em sistemas com nomes 8.3 que
migraram para o para 256.3.
-l = diretórios com nomes maiores que 31 caracteres.
-ldots = nomes começando com .
-r = extensão Rock Ridge. Permite suporte a informações como: dono, grupo, permissões, link
simbólicos, e nomes de arquivos com mais de 31 caracteres. Adicionando especificações relativas a norma
ISO9660.
-J = nomes joliet, para nomes compatíveis com os usados pela Microsoft.
-o = output (saída).
-V = especifica o nome do volume.
-b = utiliza uma imagem de boot padrão el torito.
Lembrando que a ISO não é compactada por isso o tamanho do diretório tem que ser no máximo o
mesmo do cd.
Para maiores informações consulte o man do comando.
CDRECORD
O comando crdecord transfere a iso para o cd. A sintaxe do comando é:
cdrecord <opções> <arquivo.iso>
Pode ser necessário identificar o dispositivo de gravação, para isso utilize o comando:
debian:~# cdrecord --scanbus
Caso o seu gravador de cd seja padrão IDE utilize:
debian:~# cdrecord --scanbus dev=ATA
Gravando o cd:

debian:~# cdrecord driveropts=burnfree dev=1,1,0 speed=4 backup.iso
Para apagar um cd-rw (deve ser feito antes de gravar dados na mídia):
debian:~# cdrecord dev=1,1,0 blank=all
debian:~# cdrecord dev=1,1,0 blank=fast
GROWISOFS
Para gravar DVD podemos utilizar o growisofs. A sintaxe do comando é:
growisofs <opções> <arquivo.iso>
Gravando um DVD a partir de um arquivo isso existente:

debian:~# growisofs -dvd-compat -Z /dev/sr0=arquivo.iso
Finalizando um DVD multisessão:

debian:~# growisofs -M /dev/sr0=/dev/zero
Iniciando um DVD multisessão com os arquivos de um diretório:

debian:~# growisofs -Z /dev/sr0 -R -J /home/dados
Continuando uma multisessão com os arquivos de um diretório:

debian:~# growisofs -M /dev/sr0 -R -J /home/backup
Onde:
-J = para utilizar nomes no padrão Joliet.
-R = para utilizar as extensões Rock Ridge.
/dev/sr0 = dispositivo de DVD

4- HARDWARE E ARRANJOS
4.1
Comandos de Verificação de Hardware
Verificar o hardware da máquina é necessário não só para poder escolher o que compilar no kernel
mas também para poder fazer funcionar os dispositivos que são ligados ao sistema. Bem como planejar
upgrades ou modificações no hardware.
Os tipos diferentes de hardware utilizam comandos próprios para verificação, como, por exemplo, os
PCI e os USB, etc.
LSPCI
Para verificar o hardware PCI utilizamos:
lspci <opções>
Exemplo:
Onde as opções pode ser:
- b – onde é mostrada a identificação dos dispositivos pelo barramento PCI e não pelo kernel
-v – verbose
-k – mostra o módulo do kernel relacionado ao hardware
-n – mostra a ID do dispositivo
-x – mostra o dump em hexadecimal
LSUSB
Para verificar o hardware USB utilizamos:
lsusb <opções>

Onde as opções podem ser:

-v – verbose
-t – mostra a arvore do barramento usb
LSHW
Para obter um relatório de hardware:
lshw <opções>
Onde as opções podem ser:

-html – cria um html para ser visto pelo browser
-xml – cria um xml
-sanitize – omite informações como: ip, seriais, etc.
Recomenda-se redirecionar a saída para um arquivo.
LSDEV
O comando lsdev mostra o hardware instalado e que IRQ, IO e DMA ele está utilizando.
debian:~# lsdev
O diretório /dev é uma diretório de arquivos dinâmicos, pois eles são criados por demanda. Quando
um hardware é inserido no sistema é gerado um evento, esse evento é captado pelo udevd (daemon de udev)
que reordena as chamadas hotplug para que o udevstart crie os dispositivos no /dev. Os arquivos de
configuração e as regras de criação de dispositivos estão no diretório /etc/udev.
UDEV
Em sistemas Linux mais antigos, o diretório /dev/ onde ficam os arquivos de dispositivos era estático,
isto é, quando instalado o sistema eram criados neste diretório os arquivos para mapear uma grande
quantidade de dispositivos. Mesmo que não existissem os dispositivos na máquina, os arquivos estavam lá para
mapeá-los.
Em sistemas Linux atuais o serviço udev é responsável por criar os dispositivos sob demanda, ou seja,
mesmo que não exista um arquivo de mapeamento de um hardware, o udev cria quando o hardware respectivo
é detectado.
A uma pequena sinopse de como acontece a criação dos arquivos de dispositivo através do udev:
1 - O udevsend envia ao udev os eventos hotplug detectados pelo sistema;

2 - O daemon do udev o udevd ordena os eventos hotplug do sistema antes de enviá-los ao udev para
evitar saídas múltiplas;
3 - O udevstart cria os nós de dispositivos no diretório /dev/ para os drivers que existam no kernel;
O diretório /etc/udev é usado para as configurações e permissões de acesso. O arquivo

/etc/udev/udev.conf pode ser usado para limitar o tamanho de memória usado pelo udev ou o nível de log do
syslog.
No diretório /etc/udev/rules.d/ ficam as regras para criação de uma gama de dispositivos, incluindo
placas de rede.

Assim ao inserir uma nova placa de rede na máquina ela recebe um nome complementar às placas
existentes. Se já temos eth0, a nova placa será eth1, mas se formos substituir uma placa defeituosa,
provavelmente queremos que ela tenha o mesmo nome da que estava no sistema. Para que isso aconteça é
preciso modificar o arquivo /etc/udev/rules.d/persistente-net.rules para que o MAC Address da nova placa
receba a nomeclatura da anterior.
Exemplo de arquivo persistent-net.rules
4.2
Comandos de Configuração de Hardware
Existem comandos no Linux que mudam a configuração de hardware, como os comandos hdparm e
sdparm.
HDPARM
O comando hdparm ajusta as características de funcionamento de discos IDE.
O comando hdparm ajusta desde uso de DMA até a acústica do disco.
Sintaxe do comando:
hdparm <opções> <dispositivo>
Ativando o uso de DMA para o disco hda:
debian:~# hdparm -d 1 /dev/hda
SDPARM
O comando sdparm ajusta as características de discos SCSI.

Sintaxe do comando:
sdparm <opções> <dispositivo>
Ativando o uso do cache de gravação de disco:
debian:~# sdparm -s WCE=1 -S -v /dev/sda

4.3
RAID
Redundant Array of Independent Discs (Arranjo Redundante de Discos Independentes) é como é

chamado o principal método de arranjo de discos utilizados. O RAID é uma forma de garantir melhor
desempenho, mais segurança de dados dependendo do tipo de RAID utilizado. Inicialmente o RAID não provia
segurança, mas com o tempo se tornou o princípio básico de seu funcionamento. Quando utilizamos alguns
discos na máquina podemos tratá-los como se fossem apenas um, de modo a combiná-los como se fossem um
único disco.
RAID 0
Este nível de RAID faz a soma do espaço dos discos utilizados, e também tem ganho em desempenho.
Utiliza um método de gravação chamado stripping, onde ele basicamente divide os dados a serem gravados em
partes e grava uma parte em cada disco quase que simultaneamente, fazendo com que o ganho em velocidade
seja considerável, já que temos mais de um conjunto de leitura/escrita trabalhando para cada dado.
O RAID 0 trabalha apenas com discos de mesmo tamanho.
Apesar da vantagem em desempenho, o RAID 0 não garante a segurança dos dados pois ele não é
realmente “redundante”, assim se algum dos discos falhar, os dados que estão fragmentados pelos discos serão
inutilizados.
Vejamos um exemplo de como ele funciona:
Vamos ver que os blocos ordenados de

gravação neste RAID 0 de dois discos, podem ser mais
discos, estão sendo gravados um em cada dispositivo.
Fazendo assim que dois conjuntos de leitura/escrita
trabalhem no arquivo ao mesmo tempo.
Além de discos de mesmo tamanho, o melhor

é que sejam também discos do mesmo fabricante para
que o desempenho do conjunto seja o melhor possível.
RAID 1
Este nível de RAID tem segurança de dados como característica principal. Ele utiliza mirroring
(espelhamento) para fazer com que os dados existentes em um disco sejam espelhados em outro. Por isso é
considerado o mais redundante dos níveis de RAID pois os dados que existem no disco principal estão
exatamente iguais no disco espelho.
O espelhamento faz com que o tamanho final do arranjo seja o tamanho de um disco. A vantagem é
que se o disco principal falhar o espelho assume automaticamente, sem que haja parada no sistema. Tão logo
seja feita a troca do disco defeituoso por um disco novo ele começar a fazer a sincronia dos discos, quer dizer,
ele começa a refazer o espelhamento para que os dados que existem em um disco também existam no outro. O
problema é que durante a sincronia a performance do sistema cai muito, devida a ter que ler dados no disco em

funcionamento para sincronizá-lo com o outro e ler e gravar dados no disco em funcionamento para uso normal
do sistema.
Por isso é muito comum que empresas apenas substituam discos fora do horário de trabalho a fim de
minimizar o desgaste gerado pela lentidão do acesso a disco.
O RAID 1 é o primeiro nível de RAID a suportar o uso de discos estepes (spare disks), discos que fazem
parte do arranjo mas não são utilizados. Assim um disco que quase não é utilizado, o sistema apenas verifica
periodicamente se o disco está em condições de funcionamento, não costuma apresentar defeitos. Seu
tamanho não é contado na soma total do arranjo e tem a vantagem de se um disco falhar o sistema inicia a
sincronia imediatamente, não necessitando de troca imediata do disco defeituoso e ainda assim garantindo que
mais de um dispositivo contenha os dados desejados.
Vamos ver que os blocos ordenados de

gravação neste RAID 1 de dois discos, podendo ter um
estepe se necessário, estão sendo gravados
igualmente em cada um dos dispositivos. Fazendo
assim que dois dispositivos tenham os mesmos dados
ao mesmo tempo.
Além de discos de mesmo tamanho, o melhor

é que sejam também discos do mesmo fabricante para
que o desempenho do conjunto seja o melhor possível.
RAID 5
Este nível de RAID utiliza paridade de dados para fazer a redundância, a paridade é o uso de um
algoritmo para fazer que a estrutura dos dados de um disco seja escrita em um espaço menor do que o original.
Resumindo serial algo como faz um algoritmo de compactação, escreve dados numa área menor.
As vantagens deste tipo de RAID são maior velocidade de leitura/escrita (mais de leitura) em relação ao
RAID1 e melhor tolerância a falhas já que os dados são espalhados pelos discos do arranjo. Basicamente
falando, na hora de gravar um dado o RAID5 utiliza disco que estiver menos ocupado naquele momento, assim
há um bom uso dos conjuntos de leitura/escrita, e na hora da fazer a sincronia quando há falhas o sistema
também apresenta um bom desempenho em relação ao RAID1.
Quando usamos RAID 5 cerca de 1/3 (um terço) de cada disco é reservado para acomodar a paridade
de outro disco do arranjo, assim sendo ele só pode ser feito com 3 ou mais discos.
Por exemplo, se temos um arranjo com 5 discos de 120 Gb, sendo quatro ativos em um estepe temos
um arranjo de aproximadamente 320 Gb, ou seja:
Retiramos um terço de cada disco, 120 x 2 = 240 / 3 = 80, sem a paridade cada disco tem apenas 80 Gb
livres. Multiplicamos pela quantidade de discos ativos, 4 x 80 = 320. Lembrando que o estepe não entra na
soma de espaço do arranjo.

Vamos ver que os blocos

ordenados de gravação neste RAID
5 de quatro discos, podendo ter um
estepe se necessário, estão sendo
gravados entre os dispositivos. E a
paridade de um disco fica gravada e
outro. Assim quando um disco falha
o sistema não pára seu
funcionamento.
Além de discos de mesmo

tamanho, o melhor é que sejam
também discos do mesmo
fabricante para que o desempenho
do conjunto seja o melhor possível.
Apesar de o RAID via hardware ainda apresentar melhor desempenho, a relação custo/benefício nos
mostra que com os avanços atuais o RAID via software pode ser empregado para solucionar problemas de
armazenamento e dar mais segurança aos dados de sua empresa.
O comando mdadm é o responsável pela criação e manutenção dos dispositivos de RAID, os

metadevices. Eles se localizam no diretório /dev/md/* e podem ser acessados por /dev/md* também. Após a
criação do md os discos utilizados no RAID não são mais tratados individualmente e sim através do arranjo.
MDADM
A sintaxe do comando mdadm é:
mdadm <modo de operação> <dispositivo> <opções> <dispositivo>
Supondo que coloquemos mais 3 disco padrão SATA no computador, presumindo que o sistema está
instalado no /dev/sda, teremos /dev/sdb, /dev/sdc, /dev/sdd. Criaremos uma partição primária tipo FD em
cada um dispositivo e teremos /dev/sdb1, /dev/sdc1 e /dev/sdd1.
Assim vamos criar um RAID 1 com 2 discos ativos e um disco estepe:
debian:~# mdadm -C /dev/md0 -a yes -l 1 -n 2 /dev/sdb1 /dev/sdc1 -x 1 /dev/sdd1
Onde:
-C = modo de criação de metadevices
-a = cria o md0 de modo persistente
-l = nível de RAID
-n = número de discos ativos e quais são
-x = número de discos estepes e quais são
Após criar o arranjo podemos verificar sua constituição de duas formas, pelo comando mdadm ou pelo
arquivo /proc/mdstat.
Primeiro pelo comando mdadm:

debian:~# mdadm -D /dev/md0
Onde:
-D = detalhamento
Ou
debian:~# cat /proc/mdstat
Veja o exemplo do comando mdadm:
Veja o exemplo do arquivo mdstat:
OBS: Nestes exemplos não há disco estepe.
Após o arranjo criado os passos que faltam para torná-lo utilizável são: formatar e montar. Para
formatá-lo usaríamos o exemplo abaixo:
debian:~# mkfs -t ext3 /dev/md0
Lembrando que após criarmos o arranjo não manipulamos os discos individualmente. Exceto nos casos
abaixo:
Para testar o funcionamento do RAID podemos usar o mdadm para simular falha.
debian:~# mdadm -f /dev/md0 /dev/sdb1
Onde a opção -f fará que o dispositivo /dev/sdb1, disco principal do RAID, seja tratado como um
dispositivo defeituoso dentro do arranjo /dev/md0. Assim o sistema o marcará como falhado e o colocará como
último dispositivo do arranjo, e havendo um disco estepe iniciará a sincronia de dados.

Para remover o disco falhado do arranjo:
debian:~# mdadm -r /dev/md0 /dev/sdb1
Onde a opção -r fará que o disco defeituoso, /dev/sdb1, seja removido do arranjo. Assim o arranjo
passa a ser de apenas dois discos.
Para adicionar um novo disco ao arranjo, novos discos entram como estepes se a quantidade de discos
ativos estiver completa, usamos:
debian:~# mdadm -a /dev/md0 /dev/sde1
Onde a opção -a fará com que o disco /dev/sde1 seja adicionado ao arranjo e entrará no lugar do
estepe que saiu.
No caso de possuirmos quatro discos de sdb até sde respectivamente e cada um com uma partição
primária, poderíamos criar um RAID 5 com um disco estepe.
debian:~# mdadm -C /dev/md0 -a yes -l 5 -c 128 -p left-symmetric -n 3 /dev/sdb1 /dev/sdc1 /dev/sdd1 -x 1

/dev/sde1
Onde:
-c = chunk-size, RAID de paridade utiliza a gravação em blocos para poder manipular os dados,
assim a opção -c determina em kb o tamanho destes blocos.
-p = algoritmo de paridade, determina qual tipo algoritmo irá construir e armazenar a paridade,
left-symmetric já é o algoritmo padrão, portanto poderia ser omitido.
O mdadm possui um arquivo de configuração que é usado para garantir que o RAID será inicializado
junto com o boot da máquina. Sua sintaxe é simples e de fácil compreensão.
Exemplo de arquivo do mdadm em /etc/mdadm/mdadm.conf:
As variáveis do arquivo são:

DEVICES = Indica quais partições são escaneadas para ver se fazem parte de algum arranjo,
pode usar caracteres coringa ou deixar apenas partitions.
ARRAY = Qual o arranjo que está sendo configurado, qual nível (level=), quais dispositivos
fazem parte do arranjo (devices=), podemos utilizar no lugar de devices o UUID do arranjo.
CREATE = Como serão criados os dispositivos de metadevices
HOMEHOST = Nome do sistema que contém os arranjos
MAILADDR = Email de quem será notificado quando o arranjo apresentar algum problema.
Basta ter um servidor de email de saída para que as mensagens possam ser enviadas para servidores
externos.

4.4
LVM
Existem formas de manipular discos de modo que eles ajam como um único dispositivo. Visando
segurança de dados, desempenho ou apenas soma do espaço em disco, uma dessas formas é o LVM (Logical
Volume Manager). As vantagens são: desde melhor velocidade em alguns casos de LVM, a possibilidade de
expandir o conjunto quando precisar de espaço, e até a capacidade de fazer snapshots para backup.
O LVM é bastante flexível, sua implementação no Linux permite que seja criado tendo apenas um
dispositivo e adicionando mais conforme seja preciso, incluindo até o uso de criptografia.
Para melhor trabalhar com LVM, é preciso antes de entender alguns conceitos.
O Device-Mapper é utilizado quando é necessário que haja algo no lugar entre o acesso ao dispositivo
e o dispositivo real, ele cria uma camada sobre os dispositivos, seja para criar um arranjo de dispositivos ou
criptografia sobre os mesmos. Uma das funções do device-mapper é redirecionar I/O de um dispositivo para
outro permitindo interação entre eles, trabalha com multipath como os serviços de storage melhorando
significativamente o acesso a disco.
LVM, RAID e partições criptografadas são exemplos de dispositivos que utilizam Device-Mapper.
Componentes do LVM:
PV – Phisical Volume:
Cada disco em si, a parte física do volume.
PE – Phisical Extends:
Extensões físicas, unidades de alocação de espaço, ou seja, pequenos pedaços de um VG. Um VG é
dividido em vários PE. Eles dividem o espaço em disco, gerenciam a gravação de dados e criam uma camada
que permite que vários discos sejam enxergados como um único arranjo.
VG – Volume Group:
Grupo de volumes, um VG é responsável por agrupar um ou mais discos (PV).
LV – Logical Volume:
É o volume lógico, ou seja, é uma partição (divisão) de um VG.
VGDA – Volume Group Descriptor Area

É a tabela de alocação do VG, onde todos os dados são do VG são armazenados. Divide-se em quatro
partes básicas: descritor de PV, descritor de VG, descritor de LV e vários descritores de PE e LE.
Os limites do LVM são 256 dispositivos ou 64000 vezes o tamanho de cada PE. Por exemplo um PE de
2Gb permitirá um LVM máximo de 128Tb e assim sucessivamente.
Criando um LVM:
Prepare os dispositivos físicos como PV:
debian:~# pvcreate /dev/hda6 /dev/hda7 /dev/hda8
Verifique os PV criados:
debian:~# pvdisplay
Crie o VG com os PV e determine o tamanho do PE.

debian:~# vgcreate aula /dev/hda6 /dev/hda7 /dev/hda8 -s 128M

Verifique os dados do VG incluindo o espaço livre para uso:

debian:~# vgdisplay aula
Crie o LV com os PE livres do VG:

debian:~# lvcreate aula -l 100 -n dados
Onde:
-L – determina o valor de tamanho que será alocado, o "FREE PE/SIZE" que será disponibilizado para
todo o grupo de volume.
-l – determina a quantidade de PE
-n – ou --name determina o nome do dispositivo lógico de volume.
-s – determina o tamanho de cada PE
FREE PE/SIZE – é espaço disponíveis para o grupo.
Formatando o LV:
debian:~# mkfs.ext3 /dev/grupo/data
Verificando informações do LV:

debian:~# lvdisplay /dev/grupo/data
Criando o ponto de montagem:

debian:~# mkdir /mnt/lvm
Montando o LV:
debian:~# mount /dev/grupo/data /mnt/lvm
Para aumentar o tamanho do grupo de volume, basta seguir os passos abaixo, lembrando que
filesystem como reiserfs não precisa ser desmontado para redimensioná-lo:
Adicione o novo PV:

debian:~# pvcreate /dev/hda10
Desmontando o LV:
debian:~# umount /mnt/lvm
Adicionando o PV ao VG:
debian:~# vgextend aula /dev/hda10
Verificando o espaço livre no VG:

debian:~# vgdisplay aula
Extendendo o LV:
debian:~# lvextend -l +25 /dev/aula/dados
Forçando a checagem do LV:

debian:~# fsck -f /dev/aula/dados
Redimensionando o LV:
debian:~# resize2fs /dev/aula/dados
Remontando o LV:
debian:~# mount /dev/aula/dados /mnt/lvm
Caso algum VG esteja inativo, ative-o com o comando:

debian:~# vgchange -ay
Isso ativará todos os VG disponíveis, pois nenhum nome foi especificado. Caso você não especifique
um grupo de volume ele ativará todos.
Para desativar digite:

debian:~# vgchange -an grupo
Para destruir um LVM é preciso destruir cada etapa:
Desmontando o LV:
debian:~# umount /mnt/lvm
Removendo o LV:
debian:~# lvremove /dev/aula/dados
Removendo o VG:
debian:~# vgremove /dev/aula
Removendo os PV:
debian:~# pvremove /dev/hda6 /dev/hda7 /dev/hda8
Para verificar o ocorrido em cada etapa digite:

debian:~# lvdisplay
debian:~# vgdisplay
debian:~# pvdisplay
Migrando dispositivos fixos:
Em caso de falha em algum dispositivo do LVM, é possível mover os PEs de um dispositivo fixo para
outro através do comando pvmove. Podemos utilizar essa movimentação para criar novos grupos de volume
caso você não tenha PE livres ou nenhum dispositivo novo.
Seu funcionamento é bem simples:

debian:~# pvmove -v
Em caso de possível falha no /dev/hda7 vamos trocá-lo. Podemos colocar um novo dispositivo,
adicioná-lo ao LVM com o pvcreate, adicioná-lo a grupo do /dev/hda7 (grupo) e migrar todos os PE com o
comando:
debian:~# pvmove -v /dev/hda7 /dev/hda9
Após a migração basta apenas remover o /dev/hda7 do Volume e do LVM. maneira de fazer isso é não
especificando o destino:
debian:~# pvmove -v /dev/hda7
Neste caso o LVM vai mover todos os PE que estavam no /dev/hda7 para qualquer PE livre dentro do
volume grupo, é preciso que exista em quantidade igual ao PE movidos. Depois é só remover o /dev/hda7 do
LVM, substituir por um dispositivo novo e integrá-lo ao grupo novamente.
Fazendo Snapshot de um LVM:

Quando fazemos backup, alguns programas têm problemas ao tentar ler os blocos do arquivo, pois se o
arquivo estiver em uso (leitura/escrita), alguns programas podem apresentar erro de E/S fazendo com que o
backup não seja realizado. O LVM tem um recurso que permite que dados do sistema seja mantidos estáticos
em um outro volume, enquanto o original continua sendo lido/escrito. O novo volume mantém uma imagem
estática dos dados desejados (snapshot) e permitindo assim que o backup seja realizado sem problemas.
Para se fazer um backup de dados em um LVM deve-se obrigatoriamente fazer a cópia dos dados de
backup para outro LVM dentro do mesmo VG.
Para criar um novo LV já como snapshot (-s) com o nome (-n) dados-bkp onde os dados de
/dev/aula/dados, serão copiados estaticamente para o novo lvm (dados-bkp), a quantidade de PE livres tem
que ser no mínimo do mesmo tamanho que os dados a serem copiados:
debian:~# lvcreate -s -l 804 -n dados-bkp /dev/aula/dados
Logical volume "dados-bkp" created

Criando o novo diretório para montagem posterior do LVM dados-bkp
debian:~# mkdir dados-bkp
debian:~# mount /dev/aula/dados-bkp /dados-bkp
Resumo do snapshot:
Esta é uma excelente solução para backup de dados em um computador de produção, visto que o
snapshot copia os dados em um momento exato mantendo a integridade dos mesmos. No volume que foi
criado o LVM, é feito o snapshot dos dados do LVM que se deseja duplicar, estes dados estão estáticos e não
serão alterados, podendo agora ser copiados com toda a segurança que nenhum usuário estará realizando
operação de leitura/escrita naquele momento. O backup poderá ser feito através do aplicativo tar ou
semelhante.

5- BACKUP
5.1
Estratégias de Backup
O backup é umas das ferramentas mais poderosas para o administrador e também uma grande dor de
cabeça se mal feito ou mal planejado. Conhecer a necessidade da empresa, a importância dos dados e
durabilidade da informação são requisitos obrigatórios para poder desenvolver a estratégia de backup que se
enquadre na disponibilidade de hardware e software da empresa.
A forma mais simples de backup é a cópia dos dados, o comando cp faz isso, mas backup também
envolve outros quesitos que o cp não poderia fazer.
Primeiro devemos saber que tipos de backup são os mais utilizados.
Backup Full - É a cópia completa de todos os dados desejados para serem gravados.
Backup Incremental - Backup realizado sempre com as modificações em relação ao último backup
realizado.
Backup Diferencial – Backup realizado diferença em relação ao último backup full
Vejamos dois exemplos de estratégias de backup utilizando o backup Full combinado com Incremental ou
Diferencial:
Backup Full + Incremental:
Vantagens: rápido e pequeno

Desvantagens: tempo de restauração
Para restaurar um backup incremental devemos primeiro restaurar o backup full e todos incrementais
seguidos até o dia desejado.
D S T Q Q S S
FULL IN IN IN IN IN IN
Um problema ocorrido numa sexta-feira envolveria a restauração do backup de domingo (full),

segunda-feira (alterações desde domingo), terça-feira (alterações desde segunda-feira), quarta-feira (alterações
desde terça-feira), quinta-feira (alterações desde quarta-feira) para que os dados estejam atualizados.
Backup Full + Diferencial:
Vantagens: menor tempo de restauração

Desvantagens: o backup cresce até o próximo full
Para restaurar basta apenas o backup full e o último backup diferencial.
D S T Q Q S S
FULL DIF DIF DIF DIF DIF DIF
Um problema ocorrido numa sexta-feira envolveria a restauração do backup de domingo (full) e

quinta-feira (alterações desde domingo) para que os dados estejam o mais atualizado possível.

Como parte da boa administração aconselha-se que a melhor época para restaurar um backup é numa
base regular de atividades visando verificar a integridade dos dados, o tempo decorrido para restauração, que
de acordo com a necessidade, pode ser semanal ou mensal.
A mídia de backup também é muito importante, pois dependendo do tempo necessário para gravar ou
restaurar, o tempo de duração do backup e o tamanho do mesmo influenciam na escolha da mídia. Os backups
em fitam costumam ser os mais utilizados pela sua durabilidade e tamanho. Mas com o crescimento de outras
tecnologias o armazenamento em discos óticos ou de estado sólido vem, timidamente, crescendo ao longo do
tempo.
5.2
Ferramentas de Backup
Os principais utilitários de backup são o cpio e o tar.
CPIO
Sintaxe do comando cpio:
cpio <opções> <origem> <destino>
O cpio trabalha com uma lista de arquivos e os agrupa em um único arquivo. Para otimizar o backup
criaremos a lista com o find e passaremos ao cpio através de pipe.
Fazendo backup de logs com o cpio:
debian:~# find /var/log -type f
debian:~# find /var/log -type f | cpio -o --format=tar -F backup-log.tar
Onde serão listados todos os arquivos em /var/log e o caminho completo deles será passado ao cpio
que irá criar um backup no formato do utilitário tar. A necessidade do caminho completo é porque o cpio
restaura os arquivos exatamente no local de origem.
Algumas opções do cpio:

-o – para fazer um backup
-i – para restaurar um backup
-H – o mesmo que --format
-F – nome do arquivo
-t – lista o conteúdo do backup
debian:~# find /var/log -type f | cpio -o -F backup-log.cpio
Para listar o conteúdo do arquivo backup-log.cpio faça:
debian:~# cpio -t -F backup-log.cpio
Para extrair o arquivo auth.log do arquivo backup-log.cpio faça:
debian:~# cpio -i -F backup-log.cpio /var/log/auth.log
Para extrair um backup utilizamos:
debian:~# cpio -i -F backup-log.cpio

TAR
Sintaxe do comando tar:
tar <opções> <destino> <origem> <origem> …
Exemplo de backup de diretórios com o comando tar:
debian:~# tar cf /root/backup.tar /etc /bin
Onde será feito o backup dos diretórios /etc /bin no arquivo /root/backup.tar.
Algumas opções do tar:

c – cria o backup
x – extrai o backup
f – indica que o tar irá trabalhar com um arquivo ou um dispositivo
C – caminho onde o backup será extraído (por padrão o tar extrai no diretório onde está sendo
executado o comando)
z – utiliza o gzip na compactação/descompactação do arquivo
j – utiliza o bzip2 na compactação/descompactação do arquivo
v – verbose
t – lista o conteúdo do backup
A – adiciona arquivos a um backup existente
Fazendo backup de logs com o tar e compactando com o gzip:

debian:~# tar cvfz backup-log.tar.gz /var/log
Fazendo backup do /etc e /bin e compactando com o bzip2:

debian:~# tar cvfj etc-bin.tar.bz2 /etc /bin
Listando o conteúdo do backup:

debian:~# tar tf etc-bin.tar.bz2
Para extrair o arquivo auth.log do arquivo etc-bin.tar.bz2 faça:
debian:~# tar xvfj etc-bin.tar.bz2 var/log/auth.log
Extraindo o conteúdo do backup no diretório atual:

debian:~# tar xvfj etc-bin.tar.bz2
Extraindo o conteúdo do backup no /mnt

debian:~# tar xvfj etc-bin.tar.bz2 -C /mnt
MT
O comando mt é utilizado para manipular dispositivos de fita. Ele avança, retorna, apaga entre outras
funções. Para manipulá-lo corretamente devemos primeiro identificar o dispositivo de fita que iremos utilizar.
Os dispositivos de fita (geralmente scsi) são dispositivos de caractere com major 9 e minor entre 0 224,
sendo que são criados no intervalo de 32. Eles podem ser:
/dev/st* : Dispositivo de fita SCSI com auto-rebobinamento

/dev/nst* : Dispositivo de fita SCSI sem auto-rebobinamento
Cada área gravada da fita é chamada de bloco de dados, ou apenas bloco.

A sintaxe do comando mt é:
mt -f <dispositivo> <opções>
Para apagar uma fita:

debian:~# mt -f /dev/st0 erase
Para ir para o final da fita:

debian:~# mt -f /dev/st0 eod
Para voltar a fita:

debian:~# mt -f /dev/st0 rewind
Para voltar e ejetar a fita:

debian:~# mt -f /dev/st0 offline
Para avançar a fita para um determinado bloco:

debian:~# mt -f /dev/st0 fsf 5
Para voltar alguns blocos:

debian:~# mt -f /dev/st0 bsf 2
RSYNC
O comando rsync é um utilitário para sincronização de arquivos e diretórios entre duas localidades
diferentes, locais ou remotos. Possibilitando a copia apenas dos arquivos que foram alterados desde a última
sincronia.
Antes de transferir os dados, faz uma comparação do arquivo na origem e no destino. Os arquivos são
quebrados em segmentos e os seus checksums são comparados. Os pedaços cujos checksums forem diferentes
são transmitidos.
A maioria dos repositórios de pacotes para Linux utilizam o rsync como método de atualização com os
servidores oficiais da distribuição.
A sintaxe do comando é:
rsync <opções> <origem> <destino>
Exemplos de uso do comando rsync:

debian:~# rsync -avz /mnt/servidor /backups
Onde é feita a cópia recursiva do diretório /mnt/servidor, preservando os links, proprietários para o
diretório /backups.
Algumas opções do comando rsync:

a – basicamente indica que você quer que a cópia seja recursiva e que tudo seja preservado;
v – verbose;
m – ignora diretórios vazios;
z – compactar os arquivos transferidos;
e – especifica qual o shell remoto a ser usado;
--progress – mostra o progresso da copia;
--delete-excluded – remove ns origem arquivos que não existam no destino;
--delete – remove no destino arquivos que não existam na origem;
--partial – se a conexão cair, continua de onde parou;

Fazendo a copia entre máquinas remotas:

debian:~# rsync -avz --progress --partial -e ssh usuario@10.20.1.100 /backups
Com a opção -e o rsync utiliza como shell remoto o ssh, fazendo com que toda a transferência seja
criptografada, garantindo maior segurança para o transporte dos dados.
Podemos utilizar o rsync como um daemon que escuta requisições na porta 873.
Vemos que por padrão o daemon do rsync vem desabilitado, podendo ser usado no modo standalone ou pelo
inetd.

6- GERENCIAMENTO DE REDE
6.1
Comandos de Configuração de Interface
Comandos de configuração
Comandos de manipulação de interfaces de rede, ip, rotas e outros serviços.
IFCONFIG
Comando ifconfig é utilizado para configurar as interfaces de rede, desde configurar ip, máscara,
broadcast até Mac Address.
A sintaxe do comando é a seguinte:

ifconfig <interface> <opções>
Pode ser utilizado da seguinte forma para listar as interface ativas:
debian:~# ifconfig
Para listar todas as interfaces:
debian:~# ifconfig -a
Para configurar uma interface:
debian:~# ifconfig eth0 10.20.1.100 netmask 255.255.255.0

Ou:
debian:~# ifconfig eth0 10.20.1.100/24
Para desativar uma interface:
debian:~# ifconfig eth0 down
Para mascarar um endereço Mac:
debian:~# ifconfig eth0 hw ether 00:1A:2B:F8:32:AF
Para ativar uma interface:
debian:~# ifconfig eth0 up
Para criar uma interface virtual:
debian:~# ifconfig eth0:0 10.25.1.100 netmask 255.255.255.0

Ou:
debian:~# ifconfig eth0:0 10.25.1.100/24
IPROUTE2
O pacote iproute2 provê funcionalidades de configuração de rede e roteamento em um só comando: ip

O comando ip tem a seguinte sintaxe:

ip <opções> <objeto> <comando>
Alguns exemplos de uso do comando ip:
Verificando as configurações das interfaces de rede:

debian:~# ip addr show
Desativando uma interface:

debian:~# ip link set eth0 down
Ativando uma interface:

debian:~# ip link set eth0 up
Limpando a configuração de uma interface:

debian:~# ip addr flush eth0
Atribuindo ip a uma interface:

debian:~# ip addr add 10.13.1.1/24 dev eth0
Removendo um ip de uma interface:

debian:~# ip addr del 10.13.1.1/24 dev eth0
Mostrar a tabela de roteamento:

debian:~# ip route show
Adicionar uma rota default:

debian:~# ip route add default via 10.13.1.254 dev eth0
Adicionar rota para uma rede:

debian:~# ip route add 172.31.1.0/24 via 10.13.1.200 dev eth0

As alterações feitas pelo comando ifconfig e ip são temporárias, residem em memória. Para que a
configuração seja permanente é preciso fazê-la em arquivos.
Em sistemas Debian é /etc/network/interfaces onde são configuradas todas as interfaces utilizadas.
Em sistemas Red Hat é /etc/sysconfig/network-scripts/ifcfg-<interface> um arquivo para cada

interface.
Exemplo dos arquivos:
Em Debian /etc/network/interfaces :
#
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.20.1.100
netmask 255.255.255.0
network 10.20.1.0
broadcast 10.20.1.255
gateway10.20.1.254
##########################
E as variáveis são:
allow-hotplug – ativa uma interface quando detectado conexão durante o boot
auto – ativa uma interface ao iniciar o sistema
iface – nome da interface
inet – tipo de configuração de ip, pode ser:
dhcp – ip dinâmico
static – ip fixo
address – endereço ip
netmask – máscara de rede
network – rede a que pertence
broadcast – broadcast da rede
gateway – endereço do default gateway da rede
hwaddress ether – endereço do Mac address modificado
Em Red Hat /etc/sysconfig/network-scripts/ifcfg-eth0:
# Please read /usr/share/doc/initscripts-*/sysconfig.txt

# for the documentation of these parameters.
ONBOOT=yes
USERCTL=no
IPV6INIT=no
PEERDNS=yes
TYPE=Ethernet
DEVICE=eth0
HWADDR=00:0f:ea:db:92:15
BOOTPROTO=static
NETMASK=255.255.255.0
IPADDR=192.168.1.200
GATEWAY=192.168.1.254

###########################
Onde as variáveis são:

ONBOOT – ativar a interface a iniciar o sistema
USERCTL – permite ou não o controle por usuários
IPV6INIT – carrega o suporte a ipv6 para esta interface
PEERDNS – usa o dns fornecido por terceiros
TYPE – tipo de encapsulamento de link
DEVICE – interface
HWADDR – endereço Mac
BOOTPROTO – tipo de configuração de ip
NETMASK – mascara de rede
IPADDR – endereço de ip
GATEWAY – endereço do default gateway
HOSTNAME – nome da máquina
Após os arquivos configurados podemos utilizar os comandos:
Ativa uma interface configurada em arquivo:
ifup <interface>
Desativa uma interface configurada em arquivo:
ifdown <interface>
WIRELESS
O gerenciamento de conexões wireless é extremamente importante, principalmente em tempos de

netbooks e internet gratuita, saber configurar sua conexão sem fio pelo modo de comandos é algo que irá
resolver muitas de suas dúvidas. O pacote de ferramentas básicas usadas para configurar as interfaces sem fio é
o wireless-tools, instale o pacote com:
Em sistemas Debian:
debian:~# aptitude install wireless-tools
Em sistemas Red Hat:

red-hat:~# yum install wireless-tools
Os comandos do wireless-tools servem para configurar a rede, verificar problemas e escanear por sinal.
A sintaxe dos comando é:
comando <interface> <opção>
Para escanear redes, usamos o iwlist:

Para configurar uma interface para uma determinada rede usamos o iwconfig:
Onde:
wlan0 – É a interface que está sendo configurada.
essid – É o nome da rede para a qual esta placa está sendo configurada.
mode – É o modo de trabalho da placa, podendo ser:

Managed – Rede gerenciada por um AP.
Master – Rede gerenciada pela placa, fazendo papel de AP.
Monitor – Placa em modo de monitoramento de rede, scaner de pacotes (depende da placa).
Ad-Hoc – Placa em rede direta com outra placa de rede wireless.

channel – Canal de freqüência onde a placa irá trabalhar
key – Chave WEP para autenticação na rede, podendo ser em hexadecimal escrita diretamente após a
opção key ou em ASCII escrita junto da opção -s:.
Feito o cadastramento na rede, basta configurar o IP da interface com o comando ifconfig ou ip.
Exemplo de configuração do arquivo /etc/network/interfaces com rede wireless e senha WEP:
Um exemplo de configuração do /etc/sysconfig/network-scripts/ifcfg-wlan0 com senha WEP:
Em se tratando de encriptação, é sabido e o uso de WEP torna vulnerável sua rede, mesmo usando o
WEP de 128bits. Por isso o uso de WPA pode melhorar a segurança no acesso a sua rede sem fio.
No Linux o pacote que implementa a WPA para as interfaces wireless é o wpa-supplicant. Instale-o
com:
Em sistemas Debian:
debian:~# aptitude install wpasupplicant

red-hat:~# yum install wpa_supplicant

Sua configuração é simples, basta conhecer a chave WPA da rede e configurá-la em arquivo.
Um exemplo de arquivo de configuração de WPA, o /etc/wpa_supplicant/wpa_supplicant.conf:
# Arquivo de configuração de WPA.

network={
ssid="<NOME DA MINHA REDE>"
scan_ssid=1
key_mgmt=WPA-PSK
psk="<CHAVE WPA PSK>"
}
Onde:
ssid – É o nome da minha rede sem fio.
scan_ssid – É para verificar a rede ao iniciar.
key_mgmt – É o tipo de gerenciamento de senhas da rede.
psk – É a chave usada na autenticação na rede.
Para que as interfaces wireless sejam ativadas e configuradas durante a inicialização é preciso que
estejam configuradas em arquivos, veremos alguns exemplos de arquivos de configuração com variáveis para
interfaces wireless com WPA.
Em sistemas Debian o /etc/network/interfaces com DHCP e WPA:
debian:~# vi /etc/network/interfaces
auto wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-conf /etc/wpa_supplicant.conf
Em sistemas Red Hat o /etc/sysconfig/network-scripts/ifcfg-wlan0 com DHCP e WPA:
red-hat:~# vi /etc/sysconfig/network-scripts/ifcfg-wlan0
ONBOOT=yes
BOOTPROTO=dhcp
WPA=yes
6.2
Roteamento
ROUTE
O comando route é utilizado para listar e criar rotas, ou seja, ele manipula a tabela de roteamento.
Lembrando que é uma tabela dinâmica, portanto, existe apenas em memória, para manter em funcionamento
é preciso gravar os comandos em arquivo.
Para listar a tabela de roteamento:
debian:~# route
Para listar a tabela de roteamento sem resolver nomes:
debian:~# route –n

debian:~# route -n
Adiciona uma rota para o default gateway:

debian:~# route add default gw 10.20.1.254
Apaga rota para o default gateway:

debian:~# route del default gw 10.20.1.254
Adiciona uma rota para uma rede diferente:

debian:~# route add -net 10.20.2.0 netmask 255.255.255.0 gw 10.20.1.100
ou
debian:~# route add -net 10.20.2.0/24 gw 10.20.1.100
Adiciona uma rota para um host:

debian:~# route add -host 10.20.3.100 netmask 255.255.255.255 gw 10.20.1.100
Exemplo de um esquema de Roteamento:
Dadas 4 redes distintas e isoladas uma da outra, onde todas as redes se comunicam através de seus
roteadores e cada roteador uma máquina rodando Linux, seja a seguinte estrutura:
Rede A – 10.20.1.0/24
Rede B – 10.20.2.0/24
Rede C – 10.20.3.0/24
Rede D – 10.20.4.0/24
Veja como ficaria o roteamento entre as redes.

R1
route add default gw 200.1.2.4
route add -net 10.20.2.0 netmask 255.255.255.0 gw 10.20.1.252
R2
R3
R4
Roteamento das máquinas clientes de cada rede:

Rede A:
Rede B:
Rede C:
Rede D:
Exercício:
Em uma empresa onde seus setores ocupam andares distintos com redes diferentes e ligados por
roteadores que são máquinas Linux.
As redes estão separadas no seguinte esquema:
Rede A:
172.16.1.0/24
Rede B
172.16.2.0/24
Rede C
172.16.3.0/24
Rede D
172.16.4.0/24
Configure o roteamento das redes abaixo:

6.3
Comandos de consulta de rede
O protocolo ARP faz mapeamento de endereços Mac para IP, utilizado também para fazer auditoria
sobre falsificação de endereços.
ARP
O comando arp é utilizado para verificar a tabela arp.

debian:~# arp -n
Address Hwtype Hwaddress Flags Mask Iface

10.20.1.15 ether 00:02:2A:E1:21:4A C eth0
10.20.1.2 ether 00:02:2A:E1:15:27 C eth0
10.20.1.254 ether 00:30:4F:5D:FA:56 C eth0
192.168.1.104 ether 08:00:27:44:3b:a1 C wlan0
192.168.1.103 ether 08:00:27:44:b1:23 C wlan0
192.168.1.254 ether 00:30:4f:3c:da:b1 C wlan0
Podemos utilizar a opção -s para inserir uma entrada na tabela arp:
debian:~# arp -s 192.168.1.171 00:01:02:ba:ca:da

Para remover uma entrada da tabela arp:
debian:~# arp -d 192.168.1.171
ARPWATCH
Para monitorar uma rede podemos utilizar um programa chamado arpwatch, ele mantém atualizada a
tabela arp e pode até informar alguma alteração via email. Monitora ataques tipo spoofing de arp.
O arpwatch pode ser configurado pelo arquivo localizado em /etc/arpwatch.conf (Debian) ou

/etc/sysconfig/arpwatch (Red Hat). Sua base de dados é armazenada em /var/lib/arpwatch (Debian) e
/var/arpwatch (Red Hat). Neste diretório, se localiza o arquivo arp.dat que é a base de dados do arpwatch.
As principais opções são:

-u – define como qual usuário o arpwatch deve ser executado
-e/-m – para quem deve enviar o email
-s – caminho para o comando sendmail
-d – Debugging. Inibe o envio de relatórios via email. Eles são enviados para a saída de erro padrão
(stderr)
-f – Informa qual o arquivo da base de dados deve ser usado. O valor padrão é arp.dat
-i – Especifica interface no lugar da interface padrão
-n – Especifica redes locais adicionais.
Exemplo:
OPTIONS="-u root -e admin"
Para enviar as mensagens para um email. Altere a linha para:

OPTIONS="-u root -e admin@empresa.com.br"
LSOF
O comando lsof tem como função principal mostrar todos os arquivos abertos pelo sistema, mas
também mostra informações de conexões abertas. Apesar de não ser sua principal função verificar conexões
abertas, o lsof pode ser uma excelente ferramenta na hora de analisar um sistema possivelmente
comprometido. Pois como não é muito comum e não vem instalado por padrão, dificilmente ele é alterado por
rootkits instalados no sistema.
Listando arquivos abertos:

debian:~# lsof
Listando as conexões abertas:

debian:~# lsof -i

NETSTAT
O comando netstat verifica o estado das conexões, sockets e até tabela de roteamento.
Verificas todos as conexões tcp:

debian:~# netstat -nat
Verificar as conexões tcp sem resolver nomes e mostrando o número dos processos:
debian:~# netstat -natp
Verificar as conexões tcp sem resolver nomes:

debian:~# netstat -naup
Verificar a tabela de roteamento:

debian:~# netstat -r
Verificar a tabela de roteamento de sem resolver nomes:

debian:~# netstat -rn
-n – não resolve nomes

-a – todos

-p – process
-t – tcp
-u – udp
-r – mostra a tabela de roteamento
NETCAT
O comando netcat tem como função de monitorar a comunicação entre portas e até permitir
transferência de arquivos byte a byte. Conhecido como o canivete suíço do TCP/IP esta ferramenta é útil em
auditoria de rede.
Fazer o backup de um diretório entre máquinas da rede:
Na máquina destino (10.20.1.200):

debian:~# netcat -vlp 1189 | tar xvzp
Onde o netcat irá abrir a porta 1189 e tudo recebido por ela será entregue para o tar.
Na máquina origem (10.20.1.100):

debian:~# tar cvzp /var/cache/apt | nc 10.20.1.200 1189
Onde será compactado o diretório /var/cache/apt na máquina origem e o pipe entrega para o netcat
na máquina destino diretamente na porta 1189, na máquina destino o comando netcat escutando e através do
pipe irá descompactar com tar o que estiver entrando na porta 1189.
Fazendo o backup entre máquinas em arquivo .tar.bz2 contando os bytes com o comando pv:
Na máquina destino (10.20.1.200):

debian:~# nc -vlp 3000 | pv -b | cat > bkp.tar.bz2
Na máquina origem (10.20.1.100):

debian:~# tar cvfj backup.tar.bz2 /var/cache/apt
debian:~# cat backup.tar.bz2 | pv -b | nc 10.20.1.200 3000
Escutar todas os pacotes de uma determinada porta e gravar em arquivo:

debian:~# nc -vlp 8080 | cat > log-porta8080.txt
PING
O comando ping utiliza o protocolo icmp para verificar se um host está respondendo pela rede.
Utilizando o icmp do tipo echo-request para o ping e echo-reply para o pong, o que permite que o retorno do
ping confirme se um host está ativo na rede e a velocidade da resposta permite saber como está a conexão.
Exemplo:
debian:~# ping -c 10 www.google.com

Onde o -c indica a quantidade de ping, pois o padrão no Linux é ping infinito.
A opção -b nos permite pingar para broadcast.
TRACEROUTE
O comando traceroute utiliza o protocolo icmp para verificar o caminho que é utilizado por um host
até chegar ao destino, mostrando cada roteador que é utilizado no caminho. Permitindo assim verificar se as
rotas estão corretas, se a falta de conexão de um host é por problemas nele ou no caminho até ele.
Exemplo:
debian:~# traceroute www.google.com.br
6.4
Sniffers de rede
TCPDUMP
O comando tcpdump é um sniffer de rede, ou seja, ele é coloca sua interface de rede em modo
promíscuo para “escutar” todas as comunicações que passarem pela rede. Podendo criar filtros, gravar em
arquivo, etc. Muito útil para análise de tráfego na rede.
Podemos utilizar o tcpdump com opções como:
- para escolher a interface (-i);

- para determinar onde será gravada a saída das informações (-0);

- criar filtros por protocolo (proto);
- criar filtros por porta (port);
- criar filtros por origem (src);
- criar filtros por destino (dst);
Exemplo:
debian:~# tcpdump -i eth0
Exemplo de saída do tcpdump:
Outro exemplo:
WIRESHARK
O aplicativo wireshark é um sniffer de rede, ou seja, ele é coloca sua interface de rede em modo
promíscuo para “escutar” todas as comunicações que passarem pela rede. Podendo criar filtros, gravar em
arquivo, etc. Muito útil para análise de tráfego na rede. Ele é executado em um servidor gráfico, por possuir
interface gráfica permite que seja visto em tempo real o conteúdo dos pacotes capturados, possui vários tipos
de filtros prontos, organiza a lista de comunicações por origem, destino, pacote, protocolo, etc.

6.5
Virtual Private Network
A VPN (Rede Privada Virtual) é um recurso que permite que uma rede segura que se comunique com
outra rede segura através de uma rede insegura (geralmente internet).
Utiliza o conceito de tunelamento e criptografia para que a comunicação ocorra de forma segura, por
chaves, senhas ou através de Autoridade Certificadora.
A VPN trabalha no formato cliente-servidor onde o servidor fica aguardando um determinado tipo de
conexão e o cliente é quem busca o servidor para fechar o túnel.
O OpenVPN é um aplicativo para construir VPN que faz o tunelamento da conexão, trabalhando com o
encapsulamento dos dados em pacotes UDP que conseguem até passar por firewall com NAT, faz a compressão
de dados e otimiza a velocidade da comunicação.
O OpenVPN trabalha com senha, certificados ou chaves pré-compartilhadas, dando a ele uma
flexibilidade em configuração. Os dispositivos de que ele usa para fazer o tunelamento no Linux são os
/dev/tun* (tun0, tun1, tun2).
O OpenVPN usa IP em pares para criar as pontas do túnel, seja de classe A, B ou C. Como é uma
conexão ponto a ponto não teremos Endereço de Rede e Broadcast, mas como a máscara de rede é /30 nós
teremos 4 IP na mesma rede o que só permite o uso de 2, como nos exemplos a seguir:
1 – 2 , mas 3 – 4 não
5 – 6 , mas 7 – 8 não
9 – 10, mas 11 – 12 não
Percebe-se que usamos 2 e pulamos 2 assim são construídos os pares da VPN.
O diretório de configuração do OpenVPN é /etc/openvpn, onde ficam os arquivos de configuração de

cada túnel, cada chave, cada certificado, cada rota, etc.

Seu diretório /usr/share/doc/openvpn/examples contém muitos arquivos de exemplo e scripts prontos

que auxiliam e muito na configuração de VPN, além de scripts personalizados para criação de chaves padrão
RSA tanto para Servidor quanto para Clientes da VPN.
Seja pensando em segurança quanto em velocidade o OpenVPN é um excelente software para fazer a
ligação entre redes. Possuindo versões para diversos sistemas operacionais é uma excelente solução quando
falamos de interoperabilidade.
Exemplo de arquivos de configuração, baseado na figura anterior:
MATRIZ
red-hat:/etc/openvpn# vi matriz.conf
dev tun
port 5000
ifconfig 10.1.1.1 10.1.1.2
route 192.168.2.0 255.255.255.0 10.1.1.2
secret chave-vpn1.key
comp-lzo
user nobody
group nobody
verb 3
persist-tun
ping-restart 15
ping-timer-rem 45
FILIAL
red-hat:/etc/openvpn# vi filial.conf
dev tun
port 5000
ifconfig 10.1.1.2 10.1.1.1
remote matriz.dyndns.org
route 192.168.1.0 255.255.255.0 10.1.1.1
comp-lz0
user nobody
group nobody
verb 3
persist-tun
ping-restart 15

ping-timer-rem 45
Descrição das variáveis contidas no arquivo:
dev tun
- Qual dispositivo será usado neste túnel, se especificado /dev/tun0 por exemplo e este dispositivo
estiver ocupado a VPN não conectará. Utilizando apenas /dev/tun ele usa o primeiro dispositivo livre.
port 5000
- Porta udp em que o OpenVPN trabalha.
ifconfig 10.1.1.1 10.1.1.2

- IP utilizando pelo túnel, primeiro o local depois o remoto.
route 192.168.2.0 255.255.255.0 10.1.1.2

- Rota para chegar na rede da filial é através da ponta remota do túnel (10.1.1.2).
route 192.168.1.0 255.255.255.0 10.1.1.1

- Rota para chegar na rede da matriz é através da ponta remota do túnel (10.1.1.1).
remote matriz.dyndns.org
- Caminho para a filial fechar a conexão de VPN com a matriz.
- Chave de 2048 bits précompartilhada para criptografia e autenticação. É secreta e não deve ser de
acesso a outros.
comp-lzo
- Utiliza a compressão lzo.
ping 15
- Faz um ping a cada 15 segundos para verificar a conexão.
persist-tun
ping-restart 45
ping-timer-rem
- Opções para manter a conexão ativa.
verb 3
- Nível de Log.
Comando para gerar a chave de 2048 bits no servidor:
debian:/etc/openvpn# openvpn --genkey --secret chave-vpn1.key
Para compartilhar a chave com o cliente utilize de métodos seguros como o ssh.
Iniciar manualmente a VPN, bom para verificar mensagens de aviso e erro durante a execução do
serviço, dentro de /etc/openvpn digitar:
debian:~# openvpn --config <nome_arquivo_conf>
debian:/etc/openvpn# openvpn --config matriz.conf

Fri Sep 26 15:06:57 2008 OpenVPN 2.0.9 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Sep 20 2007
Fri Sep 26 15:06:57 2008 WARNING: file 'chave-vpn1.key' is group or others accessible
Fri Sep 26 15:06:57 2008 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 26 15:06:57 2008 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 26 15:06:57 2008 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 26 15:06:57 2008 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 26 15:06:57 2008 LZO compression initialized
Fri Sep 26 15:06:58 2008 TUN/TAP device tun0 opened
Fri Sep 26 15:06:58 2008 ifconfig tun0 10.1.1.1 pointopoint 10.1.1.2 mtu 1500
Fri Sep 26 15:06:58 2008 route add -net 192.168.2.0 netmask 255.255.255.0 gw 10.1.1.2
Fri Sep 26 15:06:58 2008 Data Channel MTU parms [ L:1545 D:1450 EF:45 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Sep 26 15:06:58 2008 Local Options hash (VER=V4): 'fb384323'
Fri Sep 26 15:06:58 2008 Expected Remote Options hash (VER=V4): '14ef2354'
Fri Sep 26 15:06:58 2008 UDPv4 link local (bound): [undef]:5000
Fri Sep 26 15:06:58 2008 UDPv4 link remote: matriz.dyndns.org:5000
Se a conexão for estabelecida e a comunicação ocorrer normalmente, pode utilizar os scripts de

inicialização do OpenVPN.
Em Debian:
debian:~# invoke-rc.d openvpn start
Em Red Hat
red-hat:~# service openvpn start

7- GERENCIAMENTO DE DOMÍNIOS
7.1
DNS - Domain Name System
Conhecendo o DNS
Os servidores de DNS são os principais servidores na internet, pois permitem que através de nomes
possamos acessar os endereços. Já que toda a internet é baseada em IP, para acessarmos uma página
precisaríamos conhecer número IP dela, mas como é mais fácil lembrar de vários nomes que vários números, o
DNS permite que esses nomes sejam resolvidos para números, facilitando assim o uso da internet.
No início da internet, como foi pensada para pouco uso, havia um arquivo hosts que continha todos os
IP e nomes de máquinas que existiam na internet, o arquivo era mantido pela NIC (Network Information Center)
e distribuído por um único host, o SRI-NIC. Os administradores da Arpanet enviavam ao NIC, por e-mail,
quaisquer mudanças que tivessem sido efetuadas e periodicamente SRI-NIC era atualizado, assim como o
arquivo hosts.txt. As mudanças eram aplicadas em um novo hosts.txt uma ou duas vezes por semana. Com o
crescimento da Arpanet, entretanto, este esquema tornou-se inviável. O tamanho do arquivo hosts.txt crescia
na proporção em que crescia o número de máquinas na internet.
Além disso, o tráfego gerado com o processo de atualização crescia em proporções ainda maiores uma
vez que cada host que era incluído não só significava uma linha a mais no arquivo hosts.txt, mas um outro host
atualizando a partir do SRI-NIC. Com o uso do TCP/IP pela Arpanet a rede cresceu exponencialmente o que
tornou a atualização do arquivo algo impossível de ser mantido.
Os administradores da Arpanet tentaram outras configurações que resolvessem o problema do

hosts.txt. O objetivo era criar um sistema que resolvesse os problemas em uma tabela única de hosts. O novo
sistema deveria permitir que um administrador local tornasse os dados mundialmente disponíveis. A
descentralização da administração resolveria o problema do gargalo gerado por um único host e diminuiria o
problema do tráfego. Além disso, o fato da administração ser local faria com que atualizar os dados se tornasse
uma tarefa bem mais simples. O esquema deveria usar nomes em hierarquia para garantir a exclusividade dos
nomes.
Paul Mockapetris, do USC's Information Science Institute, foi o responsável pela arquitetura do
sistema. Em 1984 ele lançou as RFCs 882 e 883, que descreve o "Domain Name System", ou DNS. Estas RFCs
foram sucedidos pelas RFCs 1034 e 1035, que possuem as especificações atuais do DNS.
O DNS é foi criado para ser hierárquico, distribuído e recursivo, além de permitir o cache de suas
informações. Assim nenhuma máquina teria que saber todos os endereços de Internet, apenas os que estão
abaixo dela diretamente.
Os principais servidores de DNS são os Root Servers, servidores raiz de Internet (.). São servidores que
sabem quais são as máquinas responsáveis pelos domínios de primeiro nível. Ao todo existem 14 Root Server.
Para melhor entendermos podemos exemplificar a busca pelo domínio www.mcury.com.br da seguinte
forma:

www.mcury.com .br
host .3niv .2niv .1niv
Então quando você não tem um DNS de cache e precisa resolver um endereço, o resolvedor (cliente)
solicita ao servidor Root Server o endereço. Como o Root Server só conhece os domínios de primeiro nível
(.com .org .br .uk) ele repassa para o servidor que ele conhece que está ligado ao pedido do cliente, no caso o
.br, que passa pra quem sabe a resposta o .com que passa pra quem sabe a resposta .mcury que indica qual
host tem a informação pedida.
O BIND foi criado por quatro estudantes de graduação, membros de um grupo de pesquisas em ciência
da computação da Universidade de Berkeley e foi distribuído pela primeira vez com 4.3BSD. O programador
Paul Vixie, enquanto trabalhava para a empresa DEC, foi o primeiro mantenedor do BIND.
Atualmente o BIND é suportado e mantido pelo Internet Systems Consortium.
O desenvolvimento do BIND 9 foi realizado através de uma combinação de contratos comerciais e

militares. A maioria das funcionalidades do BIND 9 eram promovidas por empresas fornecedoras de sistemas
Unix que queriam garantir que o BIND se manteria competitivo com as ofertas de servidores DNS da Microsoft.
Por exemplo, a extensão de segurança DNSSEC foi financiada pelos militares dos EUA que perceberam a
importância da segurança para o servidor DNS.
7.2
Entendendo o BIND

Apesar do arquivo de configuração e as variáveis serem os mesmos, os locais são diferentes para cada
distribuição.
Em distribuições baseadas em Debian os locais são:
/etc/init.d/bind9
O script de inicialização do bind.
/etc/bind/named.conf
O arquivo de configuração.
Em distribuições baseadas em Red Hat:
/etc/init.d/named
O script de inicialização do bind.
/etc/named/named.conf
O arquivo de configuração.
Nome do daemon para ambas as distribuições é named.
Dentro do diretório de configuração do bind existe outros arquivos que configuram as zonas locais e
loopback, e outros como:
db.root - Arquivo que contém os endereços dos Root Servers
rndc.key - Arquivo com a chave para rndc, permitindo assim que de forma autenticada seja feita a
administração remota do bind. Incluindo atualização dos arquivos de zonas (DNS dinâmico).
Em Debian as configurações estão separadas em 3 arquivos named. Um para a configuração padrão

(named.conf), outro para configuração de opções para o bind (named.conf.options) e outro para as zonas que
serão adicionadas ao DNS (named.conf.local). Em Red Hat podemos ter apenas o named.conf englobando todas
estas configurações.
Uma das partes mais importantes na configuração de um DNS é o arquivo de zona, tanto da zona
direta quanto da reversa, que é importante principalmente quando se trata de servidores de E-mail que
verificam a existência de mapeamento inverso de IP (IP para nome) confirmando assim a identidade de um
emissor de email.
Nos arquivos de configuração de zonas utilizamos o RR (Resource Record), ou seja registro de recursos,
que são os registros de dados do DNS. São usados para descrever os hosts e recursos utilizados pelo DNS para
uma determinada zona.
Esses recursos são utilizados tanto para consulta de IP quanto para consulta de chaves, informações
sobre o servidor, informações sobre o email, informações sobre dados adicionais, etc.
Segundo as especificações das RFC: 1035, 1876, 2535, 2672, 2782, 2930, 2931, 3445, 3596, 3658.
Os principais RR são:
SOA – Geralmente o primeiro registro de uma zona, contém dados do domínio, email do responsável
pelo domínio e os intervalos de tempo para manutenção da zona;
@ IN SOA sala.intra. adm.sala.intra. ( 001; 3600; 7200; 86400; 3600; )

NS – Mapeia os servidores de nome com autoridade desta zona, têm sempre um registro A associado a
ele, muito importante para o funcionamento da zona;
@ IN NS sever1.sala.intra.
MX – Mapeia o servidor de E-mail associado ao domínio e qual a importância dele, quanto menor o
número associado mais importante é o servidor, têm sempre um registro A associado a ele;
@ IN MX 1 mailserver.sala.intra.
A – Mapeia um endereço associado a um nome, em Ipv4;

ftp IN A 10.20.1.220
AAAA – Mapeia um endereço associado a um nome, em Ipv6;

ftp IN AAAA 2002:0a14:01dc::1
CNAME – Mapeia um apelido para um host da rede;

pop3 IN CNAME mailserver
DNAME – Mapeia um apelido para um domínio inteiro, permite que ao apontar para um determinado
host seja redirecionado para toda uma subárvore de domínio;
empresa.teste. IN DNAME empresa-teste.sala.intra.
HINFO – Um registro HINFO fornece informações sobre tipo de CPU e sistema operacional para um
host do domínio. Nomes de CPU e SO podem ser obtidos aqui: http://www.iana.org/protocols
molde_mestre.sala.intra. HINFO INTEL-386 Linux
KEY – recurso de chave pública associada a uma zona. Utilizada pelo DNSSEC para autenticar os
registros de recursos SIG recebidos de zonas assinadas, as informações são exibidas na ordem: protocolo,
assinatura da chave, chave publica;
sala.intra. IN DNSKEY 256 3 3 BOMbSz...
LOC - Esse registro fornece a possibilidade de especificar as informações sobre localização de

computadores, sub-redes e redes no mundo. As opções são: latitude, longitude, altura, tamanho, precisão
horizontal, precisão vertical;
IN LOC 43 01 04.012 S 19 32 01.210 W 832.40m 1.10m 11003.00m 11.00m
MINFO – Esse registro fornece uma lista de servidores para uma caixa de correio ou lista de correio, o
primeiro ponto faz o papel de @ (arroba);
admin.sala.intra. IN MINFO outra-mailbox.sala.intra.
PTR – Esse registro provê mapeamento indireto para registros do DNS, mapeia IP para nome;
220.1.20.10 IN PTR ftp.sala.intra.
RP – Esse registro têm o e-mail da pessoa responsável pela zona ou host;

teste.sala.intra IN RP admin2.sala.intra.
SRV – Esse registro permite a seleção de um servidor, muito usado pela Microsoft para informar os
servidores do AD para os clientes. A RFC 1700 define alguns dos dados utilizados neste registro, ele informa:
serviço, protocolo, nome, prioridade, importância, porta, destino;
_ldap._tcp._msdcs SRV 0 0 389 ldap.sala.intra.
TXT – Esse registro contém uma informação qualquer que queira ser passada para aqueles que
consultarem a zona;
sala.intra. IN TXT "Domínio show de bola, instrutor sinistro..."

SPF - Esse registro define o servidor de email autorizado a enviar mensagens pelo domínio. É
consultado por servidores de email para confirmar autoridade sobre um domínio.
sala.intra. IN TXT "v=spf1 include:sala.net -all"
RRSIG - Registro de recurso assinado, utilizado em DNS com DNSSEC.

www.sala.intra. 6 IN RRSIG A 5 3 60 20100723102502...
Os arquivos também podem incluir as diretivas de zona:

$ORIGIN - Guarda o nome da zona.
$INCLUDE - Inclui um arquivo dentro da zona.
$TTL - Tempo de vida das consultas de DNS.
Para maiores informações sobre outros recursos consulte as RFC mencionadas acima. Para
informações sobre recursos mais utilizados em português consulte a rnp.br.
7.3
Configurando um domínio
Para configurarmos nosso domínio (zona) sala.intra, modificaremos o arquivo named.conf.local. Tendo
o primário em 10.20.1.100 e o secundário em 10.20.1.102.
zone "sala.intra" {
type master ;
file "/var/cache/bind/db.sala.intra" ;
allow-transfer { none; };
allow-update { none; };
};
zone "1.20.10.in-addr.arpa" {
type master ;
file "/var/cache/bind/db.1.20.10.rev" ;
allow-update { none; };
};
##
Assim estaremos criando um domínio que está nos arquivos db.sala.intra e db.1.20.10.rev, não tem
secundário e nem é atualizado dinamicamente.
Para podermos transferir dados do primário para o secundário é preciso que modifiquemos a variável
“allow-transfer” de “none” para o IP do DNS Slave, como no exemplo abaixo:
allow-transfer { 10.20.1.102; };
Assim somente a máquina 10.20.1.102 poderia solicitar transferência de dados do DNS primário,
utilizando a porta 53 tcp.
O arquivo named.conf.local do secundário deve ser configurado desta forma:

zone "sala.intra" {
type slave ;
file "/var/cache/bind/db.sala.intra" ;
masters { 10.20.1.100; };
};
type slave ;
file "/var/cache/bind/db.1.20.10.rev" ;
masters { 10.20.1.100; };
};
##
Assim definindo como “slave” na variável type, o DNS procura na máquina configurada em “masters”
os arquivos necessários para seu funcionamento.
Para melhorar a comunicação entre master e slave crie um seção server no named.conf.options de
cada servidor com as seguintes linhas:
Master - Deve ser configurado no servidor primário:

server 200.2.1.1 {
provide-ixfr yes;
transfer-format ( many-answers );
};
Slave - Deve ser configurado no servidor secundário:

server 200.2.1.2 {
request-ixfr yes;
};
A transferência de zona incremental (IXFR) tem como finalidade diminuir a quantidade de informações
trocadas, transferindo somente as mudanças feitas nas zonas do servidor primário para o servidor secundário.
Com essa configuração estamos dizendo que o servidor primário fornecerá esse recurso de
transferência e o servidor secundário sempre que possível utilizará. Quando, por algum motivo, o servidor
primário recusar uma IXFR, uma AXFR, transferência de zona convencional, será realizada.
Em Debian no diretório /var/cache/bind ou no Red Hat no diretório /var/lib/named os arquivos de

zona tem a seguinte estrutura.
debian:~# cd /var/cache/bind
debian:/var/cache/bind# vi db.sala.intra

$TTL 3600
$ORIGIN sala.intra.
@ IN SOA sala.intra. domainmaster.sala.intra. (
2010092001 ; serial
7200 ; refresh
3600 ; retry
86400 ; expire
3600 ) ; minimum
;;
@ IN NS ns1.sala.intra.
@ IN MX 1 mail.sala.intra.
ns1 IN A 10.20.1.10
mail IN A 10.20.1.254
pop IN CNAME mail
;;
Onde:
; – são comentários
$TTL – variável que armazena o tempo de vida das consultas, o valor é expresso em segundos, mas
pode usar multiplicadores como: H(horas), D(dias), W(semanas), etc.
$ORIGIN – variável que armazena o nome de domínio.
SOA – Start of Authority quem tem autoridade sobre esta zona, nome da zona e o email do responsável
pela zona com . no lugar do @. Armazena também os valores de tempo da zona.
serial – numero de controle de atualizações da zona, geralmente vem na forma: AAAAMMDDVV (ano
mês dia versão).
refresh – tempo em segundos que o secundário deve se atualizar com o primário.
retry – tempo em segundos que o secundário deve tentar se atualizar com o primário caso a tentativa
anterior falhe. Geralmente, esse tempo é menor que o tempo de atualização.
expire – tempo em segundos que o secundário para de responder após não conseguir se atualizar com
o primário. A desativação do secundário acontece porque ele não pode garantir as informações passadas por
ele, já que ele não as confirma com o primário.
ttl minimum – tempo de vida padrão da zona, exceto se for especificado pela variável $TTL, e tempo
que o servidor armazenará informação de consultas malsucedidas
(...) – os parênteses servem para indicar que as informações de registro podem ser escritas em várias
linhas.
Para criar o arquivo de zona reversa colocaremos apenas a parte do IP que não foi especificada no
arquivo named na zona reversa:
debian:~# vi db1.20.10.rev
$TTL 3600
@ IN SOA sala.intra. domainmaster.sala.intra. (
2010092001 ; serial
3600 ; refresh
7200 ; retry
86400 ; expire
3600 ) ; minimum
@ IN NS ns1.sala.intra.
254 IN PTR mail.sala.intra.
10 IN PTR ns1.sala.intra.
;;
Em um outro terminal deixe aberto o log do sistema para poder observar a inicialização do BIND,
permitindo assim verificar erros e mensagens geradas pelo serviço:

Em Debian:
debian:~# tail -f /var/log/syslog
Em Red Hat:
red-hat:~# tail -f /var/log/messages
Após a criação dos 2 arquivos e o monitoramento através dos logs, reiniciar o bind:
debian:/var/cache/bind# invoke-rc.d bind9 restart
Exemplo do log do bind em carregamento:
7.4
Otimizando o BIND
Para melhorar o funcionamento do bind existem sessões que alteram o comportamento do serviço em
determinada situações como:
Seção “options”
A sessão de opções permite que modifiquemos o comportamento do bind em vários casos, sendo que
algumas destas opções estão disponíveis em outras sessões:
version "Not Available";

Esta variável esconde a versão do bind para consultas ao servidor, no intuito de evitar ataques para a
versão em uso;
datasize 128M;

Esta variável limita o tamanho de memória utilizada pelo bind, evitando que o DNS consuma todos os
recursos de memória disponíveis;
blackhole { 200.1.2.3; };
Esta variável nega consultas de qualquer tipo ao DNS;
forwarders { 10.20.2.100; };
Esta variável indica para o DNS que se ele não puder responder a uma pergunta para quem ele deve
repassá-la;
directory “/var/cache/bind”;
Esta variável determina em qual diretório o bind irá procurar arquivos como os de zona;
listen-on { any; };
listen-on-v6 { any; };
Esta variável indica para o DNS de quais endereços, Ipv4 e Ipv6 respectivamente, o bind irá escutar as
requisições;
use-ixfr on;
Esta variável indica para o DNS se ele irá utilizar transferência parcial (quando possível) ou total para os
servidores slave;
allow-recursion { 10.20.1.0/24; };
Esta variável indica para o DNS se está permitindo consultas recursivas ao mesmo, pode ser descrito
como IP, rede ou ACL, lembrando que alguns MTA fazem essa consulta para verificar sobre a existência de
mapeamento reverso de um IP;
allow-query { 127.0.0.1/32; 10.20.1.0/24; };

Esta variável indica para o DNS quem está autorizado a fazer qualquer tipo de pergunta ao servidor
DNS;
allow-transfer { 10.20.1.102; };
Esta variável indica para o DNS quem está autorizado a solicitar a transferência dos arquivos de zona;
allow-update { 127.0.0.1; };
Esta variável indica para o DNS quem está autorizado a modificar informações nos arquivos de zona via
chave rndc;
provide-ixfr on;
Esta variável indica para o DNS se o “master” irá permitir transferência parcial de dados da zona;
request-ixfr on;
Esta variável indica para o DNS se o “slave” irá solicitar transferência parcial de dados da zona;
max-cache-size 512M;
Esta variável indica para o DNS o tamanho máximo do cache das consultas;
Seção “acl”
Com as ACL (Access Control Lists) podemos criar e nomear listas de endereços IP, para que ao nos
referenciarmos aos endereços usamos o nome da ACL, assim se usamos uma ACL mais de uma vez e mudarmos
algum IP mudamos apenas na ACL e todos os campos que a utilizam já estarão modificados.
Existem algumas ACL padrão que podemos utilizar, são elas:

any – Todos os hosts;

none – Nenhum host;
localhosts – Todos os IP das interfaces da máquina;
localnets – A rede inteira a qual a máquina faz parte;
Exemplo:
acl negados {
200.1.2.3;
200.4.5.6;
};
acl forward {
10.20.2.100;
10.20.3.100;
};
Assim poderíamos utilizar a ACL negados na opção “blackhole”, como poderíamos utilizar a ACL
forward na opção “forwarders”.
Seção “view”
Essa seção de permite realizar o que antes só era possível em mais de um servidor DNS. Ela permite
que se possa separar os registros que podem ser acessados por toda Internet e os que são internos, isto era
feito em mais de um servidor DNS e é chamado “split DNS”. Como em redes onde o servidor que se encontra na
DMZ, o acesso publico será apenas para os registros dos hosts "visíveis" na Internet e o interno, com os
registros da rede interna.
Exemplo de configuração desta seção:
view "publica" IN {
match-clients { any; };
zone-statistics yes;
recursion no;
zone "sala.com.br" {
type master;
file "db.sala.com.br";
};
};
view "privada" IN {
match-clients { 10.20.1.0/24; };
zone-statistics yes;
recursion yes;
zone "sala.intra" {
type master;
file "db.sala.intra";
};
};
Assim o arquivo de zona "db.sala.com.br" contém o mapeamento dos hosts públicos e pode ser
acessada por todos (any). Já o arquivo de zona "db.sala.intra" somente é acessada pelos hosts internos, ou seja,
todos da rede 10.20.1.0/24.

Se nenhuma "view" for especificada, o BIND tratará, por default, as zonas como sendo da classe IN
(Internet). Dentro das "views" são especificadas as configurações das zonas primárias e secundárias.
Seção “controls”
Essa sessão permite o controle externo do bind através da chave rndc. Muito utilizada em integração
com dhcp.
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
7.5
Enjaulando o BIND
Para dar mais segurança ao bind, pode-se fazê-lo funcionar em chroot. O chroot é uma forma de fazer
com que o bind execute "enjaulado", isto é ele está preso apenas ao diretório onde ele está sendo executado,
isto faz com que o processo tenha acesso apenas ao diretório da jaula e não ao diretório raiz do sistema,
minimizando danos caso haja quebra de segurança no serviço.
Passo a passo para criar o CHROOT para Bind
Instalando o bind9 com suporte a jaula chroot.
Instale o bind:
debian:~# aptitude install bind9
Pare o serviço do bind:

debian:~# invoke-rc.d bind9 stop
Edite o arquivo /etc/default/bind9 para que o bind rode como usuário bind e coloque os processos em
/var/lib/named:
debian:~# vi /etc/default/bind9
OPTIONS="-u bind -t /var/lib/named"
# Set RESOLVCONF=no to not run resolvconf
RESOLVCONF=yes
Crie os diretórios para o bind ser executado em chroot:

debian:~# mkdir -p /var/lib/named/etc
debian:~# mkdir -p /var/lib/named/dev
debian:~# mkdir -p /var/lib/named/var/cache
debian:~# mkdir -p /var/lib/named/var/cache/bind
debian:~# mkdir -p /var/lib/named/var/run/bind/run
Mova o diretório do bind para a nova localização:

debian:~# mv /etc/bind /var/lib/named/etc
Crie um link simbólico para a nova localização do diretório do bind, para evitar problemas:
debian:~# ln -s /var/lib/named/etc/bind /etc/bind

Crie os dispositivos usados pelo bind e corrija os donos e permissões:

debian:~# mknod /var/lib/named/dev/null c 1 3
debian:~# mknod /var/lib/named/dev/random c 1 8
debian:~# chmod 666 /var/lib/named/dev/null
debian:~# chmod 666 /var/lib/named/dev/random
debian:~# chown -R bind:bind /var/lib/named/var/*
debian:~# chown -R bind:bind /var/lib/named/etc/bind
Modifique o arquivo /etc/default/syslog para que ele consiga fazer o registro do funcionamento do
bind, já que estando fora do raiz as informações não podem ser passadas ao /dev/log:
debian:~# vi /etc/default/syslogd
#
SYSLOGD="-a /var/lib/named/dev/log"
Reinicie os serviços:
debian:~# invoke-rc.d sysklogd restart
debian:~# invoke-rc.d bind9 restart
7.6
Segurança no BIND
O DNSSEC representa para o bind uma melhoria na segurança das informações passadas pelo DNS,
com o crescente registro de ataques envolvendo “envenenamento de DNS”, ataques de “MITM”, etc. O DNS
que é um dos mais importantes recursos da Internet têm que garantir a integridade de suas informações. Com
o uso de chaves assimétricas para assinatura das zonas, o bind permite que qualquer cliente possa, através da
chave pública, verificar as zonas assinadas pela chave privada.
A chave pública é disponibilizada pelo DNS para qualquer cliente que o acessar, assim quando recebe
uma resposta daquele mesmo DNS o cliente verifica a assinatura e se ela for correspondente ele aceita as
informações do DNS.
No Brasil a implementação do DNSSEC já está disponível como opcional para quase todos os domínios,
como obrigatória para domínios .jus.br e .sec.br.
Para implementar o DNSSEC em seu domínio basta seguir os passos abaixo:
Instalar e configurar normalmente o Bind.

Entre no diretório de configuração do bind:
debian:~# cd /etc/bind
Criando as chaves:
debian:/etc/bind# dnssec-keygen -a DSA -b 768 -r /dev/urandom -n ZONE sala.intra
Onde:
dnssec-keygen - Comando utilizado para gerar chaves DNSSEC e TSIG.

-a <tipo> - Algoritmo utilizado para gerar as chaves (DSA, RSA, etc).
-b <valor> - Tamanho da chave.
-r <arquivo> - Indica qual a fonte de dados aleatórios para gerar a chave. Se omitido a entrada deverá
ser feita pelo teclado.
-n <dono> - Qual o tipo do dono da chave. Utilizar ZONE <zona atual>.
dono - Qual o dono da chave, geralmente a zona.

Serão gerados 2 arquivos:

Ksala.intra.+003+50429.key
Ksala.intra.+003+50429.private
Ksala.intra - Nome da chave.

003 - Representação numérica da chave
50429 – Impressão digital da chave.
Adicionando o registro de chave no bind:

Incluir no final do arquivo /var/cache/bind/db.sala.intra a seguinte linha:
debian:/etc/bind# vi /var/cache/bind/db.sala.intra
$INCLUDE “/etc/bind/Ksala.intra.+003+50429.key”
Assinar a zona com o seguinte comando:
debian:~# dnssec-signzone -P -r /dev/urandom -o sala.intra db.sala.intra Ksala.intra.+003+50429.private
Onde:
-o – Indica a origem do arquivo de zona.
-P – Indica para não fazer checagem por chaves KSK (incluído apenas na versão 9.6 em diante)
Alterar o arquivo /etc/bind/named.conf.local e alterar a opção file para:
debian:/etc/bind# vi named.conf.local
zone “sala.intra” {
file “db.sala.intra.signed”;
...
};
Incluir no arquivo /etc/named.conf.options a entrada para a chave DNSSEC:
debian:/etc/bind# vi named.conf.options
trusted-keys {
“sala.intra.” 256 3 3 “BPDC8hy.......“;
};
A chave pode ser encontrada no arquivo público Ksala.intra.003+50429.key

Após as modificações reiniciar o bind:
debian:~# /etc/init.d/bind9 restart
7.7
Comandos úteis
WHOIS
O comando whois exibe informações sobre um determinado domínio ou IP. Permite não somente
consultar a respeito do proprietário, dns, data de um domínio/IP, como também verificar a origem de um
endereço descoberto em um possível ataque. Ele consulta no órgão responsável pela internet de cada país para
fazer a verificação.
Sintaxe do comando:
whois <opções> <domínio/IP>

Exemplo:
debian:~# whois www.mcury.com.br
HOST
O comando host é utilizado para verificar o funcionamento de um domínio, ele mostra se a resolução
de nomes e apelidos está funcionando, seja na zona direta ou inversa.
Sintaxe do comando:
host <opções> <domínio/IP>
Exemplo:
debian:~# host -t NS sala.intra
debian:~# host -t MX sala.intra
debian:~# host 10.20.1.120
NSLOOKUP
O comando nslookup faz pesquisa sobre domínios de internet de forma interativa (em um shell
próprio) e não interativa, faz consultas que podem ou não ter uma resposta de um DNS de autoridade sobre um
domínio.
Sintaxe do comando:
nslookup <domínio> <servidor>

debian:~# nslookup ig.com.br

debian:~# nslookup ig.com.br ns1.ig.com.br
DIG
O comando dig permite fazer resoluções diretas de nomes ou indiretas de endereços, e retorna muito
mais informação do que o comando host, além de ser usado para medir o tempo de consulta de DNS.
Sintaxe do comando:
dig <servidor> <opções> <tipo>
Exemplo:
Consultando informações de um DNS.
debian:~# dig sala.intra
Consultando os servidores de DNS de um domínio:

debian:~# dig NS sala.intra
Consultando apenas os servidores de DNS de um domínio:

debian:~# dig NS sala.intra +noall +answer
Consultando os servidores MX de um domínio:

debian:~# dig MX sala.intra

Consultando apenas os servidores MX de um domínio:

debian:~# dig MX sala.intra +noall +answer
Consultando um apelido de um host:

debian:~# dig CNAME pop.sala.intra
Consultando uma chave pública do DNSSEC:

debian:~# dig +dnssec sala.intra DNSKEY @localhost
Consultando a rota utilizada para resolver um nome:

debian:~# dig www.sala.intra +trace
ou
debian:~# dig www.google.com.br +trace
Consultando sobre a autoridade sobre o domínio:

debian:~# dig sala.intra NS +noall +answer +nocmd
Consultando sobre a transferência de zona:

debian:~# dig -t axfr sala.intra @ns1.sala.intra +multiline
Consultando a versão do bind:

debian:~# dig @ns1.sala.intra version.bind txt chaos

Consultando sobre o registro SOA:

debian:~# dig sala.intra +nssearch
Consultando sobre a vulnerabilidade de um domínio, onde (POOR é vulnerável e GREAT é com melhor
segurança):
debian:~# dig +short @ns1.sala.intra porttest.dns-oarc.net TXT

8- DHCP
DHCP - Dinamic Host Control Protocol

8.1
Conhecendo o DHCP
DHCP é um serviço criado para fornecer configuração de rede para máquinas que não tem. Quando
uma máquina não tem um endereço de IP fixo, ela requisita pela rede se alguém pode fornecê-lo. O DHCP
trabalha com protocolo UDP na porta 67, bootps quando é solicitado um IP pelo Sistema Operacional, e porta
68, bootpc quando se solicita um IP pela placa de rede. Nos dois casos é enviada uma requisição tipo
DHCPDISCOVER para o broadcast universal 255.255.255.255 para obter um IP e se tornar funcional na rede, se
existir algum servidor de DHCP na rede ele responde com um DHCPOFFER, quando recebida a oferta o cliente
envia um DHCPREQUEST para pedir configurações e então ela recebe suas configurações e o servidor finaliza a
comunicação com um DHCPACK.
Informações que podem ser enviadas pelo DHCP são: IP, máscara, broadcast, gateway padrão, dns,
arquivo de configuração, sistema (via tftp), servidor nis. Não entrega tabela de roteamento, regras de firewall,
nem rotas adicionais.
O diretório de configuração é o /etc/dhcp3, seu daemon é o dhcpd e seu arquivo de configuração é o

dhcpd.conf.
Vamos verificar seu arquivo de configuração e saber suas principais variáveis.
ddns-update-style;
O parâmetro ddns-updates-style controla se o servidor vai ou não tentar fazer uma atualização de DNS
quando um arrendamento é confirmado.Por padrão none é o default para o comportamento da versão 2 do
DHCP, uma vez que o DHCP v2 não tem suporte para DDNS.
default-lease-time 1800;
Tempo padrão que a máquina pode ficar com o mesmo IP (em redes que tem mais máquinas que IP).
max-lease-time 7200;
Tempo máximo que a máquina pode ficar com o mesmo IP (em redes que tem mais máquinas que IP).
authoritative;

Se o DHCP server é o oficial da rede a diretiva authoritative deve ser descomentada.
log-facility local7;
Use para enviar o log do DHCP para um arquivo diferente do padrão. É preciso configurar o syslog para
ele registrar os eventos do recurso local7.
subnet 10.8.1.0 netmask 255.255.255.0 {

Rede e máscara distribuídos pelo dhcp.
range 10.8.1.100 10.8.1.200;
Faixa de IP que será distribuída.
option domain-name-servers 10.8.1.254;
Endereço de IP do servidor de nomes.
option domain-name "sala.intra";
Domínio de busca do DNS.
option routers 10.5.5.1;
Endereço de IP do gateway padrão.
}
Prendendo a configuração de um host pelo MAC ADDRESS.
host server1 {
Nome do host a ser configurado.
hardware ethernet 08:00:07:26:c0:a5;
Endereço de MAC ADDRESS deste host.
fixed-address 10.8.1.201;
Endereço de IP que ele irá receber.
option host-name "server1";
Nome que o host irá receber na configuração.
}
Para reiniciar o serviço:
debian:~# /etc/init.d/dhcp3-server restart
Lembrando que o DHCP só pode entregar endereços de redes que ele mesmo participe, ou seja, não
pode entregar endereço da rede 172.16.1.0/24 se ele possui endereço de IP 10.8.1.100 por exemplo.
Se possuirmos duas placas de rede com endereços de redes diferentes e quisermos que cada placa só
distribua endereço da rede que está configurada na placa, faremos o isolamento das redes para evitar que os
endereços de IP sejam distribuídos pela placa errada.
Temos a placa eth0 com o IP 10.8.1.100/24 e a placa eth1 com o IP 172.16.1.100/24, faremos o
seguinte:
Adicionamos rotas para os endereços pelas próprias placas.
debian:~# route add -host 10.8.1.100/32 dev eth0
debian:~# route add -host 172.16.1.100/32 dev eth1
Assim garantimos que cada placa só fala com o endereço da rede que ela possui. Isto também pode ser
usado para isolar redes de endereços não autorizados.
O DHCP quando em funcionamento ofertar e gerenciar os IP enviados e recolhidos, tudo será

devidamente registrado no arquivo dhcpd.leases no diretório /var/lib/dhcp3.

Exemplo:
debian:~# /etc/dhcp3# cd /var/lib/dhcp3
debian:/var/lib/dhcp3# ls –l
total 8,0K
-rw-r--r-- 1 root root 0 2010-06-08 02:37 dhclient.leases
-rw-r--r-- 1 root root 1,9K 2010-02-01 15:41 dhcpd.leases
-rw-r--r-- 1 root root 466 2010-02-01 14:08 dhcpd.leases~
Onde o dhclient.leases é o arquivo cliente de dhcp onde são registrados os IP recebidos pela máquina.
8.2
Integração DNS com DHCP
Em muitos ambientes o DHCP está presente e também o DNS, muitas vezes é preciso integrar os
serviços a fim de facilitar a função do administrador, assim quando uma máquina receber IP pelo DHCP irá
simultaneamente ser inserida nas máquinas registradas no DNS.
Em primeiro lugar configuraremos o servidor de DNS e DHCP para funcionarem normalmente segundo
o que já aprendemos.
Instale e configure o bind9 e o dhcp3-server normalmente e então faremos as modificações

necessárias para a integração.
Na configuração do Bind9 iremos gerar outra chave rndc de maior complexidade para controlar a
inserção de máquinas no DNS, assim compartilhando esta chave com o DHCP estabeleceremos uma relação de
confiança entre os serviços.
Primeiro vamos parar o serviço do Bind para que não haja problema de chaves:
debian:~# /etc/init.d/bind9 stop
Gerando uma chave em /etc/bind/rndc.key:
debian:~# rndc-confgen -a -b 512
Acrescentando a chave aos arquivos do Bind:
debian:~# cd /etc/bind/
debian: /etc/bind/# cat rndc.key >> named.conf.options
Assim acrescentamos a chave ao final do arquivo. E faremos as alterações, primeiro procure a chave no
arquivo e acrescente o trecho em negrito abaixo da chave:
key "rndc-key" {
algorithm hmac-md5;
secret "5KdY3XEaZMmCNRFbIVkbaA==";
};
controls {

inet 127.0.0.1 port 953

allow { 127.0.0.1; } keys { "rndc-key"; };
};
Essa seção controls indica quem pode controlar remotamente o Bind, escutando pelo endereço
127.0.0.1 na porta 953 somente aceita conexões vindas de 127.0.0.1 usando a chave de nome rndc-key.
Agora vamos adicionar o direito de modificação de uma zona no arquivo named.conf.local:
zone "sala.intra" {
type master;
file "db.sala.intra";
allow-update { key rndc-key; };
};
type master;
file "db.sala.intra.rev";
allow-update { key rndc-key; };
};
Essas linhas adicionadas ao arquivo dão o direito de atualizar a zona a quem possuir a chave chamada
rndc-key.
Agora basta reiniciar o Bind:
debian:~# /etc/init.d/bind9 start
Editando o DHCP para compartilhar a chave e conhecer a zona a ser atualizada.
debian:~# cd /etc/dhcp3/
debian:/etc/dhcp3/# cat /etc/bind/rndc.key >> dhcpd.conf
Assim inserimos a chave no final do arquivo.
Com o editor de texto, mudamos o valor de ddns-update-style de none para ad-hoc e inserimos as
seguintes linhas em negrito:
ddns-update-style ad-hoc;
.
.
key "rndc-key" {
algorithm hmac-md5;
secret "5KdY3XEaZMmCNRFbIVkbaA==";
};
zone sala.intra. {
primary 10.20.1.1;
key rndc-key;
}

zone 1.20.10.in-addr.arpa. {
primary 10.20.1.1;
key rndc-key;
}
Após salvar com as alterações que forneceram ao DHCP a mesma chave que o DNS confia para
atualizações, e configurar cada zona e cada DNS primário que irão receber as atualizações com a autenticação
de chave para cada zona reinicie o servidor dhcp3-server:
debian:~# /etc/init.d/dhcp3-server restart
8.3
DHCLIENT
Quanto à configuração do cliente de DHCP, não é necessário fazer alteração alguma em máquinas que
utilizem Microsoft Windows já que por padrão ele envia o hostname pela rede quando recebe um IP. Em
máquinas Linux basta alterar o arquivo de configuração do comando cliente DHCP (dhclient) para que o sistema
envie o nome para o servidor.
Devemos atualizar o hostname da maquina e alterar o /etc/dhclient.conf para enviar o hostname:
debian:~# vi /etc/dhcp3/dhclient.conf
send host-name "debian150";
Executar o dhclient para pegar as configurações do servidor:
debian:~# dhclient eth0
Este arquivo de configuração serve para mascarar o MAC ADDRESS nas requisições de endereço, forçar
o tempo de atualização, forçar a escolha do servidor, etc.

9- COMPARTILHAMENTO DE DIRETÓRIOS EM LINUX
9.1
NFS
Quando precisamos compartilhar um diretório entre maquinas Linux usamos o NFS, um protocolo que
em sua versão 4 está sendo usado até pela Microsoft para interoperabilidade com Linux/Unix.
A função do NFS é permitir que de forma transparente diretórios possam ser usados via rede,
utilizando o modelo cliente/servidor onde uma máquina disponibiliza um diretório via rede e as outras recebem
e montam este diretório em sua árvore de diretórios local. O NFS utiliza alguns daemons para poder funcionar,
e eles são:
- nfsd - Daemon de montagem e autenticação;
- portmap - Daemon das requisições RPC;
- mountd - Daemon das montagens;
- lockd - Daemon de lock de arquivos;
O NFS exporta um diretório, ou ponto de montagem, através do arquivo /etc/exports e passa as

informações ao kernel que quando recebe uma chamada de sistema via RPC entrega aos daemons do NFS.
O RPC é o serviço utilizado para implementar o modelo cliente/servidor para realizar chamadas de
processos em dispositivos remotos. O portmap é responsável pelas requisições RPC (Remote Procedure Call),
ou seja, ele utiliza a porta 111/tcp para “escutar” as requisições e as encaminha para o serviço correspondente,
por medida de segurança recomenda-se a utilizar as RPC apenas se forem necessárias, já que as RPC podem ser
exploradas remotamente.
O sistema de arquivos NFS foi implementado usando RPC (Remote Procedure Call), cujos protocolos
são descritos usando XDR (eXternal Data Representation), que define um padrão de codificação e
decodificação, criando uma identificação independente da máquina. A External Data Representation (XDR) é a
linguagem que permite definir tipos de dados de maneira consistente, propiciando a troca de dados entre
computadores com diferentes métodos de armazenamento de dados (sistemas de arquivos) utilizando NFS.
O NFS é um único protocolo que reside na camada de aplicação do modelo TCP/IP. A operação do NFS
é definida na forma de três componentes principais que podem ser vistos logicamente situados em cada uma
das três camadas do modelo OSI, correspondendo a camada de aplicação TCP/IP.
Os processos e operações do NFS especificam tarefas a serem executadas em arquivos na rede, usando
o XDR para representação e o RPC para transmitir os comandos.
Alguns dos benefícios mais notáveis que o NFS pode oferecer são:
- Estações locais usando menos espaço em disco porque dados freqüentemente usados podem ser
armazenados em uma única máquina e ainda permanecerem acessíveis a outras pela rede.
- Não há necessidade de usuários terem diretórios pessoais separados em cada máquina da rede.
Diretórios pessoais podem ser configurados no servidor NFS e serem disponibilizados através da rede.

- Dispositivos de armazenamento como leitores de CD-ROM e drives USB podem ser usados por outras
máquinas na rede, reduzindo o número de leitores de mídia removível em toda a rede e centralizando o
controle de mídias.
9.2
Servidor NFS
A configuração do servidor NFS é relativamente simples, o arquivo /etc/exports é onde configuramos

os diretórios que serão exportados, para quais redes e com quais opções. A estrutura do arquivo é a seguinte:
Diretório IP ou Rede(Opções de Exportação)
Para instalarmos os pacotes de NFS, caso não estejam instalados, usamos os seguintes comandos:
Em sistemas Debian:
debian:~# apt-get install nfs-kernel-server
red-hat:~# yum install nfs-server
Dependendo das opções utilizadas na configuração do NFS o acesso aos arquivos será feito com
permissão de outros, já que mesmo que o usuário tenha o mesmo nome ou mesma UID o banco de dados de
contas é diferente de máquina para máquina, exceto no caso da existência de um controlador de domínio.
Algumas das opções de exportação do NFS:

ro – somente leitura, mesmo que o diretório tenha permissão local 777 ele será exportado sem direito
de escrita.
rw – se o diretório local tiver permissão de escrita o NFS irá respeitar isso se possível.
sync – forçar a escrita síncrona em disco.
async – escrita assíncrona em disco.
root_squash – todas as requisições do usuário root na máquina cliente sobre o diretório exportado
serão mapeadas como se feitas pelo usuário anônimo, geralmente nobody.
no_root_squash – não serão mapeadas como usuário anônimo as requisições de root da máquina
cliente no diretório exportado.
all_squash – todas as requisições de todos os usuários na máquina cliente sobre o diretório exportado
serão mapeadas como se feitas pelo usuário anônimo, geralmente nobody.
subtree_check – faz a checagem de toda a árvore de subdiretório que foi exportada e não somente do
diretório principal.
no_subtree_check – não faz a checagem de toda a árvore de subdiretório que foi exportada e não
somente do diretório principal, está opção é mais recomendada.
sec=krb5 – atribui o serviço de ticket ao kerberos.
lock – utiliza o controle travas de acesso a arquivos, impedindo assim que dois ou mais clientes ao
acessar o mesmo arquivo ao mesmo tempo possam corrompê-lo.
nolock – desabilita o uso do controle travas de acesso a arquivos, utilizado por exemplo ao exportar o
/var, já que o /var já possui o NLM implementado em sua estrutura.
Exemplo de arquivo de NFS:

Após configurarmos o arquivo do NFS devemos exportar para o kernel o arquivo /etc/exports com o
seguinte comando:
red-hat:~# exportfs -var
Onde:
-a = Fazer export ou unexport para todos os diretórios
-r = Reexportar todos os diretórios
-v = verbose
Exemplo de exportfs:
Após configurado e exportado basta o cliente montar o diretório para ter acesso aos arquivos.
9.2
Cliente NFS
A configuração de um cliente de NFS é simples. Tanto para montagens manuais quanto para as
automáticas. Para montar um compartilhamento /home/Suporte vindo de 10.20.1.200, por exemplo, no seu
diretório /mnt/dados um cliente faria da seguinte forma:
debian:~# mount -t nfs 10.20.1.200:/home/Suporte /mnt/dados
Basta consultar com o comando df para ver o diretório montado.

Para garantir que a montagem ocorra automaticamente na hora do boot utilizamos o fstab, as opções
de fstab para NFS são as seguintes:
hard – tenta fazer a montagem até que seja possível, em caso de não haver no momento do boot
conexão com o servidor, o boot da máquina cliente pode não ser concluído.
soft – tenta fazer a montagem se receber mensagem de erro, ele retorna o erro para aplicação
responsável e geralmente cancela a montagem.
bg – após uma tentativa de montagem malsucedida, ele vai continuar as tentativas de montagem em
background.
intr – permite interromper uma montagem pendente, mas é obsoleta em kernel de 2.6.25 para cima,
pois nestes kernels só é possível interromper a montagem utilizando o SIGKILL.
Exemplo de linha de fstab para montar um compartilhamento:
10.20.1.200:/home/Suporte /mnt/dados nfs hard,rw,bg 0 0
9.3
Comandos de NFS
Alguns comandos do nfs são úteis para consulta de diretórios e processos
NFSSTAT
Mostra o status das chamadas feitas ao NFS.
SHOWMOUNT
Mostra informações sobre os diretórios exportados.

RPCINFO
Mostra informações sobre o uso das RPC.

10- GERENCIAMENTO DE LOG
10.1
Servidor de Log
Qualquer sistema operacional precisa registrar as atividades que são executadas, tanto pelo sistema
quanto pelos processos que são executados nele. O registro de atividades feitas no sistema operacional se
chama “log”, e eles são de extrema importância para detectarmos erros de sistema, falhas no funcionamento
de serviços, tentativas (bem sucedidas ou não) de invasão, ou seja, ter os logs corretamente configurados e
gerenciados é essencial para o bom funcionamento do sistema.
Existem vários servidores de log, o principal servidor de Log usado no Linux é o Syslog. Muitos
programas podem gerar e gerenciar seus próprios logs, assim o Syslog não terá responsabilidade pelas
informações daquele serviço. O Apache, Squid e o CUPS são bons exemplos de programas que mantém seus
logs independente do servidor de log do sistema. O correto funcionamento do Syslog depende de dois
daemons: syslogd e klogd
O syslogd é o daemon responsável pela captura de informações do sistema e dos principais serviços
que nele são executados.
O klogd é o daemon responsável pela captura de informações do kernel.
O arquivo de configuração do syslog é o /etc/syslog.conf e sua sintaxe é muito simples cada linha
contém um campo seletor e uma ação:
<campo seletor> <ação>
Onde o campo seletor é composto de dois subcampos: recurso ou facilidade, prioridade ou nível, ou
seja:
<recurso.prioridade> <ação>
Ou
<facilidade.nível> <ação>
Cada linha de configuração do arquivo corresponde a um log, linhas comentadas (#) são ignoradas e as
linhas interpretadas tem esta estrutura acima mencionada.
Vejamos um exemplo de arquivo de syslog:

Podemos ver que temos algumas variações da sintaxe do arquivo, como uso de meta caracteres (*),
contra barra (\), etc. Isso porque o syslog é flexível em sua configuração e nos permite algumas combinações
básicas que o tornam mais eficaz na hora de registrar as informações do sistema.
No campo seletor o subcampo recurso, ou facilidade, é responsável pelo tipo de assunto que será
registrado, ou seja, sobre o quê eu quero fazer um log. Ele pode ter um dos seguintes valores:
auth - Recurso de autenticação, qualquer verificação de credenciais para acesso a algo é uma forma de
autenticação, basicamente ele registra os eventos relacionados a segurança no sistema.
authpriv - Recurso de autenticação, basicamente e registro o acessos aos eventos do sistema.
cron - Registra as mensagens geradas pelos daemons do cron e do at.
daemon - Registra as mensagens dos serviços (daemons) que não tem um recurso específico.
ftp - Registra as mensagens geradas por um servidor de FTP.
kern - Registra as mensagens do kernel.
lpr - Registra as mensagens do servidor de impressão lpr ou lprng (O CUPS gera seus próprios logs).
mail - Registra as mensagens geradas por um servidor de email.
news - Registra as mensagens geradas por um servidor de notícias.
syslog - Registra o funcionamento dos serviços do syslog.
user - Registra mensagens do nível de usuário, serviços que usa a userspace.
uucp - Registra o uso do protocolo uucp (Unix to Unix copy), usando antigamente para transferência de
arquivos entre máquinas Unix.
local* - Vai de local7 a local7 reservados para uso local. O recurso local7 costuma ser utilizado para o
processo de boot. Caso você tenha um serviço que precise gerar um log específico, como o DHCP, basta

configurá-lo para gerar log no recurso local5, por exemplo, e configurar no syslog para que ele registre tudo que
for de recurso local5.
No campo seletor o subcampo prioridade, ou nível, é responsável pela intensidade do log que será
registrado, ou seja, a relevância da informação que quero fazer um log. Ele pode ter um dos seguintes valores:
debug – Mensagens de depuração e de testes.
info – Mensagens informativas básicas.
notice – Mensagens de condição normal e significativa.
warn – Mensagens de alerta.
error – Mensagens de erro.
crit – Mensagens críticas.
alert – Mensagens de advertência.
emerg – Mensagens emergenciais.
Os níveis estão postos em ordem crescente de importância, de debug à emerg, quanto maior a
intensidade da prioridade, mais problemas podem estar ocorrendo, ou seja, se muitas mensagens de log são do
nível emerg o seu sistema pode estar próximo de uma parada de funcionamento.
O campo ação é o que se pretende fazer com aquele log, a ação principal é geralmente enviar para
arquivo. Mas o syslog pode enviar as informações tanto para um dispositivo quanto para um outro processo
através de um pipe.
Alguns exemplos de linhas de configuração do syslog.conf:
Recurso mail com a prioridade debug sendo enviados para o arquivo depura-mail.log:
mail.debug /var/log/depura-mail.log
Recurso cron com a prioridade info sendo enviados para o terminal 12:
cron.info /dev/tty12
Recurso daemon, recurso lpr e recurso user com a prioridade notice sendo enviados para o arquivo
combo.log, quando enviamos mais de um recurso com a mesma prioridade usamos vírgula (,) para separar os
recursos:
daemon,lpr,user.notice /var/log/combo.log
Recurso kern com prioridade warn e recurso uucp com prioridade debug sendo enviados para o
arquivo simples.log, para mais de um campo seletor usamos ponto e vírgula (;) para separá-los:
kern.warn;uucp.debug /var/log/simples.log
Todos os recursos com a prioridade alert sendo enviados para um mesmo arquivo, o alerta-geral.log:
*.alert /var/log/alerta-geral.log

Todos os recursos com todas as prioridades menos o recurso cron sem nenhuma prioridade, sendo
enviado para o arquivo quase-tudo.log:
*.*;cron.none /var/log/quase-tudo.log
Recurso ftp com apenas a prioridade notice sendo enviados para o arquivo notas-ftp.log, pois quando
selecionamos uma prioridade as anteriores a ela também são selecionadas:
ftp.=notice /var/log/notas-ftp.log
Recurso local7 com a prioridade err sendo enviado para o arquivo erro-local.log e não registrando a
hora de sincronia ou reinício do syslogd, o caractere de menos (-) é que faz não registrar as informações:
local7.err -/var/log/erro-local.log
A melhor opção é não mexer nos logs existente e adicionar as suas configurações particulares, já que o
sistema por padrão já cobre a maioria das situações de registro de eventos.
Após configurar o arquivo do syslogd, devemos reiniciar o servidor de log.
Em sistemas baseados em Debian:
Em sistemas baseados em Red Hat:
red-hat:~# service syslogd restart
Para visualizarmos um arquivo de log em tempo real usamos o comando tail:
debian:~# tail -f /var/log/auth.log
Exemplo de saída de comando tail –f de um log de autenticação:
Para melhor entendermos a estrutura dos arquivos de log vejamos a linha abaixo:

Sep 7 20:10:35 mail useradd[5746]: new user: name=bind, UID=104, GID=114, home=/var/cache/bind,
shell=/bin/false
Sep 7 20:10:35 mail usermod[5747]: change user `bind' password
Sep 7 20:10:36 mail chage[5748]: changed password expiry for bind
Sep 7 20:17:01 mail CRON[5891]: pam_unix(cron:session): session opened for user root by (uid=0)
Separamos em estilos diferentes para facilitar a identificação das partes:
Negrito: Data e Hora em que a informação foi registrada.
Sublinhado: Nome da máquina ou IP onde a informação registrada aconteceu.
Itálico: Nome e PID do serviço que está gerando a informação.
Normal: Informação registrada.
10.2
Log Remoto
Um dos problemas mais comuns hoje em dia é que em máquinas que estão conectadas diretamente à
internet a possibilidade de invasão é muito grande, e um invasor costuma “cobrir seus rastros”, ou seja, ele
apaga os registros de que ele esteve naquela máquina e a mantém em seu “poder” sem que ninguém desconfie
disso.
Uma solução para evitar perder os registros de acesso às máquinas é fazer um Servidor de Logs
Remoto, ou seja, configurar uma máquina para receber os Logs de outras máquinas da rede e colocar as
informações junto com seus próprios Logs.
Assim quando qualquer informação for registrada em um log o cliente envia esta mesma informação
para o servidor de Logs, o Servidor preferencialmente não terá nenhum outro serviço sendo executado nele e
não terá acesso remoto, evitando assim ser vítima de ataques pelo invasor.
Mesmo que o invasor apague os registros de suas atividades na máquina atacada, os mesmos registros
existirão no Servidor de Logs, assim quando o administrador precisar fazer uma auditoria e comparar as
informações poderá saber o que foi removido do log da máquina atacada. Como o servidor não possui outros
serviços e não é acessado remotamente ele não é vulnerável ao mesmo tipo de ataque.
Exemplo de Servidor recebendo log de diversas máquinas:

Os registros são feitos pelo IP de cada máquina, para fazer registro por nome é preciso que haja um
DNS com as máquinas da rede ou que estejam configuradas no /etc/hosts do Servidor de Logs.
As configurações no servidor são muito simples, por padrão o daemon do syslog não aceita conexões
remotas, devemos iniciá-lo com a opção (-r) para que ele escute na porta 514/UDP. Podemos modificar o script
de Inicialização do syslog para utilizar a opção (-r) ou alterar o arquivo de configuração /etc/default/syslog:
debian:~# vi /etc/default/syslog
Após configurado basta apenas reiniciar o serviço que a máquina já estará desempenhando o papel de
Servidor de Log.
Ou
red-hat:~# service syslogd restart
Na configuração do cliente basta especificarmos qual log irá ser enviado para o servidor. Geralmente
enviamos todos os logs para o servidor, basta acrescentar ao final de seu arquivo /etc/syslog.conf a seguinte
linha: *.* @10.20.1.200

Isto presumindo que o IP 10.20.1.200 é o IP do Servidor de Logs.
debian:~# vi /etc/syslog.conf
Exemplo de configuração para log remoto:
10.3
Rotacionamento de Logs
Um dos problemas que ocorrem com o logs é o crescimento dos arquivos, arquivos muito grandes são
difíceis de ler e ocupam muito espaço em disco. É preciso gerenciar o logs a fim de não causar pane no sistema
por falta de espaço em disco, por exemplo. Para gerenciar os logs o sistema fornece uma ferramenta chamada
logrotate, um utilitário que, dependendo da configuração, copia os logs para novos arquivos evitando ter um
arquivo muito grande, cria um novo log vazio e compacta a cópia do log para evitar desperdício de espaço.
O logrotate é um comando com diversos parâmetros para cada log que ele rotaciona, o funcionamento
padrão é utilizar seu arquivo de configuração (/etc/logrotate.conf) para rotacionar os logs desejados. Para
melhor organizar os rotacionamentos seu arquivo de configuração possui um include para o diretório
/etc/logrotate.d/ onde ele carrega as configurações de todos os arquivos existentes.
Um exemplo de logrotate.conf:

Onde:
weekly – É o tempo de rotacionamento do logs, pode ser: daily (diário), weekly (semanal) e monthly
(mensal).
rotate 4 – São quantos rotacionamentos deste log irão ser mantidos em disco, no caso o log principal e
4 rotacionamentos.
create – Criará um novo arquivo de log vazio após rotacionar.
compress – Irá fazer a compressão dos rotacionamentos.
Um exemplo de arquivo de configuração em /etc/logrotate.d para os logs do apache2:
Onde:
missingok – Se o arquivo não existir o sistema não irá registrar como erro.
compress – Irá fazer a compressão dos rotacionamentos.
delaycompress – Irá fazer a compressão apenas do segundo rotacionamento em diante.
notifyempty – Irá registrar se o arquivo estiver vazio.
create 640 root adm – Irá criar um novo arquivo de log vazio com permissão 640 (rw-r-----)
pertencendo ao usuário root e ao grupo disk.
sharedscripts – Irá executar algum comando ou script antes do rotacionamento (prerotate) ou após o
rotacionamento (postrotate).
O logrotate é executado pela crontab todos os dias pelo agendamento feito no diretório
/etc/cron.daily.
Segue abaixo um exemplo de script logrotate que fica no diretório /etc/cron.daily:
O logrotate após o período de rotacionamento, definido no arquivo de configuração, ele apaga os

arquivo de log, por isso é sempre bom fazer o backup destes arquivos regularmente pois os logs são
informações importantes e podem dirimir dúvidas e resolver problemas se bem analisados.
10.4

Comando Logger
Existem comandos e informações do sistema cuja saída não é registrada em log, e muitas vezes
precisamos desta informação guardada em arquivo para posterior análise. Para isso existe o comando logger, a
função deste comando é escrever em arquivos de log informações que iriam para a saída padrão.
Vejamos um exemplo de uso do logger:

debian:~# apt-get install -y iptraf | logger -t Instalação -p info
Onde:
-t – É o nome do serviço registrado no log.
-p – É a prioridade com que este serviço será registrado, ou seja, qualquer log que registrar atividades
com a prioridade escolhida registrará a informação.
O comando logger deve sempre ser pelo menos o segundo comando da linha, pois ele precisa receber
as informações que iriam para a saída padrão para poder escrevê-las em log.

11- AGENDAMENTOS
11.1
Agendamentos
Existem no Linux, basicamente, dois aplicativos para agendamentos:
AT : Agendamento de um evento único, acontece uma vez apenas, quando determinada condição de
data e hora for alcançada.
CRON : Agendamento de evento contínuo, executado toda vez que determinada condição de data e
hora for alcançada.
Portanto dependendo da necessidade utilizaremos um ou outro aplicativo.
11.2
AT
O requisito para que o agendamento do at funcione é que o daemon do at esteja sendo executado, o
atd e que a máquina esteja ligada na hora do agendamento, pois se ela for ligada após a hora agendada o at irá
apagar a tarefa da lista sem executá-la.
Para agendamos uma tarefa para hoje às 23:00 faremos da seguinte forma:
debian:~# at 23:00
warning: commands will be executed using /bin/sh
at> mandb
at> updatedb
at> apt-get update
at> apt-get upgrade -y -d
at> <EOT>
job 2 at Thu Sep 16 23:00:00 2010
Onde o at executa as tarefas em um shell, portanto é preciso descrever os comandos que quero
agendar, pode ser mais de um comando por agendamento, e ao final da tarefa em uma linha vazia, salvar com
^d (control+d).
Para garantir que o comando vai ser executado, mesmo que a máquina seja reiniciada, no momento
certo, a tarefa criada é salva em arquivo, o diretório /var/spool/ é onde, geralmente, as tarefas são salvas.
Vejamos um exemplo de arquivo de agendamento do at:

Podemos notar que o at cria um script para a tarefa, ele descreve o shell que irá interpretar o comando
(/bin/sh) e as variáveis de ambiente necessárias para que os comandos sejam executados com as mesmas
características que o shell possuía na hora que a tarefa foi agendada. Apenas no final do script que ele descreve
os comandos a serem executados, na mesma ordem em que foram criados.
Se o horário atual for 18:00 e quisermos agendar um evento par 23:00 de hoje basta seguir o exemplo
anterior, mas se desejarmos que o evento ocorra às 23:00 de amanhã devemos informar ao at, pois ele
programa as tarefas para a primeira ocorrência daquele horário.
Exemplo:
debian:~# at 23:00 tomorrow

at> invoke-rc.d rc.firewall restart
at> <EOT>
job 4 at Fri Sep 17 23:00:00 2010
Assim a tarefa de reiniciar o script rc.firewall será executada às 23:00 de amanhã.
Para executar uma tarefa em um determinado dia posterior podemos utilizar os seguintes
parâmetros: days (dia), weekly (semana), month (mês).
Por exemplo agendando um tarefa para daqui a 3 dias:
debian:~# at 23:00 +3 days

at> mandb
at> <EOT>
job 5 at Sun Sep 19 23:00:00 2010

Para uma tarefa para daqui a uma semana
debian:~# at 23:00 +1 week

at> updatedb
at> <EOT>
job 7 at Thu Sep 23 23:00:00 2010
Para uma tarefa daqui a um mês:
debian:~# at 23:00 +1 month

at> invoke-rc.d rc.firewall restart
at> <EOT>
job 8 at Sat Oct 16 23:00:00 2010
Para um dia específico no ano:
debian:~# at 23:59 2010-12-31

at> shutdown -r 1 "Reinício de ano novo"
at> <EOT>
job 11 at Fri Dec 31 23:59:00 2010
Podemos notar que o at é bem flexível quanto as configurações. E ele é controlado pelos arquivos
/etc/at.allow e /etc/at.deny, onde:
O /etc/at.allow contém os nomes dos usuário que tem permissão de agendar pelo at, ou seja, caso o
nome do usuário esteja neste arquivo ele pode usar o at.
O /etc/at.deny contém os nomes dos usuário que não tem permissão de agendar pelo at, ou seja, caso
o nome do usuário esteja neste arquivo ele não pode usar o at.
Na falta do arquivo /etc/at.allow o sistema verifica o /etc/at.deny e qualquer um que não estiver neste
arquivo pode usar o at, na falta dos dois arquivos somente o root pode usar o at.
Exemplo de arquivo /etc/at.deny:

As tarefas agendadas pelo at estão gravadas no sistema no diretório atjobs, segue um exemplo deste diretório
abaixo:
Para consultar informações sobre as tarefas agendadas usamos os seguintes comandos:
debian:~# atq
Ou
debian:~# at -l
Quando precisamos saber o conteúdo de uma tarefa podemos visualizá-la no diretório atjobs ou usar o
comando at com a opção (-c):

Para removermos uma tarefa pendente que não precisamos mais usamos os comandos:
debian:~# at –d 5
Ou
debian:~# atrm 5
Onde 5 é o número da tarefa pendente.
11.3
CRON
O requisito para que o agendamento do cron funcione é que o daemon do cron esteja sendo
executado, o crond e que a máquina esteja ligada na hora do agendamento, pois se ela for ligada após a hora
agendada o cron não irá executar a tarefa da lista.
Existem várias formas de agendar alguma tarefa pelo cron, desde a crontab do sistema, as crontabs
pessoais, e os diretórios de agendamento do cron.
A crontab do sistema fica em /etc/crontab e é o local ideal para tarefas administrativas serem
agendadas. Ela é quem executa os diretórios /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly e
/etc/cron.monthly, que são responsáveis respectivamente por agendamentos horários, diários, semanais e
mensais.
A crontab pessoal é criada pelo usuário exclusivamente através de comando e fica em

/var/spool/cron/crontabs, a diferença na estrutura da crontab pessoal e a crontab do sistema é que a do
sistema tem o campo de usuário e a crontab pessoal não precisa disso.
Uma outra estrutura para agendamentos é o diretório /etc/cron.d/ onde para organizar melhor seus
agendamentos e até de scripts de serviços que são instalados, este diretório é usado para que haja um arquivo
por agendamento, ao invés de criarmos uma linha no /etc/crontab criamos um arquivo dentro de /etc/cron.d/
com a linha de agendamento.
Dependendo de sua necessidade você utilizará uma ou outra opção.
Vamos entender a estrutura do arquivo /etc/crontab:

minuto hora mês dia do mês dia da semana usuário comando
Onde os campos podem ser preenchidos com seguintes valores:

minutos: de 0 à 59
horas: de 0 à 23
dia do mês: de 1 à 31
mês: de 1 à 12
dia da semana: de 1 à 7, sendo 1 segunda e 7 domingo
usuário: nome do usuário com que direitos será executado o programa ou comando
comando: o comando/programa/script que queremos agendar
Segue abaixo um exemplo de crontab do sistema, com os agendamentos de hora, dia, semana e mês.
Seguem abaixo alguns exemplos de configuração de agendamentos pela crontab:
Executar uma tarefa sexta-feira 13 de agosto a meia noite e um:
m h dm m ds u comando
1 0 13 8 5 root jason.sh
Executar uma tarefa todo dia, todos os meses, toda hora e todo minuto 30 dessas horas:
30 * * * * root updatedb
Executar uma tarefa às 9,15,21 nos minutos 25 e 50 de cada uma dessas horas:
25,50 9,15,21 * * * root monitor.sh
Executar uma tarefa de 12 às 14 horas, minuto 10 de segunda à sexta:
10 12-14 * * 1-5 root relatorios.sh
Executar uma tarefa a cada duas horas do dia no minuto 30 dessas horas, todos os sábados:

30 */2 * * 6 root backups-incrementais.sh
Diretórios onde já existem agendamentos do cron:
Para configurar uma crontab particular do usuário, usamos o comando crontab, ele vai abrir o editor
padrão para criar o arquivo de crontab que ficará em /var/spool/cron/crontabs/ com o nome do usuário que o
criou. Para criar ou editar uma crontab existente usamos o seguinte comando:
debian:~$ crontab -e
Para listar uma crontab existente usamos o seguinte comando:
debian:~$ crontab -l
# m h dom mon dow command
10 9 * * 1-5 liga-banco.sh
Para remover a crontab do usuário usamos o seguinte comando:

debian:~$ crontab -r
Para o root poder manipular a crontab de algum usuário, basta ele adicionar à linha de comando a
opção (-u) e o nome do usuário que deseja manipular:
debian:~# crontab –l –u user1

Ou
debian:~# crontab –e –u user1
Ou
debian:~# crontab –r –u user1

12- SAMBA
12.1
Servidor de Domínio Samba
O samba começou pela necessidade de um desenvolvedor de integrar uma máquina com Linux e outra
com Microsoft Windows, ele criou e colocou um sniffer de rede entre duas máquinas com Microsoft Windows
mapeou a comunicação entre elas, estudando a documentação da Microsoft sobre o protocolo smb e nmb ele
conseguiu implementar as mesmas funções em ambientes Unix, o nome da ferramenta criada foi samba.
Portanto o samba é um servidor que permite máquinas Linux e Windows se comunicarem em rede,
fazendo desde compartilhamento de serviços (arquivos, diretório, impressão) através do protocolo SMB (Server
Message Block)/CIFS (Common Internet File System) a autenticação, e NMB equivalentes à implementação
NetBEUI no Windows. O samba permite que sejam criadas redes heterogêneas com máquinas Unix/Linux e
máquinas Microsoft Windows.
O protocolo SMB foi criado para operar sobre o NetBIOS, mas a partir do Microsoft Windows 2000 ele
pode operar também sobre a pilha TCP/IP. Segue uma pequena comparação entre o funcionamento do SMB:
SMB sobre NetBIOS SMB sobre TCP/IP

SMB SMB
NetBIOS
TCP e UDP TCP e UDP
IP IP
12.2
NetBIOS
O registro de nomes em redes NetBIOS é bastante peculiar e ocorre em duas formas: através de um
servidor de nomes (NBNS, NetBIOS Name Server, do qual WINS é uma implementação) e através de broadcast
na rede.
Quando uma máquina NetBIOS é colocada online, ela vai tentar registrar seu nome na rede. No caso da
utilização de broadcast, ela simplesmente envia para a rede local um pacote broadcast informando o nome que
ela deseja utilizar.
Se, após repetidos pedidos de registro, nenhuma outra máquina objetar, o registro é considerado
como tendo sido feito com sucesso e o nome foi aceito.
Mas, se alguma máquina na rede já estiver com o nome solicitado, ela vai responder e nossa estação
terá de escolher outro nome.
Outra forma de fazer isso é ter instalado um servidor de nomes NetBIOS. Deste modo quando uma
nova máquina entra na rede, em vez de enviar um broadcast, ele envia um pacote diretamente para o servidor
de nomes dizendo que quer registrar um nome NetBIOS. O servidor vai responder se este nome já está em uso
ou não. Se estiver livre, o registro é considerado feito com sucesso e a máquina cliente poderá prosseguir com
este nome.
A Resolução de nomes NetBIOS ocorre das seguintes formas: broadcast, e NBNS e ainda temos a
possibilidade de utilizar um arquivo local chamado lmhosts. Este arquivo contém endereços IP e nomes NetBIOS
de máquinas e funciona da mesma forma que arquivo /etc/hosts.

Uma máquina NetBIOS não só anuncia sua presença na rede, mas também anuncia que tipo de
recursos ela possui disponíveis. O formato utilizado para o nome possui um byte reservado para indicar este
recurso.
Por fazer uso de pacotes broadcast e UDP o NetBIOS não é a melhor solução em resolução de nomes
em uma rede. O CIFS que uma nova implementação sobre o SMB com a inclusão de novos recursos, abandona
de vez o uso do NetBIOS e passa a utilizar o protocolo TCP e uma única porta (445), ao contrário da dupla
SMB/NMB que utiliza três portas: 137/UDP (Resolução de nomes e registro de tráfego), 138/UDP (Browsing e
anúncio de tráfego) e 139/TCP (Compartilhamento de arquivos). Portanto em implementações atuais o uso de
CIFS é recomendado.
Resumo dos elementos de uma Rede NetBIOS/SMB:
Local Master Browser (LMB) - Máquina responsável por manter uma lista com os nomes das máquinas
existentes no grupo de trabalho da subrede.
Workgroup - Agrupamento administrativo de máquinas. Não representa uma hierarquia no espaço de

nomes NetBIOS.
Domínio - Grupo de trabalho que contém um PDC responsável por autenticação e autorização de
usuários.
Primary Domain Controller (PDC) - Controlador Primário de Domínio, máquina responsável por
autenticação e autorização em um domínio SMB.
Backup Domain Controller (BDC) - Backup de um PDC, máquina que sincroniza a base de dados de
usuários com o PDC e que portanto também pode autenticar e autorizar usuários.
Domain Master Browser (DMB) - Máquina responsável por sincronizar a lista de nomes NetBIOS entre
os diversos LMBs existentes na rede.
12.3
Configurando o Samba
O samba utiliza de dois daemons para fazer seus serviços funcionarem, o nmbd (daemon de NetBIOS) e
smbd (daemon de SMB/CIFS), seu diretório de configuração é o /etc/samba e seu arquivo é o smb.conf. O modo
de funcionamento padrão do samba é como WorkGroup (Grupo de Trabalho), mas o principal uso do mesmo é
em Domínio, como Controlador de Domínio ou Cliente.
Segue abaixo um exemplo de arquivo de configuração do Samba sem os comentários e a descrição de

suas principais variáveis:

Como podemos notar o arquivo do samba é dividido em seções e configurado por variáveis que são
preenchidas com parâmetros. Cada seção no arquivo de configuração é definida por um nome entre [ ]. As
seções tem como objetivo de organizar os parâmetros para que tenham efeito somente em algumas
configurações do servidor, a seção global pelo contrário é referente ao funcionamento do servidor como um
todo, e as seções locais portanto servem apenas para cada compartilhamento.
12.3.1
Seções do smb.conf
As principais seções do arquivo de configuração do Samba são:
[global] - Define configurações que afetam o servidor Samba como um todo, aplicam-se em todos os
compartilhamentos existentes na máquina, exceto se no compartilhamento existirem variáveis em contrário.
Configura o grupo de trabalho, nome do servidor, página de código, restrições de acesso por nome, comandos
do Samba, etc.
[homes] – Define as opções de acesso a diretórios home de usuários. Por padrão o diretório home é
disponibilizado somente para seu dono, após se autenticar no sistema.
[printers] - Define opções gerais para controle das impressoras do sistema. Este compartilhamento
mapeia os nomes de todas as impressoras encontradas no /etc/printcap.
[profile] - Define um perfil quando o servidor SAMBA é usado como PDC de domínio.

[netlogon] – Define o diretório onde ficam os scripts de logon, podendo ser um para todos, um script
por usuário, um script por máquina ou um script por grupo.
Qualquer outro nome de [seção] no arquivo smb.conf que não foram citadas anteriormente são
tratadas como um compartilhamento.
A sintaxe usada para configurar os parâmetros é a seguinte:
nome = valor
O valor pode ser booleano definido da seguinte forma: 0 ou 1; yes ou no; true ou false. Ou um valor
específico.
Linhas iniciadas por ";" ou "#" são tratadas como comentário.
12.3.2
Parâmetros do smb.conf
Nos parâmetros da seção [global] podemos ver os seguintes:
Especifica o nome NetBIOS primário do servidor Samba. Se não ajustado usará o hostname da
máquina.
netbios name = <nome do servidor>
Nomes adicionais que serão anunciados na rede através do serviço nmbd, ou para um servidor de
nome.
netbios aliases = <apelido>
Nome do WorkGroup (Grupo de Trabalho) ou do Domínio que o Samba participa.

workgroup = <grupo de trabalho/domínio>
Identificação enviada do servidor Samba para o ambiente de rede. A string padrão é SAMBA %v.
server string =<identificação>
Caminho completo para o arquivo de log.

log file = </caminho/arquivo>
Indica se as restrições do usuário nos módulos PAM terão efeito também no samba.
obey pam restrictions = <yes/no>
Define a conta local de usuário que será mapeada quando um usuário se conectar sem senha.
guest account =<conta>
Lista de usuários que não terão acesso ao compartilhamento.

invalid users = <usuário>
Somente os usuários especificados terão acesso ao compartilhamento.

valid users = <usuário>
Especifica o nível do Sistema Operacional. Utilizado para eleições NetBIOS, para definir o Máster
Browser de grupo local e controlador de domínio. O valor pode ser de 0 a 255, o padrão é 32.
os level = <num>

Diz se o servidor (nmbd) tentará se tornar o navegador principal de domínio (Domain Master Browser),
permitindo que os LMBs sincronizem suas listas de máquinas. É uma exclusividade do samba ser um DMB sem
ser um PDC. Os valores que podem ser especificados são: yes, no ou auto. O padrão é auto.
domain master = <valor>
Diz se o servidor participará ou não das eleições para navegador local (Local Master Browser) do grupo
de trabalho (workgroup), o valor yes é para tentar vencer a eleição, desde que possua "os level" suficiente para
tal.
local master = <valor>
Força o nmbd a solicitar uma nova eleição para o navegador, na inicialização.

preferred master = <valor>
Script que será utilizado para adicionar máquinas Windows.

add machine script = <comando>
Script que será utilizado para adicionar usuários ao Samba.

add user script = <comando>
Servidor de autenticação/login. Registra nome NetBIOS e permite o uso de scripts de logon.

domain logons = <yes/no>
Script de logon, será executado pelos usuários assim que fizerem logon.
logon script = <nome do script>
Configura a ordem de resolução de nomes NetBIOS. Valores:lmhosts wins e bcast (respectivamente).

name resolve order = <valor>
Controle de acesso por domínio. O usado tanto para WorkGroup (Grupo de Trabalho) quanto para
Domínio é user.
security =<valor>
Permite sincronizar as senhas do Samba com o Linux, ou seja, ao trocar a senha pelo Samba, ou pelo
Windows, a senha será trocada no Linux.
unix password sync = <yes/no>
A sincronização deve utilizar o PAM.

pam password change = <yes/no>
Conjunto de caracteres que o samba irá utilizar. Se omitido será utilizado utf8. Outra alternativa é
utilizar iso-8859-1.
unix charset = <conjunto de caracteres>
Página de código utilizada pelo Samba, para compatibilidade com alguns idiomas, para português
usamos cp850.
display charset = <valor>
Tipos de Backend do samba:

smbpasswd - Utiliza um arquivo texto que contém as senhas e algumas informações adicionais sobre
cada conta de usuário ou máquina. Não armazena todas as informações necessárias para uma integração
completa com clientes e servidores Windows.
tdbsam - Utiliza um arquivo .tdb (trivial database) para armazenar as senhas e demais informações. É
considerado um backend "rico", pois armazena todas as informações necessárias para uma excelente
integração com clientes e servidores Windows. Recomendado para todas as instalações Samba3.

ldapsam - Semelhante ao tdbsam, utiliza um servidor LDAP para armazenar as informações de

autenticação e contas.
passdb backend = <smbpasswd/tdbsam/ldapsam>
Mapeamento de usuários do sistema, exemplo: root = Administrador Administrator

username map = <caminho/arquivo>
Obs.: Apesar do usuário Administrador e Administrator estarem mapeados, quando logado quem irá
aparecer para o sistema é o usuário root.
IP de um servidor de nomes netbios (WINS) na rede. O Samba vai registrar seus nomes NetBIOS (nmbd)
neste servidor.
wins server = <servidor>
Permite definir se o serviço nmbd será um servidor de nomes NetBIOS e os clientes NetBIOS podem se
registrar. Se usar esta opção a anterior não pode ser utilizada. O Samba é cliente NetBIOS ou servidor, nunca os
dois ao mesmo tempo.
wins support = <yes/no>
12.3.3
Compartilhamentos
Como o compartilhamento será conhecido pela rede. Nomes com $ no final significam
compartilhamentos ocultos.
[nome do compartilhamento]
Pequena descrição do compartilhamento.

comment = <texto>
Qual diretório do sistema de arquivos será exportado.

path = </caminho/completo>
Usuário convidado pode acessar.

quest ok = <yes/no>
O compartilhamento será visível na lista de compartilhamentos disponíveis.

browseable = <yes/no>
Se o compartilhamento permite ou não escrita. O contrário desta diretiva é "read only".

writable = <yes/no>
Lista de usuários e/ou grupos que tem permissão para acessar este compartilhamento.
valid users = <usuario1 usuario2 @grupo1 @grupo2>
Lista de usuários e/ou grupos que tem permissão de escrita neste compartilhamento.
write list = <usuario1 usuario2 @grupo1 @grupo2>
Máscara de criação de arquivos. Se omitido será assumido o valor 0644.

create mask = <OCTAL>
O mesmo que "create mask", mas aplicado a diretórios. Se omitido o valor assumido será 0755.
directory mask = <OCTAL>

Não permite a gravação dos arquivos especificados no compartilhamento.

veto files = </arquivo/arquivo/arquivo>
12.3.4
Controle de Acesso
O controle de acesso tanto pode ser utilizado na seção [global] quanto nos compartilhamentos e o
funcionamento é idêntico ao tcp_wrappers.
Lista os endereços, separados por espaços ou vírgulas, que podem se conectar a este
compartilhamento. Endereços não listados terão acesso negado. Lembrando que o acesso propriamente dito
ainda é controlado por outras diretivas.
hosts allow = <ip,rede/máscara>
Idêntico ao "hosts allow".

hosts deny = <ip,rede/máscara>
Obs.: hosts allow sempre prevalece sobre esta diretiva.
12.3.5
Variáveis de Substituição (Macros)
Estas variáveis são utilizadas no arquivo de configuração que quando um usuário conecta-se a um
servidor, uma nova cópia do processo smbd é iniciada. Essa cópia relê o arquivo /etc/smb.conf, substituindo as
macros pelos seus respectivos valores.
%S - O nome do serviço atual, se existir. Usado principalmente no uso de diretórios homes.
%P - O diretório raiz do serviço atual.
%u - O nome de usuário do serviço atual (Unix), utilizado para programação de scripts e criar arquivos
de log personalizados.
%g - O grupo primário (Unix) do usuário %u.
%U - O nome de usuário da seção (Usuário NetBIOS), pode ser diferente de %u.
%G - Nome do grupo primário de %U.
%H - O diretório home do usuário, de acordo com %u.
%v - A versão do Samba.
%h - O nome DNS da máquina que está executando o Samba.
%m - O nome NetBIOS da máquina do cliente.
%L - O nome NetBIOS do servidor.
%M - O nome DNS da máquina cliente.
%I - O numero IP da máquina cliente.

%N - O nome do seu servidor de diretórios home NIS. Caso o Samba não possua suporte, o valor será
igual a variável %L.
%d - A identificação do processo (PID) atual do servidor.
%T - A data e hora atual.
12.4
Comandos do Samba
SMBPASSWD
O comando smbpasswd é utilizado para mapear Id de Usuários Windows para Id Unix/Linux.

Sintaxe:
smbpasswd <opções> <usuário>
Opções comuns:
-a - Adiciona o usuário à base de dados do samba. O usuário deve existir no sistema do ambiente Linux.
-x - Remove o usuário da base de dados do Samba.
-d - Desabilita a conta do usuário.
-e - Habilita a conta do usuário.
PDBEDIT
O comando pdbedit é utilizado para manipular a base de dados SAM, os usuários, do samba.
Sintaxe:
pdbedit <opções>
Opções comuns:
-L - Lista todas as contas de usuários cadastrados no samba. O formato é "usuário:uid:comentário"
-v - Exibe mais detalhes. Em conjunto com -L exibe todos os dados da conta de um usuário.
-w - Exibe as contas no formato do antigo backend do samba, o smbpasswd.
-u usuário - O comando será restrito ao usuário especificado.
-f "Nome_Completo" - Adiciona ou modifica o nome completo de um usuário.

-h "\\maquina\diretório" - Adiciona ou modifica o diretório pessoal do usuário.
-S "\\maquina\diretorio\script.bat" - Adiciona ou modifica a localização do script do usuário.
-D "UNIDADE:" - Adiciona ou modifica o mapeamento do homedir do usuário para o
correspondente no Windows. Ex. -D "H:".
-p "\\maquina\diretório" - Adiciona ou modifica a localização do perfil do usuário.
-c "[ ]" - Adiciona ou modifica as características de uma conta Windows. As flags mais comuns
são:

N - Não requer senha.

D - Conta desativada.
H - Diretório pessoal requerido.
X - A senha Nunca expira.
U - Usuário regular.
-x - Remove um usuário da base de dados.
Obs.: Este comando só pode ser utilizado pelo root.
SMBSTATUS
O comando smbstatus é utilizado basicamente para listar as conexões atuais do samba.

Sintaxe:
smbstatus <opção>
-b - Listagem simples.
-L - Lista apenas as travas em arquivos.
-p - Lista os processos do smbd e sai.
-S - Lista somente os compartilhamentos.
-u usuário - Restringe a listagem ao usuário especificado.
SMBCLIENT
O comando smbclient é utilizado em um cliente Samba para acessar informações sobre máquinas do
Grupo ou Domínio.
Sintaxe:
smbclient <opções>
Lista todos os diretórios disponíveis para o usuário especificado.
smbclient //10.SALA.1.MAQ/diretório <-U usuário> <senha>
Obs.: Os comando básicos do protocolo ftp são aceitos.
TESTPARM
Para verificar a sintaxe do arquivo de configuração do samba execute o comando testparm:
debian:~# testparm
SMBMOUNT
Montar compartilhamento SMB/CIFS.
mount -t smbfs -o username=<nome>,password=<senha> //<IP>/<compartilhamento> <ponto de montagem>

Ou:

smbmount -o username=<nome>,password=<senha> //<IP>/<compartilhamento> <ponto de montagem>
FINDSMB
O comando findsmb exibe as máquinas NetBIOS da rede, mas também mostra várias outras
informações, é como um ambiente de rede simples no modo texto.
Sintaxe:
findsmb
A descoberta é feita via broadcast, mas é possível que algumas máquinas não apareçam. Clientes SMB
com firewall ativo, como Windows XP SP2 não irão aparecer.
NMBLOOKUP
O comando nmblookup é uma ferramenta completa para qualquer tipo de consulta NetBIOS via
broadcast ou servidor de nomes. Segue algumas opções bem como sua sintaxe:
nmblookup <opções> <nome>
-M <nome> - procura por um Master Browser para o nome especificado.
-R - Ativa o modo recursivo. Utilizado quando interroga servidores de nomes.
-S <nome> - Obtém todos os nomes NetBIOS registrados pela máquina especificada.
-A <nome> - Interpreta <nome> como um endereço IP ao invés de um nome NetBIOS e obtém todos os
nomes NetBIOS registrados pela máquina.
-B <broadcast> - Utiliza endereço de broadcast da rede.
nome> - Indica o nome a ser consultado, ou endereço IP se for utilizada a opção -A. Para pedir um tipo
de recurso específico, utiliza-se a notação nome#código-recurso.
Consulta simples de nome:
debian:~# nmblookup debian
Procurando o Local Master Browser para o grupo de trabalho EMPRESA.LOCAL:
debian:~# nmblookup “EMPRESA.LOCAL”
Listando os nomes registrados pela máquina debian:
debian:~# nmblookup -S debian

13- LDAP
13.1
LDAP
O LDAP foi criado para ser uma opção leve (lightweight) ao Protocolo de Acesso à Diretórios (DAP), e é
utilizado por uma vasta gama de empresas e desenvolvedores. O LDAP é um protocolo de acesso a informações
armazenadas em um banco de dados (BDB, HDB, MySQL, PostGresSQL, etc), ele controla os acessos baseado
em hierarquia e credenciais. Sua principal utilização é em servidores de autenticação, mas nada impede que
seja usado para armazenas informações de DNS, DHCP, sites, etc.
Algumas implementações de protocolos baseados no X.500, como o LDAP são muito conhecidas, entre
elas: o Novell NDS e o Microsoft Active Directory.
O LDAP armazena as informações numa estrutura de árvore chamada de DIT (Directory Information
Tree), onde existem níveis de hierarquia e de ligação como no exemplo abaixo:
dc=sala,dc=intra
cn=admin
ou=users ou=groups
cn=user1 cn=user2 cn=cpd cn=computers

o=uidNumber o=uidNumber o=gidNumber o=gidNumber
o=homeDir o=homeDir o=members o=members
o=telephone o=telephone
o=gidNumber o=gidNumber
o=jpegphoto o=jpegphoto
o=password o=password
. .
. .
Como podemos ver no exemplo acima o domínio sala.intra (dc=sala,dc=intra), contém:
Um administrador (cn=admin,cd=sala,dc=intra);
Uma unidade organizacional (OU) para usuários (ou=users,dc=sala,dc=intra);
Um usuário user1 dentro da unidade usuários (cn=user1,ou=users,dc=sala,dc=intra);
Um usuário user2 dentro da unidade usuários (cn=user2,ou=users,dc=sala,dc=intra);
Uma unidade organizacional (OU) para grupos (ou=groups,dc=sala,cd=intra);
Um grupo cpd dentro da unidade de grupos (cn=cpd,ou=groups,dc=sala,cd=intra);
Um grupo computers dentro da unidade de grupos (cn=computers,ou=groups,dc=sala,cd=intra);

O nome completo de qualquer item é chamado de DN (Distinguished Name), é o nome que o

diferencia de outros, por exemplo, posso ter um grupo admin e um usuário admin, que não são o
administrador e serão diferenciados pelo seu DN: grupo admin (cn=admin,dc=groups,dc=sala,dc=intra), usuário
admin (cn=admin,ou=users,dc=sala,dc=intra).
As siglas mais utilizadas são:
DIT – Directory Information Tree (Árvore de Informação de Diretórios);

DN – Distinguished Name (Nome Distinto);
cn - Common Name (Nome Comum);
ou – Organizational Unit (Unidade Organizacional)
o – Object (Objetos);
Cada entrada pode ter vários atributos, cada atributo é uma característica que a entrada precisa, como
nome, número, foto, grupo, descrição, senha, etc.
13.2
Servidor LDAP
A configuração de um servidor básico de autenticação é simples, faremos através de linhas de

comando, a fim compreender melhor seus conceitos e comandos.
Estando logado como root instale os seguintes pacotes do servidor:
debian:~# apt-get install slapd ldap-utils libldap-2.4-2
Escolha a senha do administrador do LDAP, responda as outras perguntas com a opção

padrão.
Após instalado devemos editar o arquivo de configuração, para adicionarmos nosso domínio para a
base do LDAP e configurar a conta administrativa:
Segue abaixo um exemplo do arquivo de configuração já modificado:

Podemos ver que foi modificado o domínio para sala.intra (dc=sala,cd=intra) e a conta de
administrador foi configurada e a senha especificada em SSHA.
Fazemos esta edição com o vi da seguinte forma:
debian:~# vi /etc/ldap/slapd.conf
Após alterar o arquivo devemos reiniciar o servidor para verificar se há erros na configuração.
debian:~# /etc/init.d/slapd restart
Se tudo estiver certo o servidor será iniciado sem erros, e podemos visualizar o log do sistema para
confirmar o serviço sendo iniciado, como na figura abaixo:

Sendo o serviço iniciado sem problemas devemos verificar se ele está respondendo, a porta padrão do
serviço de LDAP é a 389/TCP, o comando de consulta é o ldapsearch que vem do pacote ldap-utils.
Pesquisando no LDAP sobre as informações do servidor:
debian:~# ldapsearch -x -h localhost -LL -b '' -s base '(objectclass=*)' namingContexts
Onde:
-x – Usa autenticação simples no lugar de SASL.
-D <binddn> – Usa o DN para se ligar ao LDAP.
-W – É usado para não especificar a senha na linha de comandos.
-w <passwd> – passwd é a senha para autenticação simples.
-h <ldaphost> – Especifica qual o host no qual o servidor LDAP está sendo executado.
-b <searchbase> – O uso de searchbase é para definir um ponto de partida especifico, senão
seria usado o que esta por default.
-f <file> – São lidas as linhas do arquivo file.
-v – Retorna o diagnóstico da operação na saída padrão.
-L – Mostra informações sobre o LDIF v1.
-LL – Mostra informações do LDIF sem os comentários
-LLL – Mostra informações sobre o LDIF sem os comentários e sem a versão.
Após executarmos o comando vamos obter o seguinte resultado:
Significa que o servidor respondeu a consulta e que o objeto principal é o domínio sala.intra.
Para que não precisemos colocar o nome da máquina que vai ser consultada, editaremos o arquivo
/etc/ldap/ldap.conf, onde configuramos o cliente para que ele saiba qual servidor deve procurar e a qual
domínio ele deve questionar.

debian:~# vi /etc/ldap/ldap.conf
Caso o seu DNS não esteja com o nome server-ldap.sala.intra, basta colocá-lo no /etc/hosts apontando
para o seu endereço de IP.
Todas as informações manipuladas pelo LDAP são feitas através de arquivos no formato LDIF (LDAP
Data Interchange Format), ou seja, qualquer inserção, modificação ou remoção de informações na base de
dados é feita através de arquivos ASCII no formato LDIF.
Vamos inserir nosso domínio e a conta de administrador no banco de dados, para isso criaremos o
arquivo LDIF e o adicionaremos com o comando ldapadd:
debian:~# vi /tmp/init.ldif
O arquivo LDIF é composto de seções e cada seção é separada por uma (apenas uma) linha em branco,
cada entrada deve ser descrita com seu DN para que não haja erro de localização da mesma.
debian:~# ldapadd -x -D 'cn=admin,dc=sala,dc=intra' -W -f /tmp/init.ldif
Onde -D é o DN (Distinguished Name) de quem tem direito de escrever nesta base de dados.

Para verificar as alterações podemos utilizar o comando ldapsearch para pesquisar as entradas
adicionadas:
debian:~# ldapsearch -x -L -b 'dc=sala,dc=intra' '(objectclass=*)'
E:
debian:~# ldapsearch -x -LL -b 'dc=sala,dc=intra' '(cn=*)'

Cujos resultados serão, respectivamente:
Vamos criar as entradas para usuários e grupos antes de cadastrar alguma conta:
debian:~# vi /tmp/people.ldif

Para adicionar ao LDAP execute:
debian :~# ldapadd -x -D 'cn=admin,dc=sala,dc=intra' -W -f /tmp/people.ldif
Agora que possuímos as entradas para contas de usuários e grupos, podemos criar grupos e usuário
dentro do LDAP. Para isso utilizaremos uma ferramenta web chamada phpldapadmin.
debian :~# apt-get install phpldapadmin
O acesso é feito através do browser pela seguinte URL: http://localhost/phpldapadmin
Após fazer o login, vemos a interface com o domínio e seus objetos filhos.

Agora criaremos os grupos para abrigar nossos usuários:
Após criar o grupo, criaremos o usuário:

Agora com o grupo e usuário criados, vejamos como fica a interface principal.
Agora com o servidor LDAP configurado e com contas criadas, vamos nos ater a configuração do
cliente.
12.3
Cliente LDAP
Para a configuração de uma estação Linux para ser cliente do servidor LDAP, instalaremos os seguintes
pacotes:
debian :~# apt-get install libpam-ldap libpam-cracklib libnss-ldap
Onde:

libpam-ldap – É a biblioteca com os módulos de autenticação LDAP para o PAM.

libpam-cracklib –É a biblioteca cracklib (para senhas mais seguras) para o PAM.
libnss-ldap – É a biblioteca com os módulos de LDAP para o NSS.
Respondas as questões da seguinte forma, para o libnss-ldap:
Especifique o caminho do servidor de LDAP, podendo ser:
ldap:// - Servidor LDAP porta 389

ldaps:// -Servidor LDAP porta 636
Especifique o domínio do LDAP, ou seja, se o domínio é sala.intra, ficará: dc=sala,dc=intra

Para mais segurança utilize a versão 3 do protocolo LDAP.
Configure a conta de administrador.

Configure a senha de administrador para acesso ao LDAP.
Para as configurações do libpam-ldap faremos o seguinte:
Colocaremos a conta de root local como administrador do banco de dados.

Configurar para não pedir autenticação para acesso à base do LDAP.
Configure a conta de administrador para o LDAP.

Configure a senha de administrador do LDAP.
Agora vamos alterar os arquivos do NSS e do PAM para alterar a ordem de busca de informações de
contas e fazer o sistema procurar o LDAP. Primeiro vamos adicionar o caminho para o servidor LDAP e o
domínio utilizado:
debian:~# vi /etc/ldap/ldap.conf
Caso o seu DNS não esteja com o nome server-ldap.sala.intra, basta colocá-lo no /etc/hosts apontando
para o endereço de IP do servidor LDAP.
Como os arquivos /etc/libnss-ldap.conf e /etc/pam_ldap.conf já foram modificados pela configuração

do debconf, vamos ao arquivo /etc/nsswitch.conf, que vai definir a ordem de consulta de informações para
contas, grupos e senhas.
debian:~# vi /etc/nsswitch.conf

Assim o sistema irá consultar primeiro nos arquivos locais e depois no servidor LDAP.
Para verificar se o cliente está conseguindo acessar o servidor LDAP e receber as informações usamos
os comandos:
debian:~# getent passwd
debian:~# getent group
Podemos ver que os usuários criados apenas no LDAP estão sendo encontrados.
Para que os programas que utilizam autenticação tenham acesso aos usuários do LDAP, devemos
centralizar os arquivos de controle do PAM: common-account, common-auth, common-password e common-
session. Estes arquivos estão em /etc/pam.d.
Edite /etc/pam.d/common-account e acrescente antes das outras configurações a seguinte linha:
account sufficient pam_ldap.so

Edite /etc/pam.d/common-auth e acrescente antes das outras configurações a seguinte linha:
auth sufficient pam_ldap.so
Edite /etc/pam.d/common-password e acrescente antes das outras configurações as seguintes linhas:
password required pam_cracklib.so retry=3 minlen=6 difok=3

password sufficient pam_ldap.so use_authtok
Edite /etc/pam.d/common-session e acrescente depois das outras configurações as seguintes linhas:
session required pam_mkhomedir.so skel=/etc/skel/

session optional pam_ldap.so
Pronto é só logar nos serviços utilizando as contas do servidor LDAP.

14- SUPERDAEMONS
14.1
Super Servidores (SuperDaemons)
Criados para permitir que serviços que não possuem daemon próprio sejam executados sob demanda
e tenham os recursos controlados. Serviços de rede precisam estar residentes em memória. Abrem uma no
porta no servidor e ficam escutando por conexões de rede.
Daemons são processos quase sempre permanentes, que executam em background funções de
suporte ao sistema operacional, assim programas que precisam se comunicar em rede e não criam seus
próprios sockets e não gerenciam portas nem recursos são configurados para funcionar sob a tutela de um
daemon de internet, um superdaemon.
O daemon Inetd é padrão em distribuições baseadas em Debian, e o Xinetd é o padrão em

distribuições baseadas em Red Hat.
14.2
INETD
O Superdaemon inetd foi criado para reunir a configuração de serviços. O inetd fica a escuta em
diversas portas e as repassa para os programas responsáveis as requisições feita em determinada portas.
Oferece segurança através do processo tcpwrappers, que filtra as conexões de acordo com as regras definidas.
Os serviços só são carregados em memória quando solicitados, assim não há desperdício de recursos
quando não há clientes usando o serviço.
O arquivo de configuração é o /etc/inetd.conf e cada linha configura um determinado serviço. As linhas

tem a seguinte estrutura:
<serviço> <tipo de socket> <protocolo> <flag> <usuário> <caminho> <argumento>
Serviço - Nome do serviço oferecido. Este nome deve estar definido no arquivo /etc/services para que
ele saiba que porta o serviço irá escutar.
Tipo de socket – Sockets TCP utilizam stream e UDP dgram, são os mais comuns.
Protocolo - Especifica o protocolo de transporte utilizado pelo serviço. TCP ou UDP. Os protocolos
devem ter uma entrada válida em /etc/protocols.
Flags - Informa se o servidor de rede libera a porta após ele ser iniciado e se outra cópia pode ser
executada para a próxima requisição de conexão. TCP utiliza nowait e UDP wait.
Usuário - Sob qual usuário o serviço será executado. Formato usuário<.grupo>
Caminho – Caminho completo para o executável do serviço. Caso seja um serviço interno do inetd,
deve-se usar a palavra INTERNAL. Alguns serviços não possuem controle de acesso, por esse motivo é carregado
/usr/sbin/tcpd e o serviço a ser será declarado no próximo campo.
Argumentos – Instruções a serem executadas pelo servidor ou o próprio serviço quando iniciado.

Exemplo de arquivo de configuração do Inetd com os servidores de telnet, talk e pop3 configurados.
Para verificar possíveis erros de execução ou apenas obter mais informações de funcionamento dos
serviços, devemos executar o inetd em modo de depuração:
debian:~# inetd -d
ADD: telnet proto=tcp, wait.max=0.256 user:group=telnetd:(default) builtin=0 server=/usr/sbin/tcpd
ADD: talk proto=udp, wait.max=1.256 user:group=nobody:tty builtin=0 server=/usr/sbin/in.talkd
ADD: ntalk proto=udp, wait.max=1.256 user:group=nobody:tty builtin=0 server=/usr/sbin/in.ntalkd
ADD: pop-3 proto=tcp, wait.max=0.256 user:group=root:(default) builtin=0 server=/usr/sbin/tcpd
Após configurado, basta executarmos seu script de inicialização:
debian:~# /etc/init.d/openbsd-inetd restart
14.3
XINETD
Criado para ser o substituto avançado do Inetd, o Xinetd (eXtendend inetd). Funciona de modo
semelhante ao Inetd, e agrega maior controle de acesso e segurança.
Características:
 Suporte nativo a tcpwrappers;

 Controle de acesso melhorado;
 Controle por data/hora, quantidade de conexões e sua taxa;
 Informações de log detalhados, incluindo duração da conexão;
 Suporta redirecionamento de serviços para outra máquina.
O arquivo de configuração principal é /etc/xinetd.conf. Neste arquivo não estão cadastrados os

serviços, os serviços agora estão em arquivos individuais no diretório /etc/xinetd.d
Apesar de alguma semelhança com alguns parâmetros do inetd, há opções adicionais:
Alguns parâmetros mais comuns:

disable yes desligado, no ligado.
flags Parâmetros de controle.
socket_type Tipo de socket: stream, dgram.
protocol Protocolo válido. Deve estar em /etc/protocols
wait Yes, xinetd vai disparar o programa responsável pelo serviço e esperar até
que ele termine, recusando novas conexões enquanto isto.
wait No, novas conexões continuarão sendo aceitas e novas cópias do programa
serão iniciadas para cada conexão mesmo com as outras em andamento.
user Usuário
group Grupo
server Especifica o programa responsável pelo serviço.
server_args Parâmetros do serviço.
log_on_failure Que informações serão registradas nos logs caso ocorra um erro USERID
DURATION HOST PID.
log_on_success Que informações serão registradas nos logs em caso de sucesso USERID
DURATION HOST PID.
instances Quantas instâncias simultâneas deste serviço são permitidas. Padrão sem
limites.
access_times Especifica o horário em que conexões a este serviço serão aceitas. O

intervalo é dado no formato 24 horas - HH:MM-HH:MM.
per_source Quantas conexões simultâneas de um mesmo IP são permitidas.
cps Limita a taxa de conexão através. Trabalha com 2 argumentos: 1º conexões

por segundo, 2º quanto tempo desativar o serviço caso a taxa de conexões seja ultrapassada.
nice Valor inicial para o nice dos processos.
only_from Aceitar conexões de redes especificadas. aceita notação CIDR.
no_access O contrário de only_from
Exemplo para /etc/xinetd.d/telnetd:
service telnet
{
disable = yes
flags = REUSE
socket_type = stream
protocol = tcp
wait = no
user = telnetd
server = /usr/sbin/in.telnetd

log_on_failure = USERID
only_from = 192.168.1.0/24 127.0.0.1
}
Para converter serviços configurados pelo Inetd para o formato utilizado pelo xinetd usamos o
comando itox (inetd to xinetd)
debian:~# grep -i telnet /etc/inetd.conf | itox -daemon_dir /usr/sbin/tcpd > /etc/xinetd.d/telnet
14.4
TCPWRAPPERS
Os tcpwrappers são os controles de acesso utilizados por daemons TCPD, ou seja daemons do inetd e
xinetd e daemons que foram compilados com suporte a biblioteca do TCPD. Pode ser utilizado para permitir ou
bloquear acesso a diversos serviços utilizando regras simples em 2 arquivos: o /etc/hosts.allow e
/etc/hosts.deny.
No arquivo /etc/hosts.allow temos as regras de liberação do cliente ao serviço especificado, e no

/etc/hosts.deny as regras de bloqueio do cliente ao serviço. As regras contidas em /etc/hosts.allow tem
precedência sobre /etc/hosts.deny.
Caso o cliente tente acesso a algum serviço que não esteja listado nesses arquivos, o mesmo terá
acesso garantido.
Formato dos arquivos:
lista_serviços : lista_clientes <: comandos_shell>
lista_serviços - Quais os serviços, ou coringas, serão afetados pela regra. Os serviços podem ser
separados por vírgulas. Pode ser utilizado o coringa ALL para todos os serviços.
lista_clientes - Uma lista de um ou mais hostnames, endereços, padrões ou coringas para casar com a
regra. A lista pode ser separada por espaço ou vírgula. Com exceção dos netgroups NIS (YP), todas as checagens
de controle de acesso não diferenciam maiúsculas e minúsculas.
Quais coringas podem ser utilizados nos arquivos:
ALL - Todos
LOCAL - Coincide com qualquer host cujo nome não contém um caractere de ponto.
UNKNOWN - Corresponde a qualquer usuário cujo nome é desconhecido, e combina com qualquer
host cujo nome ou endereço é desconhecido. Esse padrão deve ser usado com cautela, pois os servidores de
nomes podem apresentar falha temporária.
KNOWN - Corresponde a qualquer usuário cujo nome é conhecido, e combina com qualquer host cujo
nome e endereço são conhecidos. Esse padrão deve ser usado com cautela pois os servidores de nomes podem
estar indisponíveis temporariamente.
PARANOID - Coincide com qualquer host cujo nome não corresponde ao seu endereço. Normalmente
tcpd é compilado com -D PARANOID (esse é o padrão), nesse modo a conexão cai antes mesmo de ser
analisada qualquer tabela de controle de acesso.
Operador:

EXCEPT - Permite a utilização de exceção, tanto em lista_serviços quanto em lista_clientes. Esta técnica
permite a utilização de apenas um dos arquivos para liberação ao serviços especificados.
Comandos do Shell:
Se a regra casar com padrão especificado e houver um comando após a lista_clientes, alguns dados da
conexão serão repassados para as macros precedidas por %, a listagem a seguir lista algumas das macros
utilizadas:
%a (%A) - O endereço do cliente (servidor).
%c - Informações do cliente, tais como: usuário@host, usuário@IP.
%d - O nome do daemon.
%h (%H) - O nome ou endereço do cliente (servidor).
%n (%N) - O hostname do cliente (servidor). Exibe "unknown" se o mesmo não estiver disponível e
"paranoid" se o endereço e o host não correspondem.
%p - O PID do processo do serviço (daemon).
%s - Informações do servidor: daemon@host, daemon@IP.
%u - O nome do usuário, ou exibe "unknown" se não puder obter o nome.
OBS.: A entrada (stdin), saída padrão (stdout) e de erro (stderr) são conectadas a /dev/null. Especifique
um '&' no final do comando, se você não quiser esperar até que tenha terminado.
Montando uma armadilha com os tcpwrappers.
O exemplo a seguir permite que solicitações TFTP de hosts no domínio local (note o ponto inicial). Os
pedidos de outros hosts são negados. Em vez de o arquivo solicitado, um finger é enviado para o host agressor.
O resultado é enviado para o superusuário.
No /etc/hosts.allow, inserimos a linha que determina que o TFTP só é permitido para quem vem da
rede local e do domínio .sala.intra .
No /etc/hosts.deny negamos o acesso ao serviço TFTP para todos (ALL) e executamos o comando
safe_finger utilizando os parâmetro fornecidos pelo próprio tcpwrapper.

O comando safe_finger vem com tcpd wrapper e devem ser instalados em local adequado. Isso limita
os danos possíveis a partir dos dados enviados pelo servidor finger padrão.

15- OPENSSH
15.1
Secure Shell
OpenSSH é uma versão livre do SSH (Secure Shell), é uma ferramenta de conectividade que os usuários
técnicos confiam. Usuários de telnet, rlogin e FTP podem não perceber que sua senha é transmitida pela
internet sem criptografia, mas é. OpenSSH criptografa todo o tráfego (incluindo senhas) para eliminar
efetivamente sniffers, seqüestro de conexão, e outros ataques. Além disso, OpenSSH fornece capacidades de
tunelamento seguro e vários métodos de autenticação e suporta todas as versões do protocolo SSH.
O pacote do OpenSSH substitui rlogin e telnet com o programa ssh, rcp com o scp e ftp com sftp.
Também está incluído o sshd (servidor).
15.2
Criptografia
O ssh utiliza criptografia de chaves assimétricas, ou chaves públicas, o par de chaves pública/privada é
gerada a partir de números aleatórios, que vão ser descartados posteriormente no processo. Essa criptografia
só é possível pois existe uma relação matemática entre estas chaves geradas por estes números aleatórios e
pelos cálculos para encontrar estas chaves, esta relação entre as chaves é um dos resultados do estudo da
teoria dos números. A chave pública é distribuída e a chave privada mantida em segredo e armazenada em um
local seguro. Ao distribuir a chave pública a alguém, assume-se que esta pessoa vai ter condições de
compreender os dados que lhe serão enviados. O que é criptografado com a chave privada só pode ser
descriptografado com a chave pública e vice e versa.
O principal algoritmo utilizado hoje em dia, principalmente em email, transações na internet e

conexões com ssh é o algoritmo RSA. O RSA se baseia no fato de que, dois número primos muito grandes, com
centenas de dígitos por exemplo, sejam relativamente fáceis de se encontrar, conseguir fatorar o produto
destes dois números é considerado computacionalmente complexo, ou seja estima-se em milhares de anos o
tempo para isso. Portando este algoritmo mostra-se computacionalmente inquebrável com números de tais
dimensões, e a sua força é geralmente quantificada com o número de bits utilizados para descrever tais
números. Para um número de 100 dígitos são necessários cerca de 350 bits, e as implementações atuais
superam os 512 e mesmo os 1024 bits. O que garante ao ssh uma força de criptografia quase inquebrável.
O RSA foi criado pelos professores do MIT: Ronald Rivest, Adi Shamir e Leonard Adleman, que mais
tarde fundaram a RSA Data Security, Inc. Considerado um dos algoritmos mais seguros, já que as tentativas de
quebrá-lo não foram bem sucedidas. Foi também o primeiro algoritmo a possibilitar criptografia e assinatura
digital, e uma das grandes inovações em criptografia de chave pública.
15.3
Servidor SSH
O servidor SSH é que recebe as conexões, verifica as identidades e negocia a criptografia para acesso
ao shell. Ele é configurado pelo arquivo /etc/ssh/sshd_config e o daemon é o sshd.
No diretório de configuração temos os seguintes arquivos:
moduli – Onde estão os nomes dos módulos carregados pelo ssh;

ssh_config – Arquivo de configuração do cliente ssh;
sshd_config – Arquivo de configuração do servidor ssh;

ssh_host_dsa_key – Chave privada do algoritmo DSA;

ssh_host_dsa_key.pub – Chave pública do algoritmo DSA;
ssh_host_rsa_key – Chave privada do algoritmo RSA;
ssh_host_rsa_key.pub – Chave privada do algoritmo RSA;
Segue abaixo um exemplo de configuração do daemon do ssh:
As principais variáveis do arquivo são:
Em qual Porta o serviço do ssh está aguardando por conexão, é comum mudar a porta para dificultar
acesso por pessoas não autorizadas, mas lembre-se que os programas clientes por padrão procuram a porta 22:
Port 22
Em quais interfaces o ssh estará ouvindo conexões, tanto em Ipv6 quanto Ipv4:
ListenAddress ::
ListenAddress 0.0.0.0
Versão protocolo que o ssh está utilizando. Recomendável versão 2 protocolo, já que a versão 1 tinha
problemas com o tamanho das chaves:
Protocol 2
Localização do arquivo contendo as chaves ssh da versão 2 do protocolo.

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
Esta opção quando ativa irá permitir que o servidor ssh execute uma pequena quantidade de código
como root em uma jaula chroot, ou seja, após autenticar e aceitar a conexão o sshd irá criar um processo com
os privilégios do usuário que se autenticou e não mais com privilégio de root:
UsePrivilegeSeparation yes
Tempo de vida, em segundos, da chave na versão 1 do protocolo:

KeyRegenerationInterval 3600
Tamanho, em bits, da chave na versão 1 do protocolo:

ServerKeyBits 768
Recurso do Syslog que será usado para registrar as atividade do ssh:

SyslogFacility AUTH
Nível do Syslog que será usado para registrar as atividade do ssh:

LogLevel INFO
Tempo que usuário terá para efetuar o login, tempo entre envio do nome do usuário e a senha:
LoginGraceTime 120
Permissão para o usuário root logar através do ssh:

PermitRootLogin yes
Garantir que seus arquivos do ssh e diretórios tenham permissões adequadas e dono apropriado antes
de permitir que uma sessão ssh seja aberta:
StrictModes yes
Indica se a autenticação RSA pura é permitida. Esta opção é aplicada na versão 1 do protocolo.
RSAAuthentication yes
Indica se autenticação por chave pública é permitida. Aplicada somente na versão 2 do protocolo. Esta
variável também permitirá o uso de autenticação por desafio resposta:
PubkeyAuthentication yes
Indica o caminho que contém as chaves públicas que podem ser usadas para autenticação do usuário.
Caso a variável seja omitida o padrão é “.ssh/authorized_keys”:
AuthorizedKeysFile %h/.ssh/authorized_keys
Os parâmetros usados foram:

%h – Diretório pessoal;
%u – Nome do usuário.
Não permite o uso de arquivos ~/.rhosts e ~/.shosts nas opções RhostsRSAAuthentication ou

HostbasedAuthentication:
IgnoreRhosts yes
Define se será permitido ou não o redirecionamento de conexões do servidor gráfico:

X11Forwarding yes
Define o número do primeiro display usado pelo ssh, isto é usado para evitar que o ssh interfira no
funcionamento do servidor gráfico:
X11DisplayOffset 10
Define se será mostrado ou não o conteúdo do arquivo /etc/motd quando o usuário logar:
PrintMotd no
Define se será mostrado ou não o último login feito por aquele usuário:
PrintLastLog yes
Define se serão enviados pacotes pela rede para manter a conexão persistente:
TCPKeepAlive yes
Define se será utilizado o login para autenticação, se utilizado X11Forwarding não funcionará:
#UseLogin no

Especifica o número máximo de conexões simultâneas não autenticadas para o servidor SSH. Conexões
adicionais serão descartadas até que a autenticação seja bem-sucedida ou que LoginGraceTime expire para
uma conexão. O padrão é 10. Podemos usar o formato: inicial:taxa:max para especificar; quando 5 conexões
não autenticadas forem alcançadas 80% das novas conexões serão rejeitadas até o máximo de 10 conexões não
autenticadas. Então todas as novas conexões daquele endereço serão rejeitadas até que o servidor seja
reiniciado:
MaxStartups 5:80:10
Qual informação de banner será mostrada pelo ssh:

Banner /etc/issue.net
Permite ao cliente passar as variáveis de localização:

AcceptEnv LANG LC_*
Servidor de SFTP utilizado:

Subsystem sftp /usr/lib/openssh/sftp-server
Define se serão usados os mecanismos de autenticação do PAM para login, se deseja utilizar apenas
autenticação por chaves pública, esta variável deve se mudada para no:
UsePAM yes
Define se o servidor irá buscar no DNS uma entrada com o nome dos clientes, se for desabilitado
costuma tornar o login mais rápido:
UseDNS no
Define um controle de acesso por usuários, é uma variável excludente, ou seja, quem está descrito nela
pode fazer e quem não está descrito não pode fazer:
AllowUsers user1 user2 admin
Define um controle de acesso por usuários, é uma variável excludente, ou seja, quem está descrito nela
não pode fazer e quem não está descrito pode fazer, ela é o contrário da variável AllowUsers, não pode utilizar
as duas variáveis ao mesmo tempo:
DenyUsers user3 user4 estagiario
Após configurar o servidor sshd corretamente, devemos reiniciar o serviço para que as mudanças
tenha efeito:
debian:~# /etc/init.d/ssh restart
Ou:
red-hat:~# /etc/init.d/sshd restart
Para verificarmos se o SSH está em funcionamento utilizamos o netstat e verificamos se a porta

configurada no arquivo está aberta.
15.3
Segurança no Servidor SSH
Para melhoria da segurança no servidor SSH, podemos utilizar programas que trabalham com análise
das conexões e dos logs para incrementar a segurança no acesso ao serviço como o fail2ban.
O Fail2Ban utiliza os logs de acesso para analisar e através de sua configuração bloquear o acesso a
algum serviço ou porta, o SSH já possui uma configuração pronta no fail2ban, seus arquivos de configuração

estão no diretório /etc/fail2ban.
debian:~# cd /etc/fail2ban
O fail2ban funciona da seguinte forma, seu daemon fica monitorando os logs dos serviços configurados
em jail.conf, procurando por conteúdo que vem especificado nos arquivos correspondentes ao serviço no
subdiretório filter.d, e quando encontra o padrão pesquisado ele executa a ação configurada no arquivo
jail.conf na linha banaction, e descrita no arquivo correspondente no diretório action.d.
Exemplo de arquivo de configuração do fail2ban no diretório /etc/fail2ban/filter.d/sshd.conf, que

utilizando expressões regulares faz a checagem nos logs sobre autenticações malsucedidas e hosts não
autorizados.
Exemplo de log do fail2ban com dois hosts sendo banidos por ter mais de 6 acessos não autorizados:
15.4
Cliente SSH
SSH
O cliente mais comum de acesso é o comando ssh, apesar de existirem executáveis para outros
sistemas operacionais. A sintaxe do comando ssh é:
ssh <opções> <host>

-4 - Força o uso somente de IPV4.
-6 - Força o uso somente de IPV6 (padrão).
-C - Ativa a compressão.
-f - Solicita que o ssh vá para o segundo plano antes de rodar um comando.
-l <usuário> - Usuário no host remoto. Pode ser utilizado o formato login@host em substituição.
-L <bind_address>:<port>:<host>:<port> - Utilizado para criar um túnel criptografado.
-N - Não executa nenhum comando remoto, utilizado principalmente em túnel criptografado.
-o <opção>- Opções do arquivo de configuração ssh_config (cliente).
-p <porta> - Porta de acesso no host remoto, se omitido a porta 22 é assumida.
-X - Permite o repasse do Servidor X (X11). a opção -x desabilita.
-Y - Permite sempre confiar em repasses do servidor X.
-q - Modo silencioso.
-v - Modo detalhado. Exibe mais informações durante a conexão.
Exemplo de conexão com ssh:
Podemos ver que o primeiro passo foi o ssh identificar a máquina de destino, no caso 10.20.1.199, e
como não pode verificar se a máquina que estava sendo acessada era realmente a máquina desejada ele
informa que não pôde verificar a autenticidade do host e mostra o fingerprint (impressão digital) da máquina.
Aceitando o fingerprint o comando ssh vai gravá-lo no arquivo ~/.ssh/known_hosts em uma linha, junto com a
chave pública fornecida pela máquina após aceitação do fingerprint. Assim quando formos fazer conexão

novamente na máquina cliente o ssh irá verificar se o fingerprint é o mesmo que está gravado em arquivo, se
for ele continua com a conexão, se não for ele interrompe imediatamente a conexão e avisa de possível quebra
de segurança, pois mudanças de fingerprint acontecem apenas quando há reinstalação de sistema, ou seja se o
servidor de destino não teve mudanças no sistema, indica que é possível que haja um atacante se fazendo
passar pelo destino de nossa comunicação (ataque conhecido como MITM, ou seja, Man-In-The-Middle).
Exemplo de conexão recusada por divergências no fingerprint:
Além de mostrar que o fingerprint foi modificado ele informa qual linha do arquivo
~/.ssh/known_hosts contém aquela informação, assim sendo
SCP
O comando scp provê a capacidade de copiar arquivos ou diretórios pela rede utilizando toda a
segurança que o ssh possui.
Sua sintaxe é simples:
scp <opções> <origem> <destino>
Onde as opções mais usadas são:

-r – Recursiva, para copiar diretórios pela rede;
-P – Porta, para utilizar uma porta para conexão diferente da porta padrão.
Exemplo copiando como user1 o arquivo /tmp/arq1 da maquina local para a maquina 10.20.1.100 para
o diretório /home/user1 :
debian:~# scp /tmp/arq1 user1@10.20.1.100:/home/user1
Após se autenticar com a senha do usuário a cópia será feita pela rede utilizando o protocolo SSH para
segurança.
SSH-KEYGEN
O comando ssh-keygen é utilizado para gerar chaves assimétricas utilizadas para autenticação, assim
são geradas uma chave pública e uma privada para que o usuário possa se autenticar em uma outra máquina
que esteja sendo executado um servidor sshd sem uso da senha de usuário.
O funcionamento da autenticação é simples, ao gerar o par de chaves o usuário copia sua chave
pública (o arquivo de extensão .pub) para a máquina que ele quer se logar sem uso de senhas, a cópia pode ser
feita com o uso do comando scp ou com o comando ssh-copy-id.

Para gerar a chave com o nome padrão e com 4096 bits de tamanho, executamos o seguinte comando:
debian:~# ssh-keygen –b 4096
O ssh-keygen gera a chave e grava no diretório .ssh do usuário o arquivo id_rsa (chave privada) e
id_rsa.pub (chave pública), ele solicita uma senha para ser gravada na chave, assim mesmo com chave o usuário
ainda pode ter a segurança de uma frase secreta, que evita que a senha do usuário seja enviada pela rede. Se
não for preenchida nenhuma senha a autenticação vai ocorrer automaticamente apenas com o uso das chaves.
Ele gera o fingerprint da chave e utiliza o dispositivo randômico da máquina para preencher lacunas da chave, e
mostra uma imagem representativa da chave.
Após isso, basta copiar a chave pública para a maquina desejada e logar nela apenas com a chave.
SSH-AGENT
O ssh-agent é um programa usado para armazenar chaves privadas utilizadas para a autenticação de
chave pública (RSA, DSA). A idéia é que o ssh-agent seja iniciado no início de uma sessão X ou uma sessão de
login, e todas as outras janelas ou programas são iniciados como clientes para o programa ssh-agent. Através
do uso de variáveis de ambiente que o agente pode ser localizado e usado automaticamente para a
autenticação ao se conectar a outras máquinas usando o ssh.
Ou seja, se estamos utilizando a autenticação de chave pública e utilizamos uma frase senha
(passphrase) na criação das chaves, toda vez que formos autenticar com as chaves temos que digitar a frase. O
ssh-agent grava na memória da sessão que estamos utilizando, seja uma sessão de terminal ou de texto, a frase
senha, assim dentro daquela sessão, quando formos nos autenticar novamente com as chaves o ssh-agent já
fornece a frase para a autenticação.
O agente inicialmente não possui as chaves privadas. As chaves são adicionadas usando ssh-add.
Quando executado sem argumentos, o ssh-add adiciona os arquivos ~/.ssh id_rsa , ou ~/.ssh/id_dsa ou
~/.ssh/identity. Se a identidade tem uma senha, o ssh-add pede a senha (usando um aplicativo X11 se estiver
rodando sob o X11, ou a partir do terminal se funcionando sem X). Em seguida, envia a identidade para o
agente. Várias identidades podem ser armazenadas no agente, o agente pode automaticamente usar qualquer
uma dessas identidades. O comando ssh-add -l exibe as identidades atualmente na posse do agente.
Veja o exemplo abaixo:

O ssh-agent foi executado e criou um socket para se comunicar com o ssh, exportamos as variáveis
com o endereço do socket e com o PID do ssh-agent para o ambiente. Executamos o ssh-add que exportou para
o ssh-agent a chave privada do usuário e pediu a passphrase usada na criação da chave, assim qualquer
autenticação feita nesta sessão não vai pedir a passphrase novamente.

16- SERVIDOR FTP
16.1
Servidor FTP
O protocolo FTP foi criado para permitir a transferência de arquivos pela rede, seu funcionamento é
feito através das portas 20 TCP (FTP Data) e 21 TCP (FTP Command). Ele possibilita que um cliente
anonimamente ou autenticado faça downloads e até uploads de arquivos para o servidor.
O serviço de FTP pode ser acessado por linha de comando, programa específico ou até pelo browser.
16.2
Cliente FTP
Basicamente todos os sistemas operacionais vêm com um cliente de FTP, o executável geralmente se
chama apenas ftp, seu uso é muito simples e seus comandos são básicos a quase todos os outros clientes de
FTP.
Segue um exemplo de conexão em um servidor de FTP:
Após se conectar o cliente possui uma série de comandos que são úteis no gerenciamento dos
arquivos, como o FTP foi criado em ambientes Unix a maioria dos comandos são os comando usados em shell
Unix, como bash ou sh. Isto dá uma certa familiaridade para os usuários do shell, as ferramentas gráficas de FTP
nada mais fazem que executar estes comandos ao clicar no botão.
Alguns comandos abaixo são exclusivos deste cliente de FTP, mas a maioria são comandos comuns a
todos os outros.

Principais comandos:
ascii – Fazer a transferência em modo ascii.

binary – Fazer a transferência em modo binário (recomendado).
cd – Mudar de diretório no servidor.
chmod – Mudar as permissões do arquivo.
close – Fechar a conexão com o servidor.
delete – Apagar um arquivo.
dir – Listar um arquivo ou diretório
exit – Para sair do servidor.
get – Baixar arquivos do servidor para a máquina local.
lcd – Mudar de diretório na máquina local.
mkdir – Criar diretório no servidor.
open – Iniciar uma conexão com um servidor.
put – Enviar arquivos da máquina local para o servidor.
pwd – Mostrar o diretório atual no servidor.
quit – Fechar a conexão com o servidor.
rename – Renomear arquivos ou diretórios.
rmdir – Apagar diretório.
umask – Define as permissões padrão para arquivos e diretórios.
Exemplo de acesso a um diretório no servidor:

16.3
VSFTPD
O servidor VSFTPD é um leve, eficiente servidor de FTP escrito do zero com segurança em mente. O
vsftpd suporta ambos anônimo e não anônimo FTP, a autenticação PAM, limitação de banda, TLS, Virtual Hosts,
etc.
Ele é rápido, estável e seguro, seu arquivo de configuração é o /etc/vsftpd.conf e seu arquivo do PAM é
/etc/pam.d/vsftpd.
As principais opções do arquivo de configuração são:
O servidor VSFTPD ira trabalhar em modo standalone ou ser executado pelo INETD/XINETD.
listen=YES
O servidor VSFTPD ira trabalhar em modo standalone ou ser executado pelo INETD/XINETD para IPv6.
listen_ipv6=NO
Permitir acesso anônimo.

anonymous_enable=YES
Permitir que usuários locais possam usar o VSFTPD.

local_enable=YES
Permitir escrita no VSFTPD para os usuários autenticados.

write_enable=YES
Umask padrão para criação de arquivos e diretório dentro do FTP.

local_umask=022
Permitir que usuários anônimos tenham direito de fazer upload de arquivos para o servidor. É preciso
que a permissão de escrita esteja ativada e que o diretório de anônimo tenha direito de escrita para o usuário
FTP.
anon_upload_enable=NO
Permitir que o usuário anônimo crie novos diretórios.

anon_mkdir_write_enable=NO
Se permitir upload de anônimo, deve mudar o dono dos arquivos enviados para um usuário diferente,
não root.
#chown_uploads=YES
#chown_username=ftp
Ativar uma mensagem que será mostrada ao usuário quando ele entrar em certos diretórios.
dirmessage_enable=YES
Porta em que o servidor vai escutar as requisições:

listen_port=21
Garantir que as transferências se originam da porta 20 (ftp-data).

connect_from_port_20=YES
Log de Transferência do servidor VSFTPD.

xferlog_enable=YES

Caminho do Log de Transferência.

xferlog_file=/var/log/vsftpd.log
Timeout em uma sessão ociosa.

idle_session_timeout=300
Timeout após uma transferência de dados.

data_connection_timeout=120
Usuário sem privilégios que o VSFTPD irá usar para executar isolar o servidor FTP.
nopriv_user=ftpsecure
Habilita o comando ABOR para transferências assíncronas.

async_abor_enable=YES
Habilitar usar o método de transferência ASCII, isto pode causar problemas na transferência de
arquivos binários.
ascii_upload_enable=NO
ascii_download_enable=NO
Banner do servidor de FTP:

ftpd_banner=Bemvindo ao FTP.
Desabilitar alguns endereços de email de logins anônimos. Aparentemente útil para combater certos
ataques de DoS.
#deny_email_enable=YES
Arquivo com os email banidos.

#banned_email_file=/etc/vsftpd.banned_emails
Fazer que o usuário fique restrito ao seu próprio diretório (chroot).

chroot_local_user=YES
Fazer chroot de apenas alguns usuários..

#chroot_list_enable=YES
Arquivo com a lista de usuários que serão postos em chroot.

#chroot_list_file=/etc/vsftpd.chroot_list
Habilitar a opção -R para o comando ls.

ls_recurse_enable=YES
Número máximo de clientes simultâneos no FTP:

max_clients=20
Número máximo de conexões originadas do mesmo IP:

max_per_ip=3
Número máximo de falhas de login até que a sessão seja fechada pelo servidor:
max_login_fails=5
Após configurar o serviço, basta reiniciar o servidor, se ele estiver sendo executado via INETD/XINETD
basta executar o daemon, se ele estiver standalone basta reiniciar o script:
debian:~# /etc/init.d/vsftpd restart

Para testar basta fazer uma conexão na porta 21 da máquina com um cliente de FTP ou pelo browser
com: ftp://usuário@ip/nome_do_servidor.
Exemplo de arquivo de uso do VSFTPd:
16.4
Pure-FTPd
O Pure-FTPd foi criado para ser um servidor pequeno e simples para o Protocolo FTP, concebido para
utilizar menos recursos do que os servidores mais antigos, ser menor e muito seguro, e nunca executar
qualquer programa externo. Ele suporta recursos mais usados e os comandos de FTP (incluindo muitas
extensões modernas), e deixa de fora tudo o que é obsoleto, inseguro, sem sentido, ou se correlaciona com
problemas.
Diferente dos outros servidores de FTP o Pure-FTPd não foi criado para ter um arquivo de configuração
onde mudamos variáveis para mudar o comportamento do servidor, ele foi criado para através de sua linha de
comando utilizarmos as opções necessárias para que o servidor seja executado de acordo com as nossas
necessidades. Podendo trabalhar tanto pelo INETD quanto em modo standalone o Pure-FTPd não é difícil de ser
utilizado quando conhecemos suas variáveis principais.
Opções para execução do Pure-FTPd:
-0
Quando um arquivo é enviado e já existe uma versão anterior do nome do arquivo com o mesmo
nome, o arquivo antigo não será removido ou truncado. O envio terá lugar em um arquivo temporário e uma
vez que o upload estiver completo, a mudança para a nova versão será automática. Esta opção não deve ser
usada junto com quotas virtuais.
-1
Adiciona o PID para a saída do syslog. Ignorado se -f none for especificado.
-4

Escuta apenas para conexões IPv4.
-6
Escuta apenas para conexões IPv6.
-a gid
Usuários regulares ficarão em chroot para seus diretórios home, a menos que pertençam ao GID
especificado. Note que o root é sempre confiável e que sem esta opção o chroot ocorre somente para ftp
anônimo.
-A
Todos os usuários ficarão em chroot.
-b
Broken. Ativa alguns hacks de compatibilidade clientes malfeitos, e para gateways Netfilter com
problemas.
-B
Inicia o servidor em modo autônomo (standalone) em segundo plano (modo daemon).
-c clients
Permite um numero máximo de clientes conectados. Se mais do que o valor de clients estiverem
conectados, os novos clientes serão rejeitados. O valor padrão é 50.
-C max conection per IP

Limita o número de conexões simultâneas provenientes de um mesmo endereço IP. Esta é outra
maneira muito eficaz para impedir a negação de serviços e a fome de largura de banda por um único usuário.
Ele só funciona quando o servidor é iniciado no modo autônomo (se você usa um superservidor, ele é que deve
fazer isso). Esta opção precisa de memória para controlar endereços IP, mas é recomendável usá-lo.
-d
Ativa o log de depuração. Cada comando é registrado, exceto que o argumento PASS é alterado para
"<password>. Se você repetir o -d, as respostas também são registradas.
-e
Só usuários anônimos podem logar.
-E
Só usuários autenticados podem logar. Os usuários anônimos são proibidos.
-f facility
Faz o ftpd usar a facility para todas as mensagens do syslog. A facility padrão é ftp. Use -f none para
desabilitar o log.
-F fortunes file
Apresenta uma mensagem engraçada aleatória no banner de login inicial. Os cookies são
aleatoriamente extraída de um arquivo de texto no formato padrão fortunes. Se você instalou o pacote fortune,
você deve ter um diretório (normalmente /usr/share/fortune) com arquivos binários (xxxx.dat) e arquivos de
texto (sem a extensão .dat).
-g pidfile
No modo autônomo, grava o pid no arquivo especificado em vez de o /var/run/pure-ftpd.pid.
-G

Quando esta opção for ativada, as pessoas não podem mais alterar o nome dos arquivos enviados,
mesmo que sejam donos desses arquivos ou diretórios.
-H
Não resolver nomes de hosts. Significativamente Pode acelerar conexões e reduzir o uso da banda de
servidores ocupados. Especialmente usá-lo em sites públicos de FTP.
-i
Bloquear envio de arquivos por usuários anônimos, qualquer que sejam as permissões do diretório.
Esta opção é especialmente útil para hospedagem virtual.
-I timeout
Alterar o tempo ocioso máximo. O timeout é em minutos, e o padrão é 15.
-j
Se o diretório home de um usuário não existir, cria automaticamente. O diretório home pertence ao
usuário. Para evitar ataques locais, o diretório pai nunca deve pertencer a um usuário não confiável.
-k percentual
Bloqueia o upload se a partição está mais cheia do que percentual. Exemplo: -k 95 que vai garantir o
seu disco nunca vai ficar cheio mais de 95% pelos usuários de FTP.
-K
Permitir os usuários fazer upload de arquivos, mas não os excluir. Diretórios podem ser removidos,
mas apenas se eles estiverem vazios.
-L autentication:file
Ativar um novo método de autenticação. Pode ser:
-l unix para a autenticação padrão (/etc/passwd);
-l pam para autenticação PAM;
-l ldap:<arquivo de configuração> para diretórios LDAP;
-l mysql:<arquivo de configuração> para bancos de dados MySQL;
-l pgsql:<arquivo de configuração> para bancos de dados Postgres
-l puredb:<arquivo de banco de dados> para banco de dados PureDB;
-l extauth:<caminho para socket pure-authd> para manipuladores de autenticação externa.
Métodos de autenticação diferentes podem ser misturados. Por exemplo, se você executar o servidor
com -lpuredb:/etc/pwd.pdb -lmysql:/etc/my.cnf -lunix contas serão autenticadas primeiro a partir de um banco
de dados PureDB, se ele falhar, o servidor MySQL será solicitado, se a conta ainda não for encontrada na base
de dados, as contas Unix padrão serão escaneadas. Os métodos de autenticação são tentados na ordem que
você cria as opções -l.
-L max files:max depth

Evita ataques de negação de serviço, limitando o número de arquivos exibidos em um 'ls' e a
profundidade máxima do 'ls' recursivo. Os padrões são 2000:5 (2000 arquivos mostrados em um único 'ls' e
percorre no máximo cinco subdiretórios).
-m load
Não permitir que usuários anônimos baixem arquivos se a carga está acima de load quando o usuário
se conecta. Uploads e listar arquivos ainda são permitidos, assim como downloads por usuários reais. O usuário
não é informado sobre isso até que ele tenta baixar um arquivo.
-M
Permitir que usuários anônimos criem diretórios.

-n maxfiles:maxsize
Habilitar quotas virtuais. Arquivos .ftpquota são criados, e o número de arquivos para um usuário é
restrito por 'maxfiles'. O tamanho total máximo de seu diretório é restrita por 'maxsize' em Megabytes. Os
membros do grupo de confiança não estão sujeitas a quotas.
-N
Modo NAT.
-o
Habilitar o pure-uploadscript.
-O format:log file
Grava todas as transferências de arquivos em um arquivo de log específico, em um formato
alternativo. Atualmente, três formatos são suportados: CLF, Stats, W3C e xferlog.
Se você adicionar:
-O clf:/var/log/pureftpd.log
As suas opções de inicialização, o Pure-FTPd registrará transferências em /var/log/pureftpd.log em um
formato semelhante ao do servidor web Apache na configuração padrão.
Se você adicionar:
-O stats:/var/log/pureftpd.log
As suas opções de inicialização, o Pure-FTPd irá criar arquivos de log exatos para softwares de análise
de tráfego como o ftpStats.
Se você adicionar:
-O w3c:/var/log/pureftpd.log
As suas opções de inicialização, o Pure-FTPd irá criar arquivos de log conforme o formato W3C.
Por motivos de segurança, o caminho deve ser absoluto (por exemplo /var/log/pureftpd.log, não
../log/pureftpd.log).
-p first:last
Intervalo de portas usadas para downloads de modo passivo.
-P IP address or host name

Força o endereço IP especificado em resposta a um comando PASV/EPSV/SPSV.
-q upload:download
Ativa uma taxa de upload/download para usuários anônimos (ex: -q 1:5 significa que a 1MB deve ser
enviado para baixar 5 Mb).
-Q upload:download
Ativa uma taxa de upload/download usuários não-anônimos e anônimos. Se a opção -a for usada
também, o grupo de usuários de confiança será taxado.
-r
Nunca sobrescrever arquivos existentes. Fazer upload de um arquivo cujo nome já existe irá causar um
renomear automático. Arquivos serão chamados xyz.1, xyz.2, xyz.3, etc.
-R
Bloquear utilizadores (mesmo os não-anônima) o uso do comando chmod. Em serviços de
hospedagem, pode impedir que novatos cometam erros, como definição de permissões ruins em seu diretório
home. Somente o root pode usar CHMOD quando essa opção está habilitada.
-s
Não permitir que usuários anônimos recuperem arquivos de propriedade de "ftp" (Geralmente, os
arquivos enviados por outros usuários anônimos).

-S [{ip address|hostname}] [{port|service name}]

Esta opção só é eficaz quando o servidor é iniciado como um servidor autônomo. As conexões são
aceitas no IP e porta especificados. IPv4 e IPv6 são suportados.
-t bandwidth
ou -t upload bandwidth:download bandwitdh .Habilita largura de banda para usuários anônimos. O
delay deverá ser em kilobytes/segundo.
-T bandwidth
ou -T upload bandwidth:download bandwitdh .Habilita largura de banda para todos os usuários. O
delay deverá ser em kilobytes/segundo.
-u uid
Não permite que UIDs abaixo uid logarem no servidor FTP.
-U umask file:umaks dirs

Substituir as máscaras para a criação de novos arquivos e diretórios.
-V ip address
Permitir que acesso FTP não-anônimo somente neste endereço de IP local específico. Todos os outros
endereços IP serão apenas anônimos.
-x
No modo de operação normal, os usuários autenticados podem ler/escrever arquivos começando com
um ponto ('.'). Usuários anônimos não podem, por razões de segurança (como banners mudar ou esquecer
.rhosts). Quando o '-x' é usado, os usuários autenticados podem baixar arquivos . , mas não substituir/criá-los,
mesmo que pertençam a eles próprios.
-X
Esta opção é idêntica à anterior (escrita em arquivos . é proibida), mas em adição a isso os usuários não
podem sequer ler arquivos e diretórios que começam com um ponto (como "cd .ssh").
-y per user max sessions:max anonymous sessions

Essa opção permite limites de concorrência por usuário. Dois valores são separados por uma coluna. O
primeiro é o número máximo de sessões simultâneas para um único login. O segundo é o número máximo de
sessões ANÔNIMAS.
-Y tls behavior
-Y 0 (padrão) desativa SSL/TLS.
-Y 1 aceitar ambas as sessões normais TLS/SSL.
-Y 2 Recusa conexões que não usam SSL/TLS, inclusive os anônimos.
O servidor deve ter sido compilado com suporte a SSL/TLS e um certificado válido deve estar no lugar
para aceitar sessões criptografadas.
-z
Permitir que usuários anônimos ler arquivos e diretórios começando com um ponto ('.').
-Z
Adicionar regras de segurança contra erros comuns dos clientes (como chmod 0 sobre seus próprios
arquivos).
Assim a combinação destas opções em uma linha de comando faz o funcionamento do PureFTPd ser
bem controlável e seguro, o problema é que por não ter um arquivo de configuração é preciso que seja criado

um script para iniciá-lo ou fazer isso pelo INETD/XINETD.
Vamos ver um exemplo básico de script de inicialização para o PureFTPd que pode ser usado em
qualquer distribuição GNU/Linux.
debian:~ # vi /etc/init.d/pure-ftpd
#! /bin/sh
# Script usado para iniciar e parar o Pure-FTPd em modo daemon
# Variáveis principais do Script
PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin"
# Função que inicia o servidor Pure-FTPd

init_server () {
pure-ftpd -4 -A -B -c 50 -C 10 -E -f ftp -H -I 3 -j -l pam -O clf:/var/log/pure-ftpd.log -u 1000 -Z
if [ "$?" -eq "0" ] ; then
echo -e "Iniciando servidor Pure-FTPd" "\n"
else
echo -e "Erros encontrados, favor ler as mensagens e verificar o arquivo antes de continuar."
"\n"
sleep 3
fi
}
# Função que fecha o servidor Pure-FTPd

close_server () {
kill $(pgrep pure-ftpd)
if [ "$?" -eq "0" ] ; then
echo -e "Fechando servidor Pure-ftpd" "\n"
else
kill -9 $(pgrep pure-ftpd)
echo -e "Fechando servidor Pure-ftpd" "\n"
fi
}
# Parte que lê os comandos

case $1 in
stop) close_server
;;
start) init_server
;;
restart) close_server ; init_server
;;
*) echo "Use: /etc/init.d/pure-ftpd (start|stop|restart)"
esac
# fim do script
Assim podemos controlar via script de inicialização o Pure-FTPd em modo daemon (standalone) e com
as configurações que precisarmos, já que ele não tem um arquivo de configuração no padrão do vsftpd.
Basta agora iniciarmos o serviço:
debian:~# /etc/init.d/pure-ftpd restart

15.5
ProFTPd
O ProFTPd é um servidor de FTP muito seguro de configuração simplificada, que pode trabalhar com
vários métodos de autenticação e com várias configurações de recursos. Seu arquivo de configuração é o
proftpd.conf e dependendo de sua distribuição pode estar em /etc/ ou /etc/proftpd/.
A estrutura de seu arquivo de configuração é a seguinte:
- Na primeira parte estão configurados os diretórios de módulos e os módulos que serão carregados;
- Em seguida estão as configurações do servidor de FTP;
- Em seguida estão as configurações das áreas de acesso do FTP (anônimo ou não);
Caminho onde os módulos do ProFTPd estão localizados.

ModulePath /usr/lib/proftpd
Controle de acesso aos módulos.

ModuleControlsACLs insmod,rmmod allow user root
ModuleControlsACLs lsmod allow user *
Carregando módulos principais.

LoadModule mod_ctrls_admin.c
LoadModule mod_ldap.c
LoadModule mod_wrap.c
LoadModule mod_rewrite.c
LoadModule mod_load.c
LoadModule mod_ban.c
LoadModule mod_ifsession.c
Desabilitar suporte a IPv6.

UseIPv6 off
Faz verificação se cliente esta cadastrado em um DNS (perde tempo no inicio da conexão).
IdentLookups off
Nome do servidor exibido quando acessado por um cliente.

ServerName "Master of the Universe"
Servidor funciona em standalone ou inetd.

ServerType standalone
Não mostrar mensagem de boas vindas.

DeferWelcome off
Define o servidor padrão da rede.

DefaultServer on
Mostrar links simbólicos.

ShowSymlinks on

Timeout após transferência.

TimeoutNoTransfer 600
Timeoute se parar transferência.

TimeoutStalled 600
Timeout se não fizer nada no servidor.

TimeoutIdle 1200
Mensagem de boas vindas.

DisplayLogin welcome.msg
Mensagem quando o usuário trocar de diretório

DisplayChdir .message
Opções de listagem, a diretiva ListOptions pode alterar o comportamento do comando ls, fazendo de
tal forma que uma opção certa (ou opções) estejam sempre em vigor, ou sempre desativado.
ListOptions "-lhS"
Fazer CHROOT no diretório do usuário.

DefaultRoot ~
Exigir shell válido (/etc/shells).

RequireValidShel off
Porta de conexão.
Port 21
Máximo de clientes simultâneos (autenticados).

MaxInstances 30
Com qual usuário e qual grupo o proftpd será executado.

User proftpd
Group nogroup
Umask para arquivos e diretórios.

Umask 022 022
Permite sobrescrever os arquivos no ftp.

AllowOverwrite on
Logs do FTP.
TransferLog /var/log/proftpd/xferlog
SystemLog /var/log/proftpd/proftpd.log
Exemplo de área de anônimo no arquivo do ProFTPd:

Conhecendo as principais variáveis basta agora configurar o arquivo e iniciar o processo:
debian:~# /etc/init.d/proftpd restart

17- SERVIDOR HTTP
17.1
Servidor HTTP
O principal servidor de protocolo HTTP usado na atualidade é o Apache2, um servidor seguro,

extremamente configurável e com suporte a vários outros serviços através de módulos.
Criado como um fork do Apache ele rapidamente se tornou padrão para a maioria das distribuições
GNU/Linux e para uso nas empresas, o grande diferencial em relação ao Apache (1.X) é que o Apache2 é
modular tem mais foco em segurança.
Pela forma que ele é implementado, existem diferenças na localização entre distribuições Debian e Red
Hat que serão mostradas abaixo:
Debian:
Diretório de configuração:
/etc/apache2
Arquivo principal de configuração:

apache2.conf
Script de inicialização:
/etc/init.d/apache2
Nome do Daemon:
apache2
Red Hat:
Diretório de configuração:
/etc/httpd
Arquivo principal de configuração:

httpd.conf
Script de inicialização:
/etc/init.d/httpd
Nome do Daemon:
httpd
Exemplo de diretórios do Apache2 em Red Hat e em Debian:

O Debian separa as configurações que no Red Hat seriam sessões diferentes no mesmo arquivo em
arquivos diferentes.
Mesmo com nomes de arquivos de configuração diferentes as variáveis são as mesmas, vamos ver as
principais a seguir:
Define o diretório para as configurações do Apache2:

ServerRoot “/etc/apache2”
Arquivo com os número de processos do Apache2:

PidFile /var/run/apache2.pid
Tempo de desconexão (em segundos)

Timeout 120
Permite as conexões persistentes, permite o cliente fazer requisições ao mesmo servidor dentro da
conexão existente:
KeepAlive on
Máximo de requisições por conexão persistente:

MaxKeepAliveRequests 100
Tempo de desconexão das requisições persistentes (em segundos)

KeepAliveTimeout 15
Número inicial de servidores que o Apache2 irá criar:

StartServers 5
Número máximo de clientes conectados simultaneamente no Apache2:

MaxClients 200
Número máximo de requisições por processo filho:

MaxRequestPerCild 20000
Número mínimo de servidores que o Apache2 ira executar (módulo prefork):

MinSpareServers 5
Número máximo de servidores que o Apache2 ira executar (módulo prefork):

MaxSpareServers 20
Número máximo de processos simultâneos que o Apache2 irá suportar, deve ser igual ou maior que o
MaxClients (módulo prefork)

ServerLimit 200
Em que porta o Apache2 irá escutar as requisições:

Listen 80
Carregando os módulos do Apache2:

LoadModule nome_do_módulo caminho_para_o_módulo
LoadModule cgi_module /usr/lib/apache2/modules/mod_cgi.so
Como qual usuário e grupo o Apache2 será executado:

User apache
Group apache
Arquivo de controle de acesso e configuração auxiliar ao Apache2:

AccessFileName .htaccess
Como qual tipo será tratado o arquivo quando Apache2 não reconhecer:
DefaultType text/plain
Log de erro do Apache2:

ErrorLog /var/log/apache2/error.log
Log de acesso do Apache2 e seu formato:

CustomLog /var/log/apache2/access.log combined
Quais arquivos são considerados arquivos de índices para os sites hospedados pelo Apache2:
DirectoryIndex index.html index.cgi index.pl index.php
Prioridade do Apache2 na hora de exibir páginas relacionadas a idiomas:

LanguagePriority pt-BR en ca cs da de el eo es et fr he hr it ja ko ltz nl nn no pl pt ru sv zh-CN zh-TW
Tendo configurado o servidor web basta apenas reiniciar o serviço e verificar seu funcionamento:
Em sistemas baseados em Debian:

debian: ~# apache2ctl restart
Em sistemas baseados em Red Hat:
red-hat: ~# apachectl restart
17.2
VirtualHost
O Apache2 trabalha com VirtualHost, isto é, hospeda vários domínios diferentes em um único servidor.
Podem ser VirtualHost baseados em IP onde cada domínio responderá por um IP diferente, ou VirtualHost
baseado em nome, onde em conjunto com o DNS o Apache2 encaminha a requisição de um site para o
diretório correspondente mesmo que o servidor possua um único IP.
Assim cada configuração de domínio fica respondendo apenas naquele IP na porta 80.
Vejamos algumas variáveis relacionadas a domínios virtuais no Apache2:
VirtualHost baseado em nome:

NameVirtualHost *:80

Abre a tag de VirtualHost:

<VirtualHost *:80>
ServerName www.sala.intra
ServerAdmin webmaster@sala.intra
DocumentRoot /var/htdocs/sala.intra
ErrorLog /var/log/apache2/sala.intra/error.log
CustomLog /var/log/apache2/sala.intra/access.log combined
<Directory /var/htdocs/sala.intra/>
Options Indexes FollowSymlinks MultiViews
AllowOverride AuthConfig FileInfo
Order allow,deny
allow from all
</Directory>
</VirtualHost>
Onde:
ServerName – Nome do domínio;
ServerAdmin – Email do responsável pelo domínio;
DocumentRoot – Diretório onde estão as páginas deste domínio;
Directory – Esta tag define a configuração de um diretório específico;
Options – Opções que são permitidas nesse site;
AllowOverride – Define o que será permitido no arquivo .htaccess;
Order – Ordem de acesso ao site;
Para VirtualHost baseado em IP, não utilizamos a variável NameVirtualHost *:80 e utilizamos a tag
desta forma:
<VirtualHost 10.20.1.200:80>
.
.
.
</VirtualHost>
Então dentro do arquivo de configuração do Apache2, ou como faz o Debian em arquivo específico
para isso, criamos a tag VirtualHost com os dados do domínio e relemos ou reiniciamos o servidor web.
Lembrando que os diretórios apontados dentro da tag de VirtualHost devem existir antes do servidor
ser reiniciado.
17.3
Controle de Acesso
O controle de acesso e configurações adicionais é feito pelo arquivo .htaccess, onde quando ele existe
no diretório especificado e a variável AllowOverride está configurada corretamente o Apache2 lê este arquivo e
segue as configurações nele contidas.
Exemplo de arquivo .htaccess com controle de acesso por usuários e com alterações de configurações
padrão de páginas:
AuthName "Area restrita do site ..."

AuthType "Basic"
AuthUserFile "/etc/apache2/senhas"
require valid-user
DirectoryIndex directory files

IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t *.shtml include
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
AddIconByType (IMG,/icons/image.png) image/*
AddIconByType (SND,/icons/sound.png) audio/*
AddIconByType (VID,/icons/video.png) video/*
AddIcon /icons/binary.png .bin
AddIcon /icons/acquamarine-go-up.png ..
AddIcon /icons/gnome-blog.png README
AddIcon /icons/oxyviolet-folder.png ^^DIRECTORY^^
DefaultIcon /icons/gkrellm2.png
Onde:
AuthName – Texto que aparece na hora de autenticar o usuário;
AuthType – Tipo de autenticação utilizada, a mais usada é a Basic, a digest não é muito usada e muitos
clientes não a suportam;
AuthUserFile – Arquivo com as contas e senhas dos clientes;
AuthGroupFile – Arquivo com os grupos e usuários pertencentes a cada grupo;
require - Instrução para o servidor exigir alguma coisa para o acesso, pode ser:
valid-user – Qualquer usuário autenticado serve;
user user1 user2 user3 – Apenas os usuário mencionados serão aceitos;
group admin cpd – Apenas os grupos mencionados serão aceitos;
DirectoryIndex – Mesmo existindo esta diretiva no arquivo de configuração do Apache2, por ela estar
presente no .htaccess e a variável AllowOverride estar também com a opção FileInfo o servidor irá respeitar
esta variável no lugar da do arquivo.
Após configurar o arquivo e colocá-lo no diretório correto, basta criar as contas a serem autenticadas
no arquivo /etc/apache2/senhas (como no modelo acima), com o seguinte comando:
debian:~# htpasswd -c /etc/apache2/senhas user1
debian:~# htpasswd /etc/apache2/senhas user2
Onde o comando htpasswd com a opção –c cria o arquivo se ele não existe e apaga o conteúdo se ele
existir, sem a opção -c ele apenas atualiza o arquivo.
Exemplo de arquivo com as senhas de usuários, lembrando que os usuários não precisam existir no
sistema apenas no arquivo:

Basta que o arquivo .htaccess exista no diretório a ser protegido que o Apache2 irá ler seu conteúdo,
por padrão o servidor sempre tem uma diretiva visando ocultar o arquivo, mesmo quando não houver arquivo
de índice, como o exemplo abaixo:
<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>
Assim ocultando os arquivos .htaccess e .htpasswd se existirem.
17.4
Módulos
Os módulos do Apache2 são simples de ser ativados e configurados, em Debian eles possuem arquivos
específicos para carregar e para configurar o módulo, basta colocar a linha de carregamento e as linhas de
configuração dentro do arquivo do servidor web para ativá-los, por exemplo para ativar o suporte a php no
servidor faremos o seguinte dentro do arquivo de configuração:
LoadModule php5_module /usr/lib/apache2/modules/libphp5.so
<IfModule mod_php5.c>
AddType application/x-httpd-php .php .phtml .php3
AddType application/x-httpd-php-source .phps
</IfModule>
Onde a linha LoadModule tem o nome do módulo e é sempre nome_module e o caminho de onde no
sistema esse módulo se encontra.
Aberta a tag do módulo <ifModule mod_nome-do-módulo.c> basta configurar como esse módulo
deve trabalhar ou quais requisitos para o seu funcionamento e fechá-la </ifModule>.
Alguns módulos, como o do alias tem configurações mais específicas, como:
<IfModule alias_module>
Alias /icons/ "/usr/share/apache2/icons/"
<Directory "/usr/share/apache2/icons">
Options Indexes MultiViews
Order allow,deny
Allow from all
</Directory>
</IfModule>

Em distribuições baseadas em Debian, que possui arquivos separados para os módulos em

/etc/apache2/mods-available/ , temos comandos para ativar e desativar módulos sem a necessidade de alterar
o arquivo de configuração do Apache2, são eles:
Para ativar:
a2enmod nome_do_módulo
Para desativar:
a2dismod nome_do_módulo
Exemplo de arquivo de configuração do Apache2 (sem ssl):
17.5
HTTPS

Além de trabalhar com páginas pela porta 80 o servidor Apache2 também é capaz de trabalhar
servindo páginas seguras, através do protocolo SSL. Funcionando na porta 443 e trabalhando com certificados
digitais.
Os certificados digitais são como documentos emitidos por uma entidade confiável atestando a
identidade de um site, uma alusão à carteira de motorista que o órgão que a emite é confiável ao dizer que
aquela pessoa identificada tem habilidade para dirigir. Os certificados digitais são esses documento que uma
entidade confiável emite, seu browser contém várias identificações de entidades confiáveis e quando encontra
um certificados emitido por uma delas ele simplesmente aceita.Quando o browser encontra um certificado
inválido, auto assinado ou vencido, ele não abre a página ou abre uma página de aviso e deixa a critério do
usuário abrir ou não aquele site.
Portanto o uso de SSL por um site comprova a autenticidade do mesmo e pode também garantir a
troca criptografada de dados entre servidor e cliente, evitando assim que quando um formulário for preenchido
em um site, os dados trafegados pela rede possam ao ser interceptados, ser compreendidos por um atacante.
Os passos para implementar SSL no Apache2 são: instalar o módulo de SSL, alterar o arquivo de
configuração para ler e habilitar o módulo, e obter o certificado.
Utilizaremos um certificado auto assinado a fim de estudo.
 Instalando o módulo:
Em Debian e derivado o pacote apache2 já contém o suporte a SSL.
Em Red Hat:
red-hat: ~# yum install mod_ssl
 Alterando o arquivo de configuração:
Editando o arquivo de configuração incluiremos as seguintes linhas para adicionar o suporte ao SSL:
<IfModule mod_ssl.c>
SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/urandom 512
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
SSLPassPhraseDialog builtin
SSLSessionCache shmcb:/var/run/apache2/ssl_scache(512000)
SSLSessionCacheTimeout 300
SSLMutex file:/var/run/apache2/ssl_mutex
SSLCipherSuite HIGH:MEDIUM:!ADH
SSLProtocol all -SSLv2
</IfModule>
Editando o arquivo de configuração incluiremos as seguintes linhas para criar um site que utiliza SSL:
<ifModule mod_ssl.c>
<VirtualHost *:443>
ServerAdmin admin@sala.intra
ServerName www.sala.intra
DocumentRoot /var/htdocs/sala.intra-ssl

ErrorLog /var/log/apache2/sala.intra-ssl/error.log
CustomLog /var/log/apache2/sala.intra-ssl/access.log combined
<Directory /var/htdocs/sala.intra-ssl/>
Options Indexes FollowSymLinks MultiViews
AllowOverride AuthConfig
Order allow,deny
allow from all
</Directory>
SSLEngine on
SSLCertificateFile /var/htdocs/sala.intra-ssl/.cert/apache.pem
SSLCertificateKeyFile /var/htdocs/sala.intra-ssl/.cert/server.key
</VirtualHost>
</ifModule>
Como podemos ver as entradas tem que ser criadas dentro da tag de módulo do SSL e apesar de usar
VirtualHost para hospedar o site o Apache2, ainda, não cria VirtualHost baseado em nome para sites HTTPS. As
partes em negrito são as mais importantes para o site, elas indicam que o SSL vai estar ativo e quais são os
certificados utilizados.
Basta agora criar os certificados para o correto funcionamento do servidor web, o comando de
manipulação de SSL é o openssl, ele cria as chaves, requisições e certificados.
Criando as chave privada padrão RSA de 1024 bits:

debian: /var/htdocs/sala.intra-ssl/.cert# openssl genrsa -out server.key 1024
Criando a requisição de um certificado, é preciso preencher os valores de acordo com sua empresa e
site:
debian:/var/htdocs/sala.intra-ssl/.cert# openssl req -new -key server.key -out server.csr
Exemplo de dados a serem preenchido para gerar a requisição:
Criando o certificado com validade de 2 anos, a partir da requisição:

debian:/var/htdocs/sala.intra-ssl/.cert# openssl x509 -req -days 730 -in server.csr -signkey server.key -out
server.crt

No padrão X.509 o certificado é assinado com a chave pública que fica armazenada no arquivo .pem,
devendo mais tarde o certificado ser anexado no arquivo .pem:
debian:/var/htdocs/sala.intra-ssl/.cert# cp server.key apache.pem
debian:/var/htdocs/sala.intra-ssl/.cert# cat server.crt >> apache.pem
Agora temos nossa chave privada e nosso certificado auto assinado no arquivo apache.pem:
Basta reiniciar o servidor e verificar se a porta 443 está aberta:

debian:~# apachectl restart

18- SERVIDOR PROXY
18.1
SQUID
O proxy é um servidor cuja função principal não é prover nada, mas sim servir de intermediário entre
clientes e servidores web, ele é utilizado para fazer cache das páginas de internet, podendo também fazer
controle de acesso por IP, usuário, site, arquivo, etc.
Quando um usuário acessa um site através do proxy, ele verifica em seu banco de dados se o site está
armazenado em seu cache, se estiver ele entrega ao cliente a cópia armazenada em cache. Se não estiver, ele
vai à internet acessa o site desejado e enquanto entrega site ao cliente o armazena em cache, assim a próxima
consulta feita, pelo mesmo ou outro cliente, o proxy irá entregar o que está armazenado.
O principal servidor de proxy usado em Linux/Unix é o Squid, cuja configuração é feita no arquivo
squid.conf que se localiza no diretório /etc/squid.
O Squid trabalha na porta 3128/tcp e por padrão não vem com nenhuma liberação de acesso, é preciso
configurá-lo para permitir acesso por IP, nome, horário, site, etc. O Squid por padrão não é compilado com
suporte a HTTPS, fazendo apenas proxy de HTTP, pois armazenar certificados e chaves não é uma forma segura
de funcionamento, pois se o servidor tiver sua integridade comprometida, um atacante pode substituir um
certificado ou chave fazendo o cliente acreditar em uma falsa informação.
Suas configurações permitem trabalhar como proxy que é configurado no browser, ou seja ele pode
ser qualquer máquina da sua rede, até como proxy transparente, ou seja ele é executado na mesma máquina
que o roteador e não é configurado no browser.
Exemplo de arquivo de configuração do Squid, com liberação para a rede 10.20.1.0/24 e suporte
também para autenticação por usuários.

Podemos ter um proxy completamente funcional com apenas algumas linhas.
Porta de trabalho do Squid, se for proxy transparente basta anexar ao final da linha transparent:
http_port 3128
Tipo de página que não serão armazenadas em cache:

hierarchy_stoplist cgi-bin ?
Quantidade de memória RAM que será usada para cache:

cache_mem 128 MB
Tamanho máximo por objeto na memória RAM:

maximum_object_size_in_memory 8 MB
Política de substituição dos dados no cache em memória:

memory_replacement_policy lru

Política de substituição dos dados no cache:

cache_replacement_policy lru
Diretório do cache em disco do Squid, tamanho do cache, diretórios e subdiretórios do cache:

cache_dir ufs /var/spool/squid 20000 16 256
Tamanho máximo por objeto em cache:

maximum_object_size 256 MB
Porcentagem para substituição do cache em disco:

cache_swap_low 90
cache_swap_high 95
Log de acesso às páginas em disco e formato do log:

access_log /var/log/squid/access.log squid
Tabela com os tipos (mime) dos arquivos:

mime_table /usr/share/squid/mime.conf
Limite de tamanho para download de arquivos e controle de acesso:

reply_body_max_size 50331648 deny all
Email do administrador do proxy que aparece nas páginas do Squid:

cache_mgr webmaster@proxy
Programa que envia email pela linha de comando:

mail_program mail
Nome de identificação do servidor que aparece nas páginas do Squid:

visible_hostname proxy-server
Arquivo de hosts:
hosts_file /etc/hosts
Diretório onde estão as mensagens de erro do Squid:

error_directory /usr/share/squid/errors/Portuguese
18.2
Controle de Acesso
Todo a configuração que o Squid faz de acesso é por meio de acl (listas de controle de acesso) e o
controle http_access é quem decide o que é permitido (allow) ou negado (deny). As acl podem ser criadas em
qualquer ordem antes do http_access que faz referencia a ela, mas os http_access têm ordem certa para serem
criados, pois são lidos na ordem em que aparecem, e se o Squid encontra uma correspondência entre um
http_access e uma comunicação ele aplica aquele http_access e não verifica os outros posteriores.
Exemplo de controle feito pelo Squid:
acl all src all

acl localhost src 127.0.0.1/32
acl rede src 10.20.1.0/24
acl lista-negados url_regex –i “/etc/squid/negados”
acl lista-liberados url_regex –i “/etc/squid/liberados”
acl lista-downloads urlpath_regex –i “/etc/squid/downloads”

http_access deny lista-downloads

http_access allow lista-liberados
http_access deny lista-negados
http_access allow rede
http_access allow localhost
http_access deny all
Resumo das ACL’s:

- Criada uma ACL para representar todos os endereços (all);
- Criada uma ACL para a placa localhost (localhost);
- Criada uma ACL para a rede interna (rede);
- Criada uma ACL que procura expressões regulares na URL (url_regex) que aponta para um arquivo
com as URL que serão negadas (lista-negados);
- Criada uma ACL que procura expressões regulares na URL (url_regex) que aponta para um arquivo
com as URL que serão liberadas (lista-liberados), que geralmente são exceções a uma regra existente;
- Criada uma ACL que procura expressões regulares em algum ponto da URL (urlpath_regex) que
aponta para um arquivo com as extensões de arquivos que serão negados (lista-downloads);
Resumo dos HTTP_ACCESS:
- Feita a negação para todos do conteúdo da acl lista-downloads;

- Feita a liberação para todos do conteúdo da acl lista-liberados;
- Feita a negação para todos do conteúdo da acl lista-negados;
- Feita a liberação para a acl rede;
- Feita a liberação para a acl localhost;
- Feita a negação para a acl all;
Ou seja:
1 - o Squid primeiro nega para todos o conteúdo de lista-downloads, o que estiver contido naquele
arquivo será negado, caso o que está sendo testado não está no arquivo ele passa para o próximo controle;
2 - Caso o que está sendo testado se enquadre no conteúdo de lista-liberados ele vai permitir o acesso
aquele site, caso o que está sendo testado não está no arquivo ele passa para o próximo controle;
3 - Caso que está sendo testado se enquadre no conteúdo de lista-negados, ele vai negar o acesso
aqueles endereços, caso o que está sendo testado não está no arquivo ele passa para o próximo controle;
4 - Caso o que está sendo testado seja de origem da rede 10.20.1.0/24 (acl rede) será liberado o
acesso; caso o endereço de origem não seja da acl rede ele passa para o próximo controle;
5 - Caso o que está sendo testado seja de origem do endereço 127.0.0.1 (acl localhost) será liberado o
acesso; caso o endereço de origem não seja da acl localhost ele passa para o próximo controle;
6 - Caso o que está sendo testado não atenda aos critérios de nenhum http_access anterior será
negado para a acl all, que representa tudo o que não foi especificado antes.
Portando não importa a ordem em que são criadas as acl, mas sim a ordem que são criados os
http_access, assim um controle de acesso pode ser bem sucedido ou não.
Com a configuração feita e os arquivos mencionados criados é hora de iniciar o Squid, utilizaremos os
seguintes comandos para isso:
debian: ~# /etc/init.d/squid start

Para reiniciar o Squid utilizaremos:
debian: ~# /etc/init.d/squid start
Ou:
debian: ~# squid –k reconfigure
Exemplo de log de acesso do Squid:
18.3
Autenticação no Proxy
O Squid pode trabalhar como proxy autenticado, seja por usuários ou grupos. Seus métodos de
autenticação podem utilizar contas de usuários armazenadas em servidores de autenticação pam, samba, ldap,
ad, etc.
Exemplo de módulos de autenticação do Squid:

Para habilitarmos a autenticação precisamos que o Squid tenha em seu arquivo as configurações
indicando o módulo usado e quais opções, como:
auth_param basic program /usr/lib/squid/pam_auth

auth_param basic children 10
auth_param basic realm Servidor Proxy Squid
auth_param basic credentialsttl 8 hours
auth_param basic casesensitive off
A variável auth_param server para configurar a autenticação, o método basic server para todos os
tipos de clientes, já o digest não é suportado por alguns. As opções utilizadas com a variável auth_param e o
método basic são:
program – Indica o caminho do módulo de autenticação;
children – número de processos simultâneos de autenticação;
realm – texto que será exibido na caixa de autenticação;
credentialsttl – tempo de vida de uma autenticação;
casesensitive – habilita/desabilita o Squid para fazer autenticação;
Neste caso, como usamos a autenticação via PAM, basta criarmos as contas no GNU/Linux para que o
Squid consiga obter informações de autenticação. Após criarmos as entradas para definir o método de
autenticação é preciso definir a acl e os http_access, para garantir que apenas usuários autenticados obtenham
acesso à internet.
Assim sendo, teríamos no arquivo do Squid esta estrutura:
acl all src all

acl localhost src 127.0.0.1/32
acl contas proxy_auth REQUIRED
acl lista-negados url_regex –i “/etc/squid/negados”
acl lista-liberados url_regex –i “/etc/squid/liberados”

acl lista-downloads urlpath_regex –i “/etc/squid/downloads”

http_access deny lista-downloads
http_access allow lista-liberados
http_access deny lista-negados
http_access allow contas
http_access allow localhost
http_access deny all
Em relação ao que vimos no tópico anterior o Squid agora fará a liberação não pelo IP pertencer a uma
determinada rede, mas se for atendido o critério de ter um usuário válido para o proxy.
Com a autenticação podemos utilizar grupos no arquivo utilizando restrições crescentes para cada
grupo.
18.4
Relatórios
A ferramenta principal para gerar relatórios de proxy é o Sarg, ele analisa o log de acesso do proxy e
cria páginas web com as estatísticas e informações de acesso por usuários, ip, sites, downloads, horários, etc.
Seu arquivo de configuração é o sarg.conf e pode ser encontrado em:
/etc/sarg em distribuições baseadas em Red Hat.
/etc/squid em distribuições baseadas em Debian.
Suas principais variáveis são:
Idioma das páginas de relatório:

language Portuguese
Log de proxy que o Sarg irá utilizar para gerar o relatório:

access_log /var/log/squid/access.log
Título das páginas de relatório:

title "Relatorios de aceso a Internet"
Diretório onde o Sarg criará as páginas temporárias:

temporary_dir /tmp
Diretório onde serão criadas as páginas de relatórios para consulta via web:
output_dir /var/www/squid-reports
Resolver os IP para nomes de máquinas:

resolve_ip no
Resolver os IP para nomes de usuários:

user_ip no
Usuários que não aparecerão nos relatórios:

exclude_users /etc/squid/sarg.users
Hosts que não aparecerão nos relatórios:

exclude_hosts /etc/squid/sarg.hosts

Ordem de acesso na página de relatórios:

report_type topusers topsites sites_users users_sites date_time denied auth_failures downloads
Arquivo com mapeamento de máquina para usuário:

usertab /etc/squid/sarg.usertab
Extensões de arquivos que são considerados downloads:

download_suffix “zip,arj,bzip,gz,ace,doc,iso,bin,cab,com,dot,mdb,ppt,rtf,src,sys,exe,dll,mp3,avi,mpg,mpeg”
O Sarg precisa ser executado regularmente a fim de analisar o log e criar os relatórios, o comando sarg-
reports é o responsável por isso.
Exemplo de uso:
sarg-reports <opção>
Para gerar relatórios diariamente basta agendar o comando para ser executado pela crontab. Pela
linha de comando seria:
debian: ~# sarg-reports daily
Exemplos de relatórios gerados pelo Sarg:

Como as páginas de relatório ficam armazenadas no diretório /var/www/squid-reports é preciso

lembrar de rotacionar as mais antigas para que não ocupem todo o espaço em disco. Geralmente apagar neste
diretório os arquivos com mais de 90 dias de criação.

19- SERVIDOR DE EMAIL
19.1
Servidor de Email
O servidor de email é uma parte extremamente importante da comunicação pessoal e profissional, já

faz parte da rotina das pessoas confiarem em email para transmitir informações desde as mais simples e triviais
às mais importantes, inclusive para o envio de documentos.
Entender como funciona um servidor de SMTP é importante para prosseguir falando dos servidores
disponíveis em Linux.
Resumo da operação:
 Um usuário envia um email através de seu MUA (Mail User Agent), cliente de email que já está
configurado para o seu servidor de SMTP;
 O MUA envia o email para o seu servidor de SMTP, seu MTA (Mail Transport Agent), que vai verificar se
alguns requisitos foram atendidos para a mensagem ser aceita;
 Após a mensagem ser aceita o MTA verifica se ela é para entrega local ou para outro domínio;
 O MTA do remetente vai envia a mensagem para o MTA do destinatário; que faz uma série de
verificações antes de aceitar a mensagem e se for aprovadas o MDA (Mail Delivery Agent) entrega a
mensagem na caixa do usuário;
Os servidores de email geralmente compreendem programas servidores de SMTP para envio de email,
e POP/IMAP para recebimento nos programas clientes (MUA).
Veja abaixo um exemplo de mensagem trocada entre usuários:

Toda mensagem é composta por um cabeçalho (header) que contém dados como:
 Remetente;
 Destinatário;
 Identificação do servidor remetente;
 Identificação do MUA do remetente;
 Identificação da mensagem
 Identificação de anexos (se houver);
 Assunto e conteúdo da mensagem;
E também pelo corpo da mensagem (body) que é conteúdo do que foi enviado. O email foi criado para
transportar apenas caracteres ascii, ou seja, tudo que for diferente de texto plano será convertido para ascii e
depois enviado, assim fica a cargo do programa de email do cliente fazer a conversão para o formato binário
original.
Veja um email com um arquivo .doc de anexo:

Ele usa o formato base64 para fazer o encode do documento, assim o tamanho da mensagem
enquanto transmitida é bem maior que o documento original por causa dessa conversão para ascii.
Portanto mensagens de email são hoje, para muitas empresas e pessoas, o principal método de
comunicação. Seja apenas para informar algo como para transmitir pedidos, recibos, documentos e respostas
de solicitações. As provas buscam testar o conhecimento sobre alguns servidores de MTA em Linux e serviços
agregados a eles.
19.2
SENDMAIL
O Sendmail já foi o MTA mais usado na internet, seguro e robusto, mas de difícil configuração e de
combinar com outros serviços. Assim hoje ele é cobrado nas provas apenas o conhecimento de seu
funcionamento e arquivos associados a ele.
O arquivo de configuração principal do Sendmail o sendmail.cf é cheio de variáveis e expansores que

tornam seu conteúdo de difícil compreensão e de manutenção complicada. Assim todo o trabalho é feito no
arquivo sendmail.mc e depois compilado com as macros m4 para o formato do sendmail.cf.
Exemplo de arquivo sendmail.mc:

Com o arquivo configurado basta compilá-lo com a seguinte linha de comando:
debian: /etc/mail/ # m4 sendmail.mc > sendmail.cf
Após compilar o arquivo sendmail.mc a partir do exemplo acima, teremos um arquivo com mais de 741
linhas, sem contar os comentários.
O que torna mais complicado a manutenção do Sendmail são as regras com que ele trabalha, são
cheias de expansores e flags de controle que deve ser corretamente ajustadas para que o servidor funcione
corretamente. Veja abaixo exemplos de regras para o Sendmail

No exemplo acima a Rule Set 3 tem a função de realizar um préprocessamento das mensagens apenas
para retirar do cabeçalho do email o endereço do recipiente em um formato arbitrário para um formato
comum que o Sendmail possa trabalhar.
O diretório de configuração do Sendmail é o /etc/mail/ e seus principais arquivos são:
 /etc/mail/sendmail.cf - O arquivo de configuração principal do sendmail; geralmente criado

manipulado indiretamente a partir de um arquivo sendmail.mc;
 /etc/mail/access – Configuração de quem tem acesso ao servidor e quais domínios recebem e-mail, já
que o sendmail não faz relay por padrão se a rede não estiver configurada aqui não enviará email, a
esquerda no arquivo ficam os hosts/usuários e a direita as ações, que podem ser:
OK Aceita o email para entrega local;
RELAY Aceita o email para encaminhamento através deste servidor;
REJECT Rejeita o envio do email;
DISCARD Descarta o email sem gerar mensagem de erro.
 /etc/mail/aliases - Apelidos para contas, é utilizado no formato: conta: apelido,apelido,apelido
 /etc/mail/local-host-names - Lista dos hosts de quem o sendmail aceita mensagens, quais domínios
são aceitos para a máquina local;
 /etc/mail/mailertable - Tabela de entrega do mailer, direciona email vindo de fora;

 /etc/mail/virtusertable - Usuários virtuais e tabelas de domínios, pode ser usado para mapear
destinatários inválidos para uma conta válida;
 /etc/mail/host-relay - Serve para informar quem pode conectar no servidor sem autenticação
Por padrão a fila de email do Sendmail fica em /var/spool/mqueue
Algumas opções do comando do sendmail:
-bd Executar em modo daemon;

-bD Executar em modo daemon, mas não realizar fork do processo;
-bi Inicializa o banco de dados de aliases;
-bH Remover informações persistentes sobre condições de hosts;
-bh Imprimir informações persistentes sobre condições de hosts;
-bm Enviar mail;
-bp Imprimir a fila;
-bs Executar SMTP na saída padrão;
-bt Modo de teste: apenas resolução de endereços;
-bv Verificação: não aceita nem entrega mensagens;
Comandos compatíveis com o comando sendmail:

hoststat sendmail -bh
mailq sendmail -bp
newaliases sendmail -bi
purgestat sendmail -bH
smtpd sendmail -bd
19.3
POSTFIX
O servidor MTA Postfix, foi criado para ser uma alternativa simples e objetiva ao Sendmail. Assim as
configurações do Postfix são centralizadas em poucos arquivos e utiliza variáveis objetivas para sua
configuração, é o servidor usado por grandes empresas e provedores de internet. Altamente configurável e
pode trabalhar em conjunto com uma grande gama de programas.
Suas configurações ficam no diretório /etc/postfix e seus arquivos principais são:
 main.cf – Arquivo de configuração do funcionamento do servidor Postfix;
 master.cf – Arquivo de configuração dos processos (internos ou externos) utilizados pelo Postfix;
O Postfix é um MTA de configuração focada em um único arquivo, mas permite uso de arquivos
externos para funções específicas como checagem de cabeçalho, corpo da mensagem, anexos, listas de IP, listas
cinzas, listas negras, etc.
O Postfix também instala um conjunto de executáveis na máquina para auxiliar no seu funcionamento,
estes costumam ser encontrados no diretório /usr/lib/postfix e são controlados pelo arquivo master.cf.

Já seus arquivos de configuração são de simples leitura, veja exemplos abaixo de main.cf e master.cf:
As configurações no arquivo main.cf são feitas na seguinte forma: variável = valor
As principais variáveis do arquivo main.cf são:
Banner de identificação do Servidor de Email:

smtpd_banner = $myhostname ESMTP MAIL Service
Ativa/desativa o serviço de notificação de correio "biff":

biff = no
Indica que o MTA não é responsável por adicionar o domínio a um endereço:

append_dot_mydomain = no
Diretório das filas de email:

queue_directory = /var/spool/postfix
Diretório onde estão localizados os comandos do Postfix:

command_directory = /usr/sbin
Diretório de trabalho do daemon do Postfix, deve pertencer ao root:

daemon_directory = /usr/lib/postfix
Diretório de escrita dos processos do Postfix, este diretório deve pertencer ao mail_owner:

data_directory = /var/lib/postfix
Nome FQDN do MTA:

myhostname = hostname.domínio
Nome do domínio de email:

mydomain = domínio
Nome de domínio padrão que virá apos o @ do remetente.

myorigin = $mydomain
Endereços de interface de rede em que o MTA irá funcionar:

inet_interfaces = all
Protocolos em que o MTA irá funcionar:

inet_protocols = ipv4
Lista de domínios que essa maquina considera ela mesma como destino final das mensagens;
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
Lista de clientes que podem fazer relay através do MTA, máquinas que enviam email por este servidor:
mynetworks = 127.0.0.0/8, 10.20.30.0/24
Host padrão que enviará emails. Se não especificado, os emails serão enviados diretamente pelo MTA:
relayhost =
Mapas de banco de dados de apelidos usado pelo MTA para as contas:

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
A tag hash indica que esse arquivo é texto e deve ser convertido em binário antes do servidor ser
iniciado.
Caractere usado para definir uma extensão de endereço local:

recipient_delimiter = +
Caminho do arquivo de mailbox relativo ao diretório "home" do usuário:

home_mailbox = Maildir/
Comando externo para entrega de correio na mailbox:

mailbox_command =
Usuário “dono” dos processos do Postfix;

mail_owner = postfix
Tamanho da caixa de correio em bytes (0 para ilimitada) (Exemplo 500MB):

mailbox_size_limit = 524288000
Limite de tamanho das mensagens em bytes (Exemplo 12MB):

message_size_limit = 12582912
Tempo máximo que um comando externo ao Postfix pode ser executado antes de ser finalizado pelo
processo master:
command_time_limit =30m

Tempo de reenvio de mensagem em fila:

fast_flush_refresh_time = 4h
Tempo máximo de uma mensagem na fila até que ela seja considerada undeliverable:
maximal_queue_lifetime = 2d
Desabilita o comando VRFY de SMTP:

disable_vrfy_command = yes
Obriga o uso da RFC821 que no que trata do envelope das mensagens de email:
strict_rfc821_envelopes = yes
Faz com que o servidor sempre envie HELO/EHLO no inicio de uma comunicação com outro servidor:
smtp_always_send_ehlo = yes
Arquivo com filtro de cabeçalho de mensagens:

header_checks = regexp:/etc/postfix/header_checks
A tag regexp indica que o arquivo faz uso de expressões regulares:
Arquivo com filtro de corpo da mensagem:

body_checks = regexp:/etc/postfix/body_checks
Arquivo com filtro de anexos na mensagem:

mime_header_checks = regexp:/etc/postfix/mime_header_checks
Controles de Acesso aplicados no MAIL FROM da mensagem:

smtpd_sender_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_unauth_pipelining
Controles de Acesso aplicados no RCPT TO da mensagem:

smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_pipelining,
reject_unauth_destination,
reject
Algumas opções usadas para colocar a autenticação SASL debaixo de TLS:
Habilita/Desabilita o uso de SASL pelo daemon smtpd:

smtpd_sasl_auth_enable = yes
Habilita/Desabilita o uso de TLS pelo programa smtp:

smtp_use_tls = yes
Habilita/Desabilita o uso de TLS pelo daemon smtpd:

smtpd_use_tls = yes
O daemon smtpd usa apenas TLS para autenticação:

smtpd_tls_auth_only = yes

Onde está a chave usada pelo TLS:

smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
Onde está o certificado usado pelo TLS:

smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
Domínios aceitos pelo servidor SASL:

smtpd_sasl_local_domain = $myhostname
Opções de controle do SASL:

smtpd_sasl_security_options = noanonymous
Permissão de acesso a clientes com implementação não padronizada do protocolo SASL:

broken_sasl_auth_clients = yes
O arquivo master.cf é composto de 8 colunas para fazer a configuração de cada processo utilizado
pelo servidor Postfix, elas são:
service – Nome do serviço ou processo que será executado;
type – Tipo de processo, pode ser:

inet – o processo escutar em um socket TCP/IP através da rede;
fifo – o serviço irá escutar Named Pipe somente para serviços locais;
unix – o serviço irá escutar em um socket padrão unix somente para serviços locais;
private – O serviço será ou não restrito apenas ao servidor de email, processos inet não pode ser
restritos;
unprivileged – O serviço deve ser executado com privilégio de root ou apenas com as permissões do
usuário configurado na variável mail_owner;
chroot – Os processos devem ou não ser executados em ambiente chroot, lembrando que quando a

interação entre o Postfix e outros processos o ambiente chroot pode dificultar esse funcionamento;
wake up – Automaticamente “ acordar” um serviço depois de um determinado número de segundos;
process limits – número máximo de processos simultâneos de um determinado serviço;
command name + arguments – Comando e opções que serão utilizadas na execução do mesmo,
lembrando que quando uma linha se inicia com espaços ela é argumento da linha de comando acima;
Para integrar o Amavis com o Postfix precisamos criar o processo amavis dentro das configurações do
master.cf, como no exemplo abaixo:
amavis unix - - - - 2 smtp

-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
127.0.0.1:10025 inet n - - - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
-o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_bind_address=127.0.0.1
Com isso o processo Amavis que é usado para integrar o Postfix com serviços de AntiSpam e Antivírus
para incrementar as checagens e a segurança do servidor e evitar problemas para os clientes.
Após configurar ou fazer alteração em qualquer arquivo do Postfix devemos reiniciá-lo. Para verificar
as portas abertas para o serviço usamos o netstat:
19.4
Ações do Postfix
O Postfix trás algumas formas de checagens de mensagens mencionadas anteriormente, vamos falar
um pouco sobre elas e suas vantagens. A checagem de mensagens geralmente utiliza expressões regulares para
filtrar informações e tomar uma decisão com a mensagem, quando um padrão é encontrado Postfix pode
ignorar, rejeitar, marcar, etc. Algumas ações possíveis em checagens:
 DISCARD texto opcional

Avisa a entrega e silenciosamente descarta a mensagem, se especificado registra o texto, se não
apenas uma mensagem genérica no log.

Exemplo:
/^From: .*promocao@dominiosujo\.com\.br>/ DISCARD Este domínio so envia SPAM
 HOLD texto opcional

Põe a mensagem na fila de retidas e inspeciona a próxima linha, a mensagem permanece ali até
que alguém a apague ou force a entrega.
Exemplo:
/^Subject: *([Ii]mportante|[Dd]esconto|[Oo]ferta)/ HOLD Mensagem retida para analise
 REDIRECT usuário@dominio
Faz o redirecionamento da mensagem para o endereço especificado.
Exemplo:
/^TO: cpd@dominio\.com\.br>/ REDIRECT suporte@dominio.com.br
 REJECT texto opcional

Rejeita a mensagem e responde com o texto opcional ou com uma mensagem genérica.
Exemplo:
/Received: from speedy(terra|uol)\.com\.br/ REJECT Nada de xDSL aqui
 WARN texto opcional

Faz log da mensagem com o texto opcional ou com a mensagem genérica.
Exemplo:
/^\s*Content-(Disposition|Type).*name\s*=\s*"?(.+\.(zip))"?\s*$/ \ WARN ZIP em anexo
Essas checagens trazem a capacidade de personalizar o comportamento do servidor, onde por

exemplo, um domínio que não consta em uma blacklist mas que o administrador já identificou, pode fazer um
filtro para ele. Uma série de mensagens com uma determinada frase em seu corpo (body) pode ser
redirecionada para um conta específica. Esse tipo de ação é muito comum nos arquivos: header_checks,
body_checks,mime_header_checks.
A checagem pode ser feita dentro das restrições de acesso, como por exemplo ao usar uma RBL para
negar acesso a domínios listados em blacklists e precisar fazer uma exceção a um domínio negado. No arquivo
consta a lista de domínios a serem liberados e a ação OK. Ito pode ser posto com a checagem de clientes em
smtpd_client_restrictions por exemplo:
check_client_access hash:/etc/postfix/exceptions-rbl
E no dentro do arquivo o seguinte conteúdo:

domínio-exceção.com.br OK

19.5
Comandos do Postfix
O Postfix possui vários comandos para gerenciamento de mensagens, serviços e filas e conhecê-los não
apenas faz parte do conhecimento para a prova, mas também do conhecimento para administrar corretamente
um servidor de email.
POSTCONF
O comando postconf é usado para, entre outras coisas, manipular o arquivo main.cf e lidar com a
opções do Postfix. Exemplos de uso do comando:
Mostra as opções usadas pelo Postfix com seus valores default (incluindo as que não tem valor):
postconf -d
Esta opção é útil caso o administrador esqueça alguma opção geralmente utilizada e qual seu valor
padrão, ele possa verificá-la de forma rápida.
Mostra as opções usadas pelo Postfix no arquivo main.cf:

postconf -n
Exemplo:
Esta opção é útil caso o administrador precise verificar de forma rápida as opções do main.cf.
Mostras as tabelas de pesquisa suportadas pelo Postfix:

postconf -m
Mostra os tipos de plugin de servidor SASL disponíveis:

postconf -a
Especifica o diretório de configuração do Postfix, caso não esteja usando o diretório padrão:
postconf –c <caminho_do_diretório>
Edita as opções do arquivo main.cf, se a opção existe ele altera e se não existe ele cria, a configuração

a ser alterada deve vir entre ´ ´ (apóstrofos):
postconf -e ´opção = valor´
Um exemplo de uso é inserindo no arquivo do Postfix duas linhas para criar o processo do Amavis:
debian: ~# postconf -e 'content_filter = amavis:[127.0.0.1]:10024'
debian: ~# postconf -e 'receive_override_options = no_address_mappings'
POSTQUEUE
O comando postqueue gerencia a fila de mensagens.
Mostra a fila de mensagens (o mesmo que o comando mailq):

postqueue -p
Exemplo:
Força a entrega de uma mensagem em específico na fila:

postqueue -i <queue_id>
Exemplo:
debian: ~# postqueue -i 4E81E77393
Força a entrega de todas as mensagens pendentes na fila:

postqueue -f
Força a entrega de todas as mensagens pendentes na fila, pertencentes a um determinado domínio:

postqueue –f <domínio>
POSTALIAS
O comando postalias serve para gerar a base de dados de apelidos para as contas de email (aliases),
geralmente ela é criada no arquivo /etc/aliases e gerado o binário a partir dele(como no comando newaliases),
a sintaxe do arquivo de apelidos é:
apelido: conta,conta,conta,...
Após editar o /etc/aliases com os apelidos e respectivas contas basta compilá-lo com o postalias. Veja
o exemplo:

/etc/aliases
suporte: user1,administrador2,usuario@outrodominio.com.br
Agora basta executar o comando:
debian: ~# postalias /etc/aliases
POSTSUPER
O comando postsuper manipula as mensagens nas filas, as suas opções de uso são:
Colocando uma ou mais mensagens em espera (HOLD):

postsuper –h <queue_id>
Exemplo:
debian: ~# postsuper -h 4E81E77393
Libera uma mensagem colocada em espera (HOLD):

postsuper –H <queue_id>
Exemplo:
debian: ~# postsuper -H 4E81E77393
Remove uma mensagem da fila:

postsuper -d <queue_id>
Exemplo:
debian: ~# postsuper -d 4E81E77393
Remove todas as mensagens da fila:

postsuper -d ALL
Faz um purge na nos arquivos temporários da fila, que podem ser sobras de um crash no sistema ou no
postfix:
postsuper -p
Verifica a estrutura das filas e repara a fila caso exista algum problema:
postsuper -s
Recoloca a mensagem na fila, geralmente usamos quando queremos pegar uma mensagem e enviar
imediatamente:
postsuper -r <queue_id>
Exemplo:
debian: ~# postsuper -r B394E75439
POSTMAP
O comando postmap é usado para compilar qualquer mapeamento de arquivo feito dentro do Postfix
utilizando a tag hash.
postmap <caminho_do_arquivo_mapeado>
Exemplo
debian: ~# postmap /etc/postfix/client_acess

POSTCAT
O comando postcat visualiza uma mensagem específica da fila:
postcat –q <queue_id>
Primeiro localize o ID da mensagem com o postqueue depois visualize com o postcat.
Então visualize com o postcat:
18.6
Servidores POP/IMAP
Os servidores de SMTP são responsáveis pelo envio de mensagem entre cliente e servidor (quando a
mensagem vai para outro cliente do mesmo domínio), e servidor e servidor (quando a mensagem pertence a
um cliente de outro domínio).
Para o cliente poder ler ou receber suas mensagens é preciso que haja um servidor de protocolo POP3
ou IMAP para fazer o serviço. Isto é feito geralmente para que o cliente possa através de seu cliente de email

(MUA), como Thunderbird, Outlook entre outros, poder ler confortavelmente suas mensagens.
Vejamos um pouco dos dois servidores cobrados na prova e no mercado.
18.6.1
COURIER
O servidor Courier é um dos mais usados daemons de POP/IMAP, sua configuração fica centralizada
em /etc/courier e seus arquivos de configuração para as configurações de POP, IMAP e autenticação são
separados.
Podemos ver que os arquivos mantém um padrão nas nomeclaturas:

 pop3d e imapd – Arquivos de configuração do Courier para os respectivos protocolos;
 pop3d-ssl e imap3d-ssl – Arquivos de configuração do Courier para os respectivos protocolos

com suporte a SSL;
 pop3d.cnf e imapd.cnf – Arquivos de configuração para gerar os Certificados SSL;
 pop3d.pem e imap3d.pem – Os respectivos Certificados gerados e assinados com as

configurações específicas;
 authdaemonrc – Arquivo principal de métodos de autenticação usado pelo Courier;
 authldaprc – Arquivo de configuração de autenticação do Courier em serviços de diretório

LDAP;
 authmysqlrc – Arquivo de configuração de autenticação do Courier em banco de dados

MySQL;
Podemos ver abaixo o conteúdo do diretório e as portas utilizadas pelos serviços:

Vejamos abaixo um exemplo de arquivo de configuração de IMAP sem os comentários:
Suas principais variáveis são:
Endereço em que o servidor irá escutar as requisições:

ADDRESS=0
Porta padrão para o funcionamento do servidor:

PORT=143
Número máximo de processos simultâneos que o servidor irá executar:

MAXDAEMONS=40
Número máximo de conexões simultâneas do mesmo IP:

MAXPERIP=20
Domínio padrão para os emails entregues por este servidor:

DEFDOMAIL=”@sala.intra”
Ativa ou não o serviço de IMAP por padrão:

IMAPDSTART=YES
Localização dos emails no padrão Maildir no diretório dos usuários:

MAILDIRPATH=Maildir
18.6.2
DOVECOT
O Dovecot é um servidor POP/IMAP criado visando simplicidade e segurança, ele trabalha com vários
mecanismos de autenticação e banco de dados de contas, sendo assim robusto e flexível em configuração. Ele
utiliza uma linguagem de filtro chamada Sieve que pode ser usada para integrar com outros serviços e até criar

conectores com outros programas.
Suas configurações ficam no diretório /etc/dovecot, ele utiliza um arquivo para configurar todos os
serviços e usa arquivos de configuração separados para a autenticação em alguns métodos, como LDAP, SQL.
Segue abaixo um exemplo de configuração do Dovecot no arquivo dovecot.conf com POP/IMAP

utilizando autenticação shadow via PAM.
protocols = imap pop3

listen = *
disable_plaintext_auth = no
log_path = /var/log/dovecot.log
info_log_path = /var/log/dovecot-info.log
ssl_disable = yes
login_dir = /var/run/dovecot/login
login_chroot = yes
login_user = dovecot
mail_location = maildir:~/Maildir
protocol imap {
login_executable = /usr/libexec/dovecot/imap-login
mail_executable = /usr/libexec/dovecot/imap
login_greeting_capability = yes
}
protocol pop3 {
login_executable = /usr/libexec/dovecot/pop3-login
mail_executable = /usr/libexec/dovecot/pop3
pop3_enable_last = no
}
protocol lda {
postmaster_address = postmaster@sala.intra
}
auth_executable = /usr/libexec/dovecot/dovecot-auth
auth_process_size = 256
auth_cache_ttl = 3600
auth_verbose = yes
auth_debug = yes
auth_debug_passwords = yes
auth default {
mechanisms = plain login
##########################
passdb shadow {
args = blocking=yes
}
userdb passwd {
args = /etc/passwd
}
##########################
user = root
ssl_require_client_cert = no
}
dict {
}
plugin {
}

As principais variáveis são:
Os tipos de protocolos que o servidor irá usar:

protocols = imap pop3
Em quais endereços o servidor irá escutar as requisições:

listen = *
Desabilita autenticação em texto plano:

disable_plaintext_auth = no
Desabilita o uso de SSL nos protocolos (imaps e pop3s):

ssl_disable = yes
Usuário que irá ser responsável pelo serviço de login:

login_user = dovecot
Localização e tipo das Mailboxes:

mail_location = maildir:~/Maildir
As seções de protocolo configuram variáveis exclusivas do protocolo em questão, imap, pop3 e lda
(local delivery agent, protocolo de entrega local do próprio Dovecot com suporte a scripts Sieve), autenticação,
etc.
O Dovecot pode ser usado como serviço de autenticação SASL para o próprio Postfix no lugar do Cyrus
SASL, como no exemplo abaixo com um trecho do Dovecot sobre autenticação SASL no dovecot.conf:
auth default {
mechanisms = plain login
passdb pam {
}
userdb passwd {
}
socket listen {
client {
# Assuming the default Postfix $queue_directory
path = /var/spool/postfix/private/auth
mode = 0660
# Assuming the default Postfix user and group
user = postfix
group = postfix
}
# deliver and some other programs need also auth-master:
#master {
# path = /var/run/dovecot/auth-master
# mode = 0600
#}
}
}
Segue abaixo o trecho do Postfix alterado para que ele utilize o SASL do Dovecot:
smtpd_sasl_type = dovecot
# Deve ser o caminho completo ou pelo menos o relativo a variável $queue_directory
# Em Debian e derivados o Postfix é configurado para ser executado em chroot por padrão, portanto é melhor

deixar a variável como está abaixo:

smtpd_sasl_path = private/auth
# As variáveis padrão para habilitar o SASL:
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
Veja abaixo um exemplo de arquivo dovecot.conf sem os comentários:
19.7
LOG
Os logs do servidor de Email ficam registrados no diretório /var/log e são registrados pelo recurso mail,
seu principal log é o /var/log/mail.log, nele fica contida toda informação de cada mensagem que passa pelo
servidor de email, até seu direcionamento para outro servidor ou sua entrega na caixa do usuário.
Veja abaixo um exemplo do arquivo mail.log:


20- FIREWALL
20.1
IPTABLES
Desde o Kernel 2.4 o Firewall do Linux tem sido o Iptables, ele é um conjunto de implementações do
Kernel e um aplicativo para gerenciamento das regras.
O mais importante sobre o Iptables não é saber seus comandos, mas como ele entende e processa as
comunicações, assim mesmo que não lembremos algum comando (o man resolve isso), construiremos bons
Firewalls.
Algumas características do Iptables o fazem ser robusto na segurança e flexível em configurações,

como por exemplo o fato de ele ser statefull firewall, ou seja um firewall que faz controles baseado no status da
conexão, ele pode lidar com redirecionamento de endereços, análise de pacotes incluindo por conteúdo, entre
outras coisas.
20.2
ESTRUTURA DO IPTABLES
Como o nome diz o Iptables é constituído por tabelas, elas são os lugares onde criamos as regras que
são de um determinado tipo. As tabelas do Iptables são:
 Filter – Tabela de filtros, usada para criar regras baseadas em portas ou endereços;
 Nat – Tabela de tradução de endereços, usada para reescrever endereços de entrada, saída e
mascaramento de endereços para compartilhamento de Internet;
 Mangle – Tabela de marcação e alteração de pacotes, usada para inspecionar pacotes por conteúdo,
para marcar pacote no cabeçalho IP;
Essas tabelas agregam regras em locais específicos chamados cadeias, ou chains, que geralmente são
divididas de acordo com a origem, destino ou caminho do pacote.
As chains são:
 INPUT – Cadeia de entrada no iptables, relacionada a comunicações que se destinam à máquina onde
as regras são inseridas;
 OUTPUT – Cadeia de saída do iptables, relacionada a comunicações que partem da máquina firewall;
 FORWARD – Cadeia de passagem, relacionada a comunicações que passam pelo firewall, mas não são
destinadas a ele;
 PREROUTING – Cadeia de pré roteamento, relacionada a comunicações que estão entrando no firewall
e ainda não foram direcionadas para nenhuma cadeia;
 POSTROUTING – Cadeia de pós roteamento, relacionada a comunicações que estão saindo do firewall
e já passaram por outras cadeias;
Quando inserimos regras em uma cadeia, nós temos que definir uma ação para ela, o Iptables possui
algumas ações padrão e elas são:

 ACCEPT – Aceitar o pacote;
 REJECT – Rejeita o pacote, mas envia um pacote icmp do tipo destino inalcançável de volta para quem
enviou o pacote;
 DROP – Descarta o pacote e não envia nenhum retorno;
 LOG – Faz registro daquele pacote nos logs do Kernel;
20.3
CADEIAS DO IPTABLES
Veremos abaixo alguns exemplos de como as comunicações são tratadas quando o Iptables as
manipula, assim ao entender como as comunicações se processam, criar regras se torna mais simples.
Cada cadeia tem um função específica de acordo com a tabela em que está trabalhando, assim sendo
ela pode pertencer a mais de uma tabela, por exemplo, a cadeia INPUT na tabela filter não tem a mesma função
que a INPUT na tabela mangle.
As tabelas utilizam as seguintes cadeias:
Tabela filter: INPUT, OUTPUT, FORWARD;
Tabela nat: PREROUTING, POSTROUTING, OUTPUT;
Tabela mangle: INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING;

Vejamos na figura abaixo um resumo de como funciona a tabela filter em relação a que cadeia desta
tabela devemos inserir uma regra, assim podemos saber que tipo de comunicação estamos lidando para poder
criar a regra de acordo com o Firewall ser servidor ou cliente de uma comunicação.
Vejamos:
Na cadeia de INPUT podemos ter os seguintes tipos de comunicação:
 Requisição para o Firewall – O Firewall é provedor de um serviço;
 Resposta para o Firewall – O Firewall é cliente de um serviço;
Na cadeia de OUTPUT podemos ter os seguintes tipos de comunicação:
 Requisição do Firewall – O Firewall é cliente de um serviço;
 Resposta do Firewall – O Firewall é provedor de um serviço;

Na cadeia de FORWARD podemos ter os seguintes tipos de comunicação:
 Requisição da Rede Interna p/Internet;
 Resposta da Internet p/Rede Interna;
Sabendo se localizar em relação as comunicações e sabendo o papel de cada cadeia dentro da

manipulação de pacotes do Firewall o próximo passo é conhecer a estrutura da comunicação dentro do Iptables
independente de qual tabela estamos lidando.
Conhecer como as cadeias tratam o pacote quando entra no firewall para um determinado destino,
quando sai do firewall ou quando ele tem sua origem ou destino alterado, é muito importante para a
construção correta das regras.
Por exemplo, como uma comunicação feita de uma máquina da Rede Interna feita para um processo
de Servidor Web sendo executado no Firewall seria tratada:
Entendendo:
 O pacote entra no firewall (independente de por qual interface de rede) é tratado na cadeia de
PREROUTING, então são verificadas as regras naquela cadeia para ver se alguma serve para aquele
pacote. Se servir o iptables a executa, se não ele manda o pacote para a próxima cadeia, como é para
um serviço local do firewall a cadeia é INPUT;
 Na cadeia INPUT o pacote é testado para cada regra existente na cadeia, se for encontrada uma regra
que sirva para o pacote ela é executada, se não o iptables trata o pacote com a Política Padrão da
cadeia (Policy) que foi alterada para DROP, ou seja, se não existir uma regra que sirva para o pacote
ele será descartado. Como existe uma regra (na tabela filter) permitindo ele vai ser enviado para o
serviço local apropriado;
 Após ser tratado pelo serviço local o serviço gera uma resposta para o cliente, esta resposta sai pela
cadeia de OUTPUT (saída do firewall) e como ela não tem regras e sua Política Padrão (Policy) não foi
alterada (de ACCEPT para DROP) ele deixa passar;
 Finalmente ao sair da máquina o pacote de resposta gerado no serviço passa pela cadeia de
POSTROUTING e se não houve nenhuma regra que se enquadre no pacote o iptables o envia de volta
para o endereço do cliente;
Vejamos como é feito o tratamento de um pacote que parte da Rede Interna para Internet através de
nosso Firewall e como ele é tratado.

Veja:
Entendendo:
PREROUTING, então são verificadas as regras naquela cadeia para ver se alguma serve para aquele
pacote. Se servir o iptables a executa, se não ele manda o pacote para a próxima cadeia, como é para
um endereço que não é do firewall a cadeia é FORWARD;
 Na cadeia FORWARD (na tabela filter) o pacote é testado para cada regra existente na cadeia, se for
encontrada uma regra que sirva para o pacote ela é executada, se não o iptables trata o pacote com a
Política Padrão da cadeia (Policy) que foi alterada para DROP, ou seja, se não existir uma regra que
sirva para o pacote ele será descartado. Como existe uma regra permitindo ele vai ser enviado para o
endereço do servidor de destino;
 Ao ser envido para o seu destino, o pacote de passa pela cadeia de POSTROUTING, como ele foi
gerado com um IP inválido (por uma máquina da Rede Interna), tem que existir uma regra (na tabela
nat) que faça a troca do endereço de origem pelo endereço válido de Internet usado pelo Firewall;
A cadeia de POSTROUTING, na tabela nat, é usada geralmente para alterar o endereço de origem de
uma comunicação, utilizando com ações como MASQUERADE ou SNAT, é usada geralmente para
compartilhamento de Internet.
A cadeia de PREROUTING, na tabela nat, é usada geralmente para alterar o endereço de destino de
uma comunicação, utilizando ações como DNAT ou REDIRECT, é usada geralmente para publicação de
servidores que se encontram na Rede Interna na Internet.
Vejamos um exemplo de uso da cadeia de PREROUTING ao fazermos um redirecionamento de uma

comunicação de passagem (FORWARD) para um serviço local do Firewall (PROXY):

Entendendo:
PREROUTING (na tabela nat) então são verificadas as regras naquela cadeia para ver se alguma serve
para aquele pacote. O pacote inicialmente é da Rede Interna para a Internet (FORWARD), mas uma
regra na PREROUTING faz o redirecionamento para a cadeia de serviços locais (INPUT);
 Na cadeia INPUT (na tabela filter) o pacote é testado para cada regra existente na cadeia, se for
encontrada uma regra que sirva para o pacote ela é executada, se não o iptables trata o pacote com a
Política Padrão da cadeia (Policy) que foi alterada para DROP, ou seja, se não existir uma regra que
sirva para o pacote ele será descartado. Como existe uma regra permitindo ele vai ser enviado para o
serviço local apropriado (PROXY);
 Após ser processado pelo serviço o proxy envia a solicitação para o site correspondente através da
cadeia OUTPUT e sai do firewall pela PREROUTING;
A mesma idéia é usada quando precisamos publicar um servidor que está em uma DMZ para ser
acessado pela Internet, usamos a cadeia PREROUTING na tabela nat para redirecionar todo o tráfego de uma
determinada porta, ou de um determinado IP do firewall para alguma máquina da DMZ, e mascaramos a saída
daquela máquina, na cadeia de POSTROUTING, com o mesmo IP de entrada.
Assim como conhecer as tabelas e cadeias é requisito obrigatório para entender como se processam as
comunicações, conhecer o comando iptables e suas opções é o que complementa o conhecimento das tabelas.
20.4
COMANDO IPTABLES
A forma de manipular as regras é utilizando o comando iptables. Ele cria, altera e remove as regras das
tabelas e suas respectivas cadeias.
A estrutura do comando é:
iptables –t <tabela> <opções> <regra>
Sendo a tabela filter a tabela padrão, podemos até omitir sua especificação da linha de comando.
Primeiro passo para criar um firewall é saber como estão as tabelas e as cadeias. O iptables por padrão
não cria nenhum tipo de regra e não tem um arquivo específico de configuração. Os programas de firewall que
as distribuições trazem consigo é que já criam regras por padrão e possuem algum arquivo específico de
configuração. Como o nosso foco é o iptables vamos lidar com ele em sua forma padrão de uso, por linha de

comando.
Veja abaixo a tabela filter e suas cadeias:
Veja abaixo a tabela nat e suas cadeias:
Veja abaixo a tabela mangle e suas cadeias:
Como podemos ver, as tabelas do iptables vêm sem nenhuma regra e a política padrão é ACCEPT.
Assim vamos definir quais serviços serão permitidos para entrada e para passagem no firewall para começar a
criar nossas regras.
Os principais comandos do iptables são:
 -P – Define a política padrão da cadeia (policy);
 -A – Adiciona um regra a um cadeia (append);

 -I – Insere uma regra em uma posição na cadeia (insert);
 -D – Apaga uma determinada regra de uma cadeia (delete);
 -F – Apaga todas as regras de uma cadeia (flush);
 -N –Cria uma nova cadeia (new);
 -X – Apaga uma cadeia que foi criada (exclude);
Os principais parâmetros do iptables são:
 -i – Interface de entrada (input interface);
 -o –Interface de saída (output interface);
 -p – Protocolo (protocol);
 -s – Origem (source);
 -d – Destino (destination);
 --sport – Porta de origem (source port);
 --dport – Porta de destino (destination port);
 -j – Ação a ser tomada com a regra (jump);
Primeiro alterando a policy para DROP das cadeias de INPUT e FORWARD:
debian:~# iptables –t filter –P INPUT DROP

Ou:
debian:~# iptables –P INPUT DROP
debian:~# iptables –P FORWARD DROP
Criando uma regra para liberar toda comunicação de entrada para a placa loopback:
debian:~# iptables –A INPUT –i lo –j ACCEPT
Criando uma regra para permitir acesso de resposta de ping feita pelo firewall:
debian:~# iptables –A INPUT –p icmp --icmp-type echo-reply –j ACCEPT
Criando uma regra para o firewall aceitar conexões na porta 53 udp vindas da rede interna:
debian:~# iptables –A INPUT –p udp –s 10.20.1.0/24 --dport 53 –j ACCEPT
Criando uma regra para o firewall aceitar conexões na porta 67 e 68 udp:
debian:~# iptables –A INPUT –p udp –i eth0 --dport 67:68 –j ACCEPT
Criando uma regra para o firewall aceitar conexões na porta 22 tcp:

debian:~# iptables –A INPUT –p tcp --dport 22 –j ACCEPT
Criando uma regra para o firewall aceitar conexões na porta 3128 tcp vindas da rede interna:
debian:~# iptables –A INPUT –p tcp –s 10.20.1.0/24 --sport 1025: --dport 3128 –j ACCEPT
Criando uma regra para o firewall, como cliente, ter suas respostas aceitas baseadas no status da
conexão (statefull firewall):
debian:~# iptables –A INPUT –m state --state established,related –j ACCEPT
Criando regras de saída na cadeia de FORWARD para portas 25, 110, 143, 443, 1863, 3389:
debian:~# iptables –A FORWARD –p tcp –s 10.20.1.0/24 --sport 1025: --dport 25 –j ACCEPT

Deveria fazer uma regra de entrada na cadeia de FORWARD para cada regra acima, como no exemplo
abaixo:
debian:~# iptables –A FORWARD –p tcp –d 10.20.1.0/24 --dport 1025: --sport 25 –j ACCEPT

Mas como feito na cadeia de INPUT, utilizamos uma regra de retorno baseada no status da conexão:
debian:~# iptables –A FORWARD –m state --state established,related –j ACCEPT
Assim esta regra substitui todas as outras regras de retorno.
Para fazer proxy transparente iremos redirecionar (tabela nat) as comunicações da porta 80 (http),
vindas da rede interna, para a porta 3128 (squid):
debian:~# iptables –t nat –A PREROUTING –p tcp –s 10.20.1.0/24 --sport 1025: --dport 80 –j REDIRECT --to-
port 3128
Criamos finalmente a regra de NAT para mascarar o endereço de saída da rede 10.20.1.0/24 com o
endereço fornecido pelo provedor 200.200.200.200
debian:~# iptables -t nat -A POSTROUTING -s 10.20.1.0/24 ! -d 10.20.1.0/24 -j SNAT --to-source

200.200.200.200
Para marcar um pacote na tabela mangle (para uso com programas de QOS,por exemplo):
debian:~# iptables -t mangle -A FORWARD -p tcp --sport 443 -j MARK --set-mark 1
Após criar todas essas regras, basta salvá-las com o comando iptables-save que salva todas as regras
que estão em memória em um arquivo, como no exemplo abaixo:

debian:~# iptables-save > regras.ipt
Veja um exemplo do arquivo regras.ipt:
Após as regras salvas basta criar um script de inicialização para elas ou utilizar um script qualquer para
carregar uma linha com:
debian: ~# iptables-restore regras.ipt
Assim as regras do arquivo irão substituir todas as regras que estiverem em memória.
Para carregar sempre as regras na inicialização basta criar um script como o abaixo e carregar as regras
no arquivo /etc/firewall/regras.ipt:
debian:~# vi /etc/init.d/firewall.sh
#!/bin/bash
IPT=$(which iptables)
IPTR=$(which iptables-restore)
fire_start() {
# Carrega as regras de Firewall ---------------------------------------
echo -ne "Ativando o Firewall ..."
$IPTR /etc/firewall/regras.ipt
#----------------------------------------------------------------------
}
# Função que para o firewall: limpa as regras da filter e volta a chain INPUT OUTPUT FORWARD
# para ACCEPT, limpa as regras da tabela nat e mangle.
fire_stop() {

echo -e $ERR"Parando o Firewall..."$NORMAL

$IPT -F
$IPT -t nat -F
$IPT -t mangle -F
$IPT -X
$IPT -X -t nat
$IPT -Z
$IPT -F INPUT
$IPT -F OUTPUT
$IPT -F POSTROUTING -t nat
$IPT -F PREROUTING -t nat
$IPT -P INPUT ACCEPT
$IPT -P FORWARD ACCEPT
$IPT -P OUTPUT ACCEPT
}
fire_restart() {
fire_stop
sleep 1
fire_start
}
case "$1" in
'start')
fire_start
;;
'stop')
fire_stop
;;
'restart')
fire_restart
;;
*)
echo "Use: /etc/init.d/rc.firewall (start|stop|restart)"
esac
#####################FIM DO SCRIPT##################
Agora basta criar os links simbólicos para inicialização e deixar que o sistema limpe as regras ao
desligar ou reiniciar a máquina e carregue quando iniciar em modo multiusuário.

21- AUTENTICAÇÃO PAM
21.1
O QUE É O PAM
O PAM (Pluggable Authenticated Modules) é um pacote criado para compartilhar bibliotecas de

autenticação entre programas. Inicialmente um programa deveria ser compilado com um determinado método
de autenticação para poder utilizá-lo. Assim quando um programa autentica nos arquivos do Linux (/etc/passwd
e /etc/shadow) ele deve vir compilado com esse suporte, para mudar o método de autenticação é necessário
recompilar o programa para que ele compreenda o novo método.
O PAM torna isso desnecessário, quando o programa é compilado com suporte ao PAM, basta
adicionar um novo módulo para o método de autenticação desejada e configurar o PAM para utilizá-lo. Assim o
programa irá utilizar o novo método sem que haja necessidade de alterar seu código ou recompilá-lo. Podemos
assim atualizar todas as bibliotecas de autenticação e adicionar novos métodos sem sequer mexer nos
programas.
O PAM anteriormente utilizava o arquivo /etc/pam.conf para suas configurações, atualmente elas
ficam no diretório /etc/pam.d/ , cada arquivo é responsável pelo controle de um serviço, exceto os arquivos
common-auth, common-account, common-session, common-password que são arquivos gerais de
configuração do PAM.
21.2
MÓDULOS E CONTROLES DO PAM
O PAM é composto por módulos que são referentes aos tipos de acessos que o PAM pode controlar,
são eles:
 account - Fornecer tipos de verificação da conta de serviço: a senha do usuário expirou, é este usuário
acesso permitido para o serviço solicitado?
 auth - autenticar um usuário e configurar as credenciais do usuário. Normalmente isso é através de

requisições desafio-resposta que o usuário deve satisfazer: se você é quem diz ser, por favor digite sua
senha. Nem todas as autenticações são deste tipo, existem esquemas de autenticação baseada em
hardware (tais como o uso de smart cards e dispositivos biométricos), com os módulos adequados,
estes podem ser substituídos sem problemas por mais abordagens padrão para autenticação - tal é a
flexibilidade do Linux-PAM.
 password - a responsabilidade desse grupo é a tarefa de atualizar os mecanismos de autenticação.

Normalmente, estes serviços são fortemente acoplados aos do grupo de autenticação.
 session - esse grupo de tarefas tem que cobrir coisas que devem ser feitas antes de um determinado
serviço começar e após ele ser finalizado. Essas tarefas incluem a manutenção das trilhas de auditoria
e de montagem do diretório home do usuário. O grupo de gestão de sessão é importante porque
fornece um gancho de abertura e fechamento de módulos para afetar os serviços disponíveis para um
usuário.
Os módulos do PAM são regidos por controles, ou seja, ações executadas em caso de sucesso ou não
de um módulo. Os controles são muito importantes na hora de definir o acesso ao recurso desejado do PAM.
Os controles são:

 required – Uma falha em um módulo com este controle não será mostrado ao usuário até que todos
os módulos do mesmo tipo sejam executados.
 requisite – Uma falha em um módulo com este controle será retornada direto a aplicação,
independente de outros módulos configurados. Usado para evitar que o usuário tente colocar sua
senha quando há uma falha de segurança no meio testado.
 sufficient - Uma falha em um módulo com este controle não implica em falha de autenticação como
um todo. Se houver uma falha o módulo o próximo da classe é executado, não havendo próximo,
então a classe retorna com sucesso. Mas se o módulo terminar com sucesso, então os módulos
seguintes dessa classe não serão executados.
 optional – Uma falha em um módulo com este controle não influencia o resultado da autenticação,
apenas se os módulos anteriores a ele não apresentem um resultado definitivo.
Então nós temos a seguinte estrutura:
<módulo> <controle> <argumentos>
O conteúdo do diretório /etc/pam.d
Alguns arquivos do PAM:
Um exemplo de arquivo do comando su:

Podemos ver as configurações para os módulos do PAM e seus controles e ao final a inclusão dos
arquivo common referentes ao serviço do su.


Treinamento Linux Network Administrator

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Treinamento Linux Network Administrator

Enviado por

Direitos autorais:

Formatos disponíveis

MANUAL DE TREINAMENTO LINUX NETWORK ADMINISTRATOR

MANUAL DE TREINAMENTO M.CURY

MANUAL DE TREINAMENTO M.CURY

CARACTERÍSTICAS DO LINUX NETWORK ADMINISTRATOR:

 Instalar e configurar os principais serviços utilizados nas empresas;

MANUAL DE TREINAMENTO M.CURY

01- Processo de Inicialização do Linux 05

MANUAL DE TREINAMENTO M.CURY

1- PROCESSO DE INICIALIZAÇÃO DO LINUX

Abaixo segue um resumo de como é iniciado o computador:

 É iniciado o processo INIT que carrega o RUNLEVEL corretamente configurado no /etc/inittab;

 No final da execução do INIT, é carregado geralmente o primeiro comando interativo

O funcionamento do initrd e as características do kernel serão estudadas em capítulos adiante.

MANUAL DE TREINAMENTO M.CURY

Resumindo o mapeamento de hardware é feito pelo kernel e o carregamento do sistema operacional e

As principais características destes sistemas de inicialização são:

Estudaremos o SysV Init que é o padrão da maioria das distribuições Linux.

MANUAL DE TREINAMENTO M.CURY

runlevel = em que nível o processo será executado;

action = ação do init para aquele processo;

process = qual comando/script será executado.

As principais ações do init são:

initdefault - define o nível padrão do sistema

boot - ação prioritária, é executada depois da sysinit e antes das outras

ctrlaltdel - define a ação associada às teclas control + alt + del

kbrequest - define a ação associada às teclas alt + seta para cima

Os níveis de execução (RUNLEVEL) são:

MANUAL DE TREINAMENTO M.CURY

Exemplo de inittab padrão Red Hat para o runlevel 5:

O upstart é um daemon baseado em evento e um substituto do /sbin/init (pai de todos os processos).

MANUAL DE TREINAMENTO M.CURY

 As tarefas e os serviços são começados e parados por eventos (Signal);

Você pode começar a utilizar o upstart através dos comandos de controle.

Onde configurar as opções que tinham no inittab?

Exemplo: Para habilitar o tty2 apenas no runlevel 3 edite o arquivo abaixo:

start on runlevel [2]

Alterando o seu runlevel default

MANUAL DE TREINAMENTO M.CURY

Para alterar o initdefault é necessário alterar o arquivo rc-sysinit.conf. Altere a variável

O conteúdo de um arquivo dentro do /etc/init tem as seguintes características:

 Os arquivos contidos em /etc/init executam um comando sempre após o "exec".

Distribuições que utilizam o systemd por padrão:

Distribuições onde o systemd está disponível:

 Arch Linux tem pacotes para o system;

MANUAL DE TREINAMENTO M.CURY

Gerenciar serviços com o comando “systemctl”:

# systemctl status irqbalance.service

# systemctl enable httpd.service

# systemctl restart httpd.service

# systemctl stop httpd.service

MANUAL DE TREINAMENTO M.CURY

# systemctl disable telnet.service

# systemctl list-units --type=service

A ordem de execução é determinada pelos números de 00 a 99 que estão juntos da letra (K ou S) no

Como no exemplo abaixo:

K20nomedoscript – fechar o script na ordem 20

Para verificar é só listar os diretórios dos runlevels:

MANUAL DE TREINAMENTO M.CURY

Em distribuições baseadas em Red Hat:

Em distribuições baseadas em Debian:

MANUAL DE TREINAMENTO M.CURY

# case para testar os parâmetros passados ao scripts

debian:~# chmod -v 755 /etc/init.d/teste.sh