Integracao ContinuaServidor DNS

452
Linux Network Servers
www.4linux.com.br
Projetos na sua empresa
com a qualidade dos treinamentos
ence GED - ECM

Business Intelig lx8 BPM Servidor Java EE http://va.mu/Flx3
va.m u/ F http://va.mu/EuiT
http:// http://va.mu/FlyB
Integração Continua PostgreSQL Monitoramento Alta Disponibilidade

http://va.mu/FlyD http://va.mu/EuhV http://va.mu/EukN http://va.mu/FNbL
Virtualização Groupware Yj Backup Infraestrutura Web

http://va.mu/Flxl u/FN http://va.mu/Flxr http://va.mu/Flxi
http://va.m
Auditoria e Análise Segurança Ensino à Distância Implantação garantida

http://va.mu/Flxu http://va.mu/Flxy http://va.mu/Flxc http://va.mu/GcFv
Conteúdo
1 Cenário e Propostas de Solução 1

1.0.1 Cenário normalmente encontrado nas empresas . . . . . . 1
1.0.2 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Implementando Hardening e PAM em seu Servidor GNU/Linux 5

2.0.3 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.0.4 Proposta de solução . . . . . . . . . . . . . . . . . . . . . . . 5
2.0.5 Introdução teórica – Ajustes iniciais . . . . . . . . . . . . . . 6
2.0.6 Laboratório . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.0.7 Configurando a resolução de nomes . . . . . . . . . . . . . . 7
2.0.8 Configuração do Hostname . . . . . . . . . . . . . . . . . . . 7
2.0.9 Configurando o repositório de rede . . . . . . . . . . . . . . . 8
2.0.10 Introdução teórica - Hardening . . . . . . . . . . . . . . . . . 11
2.0.11 Laboratório . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.0.12 Configurando o SUDO . . . . . . . . . . . . . . . . . . . . . . 11
2.0.13 Introdução teórica - PAM . . . . . . . . . . . . . . . . . . . . 18
2.0.14 Módulos do PAM . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.0.15 Controles do PAM . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Servidor DHCP 31
3.0.16 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.0.18 Introdução teórica . . . . . . . . . . . . . . . . . . . . . . . . 31
3.0.19 Laboratório . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.0.20 Fixar IP via DHCP . . . . . . . . . . . . . . . . . . . . . . . . 38
i
Conteúdo 4Linux – www.4linux.com.br
4 Servidor NFS 43
4.1 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Proposta de solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Introdução teórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Conhecendo o NAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.5 NAS versus SAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.6 E o DAS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.7 Laboratório . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.7.1 Configurando o Servidor . . . . . . . . . . . . . . . . . . . . 49
4.7.2 Configurando o Cliente . . . . . . . . . . . . . . . . . . . . . 53
5 Implementando RAID + LVM 57

5.0.3 Introdução Teórica - RAID . . . . . . . . . . . . . . . . . . . . 57
5.0.4 Introdução Teórica – LVM . . . . . . . . . . . . . . . . . . . . 66
5.0.5 Laboratório – RAID . . . . . . . . . . . . . . . . . . . . . . . 68
6 Servidor Samba 85
6.0.6 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.0.9 subsection name . . . . . . . . . . . . . . . . . . . . . . . . . 87
7 Servidor DNS 109

7.0.12 Resolução . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7.0.13 O arquivo hosts . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.0.14 Ferramentas de consulta . . . . . . . . . . . . . . . . . . . . 117
7.0.15 Prática dirigida . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.0.16 Introdução ao BIND + Laboratório . . . . . . . . . . . . . . . 121
7.0.17 BIND como servidor cache . . . . . . . . . . . . . . . . . . . 124
7.0.18 Restringindo consultas . . . . . . . . . . . . . . . . . . . . . 126
7.0.19 Configuração do DNS primário . . . . . . . . . . . . . . . . . 130
7.0.20 Configurando o DNS reverso . . . . . . . . . . . . . . . . . . 138
7.0.21 Configurando o DNS secundário . . . . . . . . . . . . . . . . 140
7.0.22 Configurando o DNS Secundário . . . . . . . . . . . . . . . . 143
Página ii Linux Network Servers

4Linux – www.4linux.com.br Conteúdo
7.0.23 Desativar recursão externa . . . . . . . . . . . . . . . . . . . 144

7.0.24 SPF - Sender Policy Framework . . . . . . . . . . . . . . . . 145
8 Servidor Apache 147

8.0.27 MPM PreFork e MPM Worker . . . . . . . . . . . . . . . . . 148
8.0.28 Laboratório . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
8.0.29 Conhecendo a estrutura do Apache . . . . . . . . . . . . . . 150
8.0.30 Suporte a PHP . . . . . . . . . . . . . . . . . . . . . . . . . 153
8.0.31 Arrumando os diretórios . . . . . . . . . . . . . . . . . . . . . 155
8.0.32 Configurando o “php.ini” . . . . . . . . . . . . . . . . . . . . . 159
8.0.33 VirtualHost? . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
8.0.34 Criando Virtualhost para nossos domínios . . . . . . . . . . . 160
8.0.35 Fechando brechas de segurança . . . . . . . . . . . . . . . . 161
8.0.36 Configurando o Moodle . . . . . . . . . . . . . . . . . . . . . 163
8.0.37 Disponibilizando o site da Dexter Courier . . . . . . . . . . . 176
8.0.38 Ativando o SSL . . . . . . . . . . . . . . . . . . . . . . . . . . 177
9 Servidor FTP 185

9.0.39 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
9.0.42 Laboratório . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
9.0.43 Comandos em modo texto do FTP . . . . . . . . . . . . . . . 193
9.0.44 Cliente gráfico para FTP . . . . . . . . . . . . . . . . . . . . . 194
10 Servidor Postfix 197

10.0.45 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
10.0.48 Introdução ao Postfix . . . . . . . . . . . . . . . . . . . . . . 198
10.0.49 Características do Postfix . . . . . . . . . . . . . . . . . . . . 199
10.0.50 Laboratório . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Linux Network Servers Página iii

Conteúdo 4Linux – www.4linux.com.br
11 Servidor OpenLDAP 231

11.0.51 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
11.0.54 Backup da base de dados . . . . . . . . . . . . . . . . . . . 244
12 Servidor Proxy com Squid 247

12.0.55 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
12.0.57 Introdução Teórica . . . . . . . . . . . . . . . . . . . . . . . . 247
12.0.58 Proxy Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
12.0.59 Proxy Transparente . . . . . . . . . . . . . . . . . . . . . . . 249
12.0.60 ACL - Access Control Lists . . . . . . . . . . . . . . . . . . . 250
12.0.61 Definindo ACL . . . . . . . . . . . . . . . . . . . . . . . . . . 251
12.0.62 Tipos de ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
12.0.63 Regras das ACLs . . . . . . . . . . . . . . . . . . . . . . . . 254
12.0.64 Laboratório . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
12.0.65 Criando a estrutura do Squid . . . . . . . . . . . . . . . . . . 258
12.0.66 Filtrando acessos com Squid . . . . . . . . . . . . . . . . . . 258
12.0.67 Blacklist e Whitelist . . . . . . . . . . . . . . . . . . . . . . . 263
12.0.68 Autenticação NCSA . . . . . . . . . . . . . . . . . . . . . . . 265
12.0.69 Auditoria de acesso com SARG . . . . . . . . . . . . . . . . 267
12.0.70 Autenticação via OpenLDAP . . . . . . . . . . . . . . . . . . 271
13 Firewall 273
13.0.71 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
13.0.74 Revisando os conceitos de Rede . . . . . . . . . . . . . . . . 274
13.0.75 TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
13.0.76 Tabelas do Iptables . . . . . . . . . . . . . . . . . . . . . . . 279
13.0.77 O que é uma chain? . . . . . . . . . . . . . . . . . . . . . . 279
13.0.78 Compreendendo as políticas básicas e o conceito das ex-
ceções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
13.0.79 Laboratório . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
13.0.80 Script de firewall . . . . . . . . . . . . . . . . . . . . . . . . . 283
Página iv Linux Network Servers

4Linux – www.4linux.com.br Conteúdo
14 Servidor OpenVPN 289

14.0.81 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
14.0.83 Introdução Teórica . . . . . . . . . . . . . . . . . . . . . . . . 289
14.0.84 Protocolos de tunelamento . . . . . . . . . . . . . . . . . . . 291
14.0.85 Arquitetura de VPNs . . . . . . . . . . . . . . . . . . . . . . 292
14.0.86 Laboratório . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
14.0.87 Configurando o servidor . . . . . . . . . . . . . . . . . . . . . 294
14.0.88 Configurando o cliente . . . . . . . . . . . . . . . . . . . . . . 295
14.0.89 Certificados vpn . . . . . . . . . . . . . . . . . . . . . . . . . 298
14.0.90 TLS-Auth HMAC . . . . . . . . . . . . . . . . . . . . . . . . . 298
14.0.91 Gerando certificado CA e chave RSA . . . . . . . . . . . . . 300
14.0.92 Gerando parâmetros Diffie-Hellman . . . . . . . . . . . . . . 302
14.0.93 Configurando o servidor OpenVPN . . . . . . . . . . . . . . 302
15 Referências Bibliográficas 307
Linux Network Servers Página v

Capítulo 1
Cenário e Propostas de Solução
1.0.1 Cenário normalmente encontrado nas empresas
Todos sabemos que a área de TI (Tecnologia da Informação) de algumas empresas

é seu “calcanhar de Aquiles”, pois a forma que os servidores foram implementados
acabam prejudicando a produtividade diária e pondo em risco aos dados da em-
presa. Sabemos também que o uso de software proprietário sem licenciamento é
uma realidade em nosso país, tornando a ilegalidade algo comum e corriqueiro.
Mas o que muitos não sabem (ou não aceitam!) é que podemos implementar o
mesmo ambiente usando software livre, sem custo de propriedade ou licenciamento,
além de ser muito superior em estabilidade, desempenho e produtividade! Estamos
falando de usar GNU/Linux como Sistema Operacional e suas diversas ferramentas
servidoras, como web, e-mail, banco de dados, storage, autenticação de usuários,
redundância, entre outros.
1.0.2 Cenário
O ambiente comumente utilizado nas pequenas e médias empresas é composto por

software proprietário, onde se tem firewall/proxy, servidor de arquivos, e-mail, intranet
1
4Linux – www.4linux.com.br
e banco de dados. Podemos observar isto na próxima figura.
Partindo deste cenário, iremos migrar a maioria das tecnologias para a plataforma
livre, conforme exemplificado na próxima figura.
Página 2 Linux Network Servers

Além das tecnologias exibidas na figura acima, podemos ainda implementar redun-
dância de discos com RAID, gerenciamento de unidades com o LVM, segurança de
acesso ao servidor com o uso do PAM, integração da rede Linux com algumas má-
quinas Windows por meio do Samba, além de outros serviços como FTP, DHCP, DNS
e VPN.
A cada dia de Curso iremos ensinar tais serviços, mostrando como seria o dia a dia
de uma empresa e conseguiremos verificar como a produtividade, desempenho e
confiabilidade se tornarão algo comum na vida do administrador! Na próxima página
você tem um espaço para realizar suas anotações, como os Ips das máquinas!
Coloque os endereços Ips que irá utilizar durante o curso
1 eth0 => IP 200.100.50. ___ eth1 => IP 192.168. ___ .1

2
3 IP 192.168. ___ .2 IP 192.168. ___ .4
4
Linux Network Servers Página 3

5 IP 192.168. ___ .3 IP 192.168. ___ .2

6
7 IP 192.168. ___ .4 IP 192.168. ___ .3

Capítulo 2
Implementando Hardening e PAM em

seu Servidor GNU/Linux
2.0.3 Cenário
A empresa DEXTER COURIER precisa que seu servidor seja configurado com as
devidas políticas de segurança, permitindo acesso local e remoto somente à equipe
de TI em horários previamente definidos. Além disto, é necessário ter todos os regis-
tros de login/logout, bem como as atividades realizadas nos servidores.
2.0.4 Proposta de solução
A fim de atender às necessidades da empresa DEXTER COURIER , iremos aplicar

os processos de HARDENING no servidor. Além de verificar as possíveis ameaças
de segurança e corrigi-las, faremos uso do PAM, que é um mecanismo de autentica-
ção a diversas aplicações, tornando o servidor bem mais seguro com esta camada
de proteção.
5
2.0.5 Introdução teórica – Ajustes iniciais
Sempre que finalizamos a instalação de um servidor, temos que efetuar alguns ajus-
tes iniciais para que os serviços disponibilizados por ele seja acessível por todos os
usuários da rede que possuam permissão. Com isso temos todo o trabalho de fechar
possível brechas de segurança, como portas abertas, banner do aplicativo ou mesmo
algum bug na aplicação. Vamos efetuar os primeiros passos, como configurar um IP
fixo, resolução de Nomes-IPs, Hostname, arquivo Hosts e o(s) repositório(s).
2.0.6 Laboratório
Como todo servidor deve ter um IP fixo na rede, vamos efetuar esta configuração no
arquivo “/etc/network/interfaces”. Para isto, execute num terminal como “root” e
adicione o que está em negrito:
1 root@debian :~ # vi / etc / network / interfaces
1 # Interface Loopback
2 auto lo
3 iface lo inet loopback
4
5 auto eth0
6 iface eth0 inet static
7 address 192.168. X .2
8 netmask 255.255.255.0
9 network 192.168. X .0
10 broadcast 192.168. X .255
11 gateway 192.168. X .1

Na distro RedHat: # vim /etc/sysconfig/network/ifcfg-eth0
2.0.7 Configurando a resolução de nomes
Edite o arquivo “/etc/resolv.conf” para colocarmos o endereço do servidor DNS que

irá resolver Nome-IP:
1 root@debian :~ # vi / etc / resolv . conf

2 nameserver 8.8.8.8
2.0.8 Configuração do Hostname
Em um servidor, a configuração correta do “hostname” e do arquivo “hosts” é essen-

cial para eliminar problemas em serviços de rede. Abra o arquivo “/etc/hostname” e
adicione o nome da máquina:
1 root@debian :~ # vi / etc / hostname datacenter
Depois vamos parar e iniciar o serviço do hostname:
1 root@debian :~ # / etc / init .d/ hostname . sh
Faça o logout e efetue o login. Cairá no prompt já alterado!
1 root@datacenter :~ #

Edite o arquivo de /etc/hosts e adicione a linha em negrito:
1 root@datacenter :~ # vi / etc / hosts

2 127.0.0.1 localhost
3 192.168. X .2 datacenter . dexter . com . br datacenter
2.0.9 Configurando o repositório de rede
Para instalar programas no “Debian GNU/Linux”, é necessário que o repositório de

rede esteja corretamente configurado. Vamos configurá-lo para buscar os softwares
em um “repositório interno” da 4Linux. Abra o arquivo responsável pela configuração
do repositório:
1 root@datacenter :~ # vi / etc / apt / sources . list

2 deb http ://192.168.1.1:3142/ debian squeeze main contrib non -
free
Depois de configurado, faça o “update” do banco de dados do “aptitude”:
1 root@datacenter :~ # aptitude update
Vamos agora efetuar a atualização do servidor com o comando:
1 root@datacenter :~ # aptitude upgrade
Ok! Com o servidor atualizado, vamos agora instalar os programas necessários para
o andamento do curso:

1 root@datacenter :~ # aptitude install build - essential module -

assistant less vim splitvt linux - headers -$( uname -r) -y
Agora vamos configurar o editor de textos VIM, habilitando linhas numeradas, desta-
que de busca no texto, ignorar o case e deixar o texto colorido, facilitando a leitura da
configuração. Insira no final do arquivo:
1 root@datacenter :~ # vim / etc / vim / vimrc

2 syntax on
3 set number
4 set hlsearch
5 set incsearch
6 set ic
Visto que o VIM não é o editor padrão do sistema, vamos configurá-lo:
1 root@datacenter :~ # update - alternatives -- config editor

2 Existem 3 escolhas para a alternativa editor ( disponibiliza / usr / bin
/ editor ).
3 Selec ção Caminho Prioridade Estado
4 ------------------------------------------------------------
5 0 / bin / nano 40 modo autom á tico
6 1 / bin / nano 40 modo manual
7 * 2 / usr / bin / vim . basic 30 modo manual
8 3 / usr / bin / vim . tiny 10 modo manual
9
10 Pressione enter para manter a escolha actual [*] , ou digite o nú mero
da selec ção: 2
Vamos ajustar algumas variáveis do sistema e alguns “alias” dentro do arquivo

/etc/profile. Abra o arquivo e insira no final:

1 root@datacenter :~ # vim / etc / profile

2 HISTSIZE =5000
3 export HISTSIZE
4 # TMOUT =120 # vari á vel que efetua " logout " ap ós 120 segundos
5 # export TMOUT
6 alias ls =’ ls -- color = auto ’
7 alias grep =’ grep -i -- color ’
Caso deseje adicionar mais variáveis ou alias, fique à vontade! Concluída esta etapa,
vamos reler o arquivo para que as alterações sejam validadas:
1 root@datacenter :~ # source / etc / profile
A fim de ajudar na instalação de programas via aptitude ou apt-get, podemos usar a

função de autocompletar (usando o TAB) na busca por programas nos repositórios.
Primeiro instale o aplicativo e depois abra o arquivo /etc/bash.bashrc e descomente
apenas as linhas 32, 33 e 34:
1 root@datacenter :~ # aptitude install bash - completion

2 root@datacenter :~ # vim / etc / bash . bashrc
3 32 if [ -f / etc / bash_completion ] && ! shopt -oq posix ; then
4 33 . / etc / bash_completion
5 34 fi
Agora vamos reler o arquivo para validar as alterações:
1 root@datacenter :~ # source / etc / bash . bashrc
Teste agora a busca digitando os primeiros caracteres do programa após inserir o

“aptitude install” e tentando completar com o “TAB”.

2.0.10 Introdução teórica - Hardening
Hardening é um processo de mapeamento das ameaças, mitigação dos riscos e

execução das atividades corretivas - com foco na infraestrutura e objetivo principal
de torná-la preparada para enfrentar tentativas de ataque. Normalmente, o processo
inclui remover e/ou desabilitar nomes ou logins de usuários que não estejam mais
em uso, além de serviços desnecessários.
Podemos incluir nessa lista de procedimentos limitar o software instalado àquele que
se destina a função desejada do sistema; aplicar e manter os “patches” de segurança
tanto no sistema operacional como na aplicação; revisar e modificar as permissões
dos sistemas de arquivos, em especial no que diz respeito a escrita e execução;
reforçar a segurança do login, impondo uma política de senhas fortes.
Procedimentos de Pós Instalação (Hardening) serão discutidos no treinamento

de Segurança 415 – ISO27002.
2.0.11 Laboratório
2.0.12 Configurando o SUDO
O comando sudo permite a usuários comuns obter privilégios de outro usuário, em

geral o super usuário, para executar tarefas específicas dentro do sistema de maneira
segura e controlável pelo administrador. O nome é uma forma abreviada de se referir
a substitute user do (fazer substituindo usuário) ou super user do (fazer como super
usuário).
Observações importantes :
• A senha é armazenada por 15 minutos. Depois disso, você terá de digitar a

senha novamente.
• Sua senha não será mostrada na tela enquanto você a digita no terminal, ape-
nas será mostrada com asteriscos quando você digitá-la pela interface gráfica.
• Para executar usando sudo um programa que normalmente é executado como

de usuário, como o gedit, aperte ALT + F2 e digite gksudo gedit, para o Gnome.
Para usuários do KDE, use kdesu no lugar de gksudo.
Vamos instalar o sudo com o comando:
1 root@datacenter :~ # aptitude install sudo
O arquivo de configuração do sudo é o /etc/sudoers. Abra-o usando:
1 root@datacenter :~ # visudo
Insira o usuário infra na linha 18, conforme em negrito:
1 16 # User privilege specification

2 17 root ALL =( ALL ) ALL
3 18 infra ALL =( ALL ) ALL
Com esta configuração demos total poder para o usuário infra, visto que iremos
bloquear o acesso de root posteriormente. Para melhorar a segurança do sistema
com o uso do sudo, em caso de esquecer o terminal aberto como usuário infra,
podemos configurar o sudo para sempre pedir a senha ao se digitar um comando.
Para isto, adicione no final do arquivo:
1 26 Defaults : infra timestamp_timeout =0

Configurando o SSH
Serviço amplamente utilizado pelos administradores de servidores GNU/Linux, o ssh

(Secure Shell) também é visado pelos atacantes que tentam acessar o sistema via
usuário root (administrador), pois é sabido que todo GNU/Linux possui! Sendo assim,
vamos efetuar duas modificações importantes no sistema: negar o acesso de root e
mudar a porta padrão!
Primeiramente vamos instalar o servidor ssh:
1 root@datacenter :/ tmp # aptitude install ssh
Como todos sabem, o usuário root sempre acessa o sistema. Veja:
1 root@datacenter :~ # ssh localhost

2
3 root@localhost ’s password :
Agora, abra o arquivo /etc/ssh/sshd_config e altere as linhas 5, 25 e 26 conforme

em negrito:
1 4 # What ports , IPs and protocols we listen for

2
3 5 Port 51000
4 ...
5 25 LoginGraceTime 15
6 26 PermitRootLogin no
Respectivamente alteramos a porta padrão 22 para a 51000, mudamos o tempo

máximo para digitar a senha para apenas 15 segundos e negamos o login com o
usuário root! Para as novas regras entrarem em vigor, reinicie o serviço do ssh.

1 root@datacenter :~ # service ssh restart
Vamos aos testes?
1 root@datacenter :~ # ssh root@localhost

2 ssh : connect to host localhost port 22: Connection refused
4 root@datacenter :~ # ssh root@localhost - p51000
5 root@localhost ’s password :
6 Permission denied , please try again .
Melhorando nossas senhas
Sabemos que não é fácil criar uma senha, ainda mais sendo ela para um servidor!
Para ajudar nessa árdua tarefa, podemos instalar um programa chamado pwgen,
que gera combinações de caracteres, formando assim senhas aleatórias!
1 root@datacenter :~ # aptitude install pwgen
Apenas como exemplo, vamos gerar 4 combinações de senhas com 15 caracteres,

tendo letras maiúsculas, minúsculas, números e caracteres especiais. Detalhe: com
a opção ”s”, a senha será muito difícil de memorizar!
1 root@datacenter :~ # pwgen -1 sync 15 4

2 !0E >,T]We ‘ xSFDp
3 " DuI7 " /\ whdtan *
4 M=B > jQ ;& #; M3 ;_)
5 W ‘ vaJ2qAL_@ )] Hr

Verificando portas e encerrando programas desnecessários
Devemos realizar uma verificação periódica em nosso sistema a procura de portas

abertas e programas desnecessários. Para isto vamos usar o famoso NMAP, um
scanner de portas altamente poderoso. Para sua instalação, execute:
1 root@datacenter :~ # aptitude install nmap
Vamos demonstrar o procedimento de remoção de um serviço desnecessário, como

EXEMPLO. Rode o seguinte comando do nmap:
1 root@datacenter :~ # nmap -sV localhost

2 Starting Nmap 5.00 ( http :// nmap . org ) at 2011 -06 -20 22:28 BRT
3 Interesting ports on localhost (127.0.0.1) :
4 Not shown : 999 closed ports
5 PORT STATE SERVICE VERSION
6 25/ tcp open smtp Exim smtpd 4.72
7 Service Info : Host : datacenter
8 Service detection performed . Please report any incorrect results at
http :// nmap . org / submit / .
9 Nmap done : 1 IP address (1 host up ) scanned in 0.52 seconds
Neste EXEMPLO verificamos que temos o servidor de e-mail EXIM, versão 4. Como
não iremos utilizá-lo, vamos remover seus links da inicialização para que eles não
sejam iniciados no boot. Execute o comando:
1 root@datacenter :~ # insserv -rv exim4

2 insserv : remove service / etc / init .d /../ rc0 .d/ K01exim4
5 insserv : remove service / etc / init .d /../ rc3 .d/ S02exim4


9 insserv : creating . depend . boot
10 insserv : creating . depend . start
11 insserv : creating . depend . stop
Executando o Nmap novamente, percebemos que não há nenhum porta aberta em

nosso servidor!
1 root@datacenter :~ # nmap -sV localhost

2 Starting Nmap 5.00 ( http :// nmap . org ) at 2011 -06 -21 14:35 BRT
3 All 1000 scanned ports on localhost (127.0.0.1) are closed
4 Service detection performed . Please report any incorrect results at
http :// nmap . org / submit / .
5 Nmap done : 1 IP address (1 host up ) scanned in 0.67 seconds
Outro comando importante (e que cai na prova da LPI) é o netstat. Ele possui alguns
parâmetros importantes para verificarmos as conexões estabelecidas em nosso ser-
vidor. Execute:
1 root@datacenter :~ # netstat - ltupan
Opções: -l - exibe as conexões que ficam "ouvindo"oou aguardando conexão; -t -

exibe conexões TCP -u - exibe conexões UDP -p - seguido do nome do protocolo
(TCP, UDP ou IP), exibe as informações pedidas relativas ao protocolo especificado.
-a - exibe o conjunto das conexões e das portas em escuta na máquina; -n - exibe os
endereços/portas em formato numérico, sem resolução de nomes.

Logando o comando SU
Todos os usuários logados no sistema GNU/Linux podem trocar de perfil apenas

digitando o comando “su usuário” e a senha do mesmo. É interessante logarmos
as trocas de login (ou tentativas!) que os usuários do sistema efetuam, pois podemos
mapear os usuários que desejam escalar privilégios, qualquer que sejam os motivos.
Para isso, efetue o comando abaixo e descomente a linha 67:
1 root@datacenter :~ # vim +67 / etc / login . defs

2 67 SULOG_FILE / var / log / sulog
Agora crie o arquivo especificado como sendo o log:
1 root@datacenter :~ # touch / var / log / sulog
Faça alguns testes com o comando “su”, ora acertando a senha, ora errando. Se
desejar faça com o auxílio do programa splitvt:
1 root@datacenter :~ # splitvt
Deixe numa tela rodando o comando de visualização de logs:
1 root@datacenter :~ # tail -f / var / log / sulog
Na outra execute os comandos com “su infra” e “su – infra”, errando a senha!

2.0.13 Introdução teórica - PAM
O propósito do do projeto PAM é separar a concessão de privilégios nos aplicativos

do desenvolvimento de esquemas de autenticação apropriados e seguros. Isto é
realizado fornecendo-se uma biblioteca de funções utilizada pelas aplicações para
solicitar a autenticação de usuários.
PAM é o acrônimo em inglês para Pluggable Authentication Modules. Seu de-

senvolvimento inicial aconteceu em 1996 pela Sun Microsystems e atualmente é
suportado nos sistemas operacionais AIX, HP-UX, Solaris, Linux, FreeBSD, Mac OS
X e NetBSD.
As bibliotecas PAM são configuradas no arquivo /etc/pam.conf ou nos arquivos den-

tro do diretório /etc/pam.d/. Vale ressaltar que não é possível utilizar as duas
formas de configuração do LinuxPAM. Ou um ou outro, não os dois ao mesmo
tempo.!
Os arquivos de configuração utilizam módulos normalmente localizados no diretório

/lib/security/ou /lib64/security/ e se comportam como objetos carregáveis dinami-
camente.
Tipos de PAM
Embora eles não sejam classificados, podemos dizer que há três tipos de PAM:
Linux-PAM: O Linux-PAM abrange todo o PAM discutido neste capítulo. A arquite-

tura principal do PAM em qualquer plataforma Unix é semelhante à versão PAM do
Linux.
OpenPAM: O OpenPAM é outra implementação do PAM desenvolvida pelos labora-

tórios Dag-Erling Smorgrav em NAI como parte do programa de pesquisa DARPA-
CHATS. Por ser um software livre, ele é usado principalmente pelo FreeBSD, NetBSD
e por aplicativos (além do Mac OS X).

Java™ PAM ou JPam: O JPam atua como uma ponte entre a parte Java e o PAM
comum. Ele permite o uso dos módulos ou recursos do PAM (como auth, account,
passwd, session , etc.) pelos aplicativos baseados em Java. Ele fornece o JAAS e
APIs diretas e suporte para a maioria dos sistemas operacionais e arquiteturas do
Unix.
Sobre o LinuxPAM, você poderá obter mais informações no link abaixo:

http://www.kernel.org/pub/linux/libs/pam
2.0.14 Módulos do PAM
O PAM trabalha com módulos e controles, e cada tipo de módulo provê uma funcio-
nalidade diferente dentro do sistema. Vamos comentar primeiro os módulos:
• account: Verifica se a conta é valida no sistema, se a senha do usuário expirou

e se o usuário realmente tem direitos de acessar aquele serviço;
• auth (authentication): Verifica questões de autenticação, seja por senhas ou

impressões digitais (quando falamos de biometria). É o módulo “authentication”
que oferece a flexibilidade do PAM, já que para cada método de autenticação
criado, existe uma biblioteca que será adicionada à este módulo;
• password: Este módulo é responsável por cuidar dos aspectos relacionados a

tarefas envolvendo senhas, como atualização e solicitação de nova senha de
acesso no caso da troca da mesma;
• session: Responsável por tarefas pós autenticação, como montar um compar-

tilhamento de arquivos remotos que contém o diretório “/home” do usuário em
questão, por exemplo.

2.0.15 Controles do PAM
Além dos módulos, existem também os controles:
• required: Checa a existência do módulo solicitado. Caso esse módulo falhe, so-
mente depois de verificar se todos os módulos do mesmo tipo estão disponíveis
é que o usuário será avisado;
• requisite: Checa a existência do módulo solicitado e avisa o usuário imediata-

mente caso este módulo falhe.
• sufficient: Somente a verificação do módulo é suficiente para a autenticação,

desde que nenhum módulo marcado como required falhe.
• optional: O sucesso ou a falha deste módulo não interfere no processo de

autenticação.
A maioria das distribuições GNU/Linux trabalham com “PAM”. As únicas distros

que não usam são “Slackware” e suas variações!
Laboratório
Antes de executar qualquer comando deste tópico, é extremamente importante

que você deixe um terminal logado como root (pode ser o tty6) pois caso seja feito
qualquer tipo de bloqueio ao usuário root e você efetuar um logout, temos como
alterar as configurações e voltar aos testes!
Verifique quais módulos do PAM estão instalados no sistema:

1 root@datacenter :~ # ls / lib / security /
1 Como descobrir se sua aplica ção tem suporte no PAM ?

2 R: Basta utilizar o comando " ldd ".
Execute:
1 root@datacenter :~ # ldd / bin / login

2 linux - gate . so .1 => (0 xb7712000 )
3 libpam . so .0 => / lib / libpam . so .0 (0 xb7701000 )
4 libpam_misc . so .0 => / lib / libpam_misc . so .0 (0 xb76fe000 )
5 libc . so .6 => / lib / i686 / cmov / libc . so .6 (0 xb75b7000 )
Podemos verificar também quais serviços trabalham com o PAM listando os arquivos
do /etc/pam.d:
1 root@datacenter :~ # ls -l / etc / pam .d
Vamos fazer um teste simples que serve para bloquear usuários comuns. Abra o
arquivo "/etc/pam.d/login"e visualize o módulo "pam_nologin.so" na linha 36:
1 root@datacenter :~ # vim +36 / etc / pam .d/ login

2 34 # Disallows other than root logins when / etc / nologin exists
3 35 # ( Replaces the ‘ NOLOGINS_FILE ’ option from login . defs )
4 36 auth requisite pam_nologin . so
Para esse “módulo” funcionar ele necessita que o arquivo “nologin” esteja criado
dentro do diretório /etc. Execute:

1 root@datacenter :~ # touch / etc / nologin
Feito isto, tente logar com o usuário “infra” em outro terminal. Depois apague o
arquivo /etc/nologin.
Repare que a partir do momento que o “plugin” está ativado no programa

“login” e o arquivo necessário está criado, os usuários comuns não conseguem mais
logar, somente o usuário root. Isso não é muito funcional mas serve de exemplo para
entendermos como o “PAM” funciona.
Vamos bloquear o acesso de root ao terminal do servidor sem o uso do PAM, apenas
editando o arquivo /etc/securetty :
1 root@datacenter :~ # vim +31 / etc / securetty

2 28 # Virtual consoles
3 29 tty1
4 30 tty2
5 31 # tty3
6 32 tty4
Teste: Comente a linha 31 (tty3) e tente logar-se com o usuário root no TTY3!
Depois comente as linhas 29 a 34!
Uma maneira prática de usar o “PAM” é fazermos com que o usuário root não
tenha acesso direto ao login, forçando a logar com usuário comum e depois executar
“su -” para virar root.
Para usar o PAM para gerenciar o login do root, vamos abrir o arquivo /etc/pam.d/login
e descomentar a linha 68:


2 68 account requisite pam_time . so
Agora que ativamos o módulo pam_time.so, vamos negar o login do root no terminal.
Edite o arquivo “/etc/security/time.conf” e acrescente na última linha:
1 root@datacenter :~ # vim / etc / security / time . conf

2 login ;*; root ;! Al0000 -2400
Abaixo temos as opções que podemos utilizar como permissão de acesso:
login - Serviço que irá ser controlado * - Terminal root - Usuário Al0000-2400 -
Dias e horários de filtragem.
O dia da semana é especificado em duas letras, em inglês: Mo - Segunda-feira Tu

– Terça-feira We - Quarta-feira Th - Quinta-feira Fr - Sexta-feira Sa - Sábado Su -
Domingo Wd - Somente sábado e domingo (fim de semana) Wk - Segunda a sexta-
feira Al - Todos os dias "!- Neste caso especifica uma exceção. A faixa de horas é
especificada após o dia no formato: HHMM-HHMM
Tente efetuar login como root em outro terminal e veja que não será possível! Apro-
veitando o “gancho” , vamos deixar configurada a negação de acesso ao root via ssh.
Mais uma camada de proteção, além da já configurada no arquivo de configuração
do ssh (/etc/ssh/sshd_config). Abra o arquivo /etc/pam.d/sshd e inclua na linha
9:
1 root@datacenter :~ # vim +9 / etc / pam .d/ sshd

2 9 account required pam_time . so

Completando, abra o arquivo /etc/security/time.conf e adicione no final:
1 root@datacenter :~ # vim +9 / etc / security / time . conf

2 login ;*; root ;! Al0000 -2400
3 sshd ;*; root ;! Al0000 -2400
Como permitir acesso a grupos extras como, por exemplo, “audio”, ou “cdrom”?
1 root@datacenter :~ # vim / etc / security / time . conf

2 login ;*; root ;! Al0000 -2400
3 sshd ;*; root ;! Al0000 -2400
4 login ; tty *; usu á rio ; Al0800 -1800; audio cdrom
Essa sintaxe quer dizer que usuário só pode ter acesso ao grupo “audio” se efetuar
o login entre 8hs e 18hs. Outro exemplo:
1 login ; tty *;*; SaSu0000 -2400; audio games
Essa sintaxe quer dizer que todos os usuários podem ter acesso ao grupo “audio”
e “games” aos sábados e domingos. Com o PAM, podemos limitar quais usuários
poderão ter acesso a utilizar ao comando “su”. Para isso, vamos criar um grupo
chamado “admins”
1 root@datacenter :~ # groupadd admins
Agora vamos adicionar o usuário infra ao novo grupo. Com isto, apenas o usuário
infra poderá executar o comando “su”.
1 root@datacenter :~ # gpasswd -a infra admins ; id infra

Crie uma política que não possibilite o uso do “su”, exceto pelos usuários do grupo
“admins”. Abra o arquivo /etc/pam.d/su, descomente a linha 15 e adicione ao final da
linha group=admins
1 root@datacenter :~ # vim +15 / etc / pam .d/ su

2 15 auth required pam_wheel . so group = admins
Teste: Crie um usuário chamado “teste”, logue e execute um “su -”.
1 teste@datacenter :~ $ su -
2 Senha :
3 su : Permiss ão negada
Faça o mesmo teste como usuário infra.
1 infra@datacenter :~ $ su -
2 Senha :
Verifique o log do comando su:
1 root@datacenter :~ # tail -f -n2 / var / log / sulog

2 SU 06/22 21:01 - / dev / pts /0 teste - root
3 SU 06/22 21:02 + / dev / pts /0 infra - root
Vamos falar agora sobre o “pam_limits”! Esse é um excelente recurso para limitar
praticamente todos os recursos da máquina a cada usuário. Pode-se inclusive deter-
minar o tempo de consumo de CPU e memória RAM. Vejamos o módulo ativado no
/etc/pam.d/login:


2 77 session required pam_limits . so
O arquivo de configuração do “pam_limits” é o /etc/security/limits.conf. Dentro

dele, as linhas serão configuradas da seguinte forma:
1 < usuario / grupo > < tipo_de_limite > < recurso > < valor_do_limite >
Em usuário/grupo, podemos colocar um “*” para especificar todos os usuários, colo-

car um nome de usuário qualquer ou um nome de grupo, começando com “@”. No
tipo de limite, existem dois tipos possíveis: “soft” e “hard”.
Quando o limite do tipo “soft” é alcançado, o sistema avisa que chegou no limite mas
não restringe nada. Se o limite for do tipo “hard”, o sistema simplesmente restringe o
recurso e não deixa passar. O “soft” então serve apenas para um “aviso” amigável,
então na dúvida o “hard” é quem manda!
1 core - Limite do tamanho do arquivo coredump ( em KB ). É a mesma

configura ção que obtemos com o comando " ulimit -c" do shell .
2 data - Tamanho má ximo de segmento de dados que um programa pode
usar . Tamb ém como : " ulimit -d" no bash .
3 fsize - Tamanho má ximo de algum arquivo que o usu á rio possa
criar . Tamb ém: " ulimit -f".
4 memlock - Tamanho de mem ó ria alocada que os programas podem usar
( em KB ). Tamb ém: " ulimit -l".
5 nofiles - Nú mero má ximo de arquivos abertos ao mesmo tempo .
6 Tamb ém: " ulimit -n".
7 rss - Tamanho má ximo de mem ó ria compartilhada ( em KB ).
8 Tamb ém: " ulimit -m".
9 stack - Valor má ximo de um processo executado ( em KB ).

10 Tamb ém: " ulimit -s".

11 cpu - Tempo má ximo em minutos de uso da CPU . Tamb ém: " ulimit -t".
12 nproc - Nú mero má ximo de processos executados ao mesmo tempo . "
Tamb ém: ulimit -u".
13 as - Limite em KB de espa ço de endere ç amento .
14 maxlogins - Nú mero má ximo de logins para esse usu á rio
15 maxsyslogins - Nú mero má ximo de logins no sistema
16 priority - Em qual prioridade padr ão os processos desse usu á rio
devem rodar .
17 locks - Nú mero má ximo de arquivos de " locks " que podem ser
gerados pelo usu á rio . Tamb ém: " ulimit -x".
18 nice - Nú mero má ximo de prioridade que o usu á rio pode setar ,
entre -20 (má xima prioridade ) e 19 (mí nima prioridade ). Tamb ém:
" ulimit -e".
Fique atento, a prova do LPI pode cobrar as opções que encontramos dentro
do arquivo “limits.conf”. Conhecer todas estas opções e seu pleno entendimento são
tarefas essenciais para ser um Administrador de Sistemas GNU/Linux.
Vamos realizar alguns testes. Primeiro iremos limitar o número de terminais conse-
cutivos que um usuário pode utilizar. Abra o arquio /etc/security/limits.conf e insira
a seguinte linha:
1 root@datacenter :~ # vim / etc / security / limits . conf

2 @admins hard maxlogins 2
Dessa forma, limita-se o usuário teste para utilizar somente dois terminais consecu-
tivos. Segundo, vamos limitar o tamanho máximo de um arquivo criado pelo usuário
teste:

2 @admins hard maxlogins 2

3 @admins hard fsize 5000
Para o teste, faça logout e logue-se novamente com o usuário teste e tente criar
arquivos maiores que 100MB (fsize 100000).
1 infra@datacenter :~ $ dd if =/ dev / zero of = arquivo bs =1024 count =100000

2 100000+0 registros de entrada
3 100000+0 registros de sa í da
4 102400000 bytes (102 MB ) copiados , 0 ,762922 s , 134 MB /s
Criamos um arquivo de 100000KB. Agora vamos criar usando count=11000!
1 infra@datacenter :~ $ dd if =/ dev / zero of = arquivo bs =1024 count =110000

2 Excedido tamanho limite de arquivo
Outro fator importante na questão da segurança é o chamado Fork Bomb! Ele nada
mais é do que um processo criar sub-processos, em looping infinito, causando o
congelamento do servidor. Faça o teste com o usuário infra digitando:
1 infra@datacenter :~ $ bomb () { bomb | bomb & } ; bomb
Esse comando cria uma função na qual a função é jogada dentro dela mesma em
segundo plano, gerando o looping. Para parar o looping só desligando o servidor.
Para impedir isto, vamos limitar o número de processos gerados pelo usuário no
arquivo /etc/security/limits.conf

2 @admins hard nproc 200

Após isto, faça novamente o teste usando o usuário infra. Vamos ver agora como
implementar mais segurança com as senhas dos usuários. Limitaremos a quantidade
de caracteres a composição da senha. Instale o programa libpam-cracklib.
1 root@datacenter :~ # aptitude install libpam - cracklib
Abra o arquivo /etc/pam.d/common-password e deixe a linha 25 como em negrito,

comente a linha 26 e adicione a linha 27 como abaixo:
1
2 root@datacenter :~ # vim / etc / pam .d/ common - password
3 24 # here are the per - package modules ( the " Primary " block )
4 25 password requisite pam_cracklib . so retry =3 minlen =6 difok =3
5 26 # password [ success =1 default = ignore ] pam_unix . so obscure
use_authtok try_first_pass sha512
6 27 password [ success =1 default = ignore ] pam_unix . so use_authtok
nullok md5
Na linha 25 estamos especificando o seguinte:
1 retry =3 -> 3 tentativas de mudan ça de senha .;

2 minlen =6 -> Senha com no mí nimo 6 caracteres .;
3 difok =3 -> Diferen ça de pelo menos 3 caracteres da antiga senha .
Agora logue com o usuário teste e tente mudar a senha para valores que o sistema
não aceite:
1 teste@datacenter :~ $ passwd
2 Mudando senha para teste .
3 Senha UNIX ( atual ):
4 Senha :

5 SENHA INCORRETA : é muito simples / sistem á tica

6 Senha :
8 Senha :
10 passwd : Esgotado o nú mero má ximo de tentativas para servi ço
11 passwd : Palavra - passe inalterada
Agora mude a senha atendendo ao critério que configuramos:
1 teste@datacenter :~ $ passwd
2
3 Mudando senha para teste .
4 Senha UNIX ( atual ):
5 Senha :
6 Redigite a nova senha :
7 passwd : senha atualizada com sucesso
Iremos estudar “Hardening” mais a fundo no Treinamento “Segurança em Ser-

vidores Linux usando a ISO27002 – 415 “.
Visto que todo software possui “bugs” de segurança, é fundamental corrigi-los o

quanto antes. Também é sumamente importante que você esteja inscrito em lis-
tas de discussão que enviam notificações de segurança para a sua distribuição. A
ideia é manter-se informado das atualizações. Veja:
http://lists.debian.org/debian-security-announce/
https://rhn.redhat.com/errata/rhel-server-errata.html

Capítulo 3
Servidor DHCP
3.0.16 Cenário
A empresa Dexter Courier precisa de informações precisas sobre suas máquinas

no que diz respeito à origem dos acessos aos servidores, portanto ter todos os com-
putadores da rede mapeados com endereço IP fixo.
Uma grande vantagem que podemos encontrar no DHCP é o de “amarrar” o en-

dereço MAC das máquinas a um determinado IP, fazendo com que somente quem
estiver com o MAC ADDRESS cadastrado poderá utilizar a internet e os demais se-
rão bloqueados. Além disto, teremos um controle melhor sobre a origem dos acessos
aos serviços da empresa.
3.0.18 Introdução teórica
Criado e mantido pelo ISC (Internet Systems Consortium), um grupo sem fins lu-
crativos dedicado a desenvolver serviços de infra-estrutura usados na Internet, in-
31
cluindo o Bind e o NTPD. Caso esteja curioso, a página com o código fonte é a:
http://www.isc.org/sw/dhcp/. O protocolo DHCP (Dynamic Host Configuration Pro-
tocol) funciona nas camadas 2 e 3 do modelo OSI e é amplamente utilizado para
oferecer endereço IP a um "host"que ainda não está configurado, o que oferece uma
flexibilidade ao Administrador de Redes.
O que um servidor DHCP faz é bastante simples. Ele responde aos pacotes de
broadcast das estações, enviando um pacote com um dos endereços IP disponíveis
e os demais dados da rede. Os pacotes de broadcast são endereçados ao ende-
reço "255.255.255.255" e retransmitidos pelo switch da rede para todas as portas,
diferente dos pacotes endereçados a um endereço específico, que são transmitidos
apenas na porta relacionada a ele.
Periodicamente o servidor DHCP verifica se as estações ainda estão lá, exigindo

uma renovação do "aluguel"do endereço IP. Isso permite que os endereços IP se-
jam gastos apenas com quem realmente estiver online, evitando que os endereços
disponíveis se esgotem.
O protocolo "DHCP"opera da seguinte forma:
• DHCPDISCOVER - Um cliente envia um quadro "broadcast"(destinado a todas

as máquinas) com um pedido "DHCP";
• DHCPOFFER - O servidor "DHCP"captura o quadro e oferece um Endereço IP

ao "host"requisitante;
• DHCPREQUEST - O cliente envia um "DHCP REQUEST"endereçado para o

servidor "DHCP"aceitando o IP;
• DHCPACK - Esse é o pacote que confirma a atribuição de uma configuração

de rede a um cliente, ou seja, aquele cliente agora possui configurações distri-
buídas pelo servidor "DHCP";
• DHCPNAK - Caso o cliente não aceite aquele endereço IP, ele enviará um
"DHCPNAK"para o servidor, e realizará o "DHCPDISCOVER"novamente.
• DHCPDECLINE – Caso o IP já esteja sendo utilizado por outro Host, o servidor

envia um DHCPDECLINE anunciando ao servidor que o endereço já é utilizado;
• DHCPRELEASE – Se por algum motivo o cliente deixa de usar o endereço IP,

o mesmo manda um DHCPRELEASE dizendo que aquele IP ja pode ser usado
por outro Host;
• DHCPINFORM – Utilizado quando o Cliente já possui endereço IP, mas precisa

de outras informações, como o servidor DNS por exemplo, o mesmo envia um
DHCPINFORM pedindo tais informações para o servidor DHCP.
O "DHCP"oferece três tipos de alocação de endereços IP:
• Atribuição manual - Quando desejamos que certo cliente tenha determinado

endereço IP, temos que "amarrar"o endereço "MAC"da máquina cliente ao en-
dereço IP desejado. O servidor DHCP descobre o "MAC ADDRESS"do cliente
através do "DHCPDISCOVER", assim identificando quais são as máquinas que
irão receber configurações personalizadas;
• Atribuição automática - Onde o cliente obtém um endereço de um espaço de

endereços possíveis chamado de range, especificado pelo administrador. Ge-
ralmente não existe vínculo entre os vários "MAC’s"habilitados a esse espaço

de endereços. Assim que o cliente se loga pela primeira vez na rede, ele recebe
um endereçamento definitivo;
• Atribuição dinâmica - O único método que dispõe da reutilização dinâmica

dos endereços. O administrador disponibiliza um espaço de endereços possí-
veis, e cada cliente terá o software "TCP/IP"da sua interface de rede configura-
dos para requisitar um endereço por "DHCP"assim que a máquina inicialize. A
alocação utiliza um mecanismo de aluguel do endereço, caracterizado por um
tempo de vida. Após a máquina se desligar, o tempo de vida naturalmente irá
expirar, e da próxima vez que o cliente se ligue, o endereço provavelmente será
outro. Podemos ainda configurar uma atualização dinâmica dos servidores de
"DNS"para que cada cliente disponha também de um registro "DNS".
3.0.19 Laboratório
Primeiro iremos instalar o pacote do servidor dhcp:
1 root@datacenter :~ # aptitude install isc - dhcp - server
Vamos renomear o arquivo original do DHCP para uma possível consulta:
1 root@datacenter :~ # mv / etc / dhcp / dhcpd . conf / etc / dhcp / dhcpd . conf .

distro
Agora vamos iniciar nossa configuração num arquivo zerado. Abra-o e insira o con-
teúdo abaixo:
1 root@datacenter :~ # vim / etc / dhcp / dhcpd . conf

2 ddns - update - style none ;
3 deny unknown - clients ;

4 log - facility local7 ;

5 subnet 192.168. X .0 netmask 255.255.255.0 {
6 range 192.168. X .100 192.168. X .110;
7 server - identifier datacenter ;
8 authoritative ;
9 option subnet - mask 255.255.255.0;
10 option domain - name " dexter . com . br ";
11 option domain - name - servers 8.8.8.8 ,208.67.222.222;
12 option routers 192.168. X .1;
13 default - lease - time 600;
14 max - lease - time 7200;
15 }
A prova de certificação pode cobrar a utilização de cada opção, como "option

routers"ou "option domain-name-servers".
Uma vez criado o arquivo de configuração, basta reinicializar o servidor DHCP:
1 root@datacenter :~ # service isc - dhcp - server restart
Principais diretrizes do arquivo de configuração
• ddns-update-style: forma que o DHCP irá armazenar as informações de redes

dos clientes. Atualmente são implementados dois esquemas de atualização
do DNS - o modo de atualização do DNS improvisado (ad-hoc) e o modo de
atualização do esquema de interação do intervalo DHCP-DNS (interim);
• deny unknown-clients: nega acesso a MAC não cadastrado;

• log-facility local7: Criaremos uma entrada no /etc/rsyslog.conf para os logs do

servidor DHCP;
• subnet 192.168.X.0 netmask 255.255.255.0: qual rede o DHCP irá responder

quando for solicitado;
• range 192.168.X.100 192.168.X.110: faixa de IPs que será disponibilizado aos

clientes;
• server-identifier: Devemos identificar o nome do nosso servidor;
• authoritative: Indica que o servidor DHCP será autoritário em todo o segui-

mento da rede;
• option subnet-mask 255.255.255.0 - Essa opção define a máscara de subrede

a ser fornecida aos clientes;
• option domain-name dexter.com.br - O nome de domínio do cliente;
• option domain-name-servers 8.8.8.8,208.67.222.222 - Essa opção lista os ser-

vidores de nomes (DNS) a serem utilizados para resolução de nomes;
• option routers 192.168.X.1 - O cliente, além do número IP, recebe também a

informação do número do "gateway"de sua rede;
1 default - lease - time 600 - Servidores " DHCP " cedem endere ç os sob
pedido por um tempo pr é - determinado . O padr ão nesse exemplo é
ceder o endere ço IP por 600 segundos , ou 10 minutos ;
• max-lease-time 7200 - Caso o cliente solicite um tempo maior, o tempo máximo

permitido será de 7.200 segundos (2 horas);

Para habilitar o suporte ao servidor dinâmico, utilize dynamic-bootp
Exemplo: range dynamic-bootp 192.168.X.100 192.168.X.110;
Configurando os LOGs
No Debian, o arquivo de configuração do syslog fica em /etc/rsyslog.conf. A seguinte

entrada pode ser adiciona no final do arquivo:
1 root@datacenter :~ # vim / etc / rsyslog . conf

2 local7 .* / var / log / dhcpd . log
3 root@datacenter :~ # touch / var / log / dhcpd . log
4 root@datacenter :~ # service rsyslog restart
Com isso todos os logs com origem da facility local7 (facility essa que representa o
serviço de DHCP) em qualquer priority (indica o nível de importância do log) serão
logados no /var/log/dhcpd.log.
Configurando os clientes DHCP
Vamos configurar a máquina Cliente Squeeze. Abra o arquivo de rede e configure a

interface eth0 para pegar IP via DHCP :
1
2 root@squeeze :~ # vim / etc / network / interfaces
3 auto eth0
4 iface eth0 inet dhcp
Reinicie o serviço de rede e

1 root@squeeze :~ # service networking restart

2 root@squeeze :~ # dhclient eth0 -v
Caso não tenha o comando dhclient, “setar” um IP fixo manualmente e instalar

o pacote abaixo: # aptitude install isc-dhcp-client
Para visualizar a placa de rede que está utilizando: # mii-tool
3.0.20 Fixar IP via DHCP
É possível fixar o IP via "DHCP"para máquinas respectivas. Isso é feito associando

o "MAC Address"da placa de rede com um endereço IP. Considere que temos 3
estações:
Para este cenário ser possível adicione no final do arquivo de configuração "/etc/dhcp/dhcpd.con
o que está abaixo:
1 host squeeze {
2 hardware ethernet 00:00:00:00:00:00;
3 fixed - address 192.168. X .10;
4 }
5 host windowsxp {


7 fixed - address 192.168. X .20;
8 }
9 host windows7 {
11 fixed - address 192.168. X .30;
12 }
Você deve trocar o MAC Address informado aqui pelo de suas estações.
Configurações adicionais
No que diz respeito ao servidor, podemos ainda verificar alguns arquivos para diag-
nosticar problemas ou mesmo extrair relatórios. Vejamos:
1 root@datacenter :~ # less / var / lib / dhcp / dhcpd . leases

2 lease 192.168. X .102 {
3 starts 2 2011/06/28 01:27:10;
4 ends 2 2011/06/28 01:28:13;
5 tstp 2 2011/06/28 01:28:13;
6 cltt 2 2011/06/28 01:27:10;
7 binding state free ;
8 hardware ethernet 08:00:27:2 e: f9 : fa ;
9 }
Este arquivo armazena o banco de dados de aluguel do cliente DHCP. Este arquivo
não deve ser modificado manualmente. As informações de aluguel DHCP de cada
endereço IP recentemente atribuído são armazenadas automaticamente no banco
de dados de aluguel. As informações incluem datas do aluguel e os endereços MAC
da placa de interface de rede usada para recuperar o aluguel.
Todos os horários do banco de dados de aluguel estão em GMT (Greenwich Mean

Time) e não horário local. O banco de dados de aluguel é recriado de tempos em

tempos para que não fique muito grande. Primeiramente, todos os aluguéis conhe-
cidos são salvos em um banco de dados temporário de aluguel. Então, o arquivo
dhcpd.leases é renomeado para dhcpd.leases , e o banco de dados temporário é
salvo como dhcpd.leases.
O daemon DHCP pode ser finalizado (killed) ou o sistema pode falhar (crash) após
o banco de dados de aluguel ter sido renomeado como o arquivo backup, mas antes
do novo arquivo ser salvo. Se isto acontecer, o arquivo dhcpd.leases não existe, mas
é necessário para iniciar o serviço. Não crie um novo arquivo de aluguel. Se você
o fizer, todos os aluguéis antigos serão perdidos e causarão muitos problemas. A
solução correta é renomear o arquivo backup dhcpd.leases como dhcpd.leases e
então iniciar o daemon.
Outro arquivo importante é o /etc/default/isc-dhcp-server, onde podemos setar qual

interface de rede responderá as requisições dos clientes. Basta configurarmos con-
forme abaixo:
1 root@datacenter :~ # less / etc / default / isc - dhcp - server

2 11 INTERFACES =" eth0 "
Pelo lado do cliente podemos acompanhar quais os endereços IPs que já recebeu
analisando o arquivo “/var/lib/dhcp/dhclient.leases”:
1 root@datacenter :~ # less / var / lib / dhcp / dhclient . leases

2 lease {
3 interface " eth0 ";
4 fixed - address 192.168. X .110;
6 option dhcp - lease - time 3600;
7 option dhcp - message - type 5;
8 option dhcp - server - identifier 192.168. X .110;
9 renew 2 2011/06/21 21:55:15;
10 rebind 2 2011/06/21 22:22:06;
11 expire 2 2011/06/21 22:29:36;

. . . ou o arquivo /var/lib/dhcp/dhclient.eth0.leases
1 lease {
2 interface " eth0 ";
3 fixed - address 192.168. X .110;
5 option dhcp - lease - time 3600;
6 option dhcp - message - type 5;
7 option dhcp - server - identifier 192.168. X .110;
8 renew 5 2011/06/24 00:14:42;
9 rebind 5 2011/06/24 00:14:42;
10 expire 5 2011/06/24 00:14:42;
11 }
E para finalizar, evite colocar 2 servidores DHCP na mesma rede, pois isto irá gerar
alguns transtornos para os clientes!

Capítulo 4
Servidor NFS
4.1 Cenário
A empresa Dexter Courier precisa de um Storage de baixo custo para compartilhar

arquivos para os membros da rede, incluindo máquinas Windows.
4.2 Proposta de solução
Vamos utilizar um computador com GNU/Linux servindo como Storage da rede, con-
tendo os diretórios necessários para o acesso dos membros da empresa. Vamos
configurar grupos e usuários com as devidas permissões de acesso, além de geren-
ciar as quotas por grupo.
4.3 Introdução teórica
Originalmente desenvolvido pela Sun Microsystems, o NFS (Network File System)

permite compartilhar diretórios e arquivos na rede, fazendo com que os clientes aces-
43
4.4 Conhecendo o NAS 4Linux – www.4linux.com.br
sem os dados remotos como se estivessem no micro local. Por esse motivo o
“NFS” é uma solução interessante para centralização de diretórios pessoais e recur-
sos compartilhados em rede, já que as operações de backup e manutenção poderão
ser centralizadas. Para isto o NFS faz uso do Remote Procedure Call.
Para que os clientes possam acessar o servidor NFS, é necessário que os seguintes
serviços estejam sendo executados no servidor: portmapper - converte números dos
processos RPC em números no protocolo TCP/IP. Através deste daemon, os clientes
conseguem o número da porta do servidor NFS;
portmapper - converte números dos processos RPC em números no protocolo TCP/IP.

Através deste daemon, os clientes conseguem o número da porta do servidor NFS;
status - oferece informações sobre o compartilhamento afim de evitar erros;
nlockmgr - gerenciador de bloqueios do NFS;
nfsd - atende às requisições dos clientes;
mountd - executa as solicitações do nfsd (montagem dos clientes);
4.4 Conhecendo o NAS
O termo NAS (Network-Attached Storage) foi introduzido com os primeiros sis-

temas operacionais para servidores de compartilhamento de arquivos NetWare da
Novell e com o protocolo NCP em 1983. No mundo UNIX, o lançamento do NFS
da Sun Microsystems permitiu que os servidores de rede compartilhassem espaço
de armazenamento de dados com os clientes de sua rede. O 3Server e o 3+Share
da 3Com foram os primeiros servidores feitos especificamente para esta função (in-
cluindo hardware proprietário, software, e discos múltiplos), e a empresa liderou o
segmento de mercado de 1985 até o início dos anos 90. A 3Com e a Microsoft
desenvolveriam o software LAN Manager e o protocolo para entrar neste novo mer-

4Linux – www.4linux.com.br 4.4 Conhecendo o NAS
cado. Inspirados pelo sucesso dos servidores de arquivos da Novell, IBM e Sun,
várias empresas desenvolveram servidores dedicados para armazenamento de da-
dos. Enquanto a 3Com estava entre as primeiras empresas a fabricar NAS dedicados
para sistemas operacionais de desktop, a Auspex Systems foi a primeira a desen-
volver um servidor NFS dedicado para uso com UNIX. Um grupo de engenheiros da
Auspex se separou da empresa no início dos anos 90 para criar o filtro integrado
NetApp, o qual suportava tanto o CIFS (Windows) quanto o NFS (UNIX), e tinha es-
calabilidade superior e maior facilidade de instalação. Aqui inicia o mercado para
dispositivos NAS proprietários.
Sistemas NAS podem conter mais de um HD, podendo também contar com a tec-
nologia RAID (Redundant Arrays of Independent Disks), centralizando a respon-
sabilidade de servir os arquivos em uma rede e deste modo liberando recursos de
outros servidores desta rede. Os protocolos utilizados pelo NAS são o NFS, popular
em sistemas UNIX, ou CIFS/SMB (Common Internet File System/Server Message
Block) em ambientes Windows, assim como o tradicional FTP.
Equipamentos NAS estão sendo usados pelo mundo corporativo há algum tempo,
porém, com a redução dos custos destes dispositivos e com a popularização de re-
des domésticas, diversos produtos NAS surgiram para o mercado pessoal. Estes
dispositivos NAS de uso doméstico são baseados em processadores baratos ro-
dando uma versão embarcada de Linux. Além do baixo custo, estes aparelhos têm
baixo consumo de energia e têm uma instalação relativamente simples. Existem
alternativas open source para implementações caseiras de NAS, como:
FreeNAS (http://www.freenas.org/)
Openfiler (http://www.openfiler.com/)
NASLite (http://www.serverelements.com/)
Abaixo temos alguns exemplos de dispositivos NAS:

4.5 NAS versus SAN 4Linux – www.4linux.com.br
LG-N4B1-NAS-Blu-ray
Seagate-Blackarmor-NAS 440
4.5 NAS versus SAN
O NAS disponibiliza armazenamento e sistema de arquivos, contrastando com o

SAN (Storage Area Network), que só realiza armazenamento e deixa ao cliente
a tarefa de lidar com o sistema de arquivos. A principal distinção entre os dois
sistemas de armazenamento é que o NAS fornece protocolos de arquivo e o
SAN protocolos de camada. Raramente vê-se o sistema SAN sendo utilizado fora
de grandes redes de computadores.
Enquanto o NAS é especializado em dados orientados aos arquivos, o SAN cuida de

4Linux – www.4linux.com.br 4.5 NAS versus SAN
aumentar a velocidade do ERP, CRM e banco de dados pesados. A batalha entre o

NAS e a robusta SAN é um tópico popular comum para toda a indústria de TI, não
só em armazenamento. Mas este confronto aconteceu ocasionalmente.
A empresa Network Appliance foi a primeira a comercializar produtos em NAS, que,

conectados na mesma rede de dados, é baseado em um sistema operacional de rede
simplificado.
A tecnologia foi adotada por legiões de usuários da Network Appliance e por usuários
de Windows para hospedar o Microsoft Exchange e o SQL Server. Também foi usado
por milhares de outros para o armazenamento de seus dados orientados a arquivos
(file-oriented).
Com o tempo, o SAN foi adotado para criar partições diferentes no resto do tráfego
da LAN e, ao fazer isso, aumentar a velocidade de banco de dados com grande
quantidade de transações, sistemas ERP e CRM.
“Separar a propriedade de um servidor de seu storage e colocando todos os apare-

lhos de armazenamento diretamente em uma rede de fibra permite diversas cone-
xões ‘many-to-many’ dos servidores ao storage e do storage para outros aparelhos
de storage. Esta estratégia garante os benefícios tradicionais de colocar os apare-
lhos de storage em rede, como aumentar a disponibilidade, escalabilidade e desem-
penho”, escreveu o consultor Barb Goldworm.
Os defensores da SAN dizem que a tecnologia é a melhor quando se busca de-

sempenho para aplicações críticas para os negócios como banco de dados, ERP e
CRM. O NAS, definem, é impactado por problemas em desempenho. Mas se você
perguntar para usuários de NAS, no entanto, eles vão dizer que o uso do NAS para
aplicações críticas nunca gerou problemas. Por exemplo, um teste de um sistema
NAS da BlueArc NAS mostrou mais de 192,900 operações por segundo.
Abaixo alguns exemplos de SAN:

4.6 E o DAS? 4Linux – www.4linux.com.br
4.6 E o DAS?
DAS (Direct-Attached Storage) é o mais comum tipo de armazenamento. Assim

como o nome sugere, implica que todos os discos e dispositivos de armazenamento

4Linux – www.4linux.com.br 4.7 Laboratório
estejam no servidor ao invés de um dispositivo separado. Tem uma bola relação

custo-benefício, principalmente para pequenas e médias empresas.
Essa técnica é mais adequada para pequenos servidores que oferecem acesso a
arquivos para diversos PCs ou usuários de um pequeno escritório. É uma forma
confiável para armazenar aplicações que rodam em um servidor.
Tipicamente DAS é um sistema de armazenamento conectado diretamente a um

computador usando Host Bus Adapter (HBA). Entre ambos não há dispositivos de
rede (como hub, switches etc). Está é a principal diferença entre o DAS e os SAN
e NAS.
No entanto, essa arquitetura tem algumas limitações em relação à escalabilidade,

uma vez que os servidores suportam um número limitado de discos. Isto significa
que se a sua empresa precisar de mais espaço, a única alternativa é utilizar discos
de alta capacidade.
Os principais protocolos usados pelo DAS são ATA, SATA, eSATA, SCSI, SAS e
Fibre Channel.
4.7 Laboratório
4.7.1 Configurando o Servidor
Como a finalidade deste servidor é prover apenas espaço em disco, vamos realizar
uma configuração simples com NFS, compartilhando dois diretórios.
Primeiro iremos criar os diretórios a serem compartilhados:
1 root@storage :~ # mkdir / srv / dexter ; mkdir / srv / lixeiras

4.7 Laboratório 4Linux – www.4linux.com.br
Agora partiremos para a instalação do servidor NFS e suas configurações. Vamos

instalar também o NMAP para fazer alguns testes:
1 root@storage :~ # aptitude install nfs - kernel - server nmap
Vamos analisar nosso servidor, verificando portas abertas e serviços:
1 root@storage :~ # nmap -sT -sV localhost

2 PORT STATE SERVICE VERSION
3 111/ tcp open rpcbind
4 2049/ tcp open rpcbind
Vejamos com o netstat:
1 root@storage :~ # netstat - luptan

2 Conex õ es Internet Ativas ( servidores e estabelecidas )
3 Proto Recv -Q Send -Q EndLocal EndRemoto Estado PID / Program name
4 tcp 0 0 0.0.0.0:111 0.0.0.0:* OU ÇA 1468/ portmap
5 tcp 0 0 0.0.0.0:60630 0.0.0.0:* OU ÇA 1920/ rpc . mountd
6 tcp 0 0 0.0.0.0:2049 0.0.0.0:* OU ÇA -
7 tcp 0 0 0.0.0.0:57409 0.0.0.0:* OU ÇA 1677/ rpc . statd
8 udp 0 0 0.0.0.0:47545 0.0.0.0:* 1677/ rpc . statd
9 udp 0 0 0.0.0.0:1005 0.0.0.0:* 1677/ rpc . statd
10 udp 0 0 0.0.0.0:111 0.0.0.0:* 1468/ portmap
11 udp 0 0 0.0.0.0:52472 0.0.0.0:* -
12 udp 0 0 0.0.0.0:2049 0.0.0.0:*
Podemos observar que temos os serviços do portmap e nfs rodando, respectiva-

mente, nas portas 111 e 2049, conforme o arquivo /etc/services.
1 root@storage :~ # vim / etc / services

2 .
3 75 sunrpc 111/ tcp portmapper # RPC 4.0 portmapper
4 76 sunrpc 111/ udp portmapper
5 .
6 298 nfs 2049/ tcp # Network File System
7 299 nfs 2049/ udp # Network File System
Podemos ver os serviços necessários ao funcionamento do NFS executando:
1 root@storage :~ # rpcinfo -p
2 programa vers ão protocolo porta
3 100000 2 tcp 111 portmapper
4 100000 2 udp 111 portmapper
5 100024 1 udp 47545 status
6 100024 1 tcp 57409 status
7 100021 1 udp 52472 nlockmgr
8 100021 3 udp 52472 nlockmgr
9 100021 4 udp 52472 nlockmgr
10 100021 1 tcp 39468 nlockmgr
11 100021 3 tcp 39468 nlockmgr
12 100021 4 tcp 39468 nlockmgr
13 100003 2 tcp 2049 nfs
14 100003 3 tcp 2049 nfs
15 100003 4 tcp 2049 nfs
16 100003 2 udp 2049 nfs
17 100003 3 udp 2049 nfs
18 100003 4 udp 2049 nfs
19 100005 1 udp 46126 mountd
20 100005 1 tcp 60630 mountd
21 100005 2 udp 46126 mountd
22 100005 2 tcp 60630 mountd
23 100005 3 udp 46126 mountd
24 100005 3 tcp 60630 mountd
Depois destes testes, vamos configurar o compartilhamento no arquivo /etc/exports,

deixando-o como no exemplo:
1 root@storage :~ # vim / etc / exports

2 / srv / dexter 192.168. X .2( rw , root_squash , no_subtree_check , async )
3 / srv / lixeiras 192.168. X .2( rw , root_squash , no_subtree_check , async )
As opções mais usadas são:
ro - compartilhar apenas para leitura;
rw - compartilhar para leitura e gravação;
root_squash - opção padrão, faz com que o usuário root não tenha privilégios dentro
do compartilhamento NFS montado;
no_root_squash - permite ao usuário root os mesmos privilégios que num diretório

local;
async - Útil em redes locais pois permite que o NFS transfira arquivos de forma
assíncrona, sem precisar esperar pela resposta do cliente a cada pacote enviado,
aumenta um pouco a velocidade de transferência de dados;
Por padrão no compartilhamento, ele sempre assume a opção:

“no_subtree_check”. Esta opção faz com que os subdiretórios do compartilha-
mento sejam exportados. Veja mais opções do arquivo “/etc/exports” lendo seu
manual => man 5 exports
Após isto, execute o comando para reler o arquivo:
1 root@storage :~ # exportfs -r

Pronto! Diretórios compartilhados. Para realizar uma verificação execute:
1 root@storage :~ # showmount -e localhost

2 Export list for localhost :
3 / srv / lixeiras 192.168. X .2
4 / srv / dexter 192.168. X .2
Caso haja algum problema, reinicie os serviços:
1 root@storage :~ # service portmap restart

2 root@storage :~ # service nfs - kernel - server restart
4.7.2 Configurando o Cliente
Para configuramos o cliente NFS, basta a instalação do pacote nfs-common. Faça a

instalação na máquina “Datacenter”:
1 root@datacenter :~ # aptitude install nfs - common
Antes de efetuarmos a montagem efetiva dos compartilhamentos NFS, vamos remo-

ver a entrada LVM referente ao “/srv”:
1 root@datacenter :~ # umount / dev / root_vg / lv_srv

2 root@datacenter :~ # lvremove / dev / root_vg / lv_srv
3 Do you really want to remove active logical volume lv_srv ? [y/n ]: y
4 Logical volume " lv_srv " successfully removed
NÃO ESQUEÇA de remover a linha do /etc/fstab!!!

Agora crie o ponto de montagem:
1 root@datacenter :~ # mkdir -p / srv / storage ; mkdir / srv / lixeiras
Verifique os compartilhamentos do servidor:
1 root@datacenter :~ # showmount -e 192.168. X .4

2 Export list for 192.168. X .4:
3 / srv / lixeiras 192.168. X .2
4 / srv / dexter 192.168. X .2
Monte os compartilhamentos:
1 root@datacenter :~ # mount -t nfs 192.168. X .4:/ srv / dexter / srv / storage

2 root@datacenter :~ # mount -t nfs 192.168. X .4:/ srv / lixeiras / srv /
lixeiras
Verifique a montagem do compartilhamento com o comando mount:
1 root@datacenter :~ # mount
2 192.168. X .4:/ srv / dexter on / srv / storage type nfs (rw , addr =192.168. X
.4)
3 192.168. X .4:/ srv / dexter on / srv / lixeiras type nfs (rw , addr =192.168. X
.4)
Como usuário root, tente criar um arquivo:
1 root@datacenter :~ # touch / srv / storage / teste_root

2 touch : não foi poss í vel tocar "/ srv / storage / teste_root ": Permiss ão
negada

Como vimos, com a opção “root_squash” ativada por padrão o root não consegue
criar arquivos/diretórios dentro do compartilhamento! Vamos alterar o /etc/exports
no servidor “Storage” e permitir que o root grave no compartilhamento, habilitando a
opção “no_root_squash”:
1 root@storage :~ # vim / etc / exports

2 / srv / dexter 192.168. X .2( rw , no_root_squash , no_subtree_check , async )
3 / srv / lixeiras 192.168. X .2( rw , no_root_squash , no_subtree_check , async )
4 root@storage :~ # exportfs -r
Refaça o teste. Agora podemos criar o arquivo!
1 root@datacenter :~ # touch / srv / storage / teste_root ; ls -lh / srv /

storage
2 -rw -r --r -- 1 root root 0 Jun 29 22:15 teste_root
Verifique as conexões com o servidor executando:
1 root@datacenter :~ # showmount -a 192.168. X .4

2 All mount points on 192.168. X .4:
3 192.168. X .2:/ srv / dexter
4 192.168. X .2:/ srv / lixeiras
Para verificar o status do servidor “nfs”, digite os comandos: “nfsstat” e “nfsstat

-m”
Finalmente, para que o compartilhamento seja montado no boot, vamos adicionar a

configuração no final do arquivo /etc/fstab:

1 root@datacenter :~ # vim / etc / fstab

2 192.168. X .4:/ srv / dexter / srv / dexter nfs defaults , soft 0 0
3 192.168. X .4:/ srv / lixeiras / srv / lixeiras nfs defaults , soft 0 0

Capítulo 5
Implementando RAID + LVM
5.0.3 Introdução Teórica - RAID
“RAID, do inglês Redundant Array of Independent Disks, significa Conjunto Re-

dundante de Discos Independentes. A ideia básica por trás do RAID é combinar
diversos discos e de baixo custo em um conjunto, a fim de atingir objetivos de de-
sempenho ou redundância inatingíveis com um disco grande e de custo alto. Este
conjunto de discos aparece para o computador como uma única unidade ou disco de
armazenamento lógico.
O conceito fundamental do RAID é que os dados podem ser distribuídos ao longo de

cada disco do conjunto de maneira consistente. Para fazer isso, primeiramente os
dados precisam ser quebrados em pedaços de tamanho consistente (geralmente de
32KB ou 64KB, apesar de poder usar tamanhos diferentes). Cada pedaço é então
gravado em um disco rígido no RAID, conforme o nível do RAID usado. Quando os
dados tiverem que ser acessados, o processo é revertido, dando a impressão de que
os discos múltiplos são um disco grande. “
[ http://web.mit.edu/rhel-doc/3/rhel-sag-pt_br-3/ch-raid-intro.html ]
57
Temos como principais vantagens do RAID:
• Ganho de desempenho no acesso para leitura ou gravação;
• Redundância em caso de falha em um dos discos;
• Uso múltiplo de várias unidades de discos;
• Facilidade em recuperação de conteúdo perdido.;
• Impacto reduzido na falha de um disco.
“Temos 2 formas de se montar um sistema em RAID:
Via Software: Feito por aplicativos e módulos do sistema operacional. O “RAID” via
software só entra em funcionamento depois que o “Kernel” é carregado na memória
do computador. A principal vantagem é a facilidade de configuração e a flexibilidade,
já que podemos trabalhar com vários discos diferentes. A principal desvantagem é a
dependência da correta configuração do sistema operacional.
Características mais importantes:
1.Processo threaded rebuild;
2.Portabilidade dos conjuntos entre máquinas Linux sem reconstrução;
3.Reconstrução do ARRAY no background, usando recursos ociosos do sistema;
4.Suporte ao disco hot-swappable (pode ser substituído sem desligar a máquina);
5.Detecção automática da CPU para aproveitar determinadas otimizações.
Via Hardware: Feito por uma placa controladora que conecta um disco ao outro. A
principal vantagem é o desempenho, já que um “RAID” via hardware é mais rápido

e independente do sistema operacional. A principal desvantagem, é que a placa

controladora se torna um SPOF - Single Point of Failure, ou seja, é necessário ter
uma controladora de discos igual ou compatível com a que você possui para o caso
de falhas neste hardware. “
[ http://web.mit.edu/rhel-doc/3/rhel-sag-pt_br-3/s1-raid-approaches.html ]
Tipos de RAID
Os principais níveis de “RAID” utilizados hoje no mercado são os níveis 0, 1, 5, 6 e

suas derivações, como por exemplo, o RAID 10. Vamos entendê-los:
RAID 0 (Stripping): Este é o único nível de “RAID” que não implementa redundân-
cia. Sua finalidade é aumentar o desempenho de leitura e gravação, uma vez que ao
gravar, divide os dados em partes iguais e armazena cada fragmento em um disco
diferente simultaneamente. Por isto, com dois discos, a velocidade de leitura pra-
ticamente dobra. Com três discos, triplica. E assim por diante. São necessários
ao menos dois discos para implementar “RAID 0” e eles podem ser de tamanhos
diferentes.
1 Ent ão o RAID 0 garante redund â ncia ?
Não!!! Esta é a desvantagem, pois se qualquer um dos discos falhar, o sistema

operacional para de funcionar, além de ocasionar perda dos dados. Portanto, é um
método que requer cuidados.
1 Caracter í sticas do RAID 0:

2
3 * Excelente grava ção e leitura ;
4

5 * Aproveitamento total de espa ço;

6
7 * Nenhuma redund â ncia !
RAID 1 (Mirroring): O nível mais utilizado. Sua principal finalidade é prover redun-
dância dos dados. Esta é garantida pela duplicação dos dados que são gravados
em cada par de discos, logo, se um deles falhar, o outro continuará operando e man-
tendo a informação disponível, até que a substituição do disco defeituoso seja feita.
O ganho de desempenho está na leitura, uma vez que os dados são lidos em par-
tes iguais e simultaneamente de todos os discos. A desvantagem desse nível é que
só metade do volume total de armazenamento nos discos utilizados ficará disponí-
vel para o sistema operacional. É preciso no mínimo dois discos para implementar
“RAID 1”, sempre em pares.
1 RAID1 é backup ? Não !!!!! É apenas redund â ncia .
DICA DE SEGURANÇA: “RAID 1” espelhado não é backup. Se você apa-

gar um arquivo acidentalmente, esse arquivo vai ser apagado em todos os discos.
Sempre tenha uma CÓPIA dos dados.
1 Caracter í sticas do RAID 1:

2
3 * Redund â ncia : se um dos discos falhar , o sistema continua
funcionando ;
4
5 * Voc ê vai precisar de 2 HDs , mas só vai usar a á rea ú til de 1;
6
7 * Reduz um pouco o desempenho da escrita , pois o mesmo dado é
gravado nos discos que estiverem em " RAID 1".

Fique atento, a prova do LPI irá cobrar a utilização e conceitos de “RAID”.

Um comando que podemos utilizar para fazer backup e manutenção de arquivos no
sistema é o comando “rsync”. Outros comandos que nos mostra alguns detalhes
importantes são “hdparm” e “sdparm”.
RAID 5: Neste nível de “RAID” teremos um balanço das vantagens e desvantagens

do níveis anteriores, ou seja, “RAID 5” provê um ganho de desempenho e tolerância
a falhas a custos menores que “RAID 0” ou “RAID 1” individualmente. O ganho de
desempenho está mais uma vez na leitura. Quanto mais discos forem adicionados
a composição, mais rápida será a leitura, uma vez que a gravação é distribuída em
blocos de tamanhos iguais por todos os discos.
RAID 6: É um padrão relativamente novo, suportado por apenas algumas con-

troladoras. Ele é semelhante ao RAID 5, porém usa o dobro de bits de paridade,
garantindo a integridade dos dados caso até 2 dos HDs falhem ao mesmo tempo. Ao
usar 7 HDs de 500 GB em RAID 6, por exemplo, teríamos 2.5 TB para dados mais 1
TB de códigos de paridade.
A percentagem de espaço sacrificado decai conforme são acrescentados mais dis-

cos, de forma que o uso do RAID 6 vai tornado-se progressivamente mais atrativo.
No caso de um grande servidor, com 41 HDs, por exemplo, seria sacrificado o es-
paço equivalente a apenas dois discos, ou seja, menos de 5% do espaço total. Em

troca, ganha-se proteção contra a possibilidade de um segundo HD falhar durante o

processo de substituição e reconstrução dos dados do primeiro.
Tanto no caso do RAID 5, quanto no RAID 6, o servidor continua funcionando nor-

malmente durante todo o processo de substituição do disco, embora a performance
decaia, sobretudo logo depois da substituição do drive defeituoso, quando o sistema
precisa regravar os dados lendo as informações armazenadas em todos os outros
discos e fazendo os cálculos de paridade.
[ http://www.hardware.com.br/termos/raid-6 ]
Combinações de RAID
RAID 10: Combina as vantagens do RAID 0 e RAID 1 num único sistema. Fornece
segurança efetuando espelhamento de todos os dados num conjunto secundário de
discos enquanto utiliza listagem em cada conjunto de discos para acelerar as trans-
ferências de dados. O RAID 10 permite no máximo 2 discos avariados de 2 pares
diferentes.

O volume de disco RAID 10 é ideal para organizações que executam bases de dados
e outras aplicações com base em transações que requerem eficiência de armazena-
mento e proteção de dados críticos.
Em artigos que comparam os níveis RAID 5 e RAID 10, as respostas do RAID 10

foram melhores, apesar do teste ter sido feito utilizando RAID por hardware, mas
vale a pena a comparação. Veja o gráfico abaixo:
RAID 0+1: É uma combinação dos níveis 0 (Striping) e 1 (Mirroring), onde os da-
dos são divididos entre os discos para melhorar o rendimento, mas também utilizam
outros discos para duplicar as informações. Assim, é possível utilizar o bom rendi-
mento do nível 0 com a redundância do nível 1. No entanto, é necessário pelo menos
4 discos para montar um RAID desse tipo. Tais características fazem do RAID 0 + 1

o mais rápido e seguro, porém o mais caro de ser implantado. Falhando 1 disco, o
sistema vira um RAID 0.
Vantagens:
• Segurança contra perda de dados;
• Pode falhar 1 dos HD’s, ou os dois HD’s do mesmo DiskGroup.
Desvantagens:
• Alto custo de expansão de hardware (custo mínimo = 4xHDs).
• Os drives devem ficar em sincronismo de velocidade para obter a máxima per-

formance.
• RAID 50

• RAID 60
• RAID 100
A prova LPI pode cobrar conhecimentos do aluno sobre os níveis de “RAID”

citados. Não esqueça que “RAID” não é Backup. Tenha sempre Backup.

5.0.4 Introdução Teórica – LVM
"O LVM (Logical Volume Manager) é um recurso incluído no Kernel Linux a partir da
versão 2.4 que cria uma camada de abstração entre o sistema operacional e os HDs
(ou outras unidades de armazenamento utilizadas, como o RAID por exemplo). Ele
adiciona alguns complicadores adicionais na configuração, mas, em compensação
oferece um conjunto de vantagens bastante interessantes.
Imagine que no LVM o sistema não vê HDs e partições, mas sim um ou mais volumes
lógicos. Cada volume se comporta como se fosse uma partição, que é formatada e
montada da forma usual. Estes volumes são agrupados em um grupo de volumes
lógicos (logical volume group) que se comporta de forma similar a um HD.
O pulo do gato é que o grupo de volumes lógicos pode combinar o espaço de vários
HDs e ser modificado conforme necessário, incorporando mais HDs. Os volumes
lógicos dentro dele também podem ser redimensionados livremente conforme for
necessário.
Se você precisa de mais espaço dentro do volume referente à pasta /home, por
exemplo, você poderia reduzir o tamanho de um dos outros volumes do sistema (que
estivesse com espaço vago) e aumentar o tamanho do volume referente ao /home,
tudo isso com o servidor operante.
Outra possibilidade é ir adicionando novos HDs ao servidor conforme precisar de

mais espaço. Ao instalar um novo HD, você começaria criando um volume físico,
englobando todo o espaço do HD. Uma vez que o volume físico é criado, você pode
expandir o grupo de volumes lógicos, de forma que ele incorpore o espaço referente
ao novo HD. A partir daí, você pode expandir os volumes lógicos, usando o espaço
livre.
Caso seja utilizada uma controladora SCSI ou SAS com suporte a hot-swaping, é
possível até mesmo adicionar, remover ou substituir HDs, fazendo as alterações ne-
cessárias nos volumes lógicos, com o servidor ligado!

É importante enfatizar que o LVM é apenas uma mudança na forma como o sistema
acessa os discos, ele não é um substituto para o RAID. No LVM você pode agrupar
vários HDs em um único grupo de volumes lógicos, mas se um dos HDs apresentar
defeito, o servidor ficará inoperante e você perderá os dados armazenados no disco
afetado, diferente do RAID, onde você pode sacrificar parte do espaço para ter uma
camada de redundância.
O grupo de volumes lógicos criado pelo instalador é visto pelo sistema como "/dev/vg01"e
os volumes lógicos dentro dele são vistos como "/dev/vg01/lv01", "/dev/vg01/lv02",
etc. Os nomes podem ser alterados da maneira que quiser. Naturalmente, é possí-
vel também deixar de usar o LVM, voltando ao sistema normal de particionamento.
Nesse caso, você só precisa deletar os volumes e o grupo de volumes lógicos e criar
a partições desejadas usando o espaço disponível.
http://www.hardware.com.br/dicas/entendendo-lvm.html
Uma implementação melhor do LVM é em conjunto com volumes RAID, pois no caso
de falhar um dos discos, continuamos com a leitura/gravação nos demais. Em re-
lação ao usuário, o mesmo nem saberá que tem toda esta estrutura por trás da
manipulação dos dados!

5.0.5 Laboratório – RAID
Vamos adicionar 4 discos de 5GB no Servidor DataCenter para realizarmos este

laboratório. Este servidor já possui RAID-1 sem SPARE, portanto iremos fazer as
configurações usando um RAID-5 com SPARE, além de verificarmos o arquivo de
monitoração.
Primeiro crie uma partição primária em cada um dos discos com o espaço total do
disco, sendo esta partição do tipo Linux raid autodetect (fd):
1 root@datacenter :~ # cfdisk / dev / sdc

2 root@datacenter :~ # cfdisk / dev / sdd
3 root@datacenter :~ # cfdisk / dev / sde
4 root@datacenter :~ # cfdisk / dev / sdf
Verifique se as partições estão disponíveis:
1 root@datacenter :~ # cat / proc / partitions
CASO não apareça as partições, instale o pacote parted e execute o utilitário part-
probe, verificando posteriormente:
1 root@datacenter :~ # aptitude install parted ; partprobe

2 root@datacenter :~ # cat / proc / partitions
3 8 32 83886080 sdc
4 8 33 83007823 sdc1
5 8 48 83886080 sdd
6 8 49 83007823 sdd1
7 8 64 83886080 sde
8 8 65 83007823 sde1
9 8 16 83886080 sdf
10 8 17 82909184 sdf1

11 9 0 82908088 md0 # parti ção RAID sda1 / sdb1

12 253 0 9764864 dm -0 # parti ção LVM existente
Com os discos preparados, vamos iniciar a instalação e os procedimentos nestes

discos. Lembramos que, como JÁ EXISTE um RAID-1 com 2 discos na máquina,
iremos usar o /dev/sdc1, /dev/sdd1, /dev/sde1 e /dev/sdf1.
Se for instalar num servidor sem RAID, terá que fazer a instalação:
1 root@datacenter :~ # aptitude install mdadm
Vamos fazer uso do utilitário splitvt (instalado anteriormente), que faz uma divisão
na tela do terminal, facilitando a execução dos comando e verificação de logs. Para
usar esta combinação, digite no terminal splitvt e veja a saída:

Configurando o RAID-5
Em uma das telas do splitvt execute o comando para monitoração do RAID:
1 root@datacenter :~ # watch -n1 cat / proc / mdstat

2
3 md0 : active raid1 sda1 [0] sdb1 [1]
4 82908088 blocks super 1.2 [2/2] [ UU ]
Na outra tela execute o comando para a criação do RAID-5:
1 root@datacenter :~ # mdadm -- create / dev / md1 -- level =5 \

2 -- raid - devices =3 -- spare - devices =1 / dev / sdc1 / dev / sdd1 \
3 / dev / sde1 / dev / sdf1
4 mdadm : / dev / sdc1 appears to be part of a raid array :
5 level = raid5 devices =3 ctime = Thu Oct 6 17:23:36 2011
6 mdadm : / dev / sdd1 appears to be part of a raid array :
8 mdadm : / dev / sde1 appears to be part of a raid array :
10 mdadm : / dev / sdf1 appears to be part of a raid array :
12 Continue creating array ? y
13 mdadm : Defaulting to version 1.2 metadata
14 mdadm : array / dev / md1 started .
Veja a saída:

2
3 md1 : active ( auto - read - only ) raid5 sde1 [4]( S) sdf1 [3]( S) sdd1 [1]
sdc1 [0]

4 10471424 blocks super 1.2 level 5, 512 k chunk , algorithm 2

[3/2] [ UU_ ]
Neste exemplo criamos o RAID-5, porém ele não ativou um dos discos, neste caso o
/dev/sde1, conforme o item [UU_]. Para resolver isto devemos executar:
1 root@datacenter :~ # mdadm -- readwrite / dev / md1
Isto fará com que o volume RAID seja atualizado. Veja a saída em:

2 md1 : active raid5 sde1 [4] sdf1 [3]( S) sdd1 [1] sdc1 [0]
3 10471424 blocks super 1.2 level 5, 512 k chunk , algorithm 2 [3/2] [
UU_ ]
4 [ >........] recovery = 3.5% (188672/5235712) finish =4.0 min speed
=20963 K/ sec
Após alguns minutos, a atualização estará terminada!
Outro problema na montagem do RAID pode ser visto abaixo:
1 root@datacenter :~ # cat / proc / mdstat

2 Personalities : [ raid1 ] [ raid6 ] [ raid5 ] [ raid4 ]
3 md1 : active raid5 sde1 [4] sdf1 [3]( S) sdd1 [1] sdc1 [0]
UUU ]
5 resync = PENDING
Faça o mesmo procedimento para resolver isto: mdadm –readwrite /dev/md1
Bom, agora que o RAID está criado e ajustado para gravação, vamos configurar
o arquivo /etc/mdadm/mdadm.conf:

1 root@datacenter :~ # vim / etc / mdadm / mdadm . conf
Adicione no final do arquivo o seguinte conteúdo:
1 DEVICE / dev / sdc1 / dev / sdd1 / dev / sde1 / dev / sdf1

2 ARRAY / dev / md1 devices =/ dev / sdc1 ,/ dev / sdd1 ,/ dev / sde1 ,/ dev / sdf1
Verifique o status do volume RAID-5 com o comando:

2 Personalities : [ raid1 ] [ raid6 ] [ raid5 ] [ raid4 ]
3 md1 : active ( auto - read - only ) raid5 sdc1 [0] sdf1 [3]( S) sde1 [4] sdd1
[1]
UUU ]
Agora verifique os detalhes do RAID-5
1 root@datacenter :~ # mdadm -- detail / dev / md1

2 Raid Level : raid5
3 Array Size : 10471424 (9.99 GiB 10.72 GB )
4 Raid Devices : 3
5 Total Devices : 4
6 Active Devices : 3
7 Spare Devices : 1
8 Number Major Minor RaidDevice State
9 0 8 33 0 active sync / dev / sdc1
10 1 8 49 1 active sync / dev / sdd1
11 4 8 65 2 active sync / dev / sde1
12 3 8 81 - spare / dev / sdf1

Vamos criar um diretório, formatar e efetuar a montagem:
1 root@datacenter :~ # mkdir / mnt / raid

2 root@datacenter :~ # mkfs . ext4 -m .0 / dev / md1
3 root@datacenter :~ # mount -t ext4 / dev / md1 / mnt / raid
Verifique a montagem:
1 root@datacenter :~ # df -hT
2 / dev / md1 ext4 9 ,9 G 151 M 9 ,7 G 2% / mnt / raid
Agora vamos desmontar e parar o RAID-5:
1 root@datacenter :~ # umount / mnt / raid ; mdadm -S / dev / md1

2 mdadm : stopped / dev / md1
Para reiniciar o RAID, execute:
1 root@datacenter :~ # mdadm -As / dev / md1

2 mdadm : / dev / md1 has been started with 4 drives .
Efetue a montagem novamente
1 root@datacenter :~ # mount -t ext4 / dev / md1 / mnt / raid
Agora vamos desmontar e parar o RAID-5...
1 root@datacenter :~ # umount / mnt / raid ; mdadm -S / dev / md1

...e COMENTAR as linhas referentes ao RAID-5
1 root@datacenter :~ # vim / etc / mdadm / mdadm . conf

2 # DEVICE / dev / sdc1 / dev / sdd1 / dev / sde1 / dev / sdf1
3 # ARRAY / dev / md1devices =/ dev / sdc1 ,/ dev / sdd1 ,/ dev / sde1 ,/ dev / sdf1
Agora tente reiniciar o RAID-5:

2 mdadm : / dev / md1 not identified in config file .
Perceba que se você não configurar corretamente o mdadm.conf o RAID não irá
funcionar. Volte ao arquivo e descomente as linhas, reiniciando o RAID:

2 mdadm : / dev / md1 has been started with 4 drives .
Para testar o RAID, iremos criar um "script"que escreverá a data de 3 em 3 segundos

dentro do arquivo "/mnt/raid/dados.txt".
1 root@datacenter :~ # vim / root / testaraid . sh

2 # !/ bin / bash
3 while true ; do
4 date >> / mnt / raid / dados . txt
5 sleep 3
6 done
Ajuste as permissões, execute e verifque o resultado:
1 root@datacenter :~ # chmod +x / root / testaraid . sh

2 root@datacenter :~ # / root / testaraid . sh &

3 root@datacenter :~ # tail -f / mnt / raid / dados . txt
Na tela do splitvt, acompanhe o que acontece com cada comando executado. Vamos
inicialmente simular uma falha no disco “sdd1”. Digite:
1 root@datacenter :~ # mdadm / dev / md1 -- fail / dev / sdd1
Verifique que o script continua em andamento...
1 root@datacenter :~ # tail -f / mnt / raid / dados . txt
Agora temos que remover o “disco defeituoso ”:
1 root@datacenter :~ # mdadm / dev / md1 -- remove / dev / sdd1
E adicionar um “novo disco ”:
1 root@datacenter :~ # mdadm / dev / md1 -- add / dev / sdd1
O novo disco “/dev/sdd1” ficará como SPARE!
Agora cancele o script e desmonte o /mnt/raid para configurarmos o LVM.
1 root@datacenter :~ # jobs -l
2 root@datacenter :~ # kill -9 < PID_do_testaraid .sh >
3 root@datacenter :~ # cd ; umount / mnt / raid

A formatação e montagem do volume se dará em cima do LVM. No próximo passo

iremos configurar e testar o LVM.
Laboratório – LVM
Como efetuamos a instalação do servidor Debian GNU/Linux em cima de um volume

RAID+LVM, o pacote já está instalado! SE for instalar, digite:
1 root@datacenter :~ # aptitude install lvm2
Os comandos utilizados para os testes com o LVM são:
1 PV ( Phisical Volume )
2 pvs - sa í da resumida
3 pvscan - sa í da simples
4 pvdisplay - sa í da detalhada
5
6 VG ( Volume Group )
7 vgs - sa í da resumida
8 vgscan - sa í da simples
9 vgdisplay - sa í da detalhada
10
11 LV ( Logical Volume )
12 lvs - sa í da resumida
13 lvscan - sa í da simples
14 lvdisplay - sa í da detalhada
Vamos verificar nossos “Volumes Lógicos” por meio dos comandos detalhados, to-
mando como base para a produção de relatórios. Primeiro o PV:
1 root@datacenter :~ # pvdisplay

2 --- Physical volume ---

3 PV Name / dev / md0
4 VG Name root_vg
5 PV Size 79 ,07 GiB / not usable 952 ,00 KiB
6 PE Size 4 ,00 MiB
7 Total PE 20241
8 Free PE 15951
9 Allocated PE 4290
Agora do VG:
1 root@datacenter :~ # vgdisplay
2 --- Volume group ---
3 VG Name root_vg
4 VG Status resizable
5 VG Size 79 ,07 GiB
6 PE Size 4 ,00 MiB
7 Total PE 20241
8 Alloc PE / Size 4290 / 16 ,76 GiB
9 Free PE / Size 15951 / 62 ,31 GiB
E finalmente os Lvs (exemplo apenas do lv_raiz):
1 root@datacenter :~ # lvdisplay
2 --- Logical volume ---
3 LV Name / dev / root_vg / lv_raiz
4 VG Name root_vg
5 LV Size 9 ,31 GiB
6 Current LE 2384
Agora que sabemos como gerar um relatório do LVM e vimos como foi criado na
instalação do sistema, passemos para a criação de um novo VG para se trabalhar

com os perfis dos usuários do Samba. Primeiro devemos adicionar um PV, sendo
neste caso o volume RAID-5 criado anteriormente:
1 root@datacenter :~ # pvcreate / dev / md1

2 Physical volume "/ dev / md1 " successfully created
Vamos checar os PVs do sistema:
1 root@datacenter :~ # pvdisplay
2 --- Physical volume ---
3 "/ dev / md1 " is a new physical volume of " 9 ,98 GiB "
4 --- NEW Physical volume ---
6 VG Name
7 PV Size 9 ,98 GiB
Perceba que o sistema nos informa de que o /dev/md1 é um novo volume físico e
que não faz parte de nenhum VG! Sendo assim, vamos criar um novo VG com este
PV (/dev/md1):
1 root@datacenter :~ # vgcreate samba_vg / dev / md1

2 Volume group " samba_vg " successfully created
Vamos checar os VGs do sistema:
1 root@datacenter :~ # vgdisplay -v samba_vg

2 Finding volume group " samba_vg "
3 --- Volume group ---
4 VG Name samba_vg
5 Format lvm2
6 VG Size 9 ,98 GiB

7 PE Size 4 ,00 MiB

8 Total PE 2556
9 Alloc PE / Size 0 / 0
10 Free PE / Size 2556 / 9 ,98 GiB
11 --- Physical volumes ---
13 Total PE / Free PE 2556 / 2556
Finalmente vamos criar um volume lógico (LV) dentro do VG samba_vg:
1 root@datacenter :~ # lvcreate -L 6G -n samba_lv samba_vg

2 Logical volume " samba_lv " created
Verifique o relatório deste LV:
1 root@datacenter :~ # lvdisplay -v samba_vg

3 LV Name / dev / samba_vg / samba_lv
4 VG Name samba_vg
5 LV Size 6 ,00 GiB
6 Current LE 1536
Agora que temos um volume lógico criado, vamos formatar :
1 root@datacenter :~ # mkfs . ext4 -m .0 / dev / samba_vg / samba_lv
Finalizando, vamos criar um ponto de montagem e montar:
1 root@datacenter :~ # mkdir / mnt / lvm

2 root@datacenter :~ # mount -t ext4 / dev / samba_vg / samba_lv / mnt / lvm /
3 root@datacenter :~ # df -hT | tail -n2

4 / dev / mapper / samba_vg - samba_lv

5 ext4 6 ,0 G 140 M 5 ,8 G 3% / mnt / lvm
Após estes procedimentos, teremos uma unidade lógica mapeada e pronta para uso!
Vamos gravar alguns dados nesta unidade para realizarmos alguns testes.
1 root@datacenter :~ # cp -rv / boot /* / mnt / lvm ; cp -rv / sbin /* / mnt / lvm

2 root@datacenter :~ # du -sh / mnt / lvm /
3 21 M / mnt / lvm /
Vamos supor que o espaço alocado para a unidade lógica não irá atender às neces-
sidades da empresa! Neste caso teremos que aumentar o espaço da unidade lógica,
sem a necessidade de movermos dados do local ou mesmo introduzir um novo disco
no servidor. Primeiro desmonte o LV e depois execute seguintes passos:
1 root@datacenter :~ # umount / mnt / lvm

2 root@datacenter :~ # lvextend -L +2 g / dev / samba_vg / samba_lv
3 Extending logical volume samba_lv to 8 ,00 GiB
4 Logical volume samba_lv successfully resized
O comando acima diz para aumentar em 15GB o LV /dev/samba_vg/samba_lv .

Como vemos, o volume total ficou em 25GB. Mas o que fizemos foi informar apenas
ao LVM que o volume lógico foi estendido, porém o sistema em si ainda não sabe da
mudança. Para isto devemos executar os comandos abaixo, sendo o primeiro para
checar a integridade do volume e o segundo para redimensionar o tamanho:
1 root@datacenter :~ # e2fsck -f / dev / samba_vg / samba_lv

2 e2fsck 1.41.12 (17 - May -2010)
3 Pass 1: Checking inodes , blocks , and sizes
4 Pass 2: Checking directory structure
5 Pass 3: Checking directory connectivity
6 Pass 4: Checking reference counts

7 Pass 5: Checking group summary information

8 / dev / samba_vg / samba_lv :396/393216 files (0.3% non - contiguous )
,65834/1572864 blks
9 root@datacenter :~ # resize2fs / dev / samba_vg / samba_lv
10 Resizing the filesystem on / dev / samba_vg / samba_lv to 2097152(4 k)
blocks .
11 The filesystem on / dev / samba_vg / samba_lv is now 2097152 blocks long .
Pronto! Agora monte a partição e veja o tamanho e o total dos dados que nela
estavam:
1 root@datacenter :~ # mount -t ext4 / dev / samba_vg / samba_lv / mnt / lvm /

4 ext4 7 ,9 G 163 M 7 ,8 G 1% / mnt / lvm
6 21 M / mnt / lvm /
7 Observe os detalhes da parti ção redimensionada :
8 root@datacenter :~ # lvdisplay / dev / samba_vg / samba_lv
10 LV Name / dev / samba_vg / samba_lv
11 VG Name samba_vg
12 LV Size 8 ,00 GiB
13 Current LE 2048
Agora suponha que, seja lá qual for o motivo, você precise reduzir o espaço do LV.
Como proceder? Será que irei perder meus dados? E agora? Calma! Para isto
devemos nos atentar para alguns detalhes sobre os passos a serem feitos. Vamos
lá, primeiro passo é desmontar a partição. Depois devemos checar a integridade da
partição para finalmente executar o comando que fará o “resizing”.

3 root@datacenter :~ # resize2fs -p / dev / samba_vg / samba_lv 5g


blocks .
5 Begin pass 3 ( max = 64)
6 Scanning inode table
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Neste exemplo temos uma partição de 8GB e eu desejo reduzir apenas 5GB. Vamos
supor que eu tenha cerca de 3,5GB de dados. Então, para não quebrar a partição
em cima dos dados, daremos uma folga de alguns gigabytes e efetuamos o comando
de “resizing”. Agora vamos executar o comando LVM que reduzirá de fato o tamanho
da partição:
1 root@datacenter :~ # lvreduce -L -3g / dev / samba_vg / samba_lv

2 WARNING : Reducing active logical volume to 5 ,00 GiB
3 THIS MAY DESTROY YOUR DATA ( filesystem etc .)
4 Do you really want to reduce samba_lv ? [y/n ]: y
5 Reducing logical volume samba_lv to 5 ,00 GiB
6 Logical volume samba_lv successfully resized
8 root@datacenter :~ # resize2fs / dev / samba_vg / samba_lv
9 resize2fs 1.41.12 (17 - May -2010)
blocks .
Os comando acima reduziram de forma lógica o tamanho da partição para que depois
possamos reduzir de forma física. Agora é só montar e checar os dados!
1 root@datacenter :~ # mount -t ext4 / dev / samba_vg / samba_lv / mnt / lvm

4 ext4 5G 161 M 4 ,8 G 1% / mnt / lvm

6 21 M / mnt / lvm /
7 Para remover a estrutura dos testes , fa ç amos o seguinte :
9 root@datacenter :~ # lvremove / dev / samba_vg / samba_lv
10 Do you really want to remove active logical volume samba_lv ? [y/n ]:
y
11 Logical volume " samba_lv " successfully removed
12
13 -------- Se fosse o caso de remover tudo , use os comandos abaixo
--------
14
15 root@datacenter :~ # vgremove samba_vg
16 Volume group " samba_vg " successfully removed
17 root@datacenter :~ # pvremove / dev / md1
18 Labels on physical volume "/ dev / md1 " successfully wiped
A fim de deixarmos nosso ambiente estruturado para a gravação dos perfis do SAMBA,
vamos refazer o LVM da seguinte forma:
1 root@datacenter :~ # lvcreate -L 9 ,98 G -n samba_lv samba_vg

2 Logical volume " samba_lv " created
3 root@datacenter :~ # mkfs . ext4 -m .0 / dev / samba_vg / samba_lv
4 root@datacenter :~ # mkdir / srv / samba
5 root@datacenter :~ # mount -t ext4 / dev / samba_vg / samba_lv / srv / samba /
8 ext4 9 ,9 G 115 M 9 ,97 G 1% / srv / samba
Agora vamos editar o /etc/fstab e incluir no final do arquivo este novo ponto de mon-
tagem. Use o comando abaixo e deixe a entrada conforme o exemplo:
1 root@datacenter :~ # blkid | grep samba >> / etc / fstab

2 root@datacenter :~ # vim / etc / fstab

3 UUID =4 f9871d2 -92 bd -48 ea -8 d86 -3190 b7afb1f1 / srv / samba ext4 defaults
0 0

Capítulo 6
Servidor Samba
6.0.6 Cenário
A empresa Dexter Courier possui WorkStation com o Sistema Operacional GNU/-

Linux e Microsoft Windows e pretende criar uma rede com estes dois ambientes.
Como a empresa necessita de flexibilidade, deseja que seus usuários possam se
logar no sistema em qualquer computador, podendo acessar arquivos do comparti-
lhamento público, do respectivo setor e também imprimir. Pensando em questões de
segurança, deseja que todos os acessos aos compartilhamentos sejam autenticados
e logados. A empresa não deseja gastar com licença de um servidor de arquivos.
A rede possui máquinas com Windows XP e Windows 7. Os arquivos de cada um
dos setores precisam ser gravados no Storage para fins de backup e os arquivos do
“perfil” dos usuários precisam ficar no RAID (disponibilidade).
A melhor solução é um servidor GNU/Linux com Samba pois, além de ser gratuito,
possui muitas funcionalidades e flexibilidade, tornando-o superior aos servidores com
código proprietário. O servidor deverá atender aos seguintes requisitos:
85
• domínio com perfil móvel (roaming profile); autenticação de usuários; nome net-
bios; gerador de logs nível 1; gravação de arquivos com extensão mp3, mpg,
mpeg, avi, wav e jpg vetada no compartilhamento; arquivos com extensões .ini
e .log deverão ficar ocultos; sistema de lixeira para cada compartilhamento; im-
pressora compartilhada; acesso restrito à rede local; mapeamento de unidade
de rede por grupo; possibilidade do usuário alterar sua senha; criação de ar-
quivo/diretório em letra minúscula; compartilhamento oculto para uso da equipe
de suporte; codificação dos caracteres para ambos os sistemas; relatórios de
quem está conectado ao servidor.
“O Samba é um servidor para Linux (e outros sistemas baseados em Unix) que per-
mite o gerenciamento e compartilhamento de recursos em redes formadas por com-
putadores com o Windows. Assim, é possível usar o Linux como servidor de arquivos,
servidor de impressão, entre outros, como se a rede utilizasse servidores Windows
(NT, 2000, XP, 2003 ou 2008).
O Samba é uma criação de Andrew Tridgell. O que aconteceu foi que Tridgell pre-
cisava montar um espaço em disco em seu PC para um servidor Unix. Esse PC
rodava o sistema operacional MS-DOS e, inicialmente, foi utilizado o sistema de ar-
quivos NFS (Network File System) para o acesso. Porém, um aplicativo precisava de
suporte ao protocolo NetBIOS (não suportado pelo NFS). A solução encontrada por
Tridgell não foi tão simples: ele escreveu um sniffer (pequeno programa para captura
de tráfego de dados em rede) que permitisse analisar o tráfego de dados gerado
pelo protocolo NetBIOS, fez engenharia reversa no protocolo SMB (Server Message
Block) e o implementou no Unix. Isso fez com que o servidor Unix aparecesse como
um servidor de arquivos Windows em seu PC com DOS.
O código foi disponibilizado publicamente por Tridgell em 1992. Porém, tempos de-
pois, o projeto foi posto de lado até que um determinado dia Tridgell decidiu conectar
o PC de sua esposa ao seu computador com Linux. Porém, não encontrou nenhum
meio melhor que seu código para fazer isso e assim o utilizou.

Através de contatos feitos por e-mail, Tridgell descobriu que as documentações dos
protocolos SMB e NetBIOS estavam atualizadas e assim voltou a dedicar-se ao pro-
jeto. Porém, uma empresa entrou em contato com ele reivindicando os direitos sobre
o nome usado no software até então. Diante disso, Andrew Tridgell teve a idéia de
procurar em um dicionário uma palavra que tivesse as letras s, m e b (de SMB). A
busca retornou apenas as palavras "salmonberry", "samba", "sawtimber"e "scram-
ble", de forma que a escolha do nome acabou sendo óbvia. A partir daí o projeto
Samba cresceu e hoje Andrew Tridgell conta com uma excelente equipe de progra-
madores e com milhares de usuários de sua solução espalhados pelo mundo. “ [
http://www.infowester.com/linuxsamba.php
A suíte SAMBA precisa de três componentes para realizar sua função:
• nmbd - Responsável pela resolução de nomes;
• smbd - Responsável por compartilhar recursos;
• winbind - Auxilia na autenticação em um domínio “AD”.
6.0.9 subsection name
O que é um Domínio?
Domínio é um conjunto de usuários conhecidos (cadastrados) que podem utilizar vá-

rias máquinas, em vários locais diferentes. O usuário não fica preso a uma máquina
específica, pois os arquivos dele são centralizados no servidor Samba PDC e o seu
perfil é móvel. O que é uma eleição?
É necessário uma eleição quando existe mais de uma máquina querendo ser domínio
na rede. Existem algumas opções na configuração do smb.conf na seção global que
fazem com que o nosso servidor leve vantagem nesta eleição. Veremos isto mais
adiante.

Primeiro vamos iniciar este “lab” instalando o samba.
1 root@datacenter :~ # aptitude install samba samba - doc smbclient smbfs
Faça um backup do arquivo padrão do samba para efeito de consulta posterior:
1 root@datacenter :~ # cp / etc / samba / smb . conf / etc / samba / smb . conf . distro
RedHat: Na plataforma RedHat, o arquivo de configuração do samba fica em

“/etc/smb.conf”
Fique atento, as opções que iremos estudar agora poderão ser cobradas na
prova do LPI nível 2.
Segundo, vamos montar a estrutura de nosso servidor Samba, com a lista dos usuá-
rios, grupos e permissões. A empresa Dexter Courier possui o seguinte quadro de
funcionários:

Para nos ajudar nessa árdua tarefa, vamos compor uma lista com o nome e o login
de cada membro da empresa Dexter Courier. Depois gere uma lista somente com o
login de cada usuário e salve em /root/lista_users.txt do servidor, assim poderemos
utilizar scripts na criação e administração do Samba.
1 Dexter Clem - dexterclem

2 Mandark Glory - mandarkglory
3 Levinsky Mitch - levinskymitch
4 Douglas E. Mordechai - douglasmordechai
5 Chris Cavanaugh - chriscavanaugh
6 Candi Milo - candimilo
7 Allison Moore - allisonmoore
8 Kathryn Cressida - kathryncressida
9 Kath Soucie - kathsoucie
10 Jeff Bennett - jeffbennett
11 Eddie Deezen - eddiedeezen
12 Frank Welker - frankwelker
13 Luzinsky Brooks - luzinskybrooks
14 VOC Ê - voce
A senha padrão para todos será 123456. É óbvio que no “mundo real” isto não
ocorrerá. A ideia aqui é facilitar os testes! Agora vamos criar os grupos...
1 root@datacenter :~ # addgroup -- gid 2001 administrativo

2 root@datacenter :~ # addgroup -- gid 2002 comercial
3 root@datacenter :~ # addgroup -- gid 2003 logistica
4 root@datacenter :~ # addgroup -- gid 2004 rh
5 root@datacenter :~ # addgroup -- gid 2005 suporte
6 root@datacenter :~ # addgroup -- gid 2006 pdc
. . . os diretórios de trabalho do Samba...
1 root@datacenter :~ # mkdir -p \

2 / srv / storage /{ administrativo ,rh , comercial , logistica , suporte }

3 root@datacenter :~ # mkdir -p / srv / storage / drivers
. . . e definir as permissões de acesso:
1 root@datacenter :~ # chown -R root : administrativo \

2 / srv / storage / administrativo
3 root@datacenter :~ # chown -R root : rh / srv / storage / rh
4 root@datacenter :~ # chown -R root : comercial / srv / storage / comercial
5 root@datacenter :~ # chown -R root : logistica / srv / storage / logistica
6 root@datacenter :~ # chown -R root : suporte / srv / storage /{ suporte ,
drivers }
7 root@datacenter :~ # chmod -Rv 3770 / srv / storage /*
Também devemos criar a estrutura do compartilhamento público:
1 root@datacenter :~ # useradd -g users -s / bin / false smbuser

2 root@datacenter :~ # mkdir / srv / storage / publico
3 root@datacenter :~ # chown -R smbuser : users / srv / storage / publico
4 root@datacenter :~ # chmod -R 770 / srv / storage / publico
Agora iremos preparar o ambiente para a configuração do PDC:
1 root@datacenter :~ # mkdir -p / srv / samba /{ homes , profiles , netlogon }

2 root@datacenter :~ # chown -R root : users \
3 / srv / samba /{ homes , profiles , netlogon }
4 root@datacenter :~ # chmod -R 770 / srv / samba /{ homes , profiles , netlogon }
Vamos adicionar os usuários aos grupos criados:

1 root@datacenter :~ # useradd -g administrativo -G comercial ,rh ,

logistica , suporte , users -s / bin / false dexterclem
2 root@datacenter :~ # useradd -g administrativo -G users -s / bin / false
mandarkglory
levinskymitch
douglasmordechai
5 root@datacenter :~ # useradd -g comercial -G users -s / bin / false
chriscavanaugh
6 root@datacenter :~ # useradd -g comercial -G users -s / bin / false
candimilo
7 root@datacenter :~ # useradd -g comercial -s / bin / false allisonmoore
8 root@datacenter :~ # useradd -g rh -G users -s / bin / false
kathryncressida
9 root@datacenter :~ # useradd -g rh -G users -s / bin / false kathsoucie
10 root@datacenter :~ # useradd -g rh -G users -s / bin / false jeffbennett
11 root@datacenter :~ # useradd -g logistica -G users -s / bin / false
eddiedeezen
frankwelker
luzinskybrooks
14 root@datacenter :~ # useradd -g suporte -G users -s / bin / false voce
Veja o arquivo /etc/passwd:
1 root@datacenter :~ # tail - n14 / etc / passwd

2 dexterclem :x :1001:2001::/ home / dexterclem :/ bin / false
3 mandarkglory :x :1002:2001::/ home / mandarkglory :/ bin / false
4 voce :x :1014:2005::/ home / voce :/ bin / false
A fim de agilizar a preparação de nosso cenário, vamos montar um script para alterar
o diretório home e profile dos usuários, criar o diretório da lixeira e ingressar os
usuários no Samba. Depois dê permissão de execução e execute o script!

1 root@datacenter :~ # vim / root /01 _samba_pdc . sh

2 # !/ bin / bash
3 for lista in $( cat / root / lista_users . txt ); do
4 mkdir -p / srv / samba / homes / $lista
5 mkdir -p / srv / samba / profiles / $lista
6 chown -R $lista : users / srv / samba / homes / $lista
7 chown -R $lista : users / srv / samba / profiles / $lista
8 chmod -R 0700 / srv / samba / homes / $lista
9 chmod -R 0700 / srv / samba / profiles / $lista
10 mkdir -p / srv / lixeiras / $lista
11 chown -R $lista : users / srv / lixeiras / $lista
12 chmod -R 0700 / srv / lixeiras / $lista
13 usermod -d / srv / samba / homes / $lista $lista
14 pdbedit -x -u $lista 2> / dev / null
15 ( echo 123456 ; echo 123456) | smbpasswd -a -s $lista
16 done
Pronto! Já temos os diretórios, grupos, usuários, permissões de acesso e inclusão

ao SAMBA. Vamos configurar o /etc/samba/smb.conf:
1 root@datacenter :~ # vim / etc / samba / smb . conf

2 [ global ]
3 workgroup = DEXTER
4 netbios name = Servidor
5 server string = Servidor de Arquivos Linux
6 # Habilitando o Samba como PDC
7 os level = 100
8 preferred master = yes
9 domain logons = yes
10 domain master = yes
11 local master = yes
12 # Habilitando os LOGs
13 log file = / var / log / samba / log .% m
14 log level = 1

15 max log size = 1000

16 # Ní vel de seguran ça
17 enable privileges = yes
18 security = user
19 encrypt passwords = yes
20 passdb backend = tdbsam
21 admin users = root
22 hosts allow = 192.168. X.
23 # Acesso a má quinas com Windows98
24 lanman auth = yes
25 client lanman auth = yes
26 # Permiss ão de grava ção no Storage NFS
27 posix locking = no
28 # Servidor Wins
29 wins support = yes
30 # Melhorando o desempenho do Samba
31 socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE
SO_RCVBUF =8192 SO_SNDBUF =8192
32 read raw = yes
33 write raw = yes
34 oplocks = yes
35 getwd cache = yes
36 # Mapear unidade para arquivos pessoais do usu á rio
37 logon drive = H:
38 logon home = \\% L\ homes \% U
39 logon path = \\% L\ profiles \% U
40 logon script = %G. cmd
41 # Script para criar conta de má quina
42 add machine script = / usr / sbin / useradd -r -g pdc -c " SAMBA
PDC " -d / dev / null -s / bin / false %u
43 # Samba falando portugu ês
44 dos charset = CP850
45 unix charset = UTF -8
46 display charset = CP850
47 # Habilitando o Samba a imprimir
48 printing = cups
49 load printers = yes

50 # Samba responde em determinada interface de rede

51 interfaces = eth0
52 bind interfaces only = yes
53 # Habilitando o usu á rio a trocar sua senha
54 unix password sync = yes
55 passwd program = / usr / bin / passwd %u
56 passwd chat = * Enter \ snew \s *\ spassword :* %n\n * Retype \ snew \s
*\ spassword :* %n\n * password \ supdated \ ssuccessfully * .
57 # Habilitando o Samba a deixar os nomes de arquivos e diret ó rios
todos em min ú sculos
58 short preserve case = yes
59 case sensitive = no
60 default case = lower
61 # Habilitando o Samba a usar lixeiras em todos os compartilhamentos
62 vfs objects = recycle
63 recycle : keeptree = yes
64 recycle : versions = yes
65 recycle : repository = / srv / lixeiras /% U
66 recycle : exclude = *. tmp ,*. log ,* obj ,~*.* ,*. bak
67 recycle : exclude_dir = tmp , cache
68 [ administrativo ]
69 path = / srv / storage / administrativo
70 available = yes
71 read only = no
72 public = no
73 only guest = no
74 valid users = @administrativo
75 write list = @administrativo
76 force create mode = 660
77 force directory mode = 750
78 veto files = /*. mp3 /*. mpg /*. mpeg /*. avi /*. jpg /
79 hide files = /*. ini /*. log /
80 [ comercial ]
81 path = / srv / storage / comercial
82 available = yes
83 read only = no
84 public = no

85 only guest = no
86 valid users = @comercial
87 write list = @comercial
92 [ logistica ]
93 path = / srv / storage / logistica
94 available = yes
95 read only = no
96 public = no
97 only guest = no
98 valid users = @logistica
99 write list = @logistica
104 [ rh ]
105 path = / srv / storage / rh
106 available = yes
107 read only = no
108 public = no
109 only guest = no
110 valid users = @rh
111 write list = @rh
116 [ suporte ]
117 path = / srv / storage / suporte
118 available = yes
119 read only = no
120 public = no
121 only guest = no

122 valid users = @suporte

123 write list = @suporte
128 [ publico ]
129 comment = Publico
130 path = / srv / storage / publico
131 public = yes
132 force user = smbuser
133 force group = users
134 read only = no
135 guest ok = yes
140 [ lixeiras ]
141 path = / srv / lixeiras /% U
142 read only = no
143 browseable = no
148 [ printers ]
149 comment = Samsung ML -2010
150 path = / var / spool / samba
151 browseable = yes
152 read only = no
153 print ok = yes
154 guest ok = yes
155 [ netlogon ]
156 comment = Network logon service
157 path = / srv / samba / netlogon
158 writable = no

159 browseable = no
160 [ homes ]
161 comment = Diretorio pessoal
162 path = / srv / samba / homes /% U
163 public = no
164 valid users = %U
165 read only = no
166 browseable = no
167 [ profiles ]
168 comment = Perfis mó veis
169 path = / srv / samba / profiles
170 public = no
171 guest ok = yes
172 read only = no
173 browseable = no
174 create mask = 0600
175 directory mask = 0700
176 [ drivers$ ]
177 comment = Drivers Windows
178 path = / srv / storage / drivers
179 public = no
180 inherit permissions = yes
181 valid users = @suporte
182 write list = @suporte
183 only guest = no
184 read only = no
Rode o comando testparm para verificar se não há erros na configuração:
1 root@datacenter :~ # testparm
2 Load smb config files from / etc / samba / smb . conf
3 rlimit_max : rlimit_max (1024) below minimum Windows limit (16384)

4 Processing section "[ administrativo ]"

5 Processing section "[ comercial ]"
6 Processing section "[ logistica ]"
7 Processing section "[ rh ]"
8 Processing section "[ suporte ]"
9 Processing section "[ publico ]"
10 Processing section "[ lixeiras ]"
11 Processing section "[ printers ]"
12 Processing section "[ netlogon ]"
13 Processing section "[ homes ]"
14 Processing section "[ profiles ]"
15 Processing section "[ drivers$ ]"
16 Loaded services file OK .
17 WARNING : You have some share names that are longer than 12
characters .
18 These may not be accessible to some older clients .
19 ( Eg . Windows9x , WindowsMe , and smbclient prior to Samba 3.0.)
20 Server role : ROLE_DOMAIN_PDC
21 Press enter to see a dump of your service definitions
Adicione o usuário “root” ao samba para ser o administrador do Domínio:
1 root@datacenter :~ # smbpasswd -a root
E agora copie os “scripts de logon” fornecidos pelo Instrutor para o local correto, a
fim de que os usuários Windows possam mapear as unidades da rede:
1 root@datacenter :~ # cp / root / samba /*. cmd / srv / samba / netlogon /

2 root@datacenter :~ # chmod 777 / srv / samba / netlogon /*. cmd
Reinicie o serviço do samba.

1 root@datacenter :~ # service samba restart

2 Stopping Samba daemons : nmbd smbd .
3 Starting Samba daemons : nmbd smbd .
Para verificar os usuários inseridos no Samba, digite o comando:
1 root@datacenter :~ # pdbedit -Lw
Adicionando máquina Windows XP ao PDC Samba
Vamos ingressar a máquina WindowsXP ao domínio. Primeiro mude os seguintes

parâmetros para que a máquina possa acessar o domínio. Acesse o "Painel de con-
trole > Ferramentas administrativas > Diretiva de segurança local > Diretivas
locais > Opções de segurança"e desative as seguintes opções: (clicando com
o botão direito e depois em Propriedades):
1.Membro do domínio: criptografar ou assinar digitalmente os dados de canal seguro

(sempre);
2.Membro do domínio: desativar alterações de senha de conta da máquina;
3.Membro do domínio: requer uma chave de sessão de alta segurança (Windows

2000 ou posterior);
4.Reinicie a máquina com Windows XP. Depois disto, siga as próximas figuras:


Abra o “Meu Computador” e veja os mapeamentos (exemplo usuário Dexter Clem):

Adicionando máquina Windows 7 ao PDC Samba
Primeiro precisa alterar o registro no Windows 7, isso é possível editando manual-

mente o registro do Windows com os seguintes valores:
1 HKeyLocalMachine \ System \ CCS \ Services \ LanmanWorkstation \ Parameters

2 DWORD DomainCompatibilityMode = 1
3 DWORD DNSNameResolutionRequired = 0
A outra alternativa é instalar o registro Win7_Samba3DomainMember.reg, que pode

ser encontrado em:
https://bugzilla.samba.org/attachment.cgi?id=4988&action=view

Após instalar o registro e reiniciar o sistema, siga as próximas figuras. Clique em

“Iniciar” => botão direito no ícone “Computador” => “Propriedades”.
Clique em “Configurações avançadas do sistema”:

Clique no botão “Alterar”:

Selecione “Membro de Domínio” e digite “dexter” (sem aspas):
Insira o nome root e a senha do root:

Após clicar em OK irá aparecer uma mensagem de erro, Clique OK para ignorar e
depois reinicialize o computador:
Quando surgir a tela de login, clique em “Trocar Usuário” => “Outro Usuário” e digite
o usuário do Domínio DEXTER:


Capítulo 7
Servidor DNS
Cenário
A empresa DEXTER COURIER precisa configurar um servidor DNS para que os ser-
viços disponibilizados por ela possam ser acessados externamente (Internet) por no-
mes ao invés de IP. A empresa pretende registrar dois domínios junto ao http://registro.br:
dexter.com.br e mandark.com.br.
O servidor DNS será montado na máquina DMZ, podendo ser acessada pelo mundo
externo (após configuração do firewall), sendo replicada para a máquina Datacenter.
Faremos o seguinte:
1 - Neste projeto, dois servidores, o primário e o secundário, devem ter um meca-

nismo configurado corretamente para que eles se mantenham sincronizados;
2 - O DNS reverso deve estar configurado;
3 - Este servidor de DNS deve trabalhar de forma autoritativa (responsável pelos

domínios dexter.com.br e mandark.com.br) apenas;
109
4 - Configurar o servidor com SPF;
5 - Configurar o servidor corretamente para o uso do comando rndc;
6 - Configurar o servidor primário para notificar o secundário quando houver atuali-

zação na zona;
7 - Configurar o servidor primário para que ocorra atualização dinâmica na zona a

partir dele mesmo;
“Durante os anos 70, Arpanet era uma pequena comunidade de algumas centenas
de hosts. Um único arquivo, HOSTS.TXT, continha toda a informação necessária
sobre os hosts. Este arquivo continha nome para endereçar cada host conectado a
ARPANET.
O arquivo era mantido pela Network Information Center (NIC) e distribuido por um
único host, Stanford Research Institute’s Network Information Center (SRI-NIC). Os
administradores da ARPANET enviavam ao NIC, por e-mail, quaisquer mudanças
que tivessem sido efeituadas e periodicamente SRI-NIC era atualizado, assim como
o arquivo HOSTS.TXT. As mudanças eram compiladas 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 HOST.TXT crescia na proporção
em que crescia o número de hosts. 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 HOST.TXT, mas um outro
host atualizando a partir do SRI-NIC.
E quando a ARPANET passou a usar protocolos TCP/IP, a população da rede "ex-

plodiu". E passaram a existir alguns problemas com o HOST.TXT:
• Nomes que coincidiam : dois hosts do arquivo HOSTS.TXT não podiam ter o

mesmo nome. Porém, apesar do NIC poder designar endereços únicos para
cada host, ele não tinha nenhuma autoridade sobre os nomes dados aos mes-
mos. Não havia nada que pudesse evitar que alguém adicionasse um host com
um nome conflitante, interrompendo o sistema de algum outro host já existente.
• Consistência : manter a consistência do arquivo com a rede se expandindo

àquelas proporções se tornou cada vez mais difícil. Quando o arquivo conse-
guia conter todos os hosts, algum host trocava de endereço ou um novo host
adicionado tinha quebrado a conexão do host que se desejava acessar. Ironica-
mente, o sucesso da ARPANET tornou o arquivo HOSTS.TXT falho e obsoleto.
Os administradores da ARPANET tentaram outras configurações que resolvessem o

problema do HOST.TXT. O objetivo era criar um sistema que resolvesse os problemas
em uma tabela única de hosts. O novo sistema deveria: Permitir que o administrador
local tornasse os dados mundialmente disponíveis; Descentralizar a administração
a fim de resolver o problema do gargalo gerado por um único host, diminuindo o
problema do tráfego. Além disso, o fato da administração ser local iria fazer com
que a atualização dos 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 o RFCs 882 e 883, que descreve o
"Domain Name System", ou DNS. Estes RFCs foram sucedidos pelos RFCs 1034 e
1035, que possuem as especificações atuais do DNS.
[http://www.gta.ufrj.br/grad/anteriores98/dns-ticiana/historia.htm ]
Características
• Banco de dados hierárquico e distribuído representado no formato de uma ár-

vore invertida e 127 níveis;

• "Namespace"de até 63 caracteres;
• Capacidade de associar outras informações a um "host"e não só seus endere-

ços IP’s;
• Arquitetura cliente/servidor;
• Os clientes são chamados "resolvers"e costumam ser bibliotecas do sistema

operacional ("libresolv"no Gnu/Linux) compartilhadas entre os mais diversos
programas, como "ping"ou o navegador web;
• Do outro lado estão os servidores de nome "DNS", os "DNS nameserver";
• A raiz da árvore tem nome nulo ou , por isso a representamos simplesmente

como ponto (.);
• Os nós abaixo do domínio raiz são chamados domínios de nível mais elevado -
TLD (top level domains);
• Sua quantidade e nomes são impostos pela ICANN - Internet Corporation for
Assigned Names and Numbers;
• Eles são divididos em "gTLD"(domínios genéricos "com", "edu", "gov", "mil",

etc) e "ccTLD"(códigos de países ou "country-code", sempre com duas le-
tras);
• A ICANN delega, de acordo com tratados internacionais, a responsabilidade

pela administração de um "ccTLD";
• No caso do Brasil, essa responsabilidade pertence atualmente ao "CGI.br",

mais especificamente ao "REGISTRO.br";
• Uma vez delegado um domínio, sua nova autoridade pode delegar subdomínios
sem necessitar notificar a entidade responsável pelo domínio pai;

• Um subdomínio está para um subdiretório assim como um domínio está para

um diretório, e um "host"está para um arquivo;
Finalmente, vale a pena mencionar que o arquivo "HOSTS.TXT"foi portado para

o ambiente Unix e posteriormente para o Gnu/Linux como "/etc/hosts". Este ar-
quivo é normalmente o primeiro a ser consultado pelo resolvedor, que irá buscar por
um servidor de nomes apenas em caso de o "host"não ser encontrado no arquivo
"/etc/hosts". “
7.0.12 Resolução
Resolução "DNS"é o processo pelo qual um programa consulta dados a respeito de

um "hostname". Na grande maioria das vezes, consulta-se o endereço IP deste
"host"para então efetuar algum tipo de conexão à algum serviço, como "HTTP",
"SMTP, "POP", dentre outros. O processo de resolução, a partir do primeiro "na-
meserver"consultado, pode ser:
• recursiva
• iterativa
Resolução Recursiva
Tomando um navegador web como exemplo, a resolução para acesso a um "web-

site"tem as seguintes etapas:
1.Usuário solicita acesso a "www.exemplo.com.br";
2.Navegador checa se já conhece o endereço IP do "hostname"solicitado (cache do

"browser");

3.Se não conhece, o navegador passa a solicitação para a biblioteca de resolução -

o "resolver";
4.O "resolver"procura o "hostname"solicitado no arquivo "/etc/hosts"local;
5.Se não encontrar, ele checa o arquivo "/etc/resolv.conf"para saber a quais "name-
servers"deve solicitar a informação;
6.O "resolver"repassa a solicitação ao primeiro "nameserver"da lista, e logo após

para o próximo até o fim da lista, aguardando por uma resposta de qualquer um
deles;
7.O servidor de nomes acionado consulta seu "cache", se houver;
8.Se não encontrar em seu "cache", o servidor em questão vai diretamente ao servi-
dor raiz e transfere a consulta - www.exemplo.com.br?;
9.O servidor raiz não faz "cache", e também não é autoridade sobre zonas de baixo
nível, então ele apenas responde uma parte da questão: "Não sei quem é, mas sei
quem pode responder melhor: br.";
10.O servidor de nomes reenvia a consulta para o servidor ".br- www.exemplo.com.br?;
11.".br"retorna o mesmo tipo de resposta, porém como uma dica mais próxima: "Não
sei quem é, mas sei quem pode responder melhor: com.br.";
12.Passos 10 e 11 são efetuados mais uma vez, e agora a resposta é "Não sei quem
é, mas sei quem pode responder melhor: exemplo.com.br.";
13.Após repetir o passo 10, finalmente a resposta será da autoridade sobre o domínio
exemplo.com.br. Vai ser respondido o IP, juntamente ao TTL do registro, ou será
respondido "inexistente";
14.O servidor de nomes fará "cache"da resposta, ao mesmo tempo que a repassa
para o resolvedor original;

15.O resolvedor repassa a resposta para o navegador;
16.O navegador inicia uma conexão "HTTP"com o IP descoberto.
Conceitos de DNS e a sua configuração em Gnu/Linux utilizando Bind9, são

cobrados na Prova do LPI 201 – peso2.
Resolução Iterativa
Enquanto o servidor "cache"do exemplo acima executa um processo recursivo de

consultas sucessivas descendo a árvore até a autoridade capaz de responder defi-
nitivamente ao questionamento apresentado, os servidores ".", "br.", "com.br.", ape-
nas informam que conhecem alguém mais preciso que eles. Essa é uma consulta
iterativa. Iteração, nesse caso, significa "apontar para o mais próximo conhe-
cido".
7.0.13 O arquivo hosts
Derivado do arquivo "HOSTS.TXT"original, aquele que era atualizado e distribuído

antes do surgimento do "Domain Name System", o arquivo "/etc/hosts"continua tendo
um papel muito importante no processo de resolução. No passo a passo descrito
anteriormente, observe que ele é a primeira fonte de consulta do "resolver".
Este comportamento pode ser modificado através do arquivo "/etc/nsswitch", porém,

isso só seria feito em um cenário muito particular. Podemos considerar que quase a
totalidade dos sistemas "*nix"vão seguir a ordem de resolução padrão.
Sendo assim, é bom conhecer a sintaxe desse arquivo:

1 Endereco_IP Hostname_canonico Aliases

2 192.168.200.254 gateway . com . br gateway
Devemos colocar um endereço IP por linha, seguido de um endereço canônico e op-

cionalmente "aliases"(apelidos). O nome de "host"canônico pode ser qualquer nome
no formato "DNS", porém, em alguns casos, como o de servidores de e-mails, é ade-
quado que os IPs presentes nesta máquina tenham um "FQDN"pertinente. FQDN
(Fully Qualified Domain Name) é um "hostname"que identifica, sem ambiguidade,
a posição daquele nó dentro da árvore DNS.
Por esta razão, um "FQDN"deve terminar com um ".", que representa a raiz da ár-
vore. Os "aliases"podem ser outros "hostnames"canônicos, ou simples sufixos, para
simplificar a escrita de determinados endereços. Após a instalação do sistema, o ar-
quivo "hosts"costuma conter uma entrada referente ao IP da interface "loopback", e
uma entrada para cada outra interface presente na máquina para qual um endereço
foi atribuído. “
[http://gnulinuxbr.com/2010/05/04/domain-name-system-servidor-dns-no-
debian-parte-1/ ]
Por exemplo:
1 127.0.0.1 localhost
2 192.168.1.50 micro50 . dexter . com . br . micro50
Pode ser acrescentadas quantas entradas forem necessárias, inclusive para IPs ex-
ternos. Atualmente, os sistemas baseados em Debian já contém entradas para en-
dereçamento "IPv6", que seguem a mesma lógica. Poderá ver isto executando:
1 root@dmz :~ # cat / etc / hosts

2 ...
3 # The following lines are desirable for IPv6 capable hosts
4 ::1 ip6 - localhost ip6 - loopback
5 fe00 ::0 ip6 - localnet
6 ff00 ::0 ip6 - mcastprefix
7 ff02 ::1 ip6 - allnodes
8 ff02 ::2 ip6 - allrouters
7.0.14 Ferramentas de consulta
Caso ainda não estejam presentes, vamos instalar as ferramentas de pesquisa de

"DNS".
1 root@dmz :~ # aptitude install dnsutils
• nslookup
A "ISC" (Internet Systems Consortium - www.isc.org) diz, literalmente, no manual

de utilização do BIND: "Devido a sua interface misteriosa e frequente compor-
tamento inconsistente, nós não recomendamos o uso do "nslookup". Usem o
"dig"no lugar dele".
Porém, o pacote é mantido pela própria ISC em nome da legião de administradores

que se habituaram a utilizar o "nslookup"como ferramenta de resolução de proble-
mas.
Dentre suas vantagens está o fato de ter uma biblioteca de resolução independente
do sistema, e consultar um servidor por vez, dentre os listados no "/etc/resolv.conf".
Apesar da consulta ser mais lenta, torna a triagem mais controlável. Dentre os pro-
blemas mais crônicos do "nslookup"estão: respostas confusas e erros indefinidos.

• host
O comando "host"é concebido para dar respostas objetivas, limitando-se na maioria

dos casos a uma só linha. Porém, repostas mais detalhadas podem ser obtidas com
a utilização de parâmetros. Ao contrário do "dig", o "host"consulta a "search list"do
arquivo "/etc/resolv.conf".
• dig
O comando "dig"é o acrônimo para "Domain Information Groper", que significa algo
como "aquele que busca por informações de domínio no escuro", e ao mesmo
tempo, a palavra "dig"em inglês significa literalmente "escavar". Acho que mencionar
estas curiosidades demonstra o esforço de imaginação dos criadores do "dig"e, não
à toa, ele é o comando de pesquisa mais poderoso no pacote de utilitários "BIND".
No "dig"há dezenas de opções e incontáveis combinações entre elas, por isso con-
sultar o "man"e, sobretudo, ter um forte domínio do funcionamento do sistema de
nomes de domínio, é necessário para domá-lo.
O "dig"não utiliza a opção "search"do "/etc/resolv.conf", por isso é necessário utilizar

"FQDN"em todas as buscas.
7.0.15 Prática dirigida
Antes de testarmos o comando “dig”, devemos saber o significado de algumas siglas,

facilitando assim o entendimento e melhor aproveitamento deles.

Vamos testar o "verborrágico"comando "dig":
1 root@dmz :~ # dig www .4 linux . com . br .

2 ;; ->> HEADER <<- opcode : QUERY , status : NOERROR , id : 5930
3 ;; flags : qr rd ra ; QUERY : 1, ANSWER : 1, AUTHORITY : 0, ADDITIONAL : 0
4 ;; QUESTION SECTION :
5 ; www .4 linux . com . br . IN A
6 ;; ANSWER SECTION :
7 www .4 linux . com . br . 300 IN A 66.118.142.41
8 ;; Query time : 392 msec
9 ;; SERVER : 4.2.2.2 # 53(4.2.2.2)
10 ...
11
12 root@dmz :~ # dig @8 .8.8.8 www .4 linux . com . br .
16 ; www .4 linux . com . br . IN A
19
21 ;; SERVER : 8.8.8.8 # 53(8.8.8.8)
22 ...

23
24 root@dmz :~ # dig -t mx gmail . com .
28 ; gmail . com . IN MX
30 gmail . com . 1425 IN MX 40 alt4 . gmail - smtp - in .l. google . com .
31 gmail . com . 1425 IN MX 5 gmail - smtp - in .l. google . com .
36 ;; SERVER : 4.2.2.2 # 53(4.2.2.2)
37 ...
38
39 root@dmz :~ # dig -x 200.212.122.137
43 ;137.122.212.200. in - addr . arpa . IN PTR
45 137.122.212.200. in - addr . arpa . 43200 IN CNAME 137.128 -
46 191.122.212.200. in - addr . arpa .
47 137.128 -191.122.212.200. in - addr . arpa . 3600 IN PTR boca .4 linux . com . br
.
49 ;; SERVER : 4.2.2.2 # 53(4.2.2.2)
50 ...
51
52 root@dmz :~ # dig + trace www .4 linux . com . br .
53 ; <<>> DiG 9.7.3 <<>> + trace www .4 linux . com . br .
54 ;; global options : + cmd
55 . 30820 IN NS h. root - servers . net .
56 . 30820 IN NS l. root - servers . net .
57 . 30820 IN NS m. root - servers . net .
58 . 30820 IN NS i. root - servers . net .

59 . 30820 IN NS j. root - servers . net .

60 . 30820 IN NS d. root - servers . net .
61 . 30820 IN NS f. root - servers . net .
62 . 30820 IN NS e. root - servers . net .
63 . 30820 IN NS c. root - servers . net .
64 . 30820 IN NS a. root - servers . net .
65 . 30820 IN NS b. root - servers . net .
66 . 30820 IN NS k. root - servers . net .
67 . 30820 IN NS g. root - servers . net .
68 ;; Received 228 bytes from 4.2.2.2 # 53(4.2.2.2) in 132 ms
69 br . 172800 IN NS c. dns . br .
70 br . 172800 IN NS f. dns . br .
71 br . 172800 IN NS a. dns . br .
72 br . 172800 IN NS d. dns . br .
73 br . 172800 IN NS b. dns . br .
74 br . 172800 IN NS e. dns . br .
75 ;; Received 287 bytes from 192.5.5.241 # 53( f. root - servers . net ) in 216
ms
76 4 linux . com . br . 86400 IN NS ns1 .4 linux . com . br .
78 ;; Received 103 bytes from 200.189.40.10 # 53( b. dns . br ) in 32 ms
80 4 linux . com . br . 60 IN NS ns1 . testdrive .4 linux . com . br .
83 ;; Received 147 bytes from 200.212.122.137 # 53( ns1 .4 linux . com . br ) in
44 ms
7.0.16 Introdução ao BIND + Laboratório
O BIND (Berkeley Internet Name Domain) é o servidor de nomes utilizado na

grande maioria dos servidores da Internet, provendo uma estável e robusta arqui-
tetura sobre a qual as organizações podem construir sua estrutura de nomes. Será
este servidor que iremos abordar no curso. Sua instalação é bem simples:

1 root@dmz :~ # aptitude install bind9
O arquivo principal chama-se "/etc/bind/named.conf" mas contém apenas configu-

rações estáticas. Ele utiliza a cláusula include para anexar os arquivos "/etc/bind/-
named.conf.options" e "/etc/bind/named.conf.local". Sendo que desses dois, o
primeiro serve para personalizar todas opções referentes ao funcionamento do pró-
prio "BIND", enquanto que o segundo serve para declarar todas as zonas pelas quais
este servidor deve responder.
1 root@dmz :~ # ls -lh / etc / bind
Além dos arquivos citados acima, temos o arquivo "db.root"(no RedHat fica em "/var/-
named/named.ca") que relaciona os endereços dos 13 servidores raiz e é lido como
"zona hint", que será explicada adiante.
O "BIND"vai utilizar a porta 53/UDP para receber consultas, a porta 53/TCP

para transferir zonas para servidores escravos, a porta 953/TCP para receber coman-
dos via "rndc"(que dependem de chaves criptografadas), e portas "udp"altas podem
ser dinamicamente atribuídas para efetuar consultas em outros servidores.
Vamos observar a recursividade e as portas envolvidas utilizando o "tcpdump", mas

antes vamos verificar as portas:
1 root@dmz :~ # netstat - nltup

2 tcp 0 0 192.168. X .3:53 0.0.0.0:* OU ÇA 1602/
named
3 tcp 0 0 127.0.0.1:53 0.0.0.0:* OU ÇA 1602/
named
4 tcp6 0 0 :::53 :::* OU ÇA 1602/
named

5 udp 0 0 127.0.0.1:53 0.0.0.0:* 1653/

named
6 udp 0 0 192.168. X .3:53 0.0.0.0:* 1602/ named
7 udp 0 0 127.0.0.1:53 0.0.0.0:* 1602/
named
8 udp6 0 0 :::53 :::* 1653/
named
9 udp6 0 0 :::53 :::* 1602/
named
Instale o sniffer tcpdump:
1 root@dmz :~ # aptitude install tcpdump
Execute o tcpdump para verificar os pacotes saindo de uma porta alta até a porta
53/udp de seu servidor:
1 root@dmz :~ # tcpdump -i eth0 -n port 53

2 tcpdump : verbose output suppressed , use -v or -vv for full protocol
decode
3 listening on eth0 , link - type EN10MB ( Ethernet ) , capture size 65535
bytes
Em outro terminal execute:
1 root@dmz :~ # dig @localhost -t any wikipedia . com
Verifique a saída do tcpdump:
1 19:11:52.396000 IP 192.168. X .3.33625 > 198.41.0.4.53: 12121 [1 au ]

ANY ? wikipedia . com . (42)

2 19:11:52.396000 IP 192.168. X .3.29726 > 192.33.4.12.53: 39309 [1 au ]

NS ? . (28)
3 19:11:52.544000 IP 192.33.4.12.53 > 192.168. X .3.29726: 39309* -
14/0/23 NS m. root - servers . net ., NS d. root - servers . net ., NS h. root
- servers . net ., NS k. root - servers . net ., NS g. root - servers . net ., NS
i. root - servers . net ., NS b. root - servers . net ., NS j. root - servers .
net ., NS a. root - servers . net ., NS f. root - servers . net ., NS c. root -
servers . net ., NS l. root - servers . net ., NS e. root - servers . net .,
RRSIG (857)
4 19:11:52.552000 IP 198.41.0.4.53 > 192.168. X .3.33625: 12121 - 0/15/16
(737)
Os logs de seu servidor DNS estão em "/var/log/daemon.log". Verifique-os:
1 root@dmz :~ # tail / var / log / daemon . log
No RedHat e Suse os eventos do serviço serão logados diretamente no "/var/-

log/messages".
7.0.17 BIND como servidor cache
“ As bibliotecas do resolvedor da maioria dos sistemas operacionais não são capa-

zes de executar o processo de resolução completo, chamado recursivo, como vimos
acima. Ao invés disso elas dependem de um servidor intermediário com essa capaci-
dade. Quando nos conectamos de casa diretamente à Internet, o serviço "DHCP"do
provedor se encarrega de nos atribuir o endereço de seus servidores cache. Caso
contrário, nosso "resolver"não teria a quem consultar e não conseguiríamos navegar.
No entanto, muitos administradores de rede utilizam os IPs desses provedores para
configurar várias estações de trabalho de uma rede. O efeito disto é que cada es-
tação vai fazer suas próprias consultas individuais, multiplicando o volume de dados

trafegados através do link de Internet, desperdiçando tempo e ocupando largura de

banda.
Quanto maior a rede, maior o impacto. A alternativa para evitar estes problemas é
manter um servidor DNS "caching only". Servidores "cache"reservam o resultado
de suas buscas na memória pelo tempo limite estabelecido pela autoridade so-
bre o domínio consultado. Dessa forma, independente da quantidade de máquinas
da rede, as consultas serão feitas na Internet apenas uma vez a cada intervalo de
atualização.
Nosso servidor recém instalado já está operando como servidor "cache". Faça uma
consulta e verifique o “Query time”. Repita o procedimento:
1 root@dmz :~ # dig @localhost -t soa kernel . org | tail -n6

2
4 ;; SERVER : 127.0.0.1 # 53(127.0.0.1)
5 ;; WHEN : Sun Jul 31 19:33:54 2011
6 ;; MSG SIZE rcvd : 221
7
8 root@dmz :~ # dig @localhost -t soa kernel . org | tail -n6
9
11 ;; SERVER : 127.0.0.1 # 53(127.0.0.1)
12 ;; WHEN : Sun Jul 31 19:33:58 2011
Para que a partir de agora todas as nossas aplicações utilizem o potencial de nosso
servidor "cache", edite o arquivo "/etc/resolv.conf" e mantenha apenas as linhas a
seguir:
1 root@dmz :~ # vim / etc / resolv . conf

2 nameserver 127.0.0.1

DICA: Não é necessária a configuração deste arquivo, pois mesmo sem ele
o servidor continua efetuando as consultas e resolvendo os nomes, além de fazer
cache!
A fim de termos uma maior segurança em relação às mudanças do arquivo /etc/re-

solv.conf, podemos adicionar um atributo de proteção a ele, não permitindo qualquer
tipo de alteração:
1 root@dmz :~ # chattr +i / etc / resolv . conf
7.0.18 Restringindo consultas
Um cuidado muito importante que devemos tomar com servidores "cache"é limitar
quem está autorizado a utilizar esse serviço. Por padrão, o nosso "BIND"está libe-
rado para acesso público, ou seja, se houver uma interface conectada diretamente a
Internet, qualquer outro computador no mundo pode mandar nosso servidor procurar
um determinado endereço. Ficamos vulneráveis a abusos! “
[ http://gnulinuxbr.com/2010/05/06/domain-name-system-%E2
Para evitar este comportamento, vamos acrescentar a seguinte restrição no arquivo

"/etc/bind/named.conf.options" (linha 16):
1 root@dmz :~ # vim / etc / bind / named . conf . options

2 allow - query { 127.0.0.1; 192.168. X .0/24; };

Para recarregar as modificações no "BIND", execute:
1 root@dmz :~ # service bind9 restart

2 Stopping domain name service ...: bind9 waiting for pid 1602 to die .
3 Starting domain name service ...: bind9 .
Dessa forma, o servidor só responderá para consultas originadas localmente! É

possível ser (se desejar!!!) ainda mais econômico em termos de banda se, ao invés
de executar uma busca recursiva a cada nova consulta, encaminhar a consulta para
o servidor disponibilizado pelo provedor. Isto pode ser feito descomentando as
linhas 13, 14 e 15, além de configurar o IP do DNS do provedor (exemplo do Terra),
no arquivo "/etc/bind/named.conf.options":

2 forwarders {
3 200.176.2.10;
4 };
Onde IP_DO_PROVEDOR é um servidor "DNS"capaz de fazer consultas re-

cursivas. Servidor de zonas
“ Cada domínio na Internet tem sua autoridade, que nada mais é do que um servi-
dor onde as informações daquele domínio são criadas, mantidas ou alteradas. Mas
como um domínio pode se subdividir em inúmeros outros domínios, surge um outro
conceito: Zonas.
Uma "zona"é o conjunto dos "hosts"de um domínio sobre o qual se mantém

autoridade. Uma vez delegado um subdomínio a outra autoridade, os "hosts"desse
domínio pertencem à "zona"daquela autoridade e não mais à "zona"original onde
inicia-se o subdomínio. “

Tipos de zonas e Registros
Em relação às "zonas", o "BIND"pode operar de acordo com 6 tipos: "master",

"slave", "stub", "hint", "forward"e "delegation-only".
master - O "BIND"vai responder como autoridade sobre aquele domínio. Os dados

da "zona"serão criados, publicados e administrados a partir dele.
slave - O "BIND"também vai responder por esse domínio, mas nenhuma criação ou
alteração respectiva a essa "zona"será feita localmente neste servidor. Os dados
serão sempre transferidos de um servidor "master".
stub - Este tipo de "zona"não é previsto em nenhuma "RFC"e foi implementado ape-
nas no "BIND". Assemelha-se a uma "zona slave"mas replica do "master"apenas os
registros do tipo "NS". Em desuso.
hint - Específica para o "BIND"onde ele deve começar uma busca recursiva quando
estiver operando como "cache". Por padrão, há uma "zona hint"criada com os ende-
reços dos 13 "root servers".
forward - Serve para orientar o "BIND"a encaminhar a consulta sobre uma determi-
nada "zona"para outro servidor em especial. O encaminhamento de consultas tam-
bém pode ser especificado de maneira global no arquivo "named.conf.options".
delegation-only - Para evitar abusos de algumas autoridades sobre domínios de

primeiro nível como "COM", "NET", "ORG", etc., o "BIND"mantém o tipo de zona
"delegação apenas". Qualquer resposta que não tenha uma delegação explícita ou
implícita na seção autoridade será transformada em uma resposta "NXDOMAIN".
Vamos configurar nossas zonas DNS: dexter.com.br e mandark.com.br. Pode ser

que na Internet já exista um domínio com este nome, mas isso não importa porque
nossas consultas ficarão limitadas ao laboratório.
As "zonas"devem ser declaradas no arquivo "/etc/bind/named.conf.local". Uma

"zona"mestre precisa, no mínimo, do nome do domínio, tipo de "zona" e o caminho

para o banco de dados de registros. Quando apenas o nome do arquivo é citado, o
servidor "BIND"vai procurá-lo no diretório definido na opção "directory", do arquivo
"/etc/bind/named.conf.options". Isso significa que, por padrão, o caminho completo
corresponderia a "/var/cache/bind/db.dexter"e "/var/cache/bind/db.mandark".
O conteúdo do banco de dados da "zona"que foi declarado será principalmente uma

série de registros de recursos ("resources records"), ou simplesmente, registros. No
entanto, três diretivas são suportadas:
• "$TTL"
• "$ORIGIN"
• "$INCLUDE"
Com exceção do "$TTL", as demais são raramente utilizadas.
Um registro tem o seguinte formato: dono [TTL] [classe] tipo dados.
dono - É o nome do registro. Quando substituído pelo símbolo "@", o dono é o

próprio domínio. Caso o dono fique em branco, o "BIND"assume o nome do registro
imediatamente superior;
TTL - Um valor, em segundos, para a permanência dos dados deste registro no

"cache"de um servidor. Raramente utilizado.
classe - Podem ser "CH", "HS"ou "IN". O padrão é "IN", de Internet, e não precisa
ser declarada. CH = CHAOS e HS = Hesiod
tipo - No momento existem mais de 30 tipos de registro, dentre os quais veremos

"SOA", "NS", "MX", "A", "CNAME", "TXT"e "PTR".

dados - Diferentes tipos de dados são definidos para diferentes tipos de registros.
Para um registro tipo "A"temos um endereço IP por exemplo.
Recentemente, registros do tipo "TXT"tem sido usados para aumentar o controle

contra "spams". São criados de acordo com o formato definido pelo projeto SPF -
Sender Policy Framework, ou simplesmente "SPF".
O "SPF"diz quais servidores podem enviar e-mails em nome do seu domínio. O

objetivo é evitar que seu domínio seja usado para forjar remetentes falsos. Grandes
provedores já adotaram o "SPF"e cada vez mais outros domínios vem seguindo a
mesma prática. Tende a tornar-se uma imposição. Muito mais antigo que o "SPF",
e por consequência, uma imposição natural do ecossistema de e-mails, é garantir
que o IP do registro "MX" tenha endereço reverso. Esta é uma forma de checar se
o e-mail partiu de um usuário doméstico cujo computador está sendo usado como
"zumbi", por exemplo.
Normalmente, configurar o endereçamento reverso não depende do administrador

do domínio, mas sim do provedor do link. Porém, é possível requisitar autoridade
sobre o bloco de IPs destinado àquele link. Vai depender do provedor. Mas como
em nosso caso estamos utilizando apenas endereços privados, vamos assumir a
autoridade sobre todo o bloco 192.168.X.0/24.”
[ http://gnulinuxbr.com/2010/05/17/domain-name-system-%E2%80%93-
servidor-dns-no-debian-%E2%80%93-parte-3/ ]
7.0.19 Configuração do DNS primário
Agora iremos configurar o "Bind9", lembrando que estamos fazendo um teste interno,
restringindo as consultas apenas para a rede local, certifique-se de que os arquivos
"/etc/resolv.conf" e "/etc/hosts" estejam corretos. Vamos configurar as duas zonas
de nossos domínios no arquivo "/etc/bind/named.conf.local":

1 root@dmz :~ # vim / etc / bind / named . conf . local

2 zone " dexter . com . br " {
3 type master ;
4 file " db . dexter ";
5 };
6 zone " mandark . com . br " {
7 type master ;
8 file " db . mandark ";
9 };
Agora criaremos o banco de dados de registros de "DNS", onde teremos servidores

de e-mail, web e ftp. Primeiro o domínio “dexter.com.br.”
1 root@dmz :~ # vim / var / cache / bind / db . dexter

2 $TTL 86400 ; default para todos os registros sem TTL
3 @ IN SOA ns1 . dexter . com . br . root . dexter . com . br . (
4 2011073101; serial
5 8h ; refresh
6 1h ; retry
7 3d ; expire
8 3h); negative caching ttl
9 ;
10 @ IN NS ns1 . dexter . com . br .
11 @ IN MX 10 mail . dexter . com . br .
12 ns1 IN A 192.168. X .3
13 www IN A 192.168. X .3
14 ftp IN CNAME www
15 mail IN A 192.168. X .3
16 smtp IN CNAME mail
17 webmail IN CNAME mail
18 pop IN CNAME mail
19 imap IN CNAME mail
Agora o domínio “mandark.com.br”:

1 root@dmz :~ # vim / var / cache / bind / db . mandark

3 @ IN SOA ns1 . mandark . com . br . root . mandark . com . br . (
4 2011073101; serial
5 8h ; refresh
6 1h ; retry
7 3d ; expire
9 ;
10 @ IN NS ns1 . mandark . com . br .
11 ns1 IN A 192.168. X .3
12 www IN A 192.168. X .3
Sobre o registro "SOA", vão algumas explicações:
serial - É a referência para os "slaves"saberem se a "zona"sofreu alterações;
refresh - Tempo que o servidor secundário vai aguardar até checar se há atualizações
no servidor primário;
retry - Em caso de falha do "refresh", o tempo até a próxima verificação;
expire - O tempo que o secundário aguardará o primário voltar, se esgotar, o secun-

dário pára de responder por essa zona;
negative caching TTL - Se a zona expirar, esse será o tempo pelo qual um servi-
dor "cache"armazenará a informação "NXDOMAIN"antes de iniciar uma nova busca
recursiva. O máximo são 3 horas.
Vamos checar os arquivos de configuração para ver se não tem erros:
1 root@dmz :~ # named - checkconf / etc / bind / named . conf . options

2 root@dmz :~ # named - checkconf / etc / bind / named . conf . local

Se o comando retornar ao “prompt” significa que está correto! Agora vamos checar
a configuração da zona que temos autoridade:
1 root@dmz :~ # named - checkzone dexter . com . br / var / cache / bind / db . dexter

2 zone dexter . com . br / IN : loaded serial 2011073101
3 OK
4 root@dmz :~ # named - checkzone mandark . com . br / var / cache / bind / db .
mandark
5 zone mandark . com . br / IN : loaded serial 2011073101
6 OK
Reinicie o serviço do Bind9:

Vamos fazer alguns testes envolvendo nossos domínios e o comando dig:
1 root@dmz :~ # dig @127 .0.0.1 -t soa dexter . com . br

3 ;; flags : qr aa rd ra ; QUERY : 1, ANSWER : 1, AUTHORITY : 1, ADDITIONAL
: 1
5 ; dexter . com . br . IN SOA
7 dexter . com . br . 86400 IN SOA ns1 . dexter . com . br . dexter . com . br .
root . dexter . com . br . 2011073101 28800 3600 259200 10800
8 ;; AUTHORITY SECTION :
9 dexter . com . br . 86400 IN NS ns1 . dexter . com . br .
10 ;; ADDITIONAL SECTION :
11 ns1 . dexter . com . br . 86400 IN A 192.168. X .3

13 ;; SERVER : 127.0.0.1 # 53(127.0.0.1)

14 ;; WHEN : Mon Aug 1 13:04:16 2011
Agora com o domínio mandark.com.br:
1 root@dmz :~ # dig @127 .0.0.1 -t soa mandark . com . br

: 1
5 ; mandark . com . br . IN SOA
7 mandark . com . br . 86400 IN SOA ns2 . mandark . com . br . mandark . com . br .
root . mandark . com . br . 2011073101 28800 3600 259200 10800
9 mandark . com . br . 86400 IN NS ns2 . mandark . com . br .
11 ns2 . mandark . com . br . 86400 IN A 192.168. X .3
13 ;; SERVER : 127.0.0.1 # 53(127.0.0.1)
14 ;; WHEN : Mon Aug 1 13:10:46 2011
Vamos testar as configurações referente ao e-mail:
1 root@dmz :~ # dig @127 .0.0.1 -t mx dexter . com . br

: 2
5 ; dexter . com . br . IN MX
7 dexter . com . br . 86400 IN MX 10 mail . dexter . com . br .

9 dexter . com . br . 86400 IN NS ns1 . dexter . com . br .
11 mail . dexter . com . br . 86400 IN A 192.168. X .3
12 ns1 . dexter . com . br . 86400 IN A 192.168. X .3
14 ;; SERVER : 127.0.0.1 # 53(127.0.0.1)
15 ;; WHEN : Mon Aug 1 13:12:16 2011
Vamos efetuar um ping no domínio dexter.com.br:
1 root@dmz :~ # ping -c2 www . dexter . com . br

2 PING www . dexter . com . br (192.168. X .3) 56(84) bytes of data .
3 64 bytes from 192.168. X .3: icmp_req =1 ttl =64 time =0.457 ms
4 64 bytes from 192.168. X .3: icmp_req =2 ttl =64 time =0.136 ms
Reinicie o Bind9 novamente e verifique o log:

2 root@dmz :~ # tail -f / var / log / daemon . log
3 Aug 1 13:23:35 dmz named [1370]: zone localhost / IN : loaded serial 2
4 Aug 1 13:23:35 dmz named [1370]: managed - keys - zone ./ IN : loading
from master file managed - keys . bind failed : file not found
5 Aug 1 13:23:35 dmz named [1370]: managed - keys - zone ./ IN : loaded
serial
6 Aug 1 13:23:35 dmz named [1370]: running
7 Aug 1 13:23:35 dmz named [1370]: zone dexter . com . br / IN : sending
notifies ( serial 2011073101)
8 Aug 1 13:23:35 dmz named [1370]: zone mandark . com . br / IN : sending
notifies ( serial 2011073101)

Configurando o RNDC
O comando rndc (Remote Named Daemon Control) é uma ferramenta de geren-

ciamento do named. A vantagem dessa ferramenta é que ela permite controlar o
named muito facilmente sem ter que ficar enviando sinais ao processo do mesmo.
Vamos limitar o seu uso apenas no próprio servidor, para isso vamos alterar o arquivo
“/etc/bind/named.conf.local.”

2 include "/ etc / bind / rndc . key ";
3 controls {
4 inet 127.0.0.1 port 953 allow { localhost ; } keys { " rndc - key "; };
5 };
7 type master ;
9 };
11 type master ;
13 };
Para configurar o RNDC devemos primeiro gerar a chave criptográfica. Sendo assim,
execute:
1 root@dmz :~ # cd / etc / bind

2 root@dmz :/ etc / bind # rndc - confgen -r / dev / urandom -a
3 wrote key file "/ etc / bind / rndc . key "
Veja a chave gerada:

1 root@dmz :/ etc / bind # cat rndc . key

2 key " rndc - key " {
3 algorithm hmac - md5 ;
4 secret " gdt6lf3SlKt + o6e3UeqVrw == ";
5 };
Por segurança, deixe leitura e escrita somente para o root e o grupo:
1 root@dmz :/ etc / bind # chmod 770 / etc / bind / rndc . key
Agora que ajustamos as configurações, reinicie o serviço:

Veja o status do “rndc”:
1 root@dmz :~ # rndc status

2 version : 9.7.3
3 CPUs found : 1
4 worker threads : 1
5 number of zones : 20
6 debug level : 0
7 xfers running : 0
8 xfers deferred : 0
9 soa queries in progress : 0
10 query logging is OFF
11 recursive clients : 0/0/1000
12 tcp clients : 0/100
13 server is up and running

Agora podemos executar os comando re reload com o rndc:
1 root@dmz :~ # rndc reload

2 server reload successful
Para vermos o que está em cache no DNS, podemos usar os comandos abaixo:
1 root@dmz :~ # rndc dumpdb - cache

2 root@dmz :~ # cat / var / cache / bind / named_dump . db
E para limpar o cache execute:
1 root@dmz :~ # rndc flush
7.0.20 Configurando o DNS reverso
DNS reverso é um recurso que permite que outros servidores verifiquem a auten-
ticidade do seu servidor. Para isso, ele checa se o endereço IP atual bate com o
endereço IP informado pelo servidor DNS. Os servidores de e-mail irão recusar seus
e-mails ou classificá-los como spam caso o DNS reverso não esteja configurado.
É de suma importância para que o serviço de e-mail não seja detectado como
spam ao enviar um e-mail;!
Abra o arquivo “/etc/bind/named.conf.local” e inclua no final o seguinte:


2 ...
3 zone "X .168.192. in - addr . arpa " {
4 type master ;
5 file " db . rev ";
6 };
Agora configure o arquivo reverso...
1 root@dmz :~ # vim / var / cache / bind / db . rev

3 @ IN SOA ns1 . dexter . com . br . root . dexter . com . br . (
4 2011073101; serial
5 8h ; refresh
6 1h ; retry
7 3d ; expire
9 ;
11 ns1 IN A 192.168. X .3
12 3 IN PTR mail . dexter . com . br .
13 inclua no final do arquivo da zona dexter . com . br
15 @ IN MX 20 mail2 . dexter . com . br .
16 mail2 IN A 192.168. X .2
Reinicie o Bind9:


Vamos realizar um teste com o comando dig para verificar o reverso:
1 root@dmz :~ # dig @127 .0.0.1 -x 192.168. X .3

2 ...
4 ;3. X .168.192. in - addr . arpa . IN PTR
5
7 3. X .168.192. in - addr . arpa . 86400 IN PTR mail . dexter . com . br .
8
10 X .168.192. in - addr . arpa . 86400 IN NS ns1 . dexter . com . br .
Como vimos, nosso DNS reverso está corretamente configurado!
7.0.21 Configurando o DNS secundário
Para registrarmos um domínio público, precisamos de pelo menos dois servi-

dores "DNS"respondendo pelo seu domínio. Isso significa um servidor master (mes-
tre) e pelo menos um servidor slave (escravo). A exigência é uma forma de garantir
que seu domínio estará sempre disponível. Se um servidor parar, o outro continua
respondendo!
Se os servidores estiverem geograficamente separados, isto garante ainda mais dis-

ponibilidade, pois mesmo que um link caia, o outro certamente ainda estará disponí-
vel. Na verdade, um mesmo servidor rodando BIND pode ser ao mesmo tempo mes-
tre para alguns domínios, escravo para outros, e "cache"para todo o resto. Sendo
assim, vamos efetuar a instalação do Bind9 numa outra máquina para servir de es-
cravo (secundário). Esta máquina será a “Datacenter”

Antes de configuramos a máquina slave, vamos deixar nosso bind autorizado a trans-
ferir as zonas para esta máquina. Acrescente no arquivo “named.conf.local” o que
está em negrito:

2 include "/ etc / bind / rndc . key ";
3 controls {
4 inet 127.0.0.1 port 953 allow { localhost ; } keys { " rndc - key ";
};
5 };
7 type master ;
9 allow - transfer { 192.168. X .2; };
10 notify yes ;
11 also - notify { 192.168. X .2; };
12 };
14 type master ;
16 allow - transfer { 192.168. X .2; };
17 notify yes ;
18 also - notify { 192.168. X .2; };
19 };
20 zone " 200.168.192. in - addr . arpa " {
21 type master ;
22 file " db . rev ";
23 };
Explicando as inclusões:
allow-transfer - para transferir a zona para o secundário.
notify yes - o servidor mestre envia uma mensagem DNS NOTIFY para os servi-
dores escravos para fazê-los conferir o arquivo de zona imediatamente. Isso é feito

para manter o banco de dados mestre e escravo firmemente sincronizados.
also-notify - diz para o servidor também notificar o endereço fornecido entre cha-
ves.
Devemos configurar também o arquivo de registro da zona DNS dos domínios que
temos autoridade. Primeiro o domínio dexter.com.br. Coloque no final do arquivo:

2 ; configura ção do DNS secund á rio
4 ns2 IN A 192.168. X .2 ; IP da má quina Datacenter
Agora o domínio mandark.com.br, também no final do arquivo:
1 root@dmz :~ # vim / var / cache / bind / db . mandark

2 ; configura ção do DNS secund á rio
3 @ IN NS ns2 . mandark . com . br .
4 ns2 IN A 192.168. X .2 ; IP da má quina Datacenter
Não podemos esquecer do reverso! Acrescente no final do arquivo:
1 root@dmz :~ # vim / var / cache / bind / rev . dexter

2 ; configura ção do DNS reverso secund á rio
3 2 IN PTR mail . dexter . com . br .
Reinicie o Bind9:


7.0.22 Configurando o DNS Secundário
Vamos agora efetuar a instalação e configuração do Bind9 na máquina Datacenter.

Inicie a máquina e execute:
1 root@datacenter :~ # aptitude install bind9
Abra o arquivo de declaração de zonas e insira o seguinte:
1 root@datacenter :~ # vim / etc / bind / named . conf . local

3 type slave ;
5 masters { 192.168. X .3; };
6 };
8 type slave ;
10 masters { 192.168. X .3; };
11 };
Reinicie o Bind9:
1 root@datacenter :~ # service bind9 restart

Verifique no log da máquina Datacenter (slave) que houve a transferência da zona

master de nossos domínios:
1 root@datacenter :~ # cat / var / log / daemon . log | grep named | grep trans

2 Aug 2 21:19:54 datacenter named [1815]: transfer of ’ dexter . com . br /

IN ’ from 192.168. X .3 # 53: connected using 192.168. X .2#59881
3 Aug 2 21:19:54 datacenter named [1815]: zone dexter . com . br / IN :
transferred serial 2011073101
4 Aug 2 21:19:54 datacenter named [1815]: transfer of ’ dexter . com . br /
IN ’ from 192.168. X .3 # 53: Transfer completed : 1 messages , 15
records , 397 bytes , 0.008 secs (49625 bytes / sec )
5 Aug 2 21:19:54 datacenter named [1815]: transfer of ’ mandark . com . br /
IN ’ from 192.168. X .3 # 53: connected using 192.168. X .2#54614
6 Aug 2 21:19:54 datacenter named [1815]: zone mandark . com . br / IN :
transferred serial 2011073101
7 Aug 2 21:19:54 datacenter named [1815]: transfer of ’ mandark . com . br /
IN ’ from 192.168. X .3 # 53: Transfer completed : 1 messages , 7
records , 216 bytes , 0.010 secs (21600 bytes / sec )
7.0.23 Desativar recursão externa
Para o servidor DNS funcionar fora da rede local é interessante desabilitar a opção
de recursão, pois isto evitará abusos, como por exemplo, alguma máquina usar o
servidor da empresa DEXTER COURIER para fazer consultas de DNS.
Para fazer isto, vá na máquina DMZ no arquivo /etc/bind/named.conf.options e

insira o que está em negrito, restringindo o uso do DNS
1 somente na nossa rede :

3
4 allow - query { 127.0.0.1; 192.168. X .0/24; };
5 allow - recursion { 192.168. X .0/24; };
6 auth - nxdomain no ; # conform to RFC1035
7 listen -on - v6 { any ; };

7.0.24 SPF - Sender Policy Framework
É um recurso que diz quais servidores podem enviar e-mails em nome do seu
domínio. O objetivo é evitar que seu domínio seja usado para forjar remetentes
falsos, facilitando o envio de spam mundo afora!
Acrescente na última linha do arquivo “/etc/bind/db.dexter ”:
1 root@dmz :~ # vim / etc / bind / db . dexter

2 ...
3 ; configura ção do SPF
4 @ IN TXT "v= spf1 a mx ip4 :192.168. X .3 - all "
Sobre o registro "TXT":
• a - Qualquer registro "A"desse domínio;
• mx - Servidor de e-mail;
• 192.168.X.3 – Somente o IP 192.168.X.3; qualquer outra origem descarte.
Agora reinicie o Bind9:

Arrumando o DHCP
Precisamos alterar a configuração do servidor DHCP para enviar o endereço dos

nossos servidores DNS para as estações. Na máquina “Datacenter” faça:

1 root@datacenter :~ # vim / etc / dhcp / dhcpd . conf

2
3 option domain - name - servers 192.168. X .3 ,192.168. X .2;
Agora basta reinicializar o serviço do DHCP:
1 root@datacenter :~ # service isc - dhcp - server restart
Vá na máquina “Squeeze” e rode os comandos abaixo:
1 root@squeeze :~ # dhclient -r ; dhclient eth0 -v
Com isto iremos atualizar nosso “/etc/resolv.conf”, apontando para o DNS localizado
na rede. Visualize o arquivo:
1 root@squeeze :~ # cat / etc / resolv . conf

2 domain dexter . com . br
3 search dexter . com . br
4 nameserver 192.168. X .3
5 nameserver 192.168. X .2

Capítulo 8
Servidor Apache
Cenário
A empresa DEXTER COURIER precisa de um site para divulgação de seus serviços

e um ambiente de aprendizado online para treinamento de seus funcionários. Este
ambiente deverá ficar dentro da empresa, porém o acesso externo será necessá-
rio.
Será montado o ambiente com um WebServer Apache, tendo suporte à linguagem

de programação PHP e ao SGBD (Sistema gerenciador de Banco de Dados) MySQL
para acesso ao Moodle (ambiente de aprendizado online). Também iremos habilitar
SSL para os site, gerando um certificado digital. Após a implementação, testes e
homologação, o firewall deverá ser configurado para que os funcionários possam
acessar o Moodle de fora da empresa.
147
O "Web Server"Apache é um esforço comunitário feito por desenvolvedores ao redor

do mundo, cujo objetivo consiste em desenvolver um servidor web de código fonte
aberto, estável e seguro. Em 1996, tornou-se um dos "Web Servers"mais populares
no mundo e desde então, mantém sua posição como o servidor web com a maior
base instalada no mundo.
Segundo uma pesquisa feita pelo site "NetCraft"(www.netcraft.com), o Apache

está servindo, em média, mais de 50% dos sites pesquisados. Isso só foi possí-
vel graças a uma série de qualidades, das quais algumas serão listadas abaixo:
• é Software Livre, podendo ser estudado, modificado, adaptado e redistribuído;
• suporta várias linguagens, como "PHP", "Python", "Ruby", "Perl"e inclusive

"ASP"e ".NET"; sendo assim, ele é multi plataforma;
• possui suporte a várias funcionalidades providas por módulos;
• pode trabalhar com multi "threads", isto é, multi processos.
8.0.27 MPM PreFork e MPM Worker
A documentação oficial do projeto Apachempm indica que é possível escolher entre

algumas configurações que ajudam a otimizar a performance ou manter a compati-
bilidade com aplicações antigas, por exemplo. Vamos entender as particularidades
dos modos "PreFork"e "Worker".

MPM Pre Fork
Neste modo, o Apache trabalhará com a implementação de multi processos, de

acordo com a estrutura clássica de um processo Unix, similar a versão 1.3 do Web
Server em questão.
Assim sendo, um único processo será responsável por executar novos processos
que serão utilizados para aguardar novas conexões e responder as requisições exis-
tentes. Este modo é ideal para quem precisa manter compatibilidade com aplicações
e bibliotecas que NÃO SUPORTAM o modo "thread".
MPM Worker
No modo "MPM Worker", o Apache trabalhará com uma implementação mista de

processos e "threads", o que possibilita atender mais conexões simultâneas com um
custo menor de hardware, já que "threads"são mais velozes que processos.
Neste modo, o apache mantém uma série de "threads"ociosas, fazendo com que
novas conexões sejam processadas e respondidas de uma maneira mais rápida do
que no modo "Pre Fork". Infelizmente nem toda aplicação se dá bem com "threads",
como o "PHP5", por exemplo.
8.0.28 Laboratório
Visto que o servidor irá agregar tanto o site da Dexter como o Moodle no domínio
Mandark, e que ambos deverão possuir acesso externo, faremos o ambiente na
máquina “DMZ”. Apenas o MySQL ficará na máquina “Datacenter”. Inicie ambas
as máquinas e vamos fazer a instalação do WebServer e SGBD, lembrando que
precisamos desabilitar a proteção contra execução de arquivos no /tmp. Após a
instalação, ative a proteção novamente. Execute na máquina “DMZ”:

1 root@dmz :~ # aptitude install apache2 libapache2 - mod - php5 php5 php5 -

curl php5 - gd php5 - intl php5 - xmlrpc php5 - mysql php - pear
Após a instalação, abra um browser e digite:
1 http ://192.168. X .3
8.0.29 Conhecendo a estrutura do Apache
No Debian, a localização dos arquivos do Apache fica em “/etc/apache2”. Abaixo

um resumo da função de cada um dos itens:
apache2.conf - Arquivo de configuração principal; httpd.conf - Compatibilidade

com o Apache 1; modules.conf - Arquivo de configuração de módulos; ports.conf
- Arquivo de configuração de portas; sites-available/ - Configuração de VirtualHost
disponíveis; sites-enabled/ - Configuração de VirtualHost ativos; mods-available/ -
Módulos disponíveis; mods-enabled/ - Módulos habilitados; conf.d/ - Configurações

extras, como ajustes de segurança (arquivo security) e charset (configurações de

condificação).
Abra o arquivo de configuração para que possamos visualizar as principais opções

de configuração do Apache:
1 root@dmz :~ # vim / etc / apache2 / apache2 . conf \ textbf {}
A variável "ServerRoot"define o local onde o Apache deve procurar por seus arquivos
de configuração. No exemplo abaixo, os arquivos de configuração serão procurados
em "/etc/apache2":
ServerRoot /etc/apache2
O usuário e grupo que executa o apache são definidos pelas variáveis abaixo:
User $APACHE_RUN_USERS Group $APACHE_RUN_GROUP
Caso seja encontrado algum erro durante o funcionamento do Apache, o mesmo

será registrado de acordo com o desígnio da variável "ErrorLog", como no exemplo
abaixo:
ErrorLog /var/log/apache2/error.log

E, ainda falando em logs, o Apache suporta a declaração de registros personalizados

através do uso da variável "LogFormat":
1 LogFormat " \% h \% l \% u \% t \" \% r\" \% > s \% b \" \% Refereri \" \" \% User -
Agenti \"" combined
Os logs, por padrão, são armazenados no formato "combined", dentro do arquivo

"/var/log/apache2/access.log", com os seguintes itens:
1 \ textbf {\% h } - " Hostname " ou endere ço IP do visitante ;

2 \ textbf {\% l} - Hí fen ;
3 \ textbf {\% u } - Nome de usu á rio , caso exista ;
4 \ textbf { \% t} - Hor á rio de acesso ;
5 \ textbf {\% r} - Requisi ção solicitada ;
6 \ textbf {\% > s } - O resultado da solicita ção ;
7 \ textbf {\% b} - O tamanho em bytes da resposta ;
8 \ textbf { Refereri } - O site anterior a visita , se informado ;
9 \ textbf { User - Agenti } - O navegador do visitante , se informado .
A prova pode perguntar sobre as variáveis "ErrorLog", "CustomLog", "Server-

Root"e "DocumentRoot".
Ajustes dos módulos Worker e PreFork
Ainda dentro do arquivo de configuração do apache, existem ajustes de performance

para os módulos "MPM Worker"e "MPM Prefork". Por padrão, o apache vem con-
figurado para trabalhar em "MPM Worker", então, vamos entender suas configura-
ções:

1 StartServers 2 - configura o nú mero inicial de servidores ;

2 MaxClients 150 - o nú mero má ximo de conex õ es simult â neas ;
3 MinSpareThreads 25 - configura o valor mí nimo de " threads " em
espera ;
4 MaxSpareThreads 75 - configura o valor má ximo de " threads " em
espera ;
5 ThreadsPerChild 25 - configura o nú mero de threads inicializadas
por cada processo ;
6 MaxRequestsPerChild 0 - configura o valor má ximo por processo
O módulo "PreFork" também possui ajustes similares ao módulo "Worker":
1 StartServers 5 - configura o nú mero inicial de servidores ;

2 MinSpareServers 5 - configura o valor mí nimo de processos em
espera ;
3 MaxSpareServers 10 - configura o valor má ximo de processo em
espera ;
4 MaxClients 150 - nú mero má ximo de conex õ es simult â neas ;
5 MaxRequestsPerChild 0 - configura o valor má ximo por processo .
8.0.30 Suporte a PHP
A linguagem de programação PHP é uma das mais populares entre os desenvolve-

dores Web. Muitas ferramentas de "blogs", "WebSites"e também ferramentas web
para administração de serviços e servidores, como o "PhpLdapAdmin", necessitam
do "PHP5"configurado como pré requisito para instalação. Verifique se os módulos
do PHP5 estão ativados:
1 root@dmz :~ # ls -lh / etc / apache2 / mods - enabled | grep php

2 lrwxrwxrwx 1 root root 27 Ago 3 20:21 php5 . conf -> ../ mods -
available / php5 . conf

3 lrwxrwxrwx 1 root root 27 Ago 3 20:21 php5 . load -> ../ mods -
available / php5 . load
4 root@dmz :~ # apache2ctl -M | grep php
5 Syntax OK
6 php5_module ( shared )
O PHP5 é ativado por padrão durante a instalação do módulo, porém, caso neces-
sário, habilite o suporte manualmente:
1 root@dmz :~ # a2enmod php5
1 Se precisar descarregar um mó dulo , use a sintaxe :

2 a2dismod <mó dulo >
Na plataforma RedHat, a habilitação de módulos é feita utilizando o comando

system-config-http
Reinicie o serviço do Apache:
1 root@dmz :~ # service apache2 restart

2 Restarting web server : apache2 ... waiting .
Para testar o PHP, crie um arquivo com o nome "index.php"(no diretório /var/www/)
com o conteúdo a seguir e abra no seu "browser":
1 root@dmz :~ # vim / var / www / index . php

2 <?
3 phpinfo ()
4 ?>

Agora, acesse o browser e digite na URL o endereço do servidor Web e o arquivo

que acabou de criar:
1 http ://192.168. X .3/ index . php
Veja que a página exibida traz muitas informações sobre o PHP:
O arquivo "/etc/php5/apache2/php.ini", armazena as configurações do funcio-

namento do "PHP5"com Apache2. A função do arquivo e seu "path"completo podem
ser cobrados na LPI. O Apache2 e sua configuração estão na prova 202 - peso 3.
8.0.31 Arrumando os diretórios
Vamos criar a seguinte estrutura na máquina “DMZ” (192.168.X.3):

1 root@dmz :~ # mkdir -p / srv / www /{ dexter , mandark }

2 root@dmz :~ # ls -lh / srv / www /
O que é o Moodle?
Moodle é um Sistema Open Source de Gerenciamento de Cursos - Course Mana-

gement System (CMS), também conhecido como Learning Management System
(LMS) ou um Ambiente Virtual de Aprendizagem (AVA).
Tornou-se muito popular entre os educadores de todo o mundo como uma ferramenta
para criar sites de web dinâmicos para seus alunos. Para funcionar, ele precisa ser
instalado em um servidor web com suporte a PHP e banco de dados MYSQL.
O link para o site é http://moodle.org.
Baixe do servidor da sala de aula o pacote do Moodle chamado moodle.tgz e des-

compacte em /srv/www/mandark:
1 root@dmz :~ # tar xvzf moodle . tgz -C / srv / www / mandark

2 root@dmz :~ # mkdir -p / srv / www / mandark / moodledata
Crie o usuário “webdesign” para ter acesso via FTP ao nosso site e poder efetuar as
atualizações:
1 root@dmz :~ # adduser webdesign
Agora vamos mudar as permissões de acesso:

1 root@dmz :~ # chown -R webdesign : webdesign / srv / www / dexter

2 root@dmz :~ # chown -R www - data : www - data / srv / www / mandark
3 root@dmz :~ # chmod -R 775 / srv / www / mandark
Instalando o MySQL Server
Agora instale o MySQL Server na máquina “Datacenter”:
1 root@datacenter :~ # aptitude install mysql - server
Vamos criar a base de dados no MySQL para o Moodle:
1 root@datacenter :~ # mysql -u root -p

2 Enter password :
3 mysql >
Crie a data base “moodle”:
1 mysql > create database moodle ;

2 Query OK , 1 row affected (0.00 sec )
Altere a tabela para poder trabalhar com a codificação UTF-8:
1 mysql > alter database moodle default character set utf8 COLLATE
utf8_unicode_ci ;
2 Query OK , 1 row affected (0.04 sec )

Dê privilégios para o usuário moodleuser em localhost:
1 mysql > grant all privileges on moodle .* to moodleuser@ ’\% ’

identified by ’123456 ’ with grant option ;
2 Query OK , 0 rows affected (0.03 sec )
»»»> PRESTE ATENÇÃO «««<
Caso haja algum problema e você deseje remover os privilégios do usuário na

base de dados, execute:
1 mysql > revoke all privileges , grant option from moodleuser ;
Verifique se a base está criada e depois saia:
1 mysql > show databases ;

2 + - - - - - - - - - - - - - - - - - - - -+
3 | Database |
4 + - - - - - - - - - - - - - - - - - - - -+
5 | information_schema |
6 | moodle |
7 | mysql |
8 + - - - - - - - - - - - - - - - - - - - -+
9 3 rows in set (0.00 sec )
COMENTE a linha 47 do arquivo /etc/mysql/my.cnf:
1 root@datacenter :~ # vim / etc / mysql / my . cnf

2 # bind - address = 0.0.0.0
Reinicie o serviço do mysql:

1 root@datacenter :~ # service mysql restart

2 Stopping MySQL database server : mysqld .
3 Starting MySQL database server : mysqld .
4 Checking for corrupt , not cleanly closed and upgrade needing tables
..
8.0.32 Configurando o “php.ini”
Vamos voltar para a máquina “DMZ” e configurar o arquivo php.ini:
1 root@dmz :~ # vim / etc / php5 / apache2 / php . ini

2 post_max_size = 16 M # linha 728 => alterar
3 upload_max_filesize = 100 M # linha 879 => alterar
4 # ##### Acrescente no final do arquivo :
5 extension = mysql . so
6 extension = gd . so
8.0.33 VirtualHost?
O que é um VirtualHost? É uma funcionalidade que permite ao seu WebServer res-

ponder por um ou mais sites em um mesmo IP, o que possibilita acessar serviços e
páginas diferentes em um mesmo servidor, apenas apontando a entrada DNS cor-
reta nos arquivos de configuração. Qual a desvantagem nisso? Não se pode ter um
volume muito grande de sites, pois os recursos como hardware e banda são limita-
dos!
Os domínios virtuais devem ser configurados nestes dois diretórios:
/etc/apache2/sites-available: configuração dos domínios virtuais;

/etc/apache2/sites-enabled: domínios virtuais ativos (links simbólicos para os ar-

quivos de configuração localizados no diretório citado anteriormente).
8.0.34 Criando Virtualhost para nossos domínios
Vamos configurar o Virtualhost do domínio dexter.com.br:
1 root@dmz :~ # vim / etc / apache2 / sites - available / dexter . com . br

2 < VirtualHost *:80 >
3 DocumentRoot / srv / www / dexter /
4 ServerName www . dexter . com . br
5 ServerAdmin root@dexter . com . br
6 ErrorLog / var / log / apache2 / dexter - error . log
7 CustomLog / var / log / apache2 / dexter - access . log common
8 </ VirtualHost >
Agora vamos configurar o Virtualhost do domínio mandark.com.br:
1 root@dmz :~ # vim / etc / apache2 / sites - available / mandark . com . br

3 DocumentRoot / srv / www / mandark / moodle /
4 ServerName www . mandark . com . br
5 ServerAdmin root@mandark . com . br
6 ErrorLog / var / log / apache2 / mandark - error . log
7 CustomLog / var / log / apache2 / mandark - access . log common
8 </ VirtualHost >
A prova de certificação pode cobrar o uso de parâmetros, como "ErrorLog"e

sua função.

Finalmente temos que ativar os dois sites no Apache para que eles possam subir
quando digitarmos seu domínio na URL:
1 root@dmz :~ # a2ensite dexter . com . br

2 Enabling site dexter . com . br .
3 Run ’/ etc / init .d/ apache2 reload ’ to activate new configuration !
4 root@dmz :~ # a2ensite mandark . com . br
5 Enabling site mandark . com . br .
6 Run ’/ etc / init .d/ apache2 reload ’ to activate new configuration !

8.0.35 Fechando brechas de segurança
Antes de reforçarmos a segurança do servidor , vamos executar o nmap:
1 root@dmz :~ # nmap -sV localhost

2 80/ tcp open http Apache httpd 2.2.16 (( Debian ))
Agora abra o arquivo “/etc/apache2/conf.d/security” e modifique as configurações

para que o Apache mostre a menor quantidade possível de informações ao usuário
ou pior ainda, um atacante!
1 root@dmz :~ # vim / etc / apache2 / conf .d/ security

2 ServerTokens Prod
3 ServerSignature Off

4 TraceEnable Off
As opções do “ServerTokens” são: (em negrito a melhor opção) ServerTokens Prod

- Revela somente o nome do produto;
O parâmetro “ServerSignature” é utilizado para ativar/desativar as mensagens de

informações do servidor. Já o parâmetro “TraceEnable” é usado para realizar testes
e diagnósticos.

Execute o nmap para vermos o que aparecerá após as modificações:

1 root@dmz :~ # nmap -sV localhost

2 80/ tcp open http Apache httpd
Vamos testar a configuração do Apache.
1 root@dmz :~ # apache2ctl -S
2 ...
3 port 80 namevhost www . dexter . com . br (/ etc / apache2 / sites -
enabled / dexter . com . br :1)
4 port 80 namevhost www . mandark . com . br (/ etc / apache2 / sites -
enabled / mandark . com . br :1)
5 Syntax OK
8.0.36 Configurando o Moodle
Vamos configurar o Moodle, que deverá ser acessado através do browser: No Nave-
gador, digite:
http://www.mandark.com.br
Irá abrir a tela de instalação e configuração do Moodle. Preste atenção para não
cometer erros, ok! Escolha o idioma Português.

Confirme o diretório (já criado) para os dados do Moodle.

Pacote de idioma português não encontrado, pegue no servidor!

Escolha o driver MySQL para acesso à base de dados!

Configuração de acesso à base SQL.

Conexão ao banco OK! Termo de licença para aceite.

Checagem de requisitos para o servidor OK!

Instalação do sistema.

Instalação do sistema concluída.

Configuração do administrador, senha, e-mail e localização.

Configuração do nome do Ambiente e mensagem de apresentação.

Tela de apresentação do Ambiente Moodle.

Tela de login do Moodle após a instalação!

8.0.37 Disponibilizando o site da Dexter Courier
Baixe do servidor o arquivo contendo o site da Dexter e depois descompacte-o:
1 root@dmz :~ # tar xzvf site . dextercourier . tar . gz -C / srv / www /

8.0.38 Ativando o SSL
SSL (Secure Socket Layer) é o protocolo que encripta toda a transmissão entre o cli-
ente e um servidor, indicado para criar páginas seguras. Sites de comércio eletrônico
utilizam essa camada de segurança, portanto o SSL é um padrão Web que permite
trafegar dados sensíveis e confidenciais com segurança através da internet.
O protocolo HTTPS é utilizado também em bancos e empresas que utilizam auten-

ticação com criptografia, dependendo da configuração do SSL, bem como a criação
de chaves e certificados.
O que é um certificado digital?
Um certificado digital é um arquivo que contém um conjunto de informações referen-

tes a entidade para o qual o certificado foi emitido, seja uma empresa, pessoa física
ou computador, mais a chave pública referente à chave privada que acredita-se ser
de posse unicamente da entidade especificada no certificado.
As assinaturas contidas em um certificado são atestamentos feitos por uma entidade

que diz confiar nos dados contidos naquele certificado.
Gerando o site seguro da Dexter
Para instalar e configurar as chaves e o certificado, execute:
1 root@dmz :~ # aptitude install openssl

2 root@dmz :~ # a2enmod ssl
3 Enabling module ssl .
4 See / usr / share / doc / apache2 .2 - common / README . Debian . gz on how to
configure SSL and create self - signed certificates .
5 Run ’/ etc / init .d/ apache2 restart ’ to activate new configuration !


Veja que o módulo SSL está habilitado para “ouvir” na porta 443:
1 root@dmz :~ # vim / etc / apache2 / ports . conf

2 < IfModule mod_ssl .c >
3 Listen 443
4 </ IfModule >
Agora crie a chave que será usada para assinar o certificado:
1 root@dmz :~ # openssl genrsa - out / etc / ssl / dexter . key 1024

2 Generating RSA private key , 1024 bit long modulus
3
4 e is 65537 (0 x10001 )
Com a chave em “mãos”, crie o certificado para a Dexter, preenchendo os campos

conforme forem pedidos:
1 root@dmz :~ # openssl req - new - key / etc / ssl / dexter . key - out \
2 / etc / ssl / dexter . csr
3
4 Country Name (2 letter code ) [ AU ]: BR
5 State or Province Name ( full name ) [ Some - State ]: São Paulo
6 Locality Name (eg , city ) []: São Paulo
7 Organization Name (eg , company ) [ Internet Widgits Pty Ltd ]: Dexter
Courier
8 Organizational Unit Name (eg , section ) []: Depto . TI

9 Common Name (eg , YOUR name ) []: Admin

10 Email Address []: root@dexter . com . br
11 Please enter the following ’ extra ’ attributes to be sent with your
certificate request
12 A challenge password []:
13 An optional company name []:
Depois de criar o certificado, você poderá enviá-lo a uma unidade certificadora, por
exemplo a Serasa Experian, VeriSign, CertSign, ACBR, Serpro, entre outras, que
o assinará por um valor anual. Você tem a opção de auto assinar seu o certificado,
lembrando que, neste caso, o cliente dirá que o certificado não foi reconhecido por
uma unidade certificadora!
Para assinar seu certificado, execute o comando abaixo:
1 root@dmz :~ # openssl x509 - req - days 365 -in / etc / ssl / dexter . csr \
2 - signkey / etc / ssl / dexter . key - out / etc / ssl / dexter . crt
3 Signature ok
4 subject =/ C= BR / ST =S\ xC3 \ xA3o Paulo /L=S\ xC3 \ xA3o Paulo /O= Dexter
Courier / OU = Depto . TI / CN = Admin / emailAddress = root@dexter . com . br
5 Getting Private key
Agora basta adicionar a configuração do certificado digital no final do arquivo refe-

rente ao nosso domínio.
1 root@dmz :~ # vim / etc / apache2 / sites - available / dexter . com . br

2
4 DocumentRoot / srv / www / dexter /
5 ServerName www . dexter . com . br
6 ErrorLog / var / log / apache2 / dexter - error . log
7 CustomLog / var / log / apache2 / dexter - access . log common
8 SSLEngine on
9 SSLCertificateFile / etc / ssl / dexter . crt

10 SSLCertificateKeyFile / etc / ssl / dexter . key

11 RewriteEngine On
12 RewriteCond \%{ SERVER_PORT } 80
13 RewriteRule ^(.*) \$ https :// www . dexter . com . br /\ $1 [R ,L]
14 </ VirtualHost >
Explicando:
1 RewriteEngine - Ativa o modo rewrite .

2
3 RewwriteCond - For ça https para voc ê poder usar com seguran ça a
autentica ção HTTP no diret ó rio .
4
5 RewriteRule - Estamos aplicando uma express ão regular onde
qualquer palavra escrita ap ós " http :// www . dexter . com . br /" seja
apagada e que nosso web server redirecione devolta para o "/".
Isso é muito ú til quando não queremos ningu ém vasculhando os
sub - diret ó rios de nosso dom í nio . Al ém de for ç ar o uso do https
.
1 Sobre a linha ( RewriteRUle ^ (.*) $ https :// www . dexter . com . br / $ [R ,L

] )
As letras dentro dos colchetes significam respectivamente: [R] reescrever a URL e

redirecionar, [NC] case insensitive e [L] aplica somente uma vez a cada tentativa,
isso evita que a regra entre em loop infinito.
Ative o “mod_rewrite” para que, toda vez que alguém acessar seu site, seja auto-
maticamente redirecionado para o site com HTTPS ativado:
1 root@dmz :~ # a2enmod rewrite

2 Enabling module rewrite .

3 Run ’/ etc / init .d/ apache2 restart ’ to activate new configuration !
E finalmente reinicie o Apache:

Após a preparação do SSL, abra o site e verifique o https e o certificado digital.
http://www.dexter.com.br

Clique em “Adicionar exceção”.
Clique em “Obter Certificado”, depois deve ticar a opção “Salvar esta exceção per-
manentemente” e por último em “Confirmar exceção de segurança”.



Capítulo 9
Servidor FTP
9.0.39 Cenário
Como a empresa DEXTER COURIER é muito dinâmica, precisa estar atualizada e

em sintonia com seus clientes, por isto o site é o melhor canal de comunicação! A fim
de agilizar tais procedimentos, precisa de uma conexão diretamente no servidor Apa-
che, a fim de que o WebDesigner possar subir os arquivos do site www.dexter.com.br.
Além disto, ele não poderá fazer mais nada no servidor!
A implementação de um servidor FTP irá suprir a necessidade da empresa Dexter,

pois faremos o WebDesigner acessar diretamente o diretório do site, além de blo-
quearmos o acesso aos demais diretórios do sistema com proteção “chroot”.
O FTP (File Transfer Protocol) é um protocolo simples para transferência de arqui-

vos. O cliente "FTP"faz uma solicitação ao servidor "FTP", a seção é estabelecida e
185
então é solicitado um usuário e senha válidos no caso de um "FTP"autenticado, ou,

caso este servidor permita navegação anônima, basta entrar com o usuário "anony-
mous" e uma senha qualquer.
Em relação ao modo de conexão do servidor FTP, ele pode atuar como servidor
ativo ou passivo. No modo ativo, os comandos são enviados por uma porta alta
(acima de 1024) pelo cliente e são recebidas pela porta 21 no servidor, enquanto
que os dados são transmitidos pelo servidor ao cliente através da porta 20.
Qual a desvantagem do motivo ativo?
Neste modo, um firewall mal configurado pode dar uma falsa sensação de funciona-
mento do FTP, pois a conexão e os comandos FTP funcionarão normalmente, porém,
na hora da transferência de arquivos, ocorrerá uma falha de desconexão ou time out,
dependendo do tipo de servidor.
Já no modo passivo, os comandos também são enviados para o servidor através

de uma porta alta pelo cliente e são recebidas na porta 21 do servidor. Neste mo-
mento, o cliente avisa ao servidor que ele deve utilizar o modo passivo através do
comando "PASV", e então os dados serão enviados utilizando portas altas tanto
pelo cliente quando pelo servidor. Neste caso, não temos mais problemas com o
"Firewall"no lado do cliente, porém, temos que habilitar a utilização de portas altas
no servidor, o que pode gerar outros problemas. Felizmente, na configuração do
servidor "FTP"podemos especificar o "range"de portas que o servidor deve utilizar,
minimizando assim o problema no lado do servidor.
Modo Ativo

Modo Passivo
O VSFTPD (Very Secure File Transfer Protocol Daemon) é a escolha de empre-

sas como RedHat, IBM e Novell (SUSE Linux) quando o assunto é servidor FTP
confiável e seguro. Inclusive o projeto "OpenBSD"utiliza o "VSFTPD"como servidor

"FTP"padrão da distribuição. Logo, podemos considerar este software como bem

qualificado em termos de segurança de código. Apesar de alguns Administradores
apontarem o "VSFTPD"como carente em termos de documentação, todos os seus
parâmetros podem ser encontrados em sua "man page", o que facilita o processo de
configuração.
Além do "VSFTPD", existem outros programas de Servidor FTP, para Gnu/Li-

nux, como "proftpd"e o "wu-ftpd", que não serão abordados neste treinamento.
Sobre segurança: um dos principais problemas do "FTP"é que a maioria dos

servidores não implementa criptografia, então, caso você deseje um ambiente se-
guro com "FTP", é necessário a implementação de criptografia, como "OpenSSL"ou
"TLS".
Para logar num servidor FTP, temos duas maneiras:
Tradicional: o servidor aceita conexões por meio de um usuário e senha válidos,

liberando desta forma um prompt de comandos ou mesmo a interface gráfica;
Anonymous: o Servidor FTP com anonymous é muito utilizado na Internet pelo

motivo de não ser necessário ter um usuário no servidor. Desta forma, o usuário pode
abrir um browser e chamar o endereço “ftp://ftp.servidor.com.br” para ter acesso
ao diretório disponibilizado pelo serviço. Geralmente esse diretório é o “home” do
usuário FTP, sendo no Debian em “/home/ftp” .
No nosso servidor FTP vamos desativar o modo Anonymous, pois ele será usado
apenas pelo webdesigner pode fazer upload dos arquivos da empresa DEXTER. O
usuário root não poderá fazer acesso ao servidor FTP. Para esta configuração, iremos
utilizar a máquina “DMZ”.

Recapitulando... A plataforma RedHat utiliza o "vsftpd"por padrão.
9.0.42 Laboratório
Para instalar o vsftpd, primeiro permita a execução de binário na partição /tmp, depois
instale o pacote e efetue o bloqueio novamente:
1 root@dmz :~ # aptitude install vsftpd
Após instalar, vamos abrir o arquivo de configuração “/etc/vsftpd.conf ” e então

alterar alguns parêmtros
1 root@dmz :~ # vim / etc / vsftpd . conf
Localize as configurações que seguem abaixo e altere as que estão em negrito:
1 # ## Permite que o VSFTPD funcione em modo daemon

2 listen = Yes
3 ## Permite a utiliza ção do FTP com o usu á rio anonymous
4 anonymous_enable = No
5 ## Habilitar a vari á vel que permite que os usu á rios do sistema
possam ## usar o servidor FTP :
6 local_enable = Yes
7 ## Vari á vel que permite o upload para os usu á rios :
8 write_enable = Yes
9 ## Permite a exibi ção de mensagens aos usu á rios
10 dirmessage_enable = Yes
11 ## Ativa os logs para downloads e uploads

12 xferlog_enable = Yes
13 ## Utiliza a porta FTP - DATA para transfer ê ncia de arquivos ( vamos
usar ## FTP Passivo )
14 connect_from_port_20 = No
15 ## Definindo timeout para sess ão e conex ão de dados em 2 minutos
(120 ## segundos )
16 idle_session_timeout =120
17 data_connection_timeout =120
18 ## Não permitir que o usu á rio veja arquivos que não sejam seus
19 chroot_local_users = YES
As opções "anonymous_enable"e "xferlog_enable"podem cair na prova LPI.
Lembre-se que adicionamos o usuário “webdesign” na aula de Apache. O diretório

onde ele terá permissão para fazer upload e download de arquivos será:
1 / srv / www / dexter
Confirme as permissões, dono e grupo deste diretório e...
1 root@dmz :~ # ls -ld / srv / www / dexter

2 drwxr -xr -x 5 webdesign webdesign 4 ,0 K Ago 5 20:13 / srv / www / dexter
. . . caso não estejam configuradas, realize as alterações abaixo:
1 root@dmz :~ # chown -R webdesign : webdesign / srv / www / dexter /

2 root@dmz :~ # chmod -R 775 / srv / www / dexter /
3 root@dmz :~ # ls -ld / srv / www / dexter /
4 drwxrwxr -x 5 webdesign webdesign 4 ,0 K Ago 5 20:13 / srv / www / dexter
5 root@dmz :~ # usermod -d / srv / www / dexter webdesign

6 root@dmz :~ # grep web / etc / passwd

7 webdesign :x :1002:1003: , , ,:/ srv / www / dexter :/ bin / bash
Com isso mudamos a permissão de acesso ao diretório e o diretório padrão do usuá-

rio “webdesign”. Também devemos verificar se o usuário root está bloqueado para
acessar o FTP:
1 root@dmz :~ # grep root / etc / ftpusers

2 root
Caso você queira bloquear mais algum usuário para que ele não acesse o servidor
FTP, coloque o nome dele no arquivo! Crie o arquivo “/srv/www/dexter/.message” e
coloque a mensagem abaixo:
1
2 root@dmz :~ # vim / srv / www / dexter /. message
3 ============================================================
4 ## Este sistema é para uso exclusivo da empresa DEXTER .
5 ## Todas as atividades ser ão registradas .
6 ## É vetada a utiliza ção deste sistema para transfer ê ncia de
7 ## arquivos protegidos por qualquer lei de direito autoral
8 ## ou arquivos que infrinjam a legisla ção vigente .
9 ============================================================
Após escrever a mensagem, salve o arquivo e reinicie o serviço FTP:
1 root@dmz :~ # service vsftpd restart

2 Stopping FTP server : vsftpd .
3 Starting FTP server : vsftpd .
Verifique em qual porta o servidor "FTP"está escutando:

1 root@dmz :~ # netstat - ltupan

2 tcp 0 0 0.0.0.0:21 0.0.0.0:* OU ÇA 992/
vsftpd
Agora vamos fazer alguns testes de acesso ao FTP, mas antes instale os clientes
FTP, tanto para o modo texto como para o gráfico. Execute na máquina “Sque-
eze”:
1 root@squeeze :~ # aptitude install ftp
Concluída a instalação, acesso o FTP pelo modo texto:
1 root@squeeze :~ # ftp ftp . dexter . com . br

2 Connected to www . dexter . com . br .
3 220 ( vsFTPd 2.3.2)
4 Name ( ftp . dexter . com . br : root ): webdesign
5 331 Please specify the password .
6 Password :
7 230 -============================================================
8 230 - ## Este sistema é para uso exclusivo da empresa DEXTER .
9 230 - ## Todas as atividades ser ão registradas .
10 230 - ## É vetada a utiliza ção deste sistema para transfer ê ncia de
11 230 - ## arquivos protegidos por qualquer lei de direito autoral
12 230 - ## ou arquivos que infrinjam a legisla ção vigente .
13 230 -============================================================
14 230 Login successful .
15 Remote system type is UNIX .
16 Using binary mode to transfer files .
17 ftp >

9.0.43 Comandos em modo texto do FTP
Os servidores de "FTP"muito raramente mudam, mas novos programas clientes "FTP"aparecem

com bastante regularidade. Estes clientes variam no número de comandos que im-
plementam. A maioria dos clientes "FTP"comerciais implementam apenas um pe-
queno subgrupo desses comandos. Mesmo que o "FTP"seja um protocolo orientado
à linha de comandos, a nova geração dos clientes "FTP"esconde esta orientação
num ambiente gráfico muitas vezes bastante desenvolvido.
As interfaces clientes do "FTP"do "BSD UNIX"e do GNU/Linux possuem muitos co-

mandos, alguns deles arcaicos e sem utilidade hoje em dia, como por exemplo o
"tenex"e o "carriage control".
Os comandos listados abaixo podem ser cobrados na prova de certificação.
Abaixo estão listados alguns dos mais utilizados comandos "FTP":
1 ## Para saber em qual diret ó rio se encontra :

2 ftp > pwd
3 ## Para saber em qual diret ó rio se encontra ( lado cliente ):
4 ftp > ! pwd
5 ## Para trocar de diret ó rios dentro do servidor :
6 ftp > cd < diret ó rio >
7 ## Para voltar um diret ó rio :
8 ftp > cd ..
9 ## Para listar o conte ú do do diret ó rio atual :
10 ftp > ls
11 ## Para listar os diret ó rios locais ( lado cliente ):
12 ftp > ! ls
13 ## Para mudar de diret ó rio na má quina cliente :
14 ftp > lcd < diret ó rio >
15 ## Para realizar o download de um arquivo :
16 ftp > get < arquivo >

17 ## Para realizar mú ltiplos downloads :

18 ftp > mget *
19 ## Para realizar o upload de um arquivo :
20 ftp > put < arquivo >
21 ## Para realizar mú ltiplos uploads :
22 ftp > mput *
23 ## Para uma lista completa de comandos :
24 ftp > help
Para verificar os logs do ftp, execute:
1 root@dmz :~ # cat / var / log / vsftpd . log

2 Tue Aug 9 22:35:50 2011 [ pid 2] CONNECT : Client " 192.168. X .10 "
3 Tue Aug 9 22:35:56 2011 [ pid 1] [ webdesign ] OK LOGIN : Client "
192.168. X .10 "
4 Tue Aug 9 22:36:12 2011 [ pid 3] [ webdesign ] OK DOWNLOAD : Client "
192.168. X .10 " , "/ index . php " , 4621 bytes , 282.04 Kbyte / sec
9.0.44 Cliente gráfico para FTP
Podemos acessar um FTP a partir da interface gráfica. Um dos principais clientes

FTP é o Filezilla (http://filezilla-project.org), que possui versão para GNU/Linux, Win-
dows e Mac OS. Para instalar no GNU/Linux basta digitarmos na máquina “Sque-
eze”:
1 root@dmz :~ # aptitude install filezilla
Para abrir o aplicativo, vá em Aplicativos -> Internet -> Filezilla. Na tela que abrir,
entre com os seguintes dados:

1 Host : ftp . dexter . com . br

2 Usu á rio : webdesign
3 Senha : 123456
4 Porta : 21
Será estabelecida a conexão e nosso Webdesign poderá atualizar o site!

Capítulo 10
Servidor Postfix
10.0.45 Cenário
Hoje em dia é muito raro uma empresa não possuir uma conta de e-mail! A comu-
nicação proporcionada por esta ferramenta é muito abrangente, por isso a empresa
DEXTER COURIER precisa que cada colaborador tenha seu e-mail. Como ela não
tem interesse em pagar um plano de hospedagem e deixar seu servidor de e-mail
nas mãos sabe-se lá de quem, quer que ele ele seja instalado e configurado dentro
de seu DataCenter. Além disto, precisa de segurança na autenticação dos usuários
e uso de protocolo seguro em relação aos e-mails que sua equipe irá utilizar.
Para suprir a necessidade da empresa Dexter, iremos montar na máquina “DMZ” o

MTA (servidor de e-mail) Postfix, além de configurar as contas de e-mail nos clientes
e disponibilizar um Webmail para acesso externo. Também teremos algumas contas
“alias” para não sobrecarregar o usuário com muitas contas. Além disto faremos com
que todos os usuários tenham autenticação no servidor por meio de TLS.
197
O que é um MTA?
Mail Transport Agent (MTA) é o servidor de e-mails propriamente dito. É a parte

mais importante de um sistema de correio. Ele é o responsável pelo recebimento das
mensagens e assegurar que essas mensagens cheguem ao seus destinos. Temos
como exemplos de MTA: o Exim (padrão do Debian) , Sendmail (padrão do Red Hat)
, Qmail , Postfix e o Microsoft Exchange (proprietário) .
O que é um MUA?
Mail User Agent (MUA) é o nome designado para o programa cliente de e-mail.
Podemos citar como exemplos o Thunderbird , Evolution e o Microsoft Outlook
O que é um MDA?
Mail Delivery Agente (MDA) é um intermediário entre o MTA e o MUA. Ele é usado
para aplicar filtros antispam, remover vírus em anexos e fazer encaminhamento de
e-mails para outros endereços. Exemplos de MDA: Procmail, Fetchmail, Binmail,
Dovecot, Maildrop, Postdrop etc.
O que é o SMTP?
SMTP (Simple Mail Transfer Protocol) é um protocolo baseado em linhas de co-

mando executado sobre o protocolo TCP, cujo objetivo é transmitir mensagens de
e-mail dentre dois computadores. A porta utilizada pelo protocolo SMTP é a 25.
10.0.48 Introdução ao Postfix
“Na década de 70, as primeiras mensagens eram enviadas pela "ARPAnet", ante-
cessora da atual Internet. A troca de mensagens era feita em sua maioria por es-
tudantes, pesquisadores e profissionais dos grandes centros de pesquisa, restrita

a poucos usuários que tinham acesso a essa rede. As mensagens eram enviadas
através de um protocolo semelhante ao atual "SMTP", que foi definido apenas em
1982.
O "Sendmail"era o servidor de correios mais utilizado na década de 90, causando

amor e ódio aos administradores de sistema. Causava amor àqueles que tinham
tempo de ler, estudar e compreender o seu funcionamento complexo e cheio de
macros. Ódio para aqueles que precisavam apenas rotear suas mensagens e não
havia necessidade de perder horas e mais horas tentando compreender seu funci-
onamento. A sua forma monolítica também era um grande ponto negativo. Sendo
apenas um único processo controlando todas as etapas de transmissão de e-mail,
o "Sendmail"apresentava inúmeras falhas de segurança, de maior risco quando exe-
cutado em modo root. Muitos servidores eram invadidos por crackers e naturalmente
os administradores de sistema procuravam alternativas.
Na época não existia muitas alternativas, portanto os administradores continuavam a

utilizar o "Sendmail". Em 1998 as primeiras versões do "Postfix"começaram a surgir.
Wietse Venema é seu criador e possui inúmeros trabalhos relacionados à segurança
da informação. Wietse é pesquisador da IBM e Ph.D em física até hoje. Escrito em
linguagem C, a primeira versão oficial do "Postfix", como Software Livre, foi lançada
em Dezembro de 1998.
10.0.49 Características do Postfix
• Sistema multitarefa - O "Postfix"possui um conjunto de módulos que desem-

penham um papel específico para cada etapa do tráfego de e-mails, este com-
portamento permite melhor desempenho em equipamentos multiprocessados.
• Separação de privilégios - O "Postfix"pode ser executado em "chroot"que res-

tringe o acesso a arquivos internos à uma "jaula", tornando sua execução muito
mais segura..
• Modular - É possível criar módulos para trabalhar em conjunto com o "Postfix",

tornando-o facilmente extensível.
• Compatibilidade - O "Postfix"foi desenvolvido para suportar os formatos de

armazenamentos de mensagens existentes.
Os arquivos de configuração do "Postfix", podem ser encontrados no diretório "/etc/-

postfix", onde os seus principais arquivos são:
main.cf - Arquivo principal do "Postfix"onde ficam todas as configurações principais

relacionadas ao funcionamento do "Postfix".
master.cf - É o arquivo que controla a ação de cada "daemon"do "Postfix". Nele

podemos dizer quantos processos "smtpd"estarão em execução, por exemplo. Caso
tenhamos uma estrutura grande de máquina, uma ajuste nesses "daemons"serão
bem compensadores em termos de performance.
http://www.prefirolinux.com/forum/viewtopic.php?f=2&t=12
10.0.50 Laboratório
Na máquina “DMZ”, execute:
1 root@dmz :~ # aptitude install postfix procmail

2 Os pacotes a seguir possuem depend ê ncias não satisfeitas :
3 exim4 - config : Conflita : postfix mas 2.7.1 -1+ squeeze1 ser á
instalado .
4 postfix : Conflita : mail - transport - agent o qual é um pacote virtual
.
5 exim4 - daemon - light : Conflita : mail - transport - agent o qual é um
pacote virtual .
6 As seguintes açõ es resolver ão estas depend ê ncias :

7 Remover os pacotes a seguir :

8 1) exim4
9 2) exim4 - base
10 3) exim4 - config
11 4) exim4 - daemon - light
12 Aceitar esta solu ção? [Y/n/q /?] Y\ textbf {}
13
14 Os NOVOS pacotes a seguir ser ão instalados :
15 postfix python {a} python - minimal {a} python2 .6{ a} python2 .6 - minimal
{a} procmail
16 Os pacotes a seguir ser ão REMOVIDOS :
17 exim4 {a} exim4 - base {a} exim4 - config {a} exim4 - daemon - light {a}
18 0 pacotes atualizados , 5 novos instalados , 4 a serem removidos e 32
não atualizados .
19 É preciso obter 5341 kB de arquivos . Depois do desempacotamento ,
14 ,3 MB ser ão usados .
20 Voc ê deseja continuar ? [Y/n /?] Y
Aceite remover os pacotes do exim4 para continuar com a instalação. Irá surgir a tela
abaixo, então selecione “Site Internet”.

Depois, na tela abaixo, digite o domínio da Dexter – dexter.com.br
No Debian, quando instalarmos o "Postfix", ele automaticamente remove o

servidor padrão que é o "Exim4".
Sobre o formato da caixa de correio, temos:
MailBox ou Mbox - é o formato padrão para caixa de correio do Postfix. Este formato
armazena todas as mensagens em um único arquivo de texto. Esses arquivos são

nomeados de acordo com o nome do usuário e armazenados em geral em /var/mail

ou /var/spool/mail.
Desvantagens:
• Encarece a exclusão de mensagens (requer regravação no arquivo inteiro, ex-

ceto se a mensagem a ser excluída for a última);
1 O arquivo que guarda a mensagem pode se corromper caso softwares em

diferentes má quinas o usem ao mesmo tempo ( concorrentemente );
MailDir - usa diretórios e um arquivo por mensagem. A exclusão de mensagens

sempre é muito rápida.
Desvantagem:
• O tempo para varrer a caixa de correio e produzir uma lista de mensagens é

maior, pois todos os arquivos devem ser abertos e lidos.
Vamos passar agora para o arquivo de configuração. Edite-o e deixe assim:
1 root@dmz :~ # vim / etc / postfix / main . cf

2 ## Banner que ser á mostrado nas conex õ es . É importante mudar .
3 smtpd_banner = MTA da Dexter - Servidor $myhostname
4 ## Modificar o dom í nio caso o MUA não fizer corretamente , mas
5 ## deixamos ativado , pois isso é trabalho do pr ó prio MUA .
6 append_dot_mydomain = yes
7 ## Nessa op ção , precisamos colocar o hostname da má quina e o
8 ## dom í nio que é conhecido como FQDN .
9 myhostname = dmz
10 ## Arquivos onde são configurados os alias de e - mails .
11 alias_maps = hash :/ etc / aliases
12 alias_database = hash :/ etc / aliases

13 ## Define a origem local , que por padr ão é o mesmo FQDN que est á em
14 ## / etc / mailname .
15 myorigin = dexter . com . br
16 ## Dom í nios que o seu servidor pode receber mensagens .
17 mydestination = dexter . com .br , smtp . dexter . com .br , mail . dexter . com .
br , webmail . dexter . com .br , pop . dexter . com .br , imap . dexter . com .br ,
localhost
18 ## Essa op ção só é usada se o seu servidor faz Relay para outros
19 ## servidores de e - mail .
20 relayhost =
21 ## Nesse campo deveremos colocar apenas os IP ’s que podem realmente
22 ## fazer relay em seu servidor . CUIDADO , se adicionarmos IP ’s ou
23 ## classes demais , o servidor poder á virar alvo de spammers .
24 mynetworks = 127.0.0.0/8 192.168. X .0/24
25 ## Padr ão de entrega das mensagens . Nesse caso é usado o mbox .
26 mailbox_command = procmail -a " $EXTENSION "
27 ## Tamanho má ximo de caixa - postal para entrega local
28 mailbox_size_limit = 0
29 ## Interfaces de rede na qual o Postfix pode fazer bind , ou seja ,
30 ## estabelecer conex õ es . O padr ão do Debian seria todas as
interfaces .
31 inet_interfaces = all
32 ## Tamanho má ximo da mensagem
33 message_size_limit = 25000000
34 ## Em alguns clientes , podemos adicionar um sinal espacial ao endere
ço
35 ## de e - mail para direcionar mensagens a uma determinada pasta
36 recipient_delimiter = +
Agora vamos reiniciar o Postfix:
1 root@dmz :~ # service postfix restart

2 Stopping Postfix Mail Transport Agent : postfix .
3 Starting Postfix Mail Transport Agent : postfix .

Veja se a porta 25 (smtp) está pronta para receber conexões:
1 root@dmz :~ # netstat - nltup | grep master

2 tcp 0 0 0.0.0.0:25 0.0.0.0:* OU ÇA 2085/
master
Agora que temos o servidor ativado, devemos criar os usuários que usarão os servi-
ços de correio eletrônico. Para isso, utilize um script com base na lista utilizada na
criação dos usuários do Samba:
1 root@dmz :~ # vim postfix - users . sh

2 # !/ bin / bash
3 aptitude install whois -y
5 useradd -g users -m -p $( mkpasswd 123456) -s / bin / false $lista
6 done
Após a inclusão dos usuários, vamos realizar alguns testes usando o telnet:
1 root@dmz :~ # aptitude install telnet -y

2 root@dmz :~ # telnet mail . dexter . com . br 25
3 Trying 192.168. X .3...
4 Connected to mail . dexter . com . br .
5 Escape character is ’^] ’.
6 220 MTA da Dexter - Servidor dmz . dexter . com . br
7 helo mail
8 250 dmz . dexter . com . br
9 mail from : tux@linus . com
10 250 2.1.0 Ok
11 rcpt to : dexterclem@dexter . com . br
12 250 2.1.5 Ok
13 data
14 354 End data with <CR ><LF >. < CR ><LF >

15 subject : Teste de e - mail

16 Nosso MTA é dezzzzzzzz ...
17 .
18 250 2.0.0 Ok : queued as 4 E20069
19 quit
20 221 2.0.0 Bye
21 Connection closed by foreign host .
Agora verifique o e-mail enviado para o usuário Dexter Clem:
1 root@dmz :~ # cat / var / spool / mail / dexterclem

2 From neo@matrix . com Thu Aug 11 20:15:02 2011
3 Return - Path : < tux@linus . com >
4 X - Original - To : dexterclem@dexter . com . br
5 Delivered - To : dexterclem@dexter . com . br
6 Received : from mail ( dmz . dexter . com . br [192.168. X .3])
7 by dmz ( Postfix ) with SMTP id 5 CC607CF
8 for < dexterclem@dexter . com .br >; Thu , 11 Aug 2011 20:14:02 -0300 (
BRT )
9 subject : teste de e - mail
10 Message - Id : <20110811231420.5 CC607CF@dmz >
11 Date : Thu , 11 Aug 2011 20:14:02 -0300 ( BRT )
12 From : neo@matrix . com
13 To : undisclosed - recipients :;
14 Nosso MTA é dezzzzz .....
Para verificar a lista de e-mails no servidor em produção, execute:
1 root@dmz :~ # mailq

MDA Courier - POP3 e IMAP para os clientes
Um servidor de e-mail só estará completo se tivermos a instalação de um daemon

"POP3"e "IMAP". Para isso, vamos instalar e utilizar o MDA (Mail Delivery Agent)
"Courier".
O que é o POP?
Para coletar suas mensagens, o usuário pode utilizar o protocolo POP (Post Office
Protocol). O POP é mais antigo. Através do POP o usuário baixa as mensagens
para seu computador local e as exclui do servidor. A desvantagem é que, se o usuário
desejar acessar suas mensagens de outros locais, não poderá fazer. O POP não é
utilizado para armazenamento permanente de mensagens. A porta 110 é padrão por
este protocolo. Quando implementada uma camada de segurança ao POP, deverá
trabalhar na porta 995.
O que é o IMAP?
O IMAP (Internet Message Access Protocol) foi projetado para permitir que o usuá-
rio armazene as mensagens permanentemente no servidor. Com o IMAP o usuário
pode acessar todas as mensagens a partir de qualquer lugar no mundo. O IMAP
também tem uma implementação mais disseminada das conexões TLS seguras. A
porta 143 é utilizada por este protocolo. IMAP sobre TLS é a porta 993. Vamos então
instalar nosso MDA:
1 root@dmz :~ # aptitude install courier - authdaemon courier - authlib

courier - base courier - imap courier - pop nail -y
Após este passo, edite o arquivo do Postfix:

2 # ## comentar :
3 # mailbox_command = procmail -a " $EXTENSION "

4 # ## adicionar :
5 home_mailbox = Maildir /
6 DEFAULT = $HOME / Maildir /
7 MAILDIR = $HOME / Maildir /
Reinicie o serviço do Postfix:
Precisamos também criar mais um arquivo do PAM referente ao "smtp":
1 root@dmz :~ # cp / etc / pam .d/ pop3 / etc / pam .d/ smtp
Criando caixas postais
Vamos agora criar as caixas postais. Para isto vamos criar uma script:
1 root@dmz :~ # vim maildir . sh

2 # !/ bin / bash
4 maildirmake / home / $lista / Maildir
5 maildirmake / home / $lista / Maildir /. Enviadas
6 maildirmake / home / $lista / Maildir /. Rascunhos
7 maildirmake / home / $lista / Maildir /. lixeira
8 maildirmake / home / $lista / Maildir /. Spam
9 chown -R $lista : users / home / $lista
10 done

O comando "maildirmake"faz parte do pacote "Courier", veja este site:

http://www.courier-mta.org/maildirmake.html
Reinicie os serviços :
1 root@dmz :~ # service courier - authdaemon restart

2 root@dmz :~ # service courier - imap restart
3 root@dmz :~ # service courier - pop restart
Verifique as conexões ativas no servidor:
1 root@dmz :~ # netstat - putan | grep 110

2 tcp6 0 0 :::110 :::* OU ÇA 3742/ couriertcpd
4 tcp6 0 0 :::143 :::* OU ÇA 3665/ couriertcpd
Agora teste a nova caixa postal:
1 root@dmz :~ # echo " Reuniao amanha as 15 hs ." | mail -s " Reuniao com
Cliente 4 Linux " dexterclem@dexter . com . br
2 root@dmz :~ # cat \
3 / home / dexterclem / Maildir / new /1313109656. Vfd00I607a1M156000 . dmz
4 Return - Path : < root@dexter . com .br >
5 X - Original - To : dexterclem@dexter . com . br
6 Delivered - To : dexterclem@dexter . com . br
7 Received : by dmz ( Postfix , from userid 0)
8 id 222 E07E1 ; Thu , 11 Aug 2011 21:40:56 -0300 ( BRT )
9 Date : Thu , 11 Aug 2011 21:40:56 -0300
10 From : root@dexter . com . br

11 To : dexterclem@dexter . com . br
12 Subject : Reuniao com Cliente 4 Linux
13 Message - ID : <4 e447698 . M8zZc0OB8yim8VHd % mandarkglory@dexter . com .br >
14 User - Agent : Heirloom mailx 12.4 7/29/08
15 MIME - Version : 1.0
16 Content - Type : text / plain ; charset =us - ascii
17 Content - Transfer - Encoding : 7 bit
18 Reuniao amanha as 15 hs .
Não esqueça de publicar o registro "MX"no seu DNS, configurar corretamente

o campo "TXT"e também o DNS REVERSO.
Criando alias no Postfix
Podemos criar "aliases"(apelidos) para que um usuário possa receber vários e-mails
diferentes na mesma conta. Edite o arquivo de alias e crie um para o seu usuário,
no formato "usuario_de_alias: usuario_real":
1 root@dmz :~ # vim / etc / aliases

2 ouvidoria : mandarkglory
Para validar essas modificações e gerar o arquivo de "hash", precisamos usar ou o

comando "postalias" ou "newaliases":
1 root@dmz :~ # postalias / etc / aliases

2 ou
3 root@dmz :~ # newaliases
Verifique se o arquivo "aliases.db"foi atualizado:

1 root@dmz :~ # stat / etc / aliases . db

2 ...
3 Access : 2011 -08 -11 22:05:41.028000893 -0300
4 Modify : 2011 -08 -11 22:05:41.028000893 -0300
5 Change : 2011 -08 -11 22:05:41.028000893 -0300
Agora podemos fazer um teste enviando um e-mail para o usuário de "alias":
1 root@dmz :~ # echo " Teste de Alias " | mail -s " Teste de alias " \
2 ouvidoria@dexter . com . br
3 root@dmz :~ # cat \
4 / home / mandarkglory / Maildir / new /1313111359. Vfd00I607aM81600 . dmz
5 Date : Thu , 11 Aug 2011 22:09:19 -0300
6 From : root@dexter . com . br
7 To : ouvidoria@dexter . com . br
8 Subject : Teste de alias
9 Message - ID : <4 e447d3f .+ kR8VGISl9eSI9ON % root@dexter . com .br >
10 User - Agent : Heirloom mailx 12.4 7/29/08
11 MIME - Version : 1.0
12 Content - Type : text / plain ; charset = utf -8
13 Content - Transfer - Encoding : 8 bit
14 Teste de Alias
Repare que a visualização foi feita no arquivo do usuário Mandark Glory!
Configurando o Webmail
O Squirrelmail é um Webmail desenvolvido em PHP com o objetivo de acessar as

mensagens de um servidor IMAP. Para podermos instalar e configurar este webmail
precisaremos ter o Servidor Postfix com suporte a IMAP e o Servidor Apache com
suporte a PHP. Em nosso caso já temos ambos configurados! Então...

1 root@dmz :~ # aptitude install squirrelmail
Com a instalação concluída, vamos adicionar ao arquivo “/etc/apache2/httpd.conf

” o seguinte:
1 root@dmz :~ # vim / etc / apache2 / httpd . conf

2 Alias / webmail "/ usr / share / squirrelmail /"
3 DirectoryIndex index . php
Agora vamos configurar o SquirrelMail. Execute:
1 root@dmz :~ # squirrelmail - configure
Selecione a opção 1:

Selecione novamente a opção 1:

Entre com o nome da Organização – Dexter:
Selecione a opção “R” para retornar ao menu principal:

Selecione a opção 2 para configurar o servidor:
Selecione a opção 1:

Entre com o domínio da Dexter – dexter.com.br:
Selecione “R” para voltar ao menu principal e depois selecione “S”:

Selecione “Q” para sair da configuração:
Agora vamos criar o Virtualhost do Webmail da Dexter:
1 root@dmz :~ # vim / etc / apache2 / sites - available / webmail . dexter . com . br

3 DocumentRoot / usr / share / squirrelmail
4 ServerName webmail . dexter . com . br
5 ErrorLog / var / log / apache2 / webmail - error . log
6 CustomLog / var / log / apache2 / webmail - access . log common
7 </ VirtualHost >
9 DocumentRoot / usr / share / squirrelmail
10 ServerName webmail . dexter . com . br
11 ErrorLog / var / log / apache2 / webmail - error . log
12 CustomLog / var / log / apache2 / webmail - access . log common
13 SSLEngine on
14 SSLCertificateFile / etc / ssl / dexter . crt
15 SSLCertificateKeyFile / etc / ssl / dexter . key
16 </ VirtualHost >

Ative o novo site e reinicie o Apache:
1 root@dmz :~ # a2ensite webmail . dexter . com . br

Acesse nosso webmail: https://www.dexter.com.br/webmail
Acessando com o usuário dexterclem, veja a mensagem:

Autenticando os usuários de e-mail
Porque ativar a autenticação?
Habilitar a autenticação no servidor de e-mail permite que os usuários enviem men-

sagens utilizando seu MTA sem ter que passar o endereço da rede na diretiva my-
networks no arquivo "/etc/postfix/main.cf". Se você começar a inserir vários en-
dereços nesta diretiva, logo seu servidor MTA vai virar alvo de SPAMMERS. Vamos
utilizar o SASL (Simple Authentication and Security Layer ou Camada de Sim-
ples Autenticação e Segurança).
1 root@dmz :~ # aptitude install libsasl2 -2 sasl2 - bin libsasl2 - modules \

2 libdb4 .6 procmail
Vamos renomear o arquivo configuração e criar um diretório de spool:

1 root@dmz :~ # mv / etc / default / saslauthd \

2 / etc / default / saslauthd . backup
3 root@dmz :~ # mkdir -p / var / spool / postfix / var / run / saslauthd
Agora abra um arquivo novo e inclua o seguinte:
1 root@dmz :~ # vim / etc / default / saslauthd

2 START = yes
3 MECHANISMS =" pam "
4 MECH_OPTIONS =""
5 THREADS =5
6 OPTIONS =" -c -m / var / spool / postfix / var / run / saslauthd -r "
Crie também o arquivo abaixo e inclua o seguinte:
1 root@dmz :~ # vim / etc / postfix / sasl / smtpd . conf

2 pwcheck_method : saslauthd
3 mech_list : plain login
Reinicie o serviço do saslauthd:
1 root@dmz :~ # service saslauthd restart

2 Short name ( NAME ) undefined in / etc / default / saslauthd , using default
... ( warning ).
3 Stopping : default .
4 Starting : default .
Inclua o usuário “postfix” no grupo sasl:
1 root@dmz :~ # adduser postfix sasl

Acrescente no final do arquivo principal do Postfix:

2 smtpd_sasl_local_domain =
3 smtpd_sasl_auth_enable = yes
4 smtpd_sasl_security_options = noanonymous
5 smtpd_recipient_restrictions = permit_sasl_authenticated ,
permit_mynetworks , reject_unauth_destination
6 smtpd_tls_auth_only = no
Reinicie novamente o Postfix:

2 Short name ( NAME ) undefined in / etc / default / saslauthd , using default
... ( warning ).
3 Stopping : default .
4 Starting : default .
Ativando maior segurança com TLS
TLS significa Transport Layer Security e é uma camada de segurança para o sis-
tema de autenticação que já foi configurado. O sistema de autenticação não traz
segurança, pois o mesmo ocorre em texto puro, sem encriptação. Com isso, as se-
nhas podem ser capturadas com um sniffer. Portanto, mãos à obra! Começaremos
criando o diretório onde ficará chave de criptografia; depois gere a chave neste dire-
tório:
1 root@dmz :~ # mkdir -p / etc / postfix / ssl

2 root@dmz :~ # cd / etc / postfix / ssl /
3 root@dmz :/ etc / postfix / ssl /# openssl genrsa - des3 - rand \ / etc / hosts
- out smtpd . key 1024

4 271 semi - random bytes loaded

5 Generating RSA private key , 1024 bit long modulus
6
7
8 e is 65537 (0 x10001 )
9 Enter pass phrase for smtpd . key : 123456 <<<--- Adicione uma senha
10 Verifying - Enter pass phrase for smtpd . key : 123456 <<<--- Confirme
Altere a permissão do arquivo de chave para que somente o root tenha acesso:
1 root@dmz :/ etc / postfix / ssl /# chmod -v 600 smtpd . key

2 modo de " smtpd . key " alterado para 0600 (rw - - - - - - -)
Agora vamos criar o certificado de autenticidade para os acessos :
1 root@dmz :~/ etc / postfix / ssl # openssl req - new - key smtpd . key - out \
2 smtpd . csr
3 Enter pass phrase for smtpd . key : 123456
4 ...
11 Email Address []: root@dexter . com . br
12 Please enter the following ’ extra ’ attributes
13 to be sent with your certificate request
14 A challenge password []:123456
15 An optional company name []: Dexter
Agora vamos assinar nosso certificado digital:

1 root@dmz :~/ etc / postfix / ssl # openssl x509 - req - days 365 -in \
2 smtpd . csr - signkey smtpd . key - out smtpd . crt
3 Signature ok
4 subject =/ C= BR / ST =S\ xC3 \ xA3o Paulo /L=S\ xC3 \ xA3o Paulo /O= Dexter / OU =
Dpto . TI / CN = Admin / emailAddress = root@dexter . com . br
5 Getting Private key
E finalmente, a chave sem criptografia:
1 root@dmz :~/ etc / postfix / ssl # openssl rsa -in smtpd . key - out \
2 smtpd . key . unencrypted
4 writing RSA key
Sobrescreva a chave criada anteriormente para a chave de mesmo nome:
1 root@dmz :~/ etc / postfix / ssl # mv smtpd . key smtpd . key - original
2 root@dmz :~/ etc / postfix / ssl # mv smtpd . key . unencrypted smtpd . key
Agora vamos gerar o certificado “.pem”:
1 root@dmz :~/ etc / postfix / ssl # openssl req - new - x509 - extensions \
2 v3_ca - keyout cakey . pem - out cacert . pem - days 365
3 ...
4 Enter PEM pass phrase : 123456
5 Verifying - Enter PEM pass phrase : 123456
6 ...


13 Email Address : root@dexter . com . br
Acrescente no final do arquivo principal do Postfix:

2 smtp_use_tls = yes
3 smtp_tls_note_starttls_offer = yes
4 smtpd_tls_CAfile = / etc / postfix / ssl / cacert . pem
5 smtpd_tls_loglevel = 1
6 smtpd_tls_received_header = yes
7 smtpd_tls_session_cache_timeout = 3600 s
8 smtpd_tls_cert_file = / etc / postfix / ssl / smtpd . crt
9 smtpd_tls_key_file = / etc / postfix / ssl / smtpd . key
10 smtpd_tls_session_cache_database = btree :${ queue_directory }/
smtpd_scache
11 smtp_tls_session_cache_database = btree :${ queue_directory }/
smtp_scache
12 tls_random_source = dev :/ dev / urandom
Agora vamos instalar os pacotes de configuração do MDA Courier:
1 root@dmz :~ # aptitude install courier - imap - ssl courier - pop - ssl \

2 courier - ssl
Durante a instalação irá surgir uma tela como a da próxima figura, avisando sobre o
certificado digital ser assinado por uma empresa confiável!

Reinicie o Postfix:
Verifique as portas seguras ativadas:

2 tcp6 0 0 :::993 :::* OU ÇA 2200/
couriertcpd
3 root@dmz :~ #
5 tcp6 0 0 :::995 :::* OU ÇA 2153/
couriertcpd
Agora é só testar utilizando um MUA, como por exemplo, o Thunderbird, Icedove

ou Outlook. Iremos testar no Thunderbird 5.0! Efetue o download do aplicativo na

máquina “Squeeze” e execute:
1 root@squeeze :~ # tar xjvf thunderbird -5.0. tar . bz2 -C / opt

2 root@squeeze :~ # chmod +x / opt / thunderbird / thunderbird
Crie um atalho na barra do Gnome e abra o aplicativo. Entre com os dados do

usuário, como nome, e-mail e senha, depois clique em continuar:
Na tela abaixo, clique em “Config manual”:

Entre com os dados do POP e SMTP, conforme abaixo:
Será solicitada confirmação dos riscos , depois clique me “Criar conta”:

Confirme a verificação do certificado e depois em confirmar exceção:

Você já poderá receber e enviar e-mails com segurança!
Para configurarmos o recebimento de e-mail via IMAP, vá no menu Edit -> Configurar
contas -> Nova conta. Agora faça como abaixo:
Aceite o certificado digital:

Basta seguir os procedimentos de rotina de uso do MUA!!

Capítulo 11
Servidor OpenLDAP
11.0.51 Cenário
A empresa DEXTER COURIER precisa de agilidade em suas conexões, mas princi-

palmente na forma como seus usuários efetuam o login nos sistemas. Para acabar
de vez este problema, deseja que haja uma centralização na autenticação dos usuá-
rios em vista de seus recursos tecnológicos.
Para atender a empresa Dexter, teremos que implantar um servidor de autenticação

centralizada baseado no protocolo LDAP, onde poderemos disponibilizar acesso aos
sistemas da empresa de forma ágil e eficiente.
O que é o LDAP? LDAP (Lightweight Directory Access Protocol ou Protocolo

Leve de Acesso a Diretórios), “é um padrão aberto capaz de facilitar, de forma fle-
xível, o compartilhamento, a manutenção e o gerenciamento de grandes volumes de
231
informações, definindo um método padrão de acesso e atualização de informações

dentro de um diretório.” (TUTTLE 2009)
“Este é um protocolo de rede que roda sobre o TCP/IP que permite organizar os
recursos de rede de forma hierárquica, como uma árvore de diretório, onde temos
primeiramente o diretório raiz, em seguida a rede da empresa, o departamento e
por fim o computador do funcionário e os recursos de rede (arquivos, impressoras,
etc.) compartilhados por ele. A árvore de diretório pode ser criada de acordo com a
necessidade.
Uma das principais vantagens do LDAP é a facilidade em localizar informações e

arquivos disponibilizados. Pesquisando pelo sobrenome de um funcionário é possí-
vel localizar dados sobre ele, como telefone, departamento onde trabalha, projetos
em que está envolvido e outras informações incluídas no sistema, além de arquivos
criados por ele ou que lhe façam referência. Cada funcionário pode ter uma conta de
acesso no servidor LDAP, para que possa cadastrar informações sobre si e compar-
tilhar arquivos.
O LDAP oferece uma grande escalabilidade. É possível replicar servidores (para

backup ou balanceamento de carga) e incluir novos servidores de uma forma hierár-
quica, interligando departamentos e filiais de uma grande multinacional por exemplo.
A organização dos servidores neste caso é similar ao DNS: é especificado um servi-
dor raiz e a partir daí é possível ter vários níveis de subservidores, além de mirrors
do servidor principal.
O LDAP pode ser usado em qualquer tipo de rede TCP/IP e é um padrão aberto,
permitindo que existam produtos para várias plataformas.
Uma das suítes mais usadas é o OpenLDAP (GPL), que pode ser baixado no:
http://www.openldap.org “ http://www.hardware.com.br/termos/ldap
O que é o OpenLDAP?

O projeto OpenLDAP é um serviço de diretório que utiliza o protocolo LDAP, base-

ado no protocolo X.500. É compatível com LDAPv3 livre e popular e está disponível
para várias plataformas como: Linux, Solaris, Mac OS e Windows. “ Segurança e
controle de dados é imprescindível em qualquer empresa, por isso uma das vanta-
gens do OpenLDAP é a possibilidade de que vários sistemas possam compartilhar
de base de dados de usuários e senhas de forma centralizada e integrada. “
http://www.otrampolim.com.br/coluna/3675/bruno-lopes-
siqueira/cotidiano/openldap
Como o LDAP, utiliza o tráfego de dados via TCP/IP, podendo ser implementado em
diversas plataformas em redes IPV4 e IPV6, possibilitando também autenticação,
mecanismos de segurança no uso de certificados e criptografia, podendo ser confi-
gurado para restringir acesso a "socket layer", ter múltiplas instâncias de banco de
dados, múltiplas "threads", permite replicação e configuração do serviço de acordo
com a sua necessidade através dos "schemas".
O OpenLDAP constitui-se de:
• slapd - Serviço OpenLDAP
• syncrepl - Serviço para replicação e atualização OpenLDAP
• libraries - Bibliotecas para implementação do OpenLDAP, com utilitários e fer-

ramentas
Quais serviços podem usar a base de dados do OpenLDAP?
Podemos destacar o Apache, DNS, FTP, Kerberos, MySQL, PAM, Postfix, Samba,
Squid, SSL, Clusters entre outros.

O que é um diretório?
Diretório significa algo usado para indicar direções. Um exemplo simples: Uma
lista telefônica. A lista é organizada de maneira hierárquica para que a informação
buscada seja encontrada de forma eficiente. Em um diretório você pode pesquisar,
inserir, alterar e apagar itens.
O que NÃO é um diretório?
Um diretório não pode ser considerado um banco de dados, porque o bando de

dados é otimizado para ler e gravar dados com o mesmo grau de eficiência. O diretó-
rio é otimizado apenas para leitura e seu sistema de transações é bem mais simples
do que de um banco de dados. Um diretório não pode ser considerado um sistema
de arquivos, por que o sistema de arquivo possui otimizações para manipulação de
arquivos, como por exemplo, para trabalhar com grandes arquivos.
Podemos destacar alguns atributos de diretórios:
1 c - Representa pa ís ( country )
2 o - Representa uma organiza ção como uma empresa ( organization )
3 ou - Representa um departamento ( organization unit )
4
5 Alguns atributos de entradas :
6 cn - Representa um nome ( common name )
7 uid - Representa a identidade de um usu á rio ( user ID )
8 gn - Representa o nome pr ó prio de uma pessoa ( given name )
9 sn - Representa o sobrenome de uma pessoa ( surname )
Laboratório
Vamos iniciar a instalação do OpenLDAP na máquina “Datacenter”:

1 root@datacenter :~ # aptitude install slapd ldap - utils libldap -2.4 -2
Vamos gerar o hash da senha do administrador para inserirmos na diretiva
1 rootpw que estar á no arquivo / etc / ldap / slapd . conf :

2 root@datacenter :~ # slappasswd | tee / root / ldap . txt
3 New password : 123456
4 Re - enter new password : 123456
5 { SSHA } yb9Xs4qy9rtG4CSd / hph62qo6X1LFxmW
Agora vamos criar o arquivo /etc/ldap/slapd.conf conforme abaixo, adicionando o

hash da senha do administrador da base:
1 root@datacenter :~ # vim / etc / ldap / slapd . conf

2 include / etc / ldap / schema / core . schema
3 include / etc / ldap / schema / cosine . schema
4 include / etc / ldap / schema / nis . schema
5 include / etc / ldap / schema / inetorgperson . schema
6
7 allow bind_v2
8 pidfile / var / run / slapd / slapd . pid
9 argsfile / var / run / slapd / slapd . args
10 loglevel none
11
12 modulepath / usr / lib / ldap
13 moduleload back_bdb
14 sizelimit 500
15 tool - threads 1
16 backend bdb
17 database bdb
18
19 suffix " dc = dexter , dc = com , dc = br "
20 rootdn " cn = admin , dc = dexter , dc = com , dc = br "

21 rootpw { SSHA } yb9Xs4qy9rtG4CSd / hph62qo6X1LFxmW

22
23 directory "/ var / lib / ldap "
24 dbconfig set_cachesize 0 2097152 0
25 dbconfig set_lk_max_objects 1500
26 dbconfig set_lk_max_locks 1500
27 dbconfig set_lk_max_lockers 1500
28
29 index objectClass eq
30 lastmod on
31 checkpoint 512 30
32
33 access to attrs = userPassword , shadowLastChange
34 by dn =" cn = admin , dc = dexter , dc = com , dc = br " write
35 by anonymous auth
36 by self write
37 by * none
38
39 access to dn . base ="" by * read
40
41 access to *
42 by dn =" cn = admin , dc = dexter , dc = com , dc = br " write
43 by * read
Após criar o arquivo slapd.conf em /etc/ldap, vamos parar o serviço slapd e fazer
nossas alterações:
1 root@datacenter :~ # service slapd stop

2 Stopping OpenLDAP : slapd .
3 root@datacenter :~ # cd / etc / ldap
Faça backup do diretório original antes de alterá-lo:
1 root@datacenter :~ # cp -r slapd .d slapd .d. backup

Remova o diretório antigo:
1 root@datacenter :~ # rm -r slapd .d
Crie um novo:
1 root@datacenter :~ # mkdir slapd .d
Teste se o arquivo novo está OK:
1 root@datacenter :~ # slaptest -f slapd . conf -F slapd .d

2 slapd . conf : line 36: rootdn is always granted unlimited privileges .
3 slapd . conf : line 42: rootdn is always granted unlimited privileges .
4 config file testing succeeded
Se aparecer essa mensagem está tudo certo! As linhas 36 e 42 são apenas infor-
mações referentes a privilégios do administrador em relação à base! Agora altere o
dono e grupo para openldap para o novo diretório slapd.d:
1 root@datacenter :~ # chown -R openldap : openldap slapd .d
Inicie novamente o slapd:
1 root@datacenter :~ # service slapd start

2 Starting OpenLDAP : slapd .
Veja se a porta do serviço está em escuta:

1 root@datacenter :~ # netstat - putan | grep 389

2 tcp 0 0 0.0.0.0:389 0.0.0.0:* OU ÇA 12484/ slapd
tcp6 0 0 :::389 :::* OU ÇA 12484/
slapd
O que é um LDIF?
LDIF (LDAP Data Interchange Format) é o formato de arquivo de entrada padrão

do OpenLDAP. É desta maneira que os dados devem ser incluídos no sistema LDAP
quando não temos nenhuma ferramenta de administração. Para nos ajudar na mi-
gração da base de usuários que temos no sistema do servidor para a base de dados
do OpenLDAP, vamos utilizar uma ferramenta chamada migrationtools. Faça a ins-
talação:
1 root@datacenter :~ # aptitude install migrationtools
Localize as linhas 71 e 74, respectivamente, e as deixe exatamente assim:
1 root@datacenter :~ # vim +71 / usr / share / migrationtools / migrate \ _common

. ph $DEFAULT \ _MAIL \ _DOMAIN = " dexter . com . br ";
2 $DEFAULT_BASE = " dc = dexter , dc = com , dc = br ";
Agora entre no diretório e execute os scripts abaixo:
1 root@datacenter :~ # cd / usr / share / migrationtools /

2 root@datacenter :/ usr / share / migrationtools # ./ migrate_passwd . pl \
3 / etc / passwd / etc / ldap / users . ldif
4 root@datacenter :/ usr / share / migrationtools # ./ migrate_group . pl \
5 / etc / group / etc / ldap / groups . ldif

6 root@datacenter :/ usr / share / migrationtools # ./ migrate_base . pl > \

7 / etc / ldap / base . ldif
Verificaque se o arquivo /etc/ldap/base.ldif está com o cabeçalho correto:
1 root@datacenter :~ # head / etc / ldap / base . ldif

2 dn : dc = dexter , dc = com , dc = br
3 dc : dexter
4 objectClass : top
5 objectClass : domain
Caso tiver alguma coisa antes da linha “dn: dc=dexter,dc=com,dc=br, remova!
Agora que temos os arquivos “.ldif”, vamos inseri-los na base de dados do OpenL-
DAP. Você precisará da senha de administrador da base. Inicie pelo arquivo da base,
depois insira os grupos e finalmente os usuários:
1 root@datacenter :~ # ldapadd -x -D cn = admin , dc = dexter , dc = com , dc = br -f

\
2 / etc / ldap / base . ldif -W
\
4 / etc / ldap / groups . ldif -W
\
6 / etc / ldap / users . ldif -W
Parâmetros do comando “ldapadd”:
1 -x - autentica ção simples

2 -D - espec í fica o dom í nio
3 -f - indica o arquivo ldif

4 -W - chama o prompt de autentica çã o

5 -w senha - executa o comando sem solicitar a senha
Faça uma busca simples na base à procura de um determinado “uid”:
1 root@datacenter :~ # ldapsearch -x -b dc = dexter , dc = com , dc = br \

2 uidNumber =1002
3 # extended LDIF
4 #
5 # LDAPv3
6 # base <dc = dexter , dc = com , dc =br > with scope subtree
7 # filter : uidNumber =1002
8 # requesting : ALL
9 #
10
11 # dexterclem , People , dexter . com . br
12 dn : uid = dexterclem , ou = People , dc = dexter , dc = com , dc = br
13 uid : dexterclem
14 cn : dexterclem
15 objectClass : account
16 objectClass : posixAccount
17 objectClass : top
18 objectClass : shadowAccount
19 shadowMax : 99999
20 shadowWarning : 7
21 loginShell : / bin / false
22 uidNumber : 1002
23 gidNumber : 2001
24 homeDirectory : / srv / samba / homes / dexterclem
25
26 # search result
27 search : 2
28 result : 0 Success
29
30 # numResponses : 2
31 # numEntries : 1

Vamos agora aprender como alterar o dado de um usuário que está no OpenLDAP.
Para isto temos que criar um arquivo ldif:
1 root@datacenter :~ # vim / root / loginShell . ldif

2 dn : uid = mandarkglory , ou = People , dc = dexter , dc = com , dc = br
3 changetype : modify
4 replace : loginShell
5 loginShell : / bin / bash
Neste exemplo, o shell do usuário “mandarkglory” será alterado para /
1 bin / bash . Vamos ent ão aplicar a altera ção:

2 root@datacenter :~ # ldapmodify -x -D cn = admin , dc = dexter , dc = com , dc = br
\
3 -f / root / loginShell . ldif -W
4 Enter LDAP Password :
5 modifying entry " uid = mandarkglory , ou = People , dc = dexter , dc = com , dc = br "
Vamos consultar a base para ver se alterou mesmo:
1 root@datacenter :~ # ldapsearch -x -b dc = dexter , dc = com , dc = br \

2 uid = mandarkglory | grep login -A4 -B3
3 uidNumber : 1003
4 gidNumber : 2001
5 homeDirectory : / srv / samba / homes / mandarkglory
6 loginShell : / bin / bash
7
8 # search result
9 search : 2
10 result : 0 Success

Para voltar ao normal, é só alterar o arquivo /root/loginShell.ldif e aplicar o comando

“ldapmodify” novamente.
Vamos aprender agora uma forma alternativa (e mais fácil!) para administrar a base
OpenLDAP, através do phpldapadmin. Você vai precisar ter o Apache instalado no
servidor do OpenLDAP e mais alguns pacotes mostrados abaixo:
1 root@datacenter :~ # aptitude install apache2 php5 php - pear php5 - ldap

\
2 phpldapadmin
Vá no navegador da máquina “Squeeze” e acesse o endereço :
http://192.168.X.2/phpldapadmin/index.php

Clique em conectar e no campo “senha” digite 123456:
Tela inicial com a base do lado esquerdo:

11.0.54 Backup da base de dados
Inicialmente, pare o servidor OpenLDAP:
Para realizar o backup, simplesmente realize o seguinte comando:
1 root@datacenter :~ # slapcat -l / root / backup_ldap . ldif
Gerando uma cópia de segurança:

1 root@datacenter :~ # cp / root / backup_ldap . ldif \

2 / root / backup_ldap_copia . ldif
DICA: Para ter certeza que o seu backup é seguro, é importante realizá-lo em
um período livre de gravações, ou com o servidor slapd desligado.
Inicie o servidor slapd novamente:
Após realizar o backup, vamos remover sua base de dados inteira:
1 root@datacenter :~ # ldapdelete -x -D cn = admin , dc = dexter , dc = com , dc = br

\
2 -r dc = dexter , dc = com , dc = br -W
Para nos certificarmos de que a base realmente foi removida, execute o comando
slapcat novamente, mas tenha certeza de que você não está sobrescrevendo o seu
backup:
1 root@datacenter :~ # slapcat
Pare o servidor:

Vamos restaurar a nossa base, utilizando o comando slapadd:
1 root@datacenter :~ # slapadd -l backup_ldap . ldif

2 .# ################### 100.00% eta none elapsed none fast
! Closing DB ...
Inicie o slapd:
Execute o comando slapcat novamente para termos certeza que o backup foi restau-
rado:
1 root@datacenter :~ # slapcat

Capítulo 12
Servidor Proxy com Squid
12.0.55 Cenário
A fim de evitar abusos no uso da internet, a empresa DEXTER COURIER precisa

de uma solução que integre permissão de acesso, tipos de arquivos que poderão
efetuar download, cache de páginas e monitoramento destes acessos.
Muitas empresas empregam o uso de PROXY, seja para fazer cache, seja para filtrar
conteúdo. A implementação do servidor proxy Squid é amplamente utilizada, possi-
bilitando assim suprir as necessidades da empresa Dexter. Além disto, faremos uso
do SquidGuard, um poderoso filtro de conteúdo.
12.0.57 Introdução Teórica
Imagine que os seus usuários necessitem acessar com frequência um site de notí-
cias. A cada requisição, o navegador Web resolve o DNS deste site, faz a requisição
247
ao servidor Web encontrado e traz o conteúdo até o usuário. Agora, imagine que 500
clientes estão acessando este site. Desperdício de banda, não acha?
As soluções Web Proxy foram desenvolvidas justamente para contornar este pro-
blema. Imagine o mesmo cenário acima, só que desta vez, ao invés de consultar o
site, o navegador consulta o "Web Proxy"previamente configurado, e então o servi-
dor "proxy"faz a consulta ao site, só que antes de entregar a requisição ao cliente,
o servidor "proxy"armazena o conteúdo do site em um diretório num disco rígido e,
quando um segundo cliente acessar o mesmo site, o servidor "proxy"verifica se o
conteúdo esta armazenado em "cache".
Em caso positivo, o servidor entrega o conteúdo do "cache", acelerando a navegação

e economizando banda. Além disso, o "Web Proxy"também pode agir como filtro
de conteúdo, verificando se é desejável que aquele conteúdo seja acessível para
aquele usuário, endereço IP ou Mac Address, e então libera ou nega o acesso de
acordo com o especificado nas ACL’s (Access Control List), item que veremos
mais adiante.
O Web Proxy pode trabalhar de dois modos: manual ou transparente.
12.0.58 Proxy Manual
“Em um proxy manual, o navegador sabe que é necessário fazer uma requisição ao
servidor "proxy", então temos uma série de funções que o "browser"pode solicitar,
como forçar a atualização do "cache", verificar se as credenciais de autenticação
foram fornecidas previamente, ou seja, o cliente sabe que deve falar com um "proxy"e
fará a requisição direto a este. Além disso, o servidor, por sua vez, possui o número
IP do cliente que fez aquela requisição, o que possibilita criar regras específicas e
controle de logs mais apurados.

http://www.linuxnaveia.com/mais-artigos/215-squid-configuracao-basica.html
A imagem a seguir mostra como funciona um proxy manualmente configurado.
http://www.hardware.com.br/livros/servidores-linux/configurando-servidor-
proxy-com-squid.html
12.0.59 Proxy Transparente
Em um proxy transparente não há necessidade de configurarmos o "browser". O

cliente fará sua requisição ao "gateway"padrão daquela rede e então, com uma re-
gra de "firewall"previamente configurada, o "gateway"fará o redirecionamento para o
proxy, que por sua vez realizará seu trabalho.
A maior vantagem deste modelo é que não temos a necessidade de configurarmos

os navegadores Web manualmente, o que seria justificável em uma rede onde não

temos o poder de manipular o computador dos usuários, como um provedor de inter-

net, por exemplo.
Em compensação, perderemos a flexibilidade dos logs e autenticação, já que o nave-

gador web não sabe que está passando por um proxy e também teremos que fazer
"NAT"para acessos a sites que utilizam "HTTPS", já que o "Squid"não sabe lidar com
este tipo de conteúdo quando está trabalhando de forma transparente.
Abaixo uma ilustração simplificada de como esse processo funciona:
http://www.hardware.com.br/livros/servidores-linux/configurando-servidor-
proxy-com-squid.html
12.0.60 ACL - Access Control Lists
As ACLs (Access Control List) são regras para navegação via proxy. Vale ressaltar
que as ACLs são lidas na ordem em que aparecem e podem ser combinadas, tome
muito cuidado ao criar ou alterar uma nova regra. Veja a documentação online no
endereço http://www.squid-cache.org para as configurações não citadas!

12.0.61 Definindo ACL
As ACLs são dispostas de seguinte forma:
1 acl NOME_DA_ACL TIPO_DA_ACL par â metro
Nesta regra será definido todos os parâmetros em sequência, separados por espaço,
utilizado para regras com poucos parâmetros.
1 acl NOME_DA_ACL TIPO_DA_ACL "/ caminho / completo / regra . conf "
Já nesta outra forma será definido um arquivo para adição dos parâmetros dispostos,
um por linha, utilizado para regras com muitos parâmetros. Todas as ACLs são tra-
tadas com CASE-SENSITIVE. Para definir como CASE-INSENTIVE, utilize a opção
“-i” logo após o tipo de ACL.
12.0.62 Tipos de ACL
• src => ACL do tipo src (origem) trata sobre um determinado IP ou uma faixa de
IP com que o cliente chega ao Proxy.
1 acl ESTACAO_DIRETOR src 192.168.200.100/255.255.255.255

2 acl MyNetwork src 192.168.200.0/24
3 acl gateway src 192.168.200.254
• dst => ACL do tipo dst (destino) trata do IP de destino da navegação.
1 acl UOL dst 200.221.2.45/255.255.255.255

2 acl Servers dst 192.168.200.1 192.168.200.2 192.168.200.3
• dstdomain => ACL do tipo dstdomain (domínio de destino) trata do domínio de

destino da navegação.
1 acl SITE_INTEGRAL dstdomain . terra . com . br

2 acl 4 linux dstdomain .4 linux . com . br
3 acl Brasil dstdomain . com . br
• time => ACL do tipo time (tempo) trata de um determinado momento baseado
em dia da semana e hora.
1 acl HORARIO_ALMOCO time 12:00 -13:30

2 acl HORARIO_ALMOCO time MTWHF 12:00 -13:30
Segue abreviação dos dias.
Abreviação Dia da semana
S domingo M segunda-feira T terça-feira W quarta-feira H quinta-feira F sexta-feira A

sábado
• url_regex => ACL do tipo url_regex (expressão regular na URL) trata de uma
determinada entrada na URL. Pode-se fazer muitas regras baseadas em ex-
pressões regulares, porém é preciso conhecer muito bem sobre o assunto.
1 acl EXTENSAO_PROIBIDA url_regex ?i \. exe$
• port => ACL do tipo port (porta) trata da porta de destino da navegação.

1 acl SITE_8080 port 8080
• proxy_auth => ACL do tipo proxy_auth (autenticação no Proxy) trata do Login

com que o cliente se autentica no Proxy. Requer uma configuração de autenti-
cação.
1 acl DIRETOR proxy \ _auth joao
"ACL’S"de origem e destino podem ser cobrados na LPI-2, bem como sua
forma de utilização.
Esses são os tipos básicos de "ACL’s", porém uma "ACL"sozinha não faz absoluta-
mente nada. Durante o laboratório veremos como tornar as "ACL’s"úteis com con-
figurações que permitem utilizá-las para bloqueio e liberação de sites, domínios e
horários.
1
2 LEMBRETE - Tipos de ACL
3
4 src - Filtro por rede ou endere ço IP ;
5 time - Filtro por hora e dia da semana ;
6 urlpath_regex - filtro de complemento de uma " url ";
7 url \ _regex - Filtro de uma " string " na " url ";
8 dstdomain - Filtro de uma " url ";
9 proxy \ _auth - Filtro por usu á rios autenticados ;
10 arp - Filtro por " MAC Address ";
11 maxconn - Filtro por conex õ es ;
12 proto - Filtro por protocolos ;
13 port - Filtro por porta .

12.0.63 Regras das ACLs
• http_access => Permite ou nega acessos baseados nas ACLs pré definidas.
É utilizado seguido de allow ou deny. Se a ACL for precedida de um ponto
de exclamação significa que será a negação da ACL. As regras serão lidas na
ordem em que aparecem.
Seguem exemplos :
• Acesso liberado para o diretor baseado em login
1 http_access allow DIRETOR
• Acesso liberado ao site do UOL exceto no horário do almoço
1 http_access allow UOL ! HORARIO_ALMOCO
• Extensão proibida baseado em expressão regular
1 http_access deny EXTENSAO_PROIBIDA
Toda e qualquer modificação no arquivo de configuração do SQUID faz-se necessário

digitar o comando abaixo para que entrem em vigor imediatamente!
1 # squid -k reconfigure

Vamos instalar nosso PROXY na máquina “Firewall”. Para isto, execute:
1 root@firewall :~ # aptitude install squid
Os arquivos e diretórios principais que ele utilizará:
/etc/squid/squid.conf - Arquivo de configuração /var/log/squid/* - Arquivos de log.

/var/spool/squid - Diretório que contém o cache.
Após confirmar a instalação do "Squid", verifique o conteúdo dos diretórios:
1 root@firewall :~ # ls -lh / etc / squid

2 root@firewall :~ # ls -lh / var / log / squid
3 root@firewall :~ # ls -lh / var / spool / squid
Para posterior consulta, renomeie o arquivo de configuração original:
1 root@firewall :~ # mv / etc / squid / squid . conf / etc / squid / squid . conf .

distro
A configuração padrão do "Squid"não permite nenhum tipo de navegação por me-

didas de segurança. A primeira coisa que devemos fazer é especificar qual rede
o "Squid"deve aceitar, e também devemos especificar uma "ACL"do tipo origem,
que case com o nosso endereço IP. Vamos configurar nosso proxy com as regras
abaixo:

1 root@firewall :~ # vim / etc / squid / squid . conf

2 ## Para que o " Squid " ou ça apenas uma rede , troque o valor do
3 ## par â metro " http_port 3128" para :
4 http_port 192.168. X .1:3128
5 ## Este par â metro diz qual ser á o hostname que o " Squid " utilizar á
6 ## para resolver seu endere ço local e tamb ém o endere ço que ser á
7 ## apresentado nas pá ginas de informa ção.
8 visible_hostname proxy . dexter . com . br
9 ## Espa ço em mem ó ria RAM para o cache de pá ginas
10 cache_mem 64 MB
11 ## Espa ço em disco para o cache de pá ginas
12 ## ufs = sistema de arquivo padrao do squid
13 ## 5120 = 5 GB para cache de pagina , se precisar de Windows Update e
14 ## antivirus , tera que aumentar este valor
15 ## 128 = 128 diretorios
16 ## 256 = subdiretorios dentro dos diret ó rios acima criados
17 ## utiliza esta divisao para indexar mais rapido quando lotar o
cache
18 ## de disco , descartando os arquivos mais antigos !
19 cache_dir ufs / var / spool / squid 5120 128 256
20 ## Log de acesso à pá ginas
21 access_log / var / log / squid / access . log
22 ## Inibe a informa ção da vers ão do Squid quando um site é bloqueado
23 httpd_suppress_version_string on
24 ## Pá ginas de bloqueios exibidos em Portugu ês
25 error_directory / usr / share / squid / errors / Portuguese
26 ## Tamanho má ximo do arquivo no cache em RAM e disco ,
respectivamente
27 maximum_object_size_in_memory 64 KB
28 maximum_object_size 700 MB
29 minimum_object_size 0 KB
30 ## Porcentagem de uso do cache de disco mí nimo e má ximo ,
respectivamente
31 cache_swap_low 90
32 cache_swap_high 95
33 ## Log de uso do cache em disco

34 cache_access_log / var / log / squid / cache . log

35
36 # ##### Declara ção das ACL ’s ######
37
38 # ##### ACL ’s do pr ó prio Squid ######
39 acl all src 0.0.0.0/0.0.0.0
40 acl manager proto cache_object
41 acl localhost src 127.0.0.1/255.255.255.255
42 ## As acl ’s " SSL_ports " e a " Safe_ports " são as respons á veis por
43 ## limitar as portas que podem
44 ## ser usadas atrav és do proxy . Na documenta ção do Squid , que prev ê
o
45 ## uso de diversos protocolos
46 ## conhecidos e tamb ém o uso de portas altas
47 acl SSL_ports port 443 563
48 acl Safe_ports port 21 80 443 563 70 210 280 488 59 777 901
1025 -65535
49 ## Exclui os objetos que foram armazenados no cache do squid
50 acl purge method PURGE
51 ## Permite ao Squid deixar fazer a conex ão direta quem fizer parte
da
52 ## ACL connect
53 acl CONNECT method CONNECT
54
55 # ##### Minhas ACL ’s ######
56
57 # ##### Aplica ção das ACL ’s ######
58 # Permite acesso ao gerenciamento do cache vindo somente do
localhost
59 http_access allow manager localhost
60 http_access deny manager
61 # Permite acesso a exclus ão dos objetos no cache somente pelo
localhost
62 http_access allow purge localhost
63 http_access deny purge
64 # Nega acesso a requisi çõ es de portas desconhecidas
65 http_access deny ! Safe_ports

66 # Nega conex ão exceto para portas SSL

67 http_access deny CONNECT ! SSL_ports
68 # Libera acesso ao localhost
69 http_access allow localhost
70
71 # ##### Minhas regras ######
72
73 # Nega qualquer outra rede
74 http_access deny all
12.0.65 Criando a estrutura do Squid
Execute os comandos abaixo para criar a estrutura de diretórios do Squid:
1 root@firewall :~ # service squid stop

2 root@firewall :~ # squid -z
3 2011/08/17 16:56:05| Creating Swap Directories
4 root@firewall :~ # service squid start
5 Starting Squid HTTP proxy : squid .
12.0.66 Filtrando acessos com Squid
Controlar o que deve ou não deve ser acessível na internet a partir da rede interna é
uma das opções mais interessantes oferecidas pelo "Squid". Então, para que possa-
mos entender como trabalhar com "ACL’s", vamos criar o seguinte cenário: qualquer
"host"na minha rede deve ser impedido de navegar em qualquer domínio ".com",
tendo como única exceção o site "www.globo.com". Como fazer isso?
Crie uma ACL com a rede de origem, uma ACL para domínios ".com" e uma ACL
para o domínio "globo.com". Insira as linhas abaixo da entrada “Minhas ACL’s” no

“/etc/squid/squid.conf”:

2 # ##### Minhas ACL ’s ######
3 acl RedeDexter src 192.168. X .0/24
4 acl Internacional dstdomain . com
5 acl Globo dstdomain . globo . com
Agora com as ACL’s criadas, iremos especificar as políticas de acesso e bloqueios

com o "http_access". Insira uma entrada “Minhas regras” no final do arquivo o
“/etc/squid/squid.conf”, conforme abaixo:

2 # ##### Minhas regras ######
3 http_access allow RedeDexter Globo
4 http_access deny RedeDexter Internacional
5 http_access allow RedeDexter
Para checar se há erros na configuração, execute o comando abaixo. Se retornar ao

prompt, sua configuração está OK:
1 root@firewall :~ # squid -k parse
Visto que não é recomendável efetuar um restart no serviço do Squid devido à de-
mora em checar todas as suas entradas em cache, execute o comando abaixo para
reler o arquivo squid.conf:
1 root@firewall :~ # squid -k reconfigure
Configure o navegador no cliente:

Acesse as opções na sequência abaixo:

Informe o endereço do seu servidor Proxy e a porta a ser utilizada. Marque a utiliza-
ção do proxy para todos os protocolos:
Limpe o cache do navegador para não atrapalhar nossos teste:

Acessando a página do “google.com.br” - LIBERADO!
Acessando a página do “google.com” - NEGADO!

Lembrete: A ordem das ACL’s não importa, porém, o "Squid"fará o filtro de

acordo com a ordem das regras de acesso configuradas por "http_access". Portanto
a ordem dos "http_access"é o que nos importa! Lembre-se disso quando fizer "trou-
bleshooting"ou criar novas regras.
12.0.67 Blacklist e Whitelist
O conceito de "Blacklist"e "Whitelist"é muito simples:
• Blacklist - Uma lista de palavras que eu quero negar;
• Whitelist - Uma lista de domínios que eu quero liberar.
Para exemplificar o uso de "blacklists"e "whitelists", vamos criar duas "ACL’s", uma
negando qualquer "url"que contenha a palavra "linux" e outra liberando os sites
"www.linux.com" e "www.4linux.com.br":


2 # ##### Minhas ACL ’s ######
3 acl RedeDexter src 192.168. X .0/24
4 acl Internacional dstdomain . com
5 acl Globo dstdomain . globo . com
6 acl blacklist url_regex linux
7 acl whitelist dstdomain www . linux . com www .4 linux . com . br
8 ...
9 # ##### Minhas regras ######
10 http_access allow RedeDexter whitelist
11 http_access deny RedeDexter blacklist
12 http_access allow RedeDexter Globo
13 http_access deny RedeDexter Internacional
14 http_access allow RedeDexter
Reinicie o squid:
Agora, tente acessar os sites:
1 www .4 linux . com . br

2 www . vivaolinux . com . br
3 www . linux . com
4 www .br - linux . org
Para aprender mais, acesse http://www.squid-cache.org e leia a documentação

oficial do projeto "Squid".

12.0.68 Autenticação NCSA
O "Squid"possui um mecanismo de autenticação que pode trabalhar de diversas ma-

neiras, e uma delas, a NCSA, utiliza o mesmo mecanismo de autenticação do servi-
dor Web Apache. Vamos configurar esse modelo de autenticação e criar uma ACL
que exija autenticação também. Vamos configurar a autenticação do Squid, adicio-
nado o conteúdo abaixo no início do arquivo /etc/squid/squid.conf:

2 1 auth_param basic program / usr / lib / squid / ncsa_auth / etc / squid /
passwd
3 2 auth_param basic children 5
4 3 auth_param basic realm >>> Servidor Proxy Squid - Dexter <<<
5 4 auth_param basic credentialsttl 2 hours
1.Linha 1 - configura o programa autenticador;
2.Linha 2 - número de processos de autenticação;
3.Linha 3 - configura a mensagem da caixa de autenticação;
4.Linha 4 - configura o tempo de validade da autenticação. Vamos cadastrar também,

além da ACL que irá gerenciar a autenticação no proxy, o http_access que permitirá
o acesso autorizado:
1 # #### Minhas ACL ’s ######

2 acl password proxy_auth REQUIRED
3
4 # ##### Minhas Regras ######
5 http_access deny ! password # ### => primeira da lista !
Gerando o arquivo de senhas:

1 root@firewall :~ # aptitude install apache2 - utils

2 root@firewall :~ # htpasswd -c / etc / squid / passwd mandarkglory
Reinicie o serviço do Squid e tente acessar qualquer site!
1 root@firewall :~ # service squid restart
Solicitação de usuário e senha:
Após o logar com o usuário válido no proxy:

12.0.69 Auditoria de acesso com SARG
O SARG (Squid Analysis Report Generator) é uma ferramenta desenvolvida pelo

brasileiro Pedro Lineu Orso, cujo objetivo é analisar o arquivo "/var/squid/log/ac-
cess.log" e gerar um relatório de acesso baseado no conteúdo acessado pelos
usuários. Resumindo, é usado para auditoria de acesso!
Na versão do Debian Squeeze o Sarg não está no repositório oficial, por isto teremos
que inserir o repositório backports. O que seria então backports? O backports é um
repositório paralelo ao projeto Debian. Ele é mantido pelos desenvolvedores e
pela equipe de segurança do Debian. Esse repositório reúne novos programas e
novas versões de programas compilados sobre o stable.
Para utilizarmos o backports é simples, primeiro devemos adicionar o seu repositório

no arquivo /etc/apt/sources.list:
1 root@firewall :~ # vim / etc / apt / sources . list

2 # ## adicionar
3 deb http :// www . backports . org / debian squeeze - backports main contrib \
non - free
Depois atualize:
1 root@firewall :~ # aptitude update

2 root@firewall :~ # aptitude -t squeeze - backports install sarg
3 root@firewall :~ # sarg
Como você pode perceber, todos os backports vem desativados por default. Por isto
tivemos que informar qual o tipo de repositório a ser utilizado!
Vamos observar seu arquivo de configuração. Fique a vontade e leia alguns comen-
tários para entender as funções do "SARG".
1 root@firewall :~ # vim / usr / sbin / sarg - reports
Para que a página de relatório seja acessada, instale o Apache2:
1 root@firewall :~ # aptitude install apache2 -y
Edite o arquivo abaixo com o conteúdo apontando para o diretório do Sarg:
1 root@firewall :~ # vim / etc / apache2 / httpd . conf

2 Alias / squid - reports "/ var / lib / sarg /"
3 DirectoryIndex index . html
Reinicie o Apache:

1 root@firewall :~ # service apache2 restart
Agora, acesse o endereço e veja os acessos dos usuários:
1 http ://192.168. X .1/ squid - reports
Tela inicial do Sarg com data de acesso:
Selecionando um data, podemos ver os usuários/IPs. Selecione o usuário:

Agora podemos ver o final do relatório de acessos e o total de uso de banda:

12.0.70 Autenticação via OpenLDAP
Vamos agora configurar o Squid para fazer autenticação usando a base de dados do
OpenLDAP já criada. É bastante simples. Bata alterar a linha de configuração da
autenticação do usuário (auth_param basic program /usr/lib/squid/ncsa_auth /etc/s-
quid/passwd) para a linha abaixo:

2 auth_param basic program / usr / lib / squid / ldap_auth -b \
3 dc = dexter , dc = com , dc = br -f uid =% s 192.168. X .2
Reinicie o serviço:
Quando habilitamos a autenticação anteriormente, só tínhamos criado o usuário

mandarkglory com o htpasswd, agora você pode testar outros usuários na auten-
ticação, pois agora a base usada será a do OpenLDAP. Faça o teste logando com os
usuários “allissonmore” e “candimilo”!

Capítulo 13
Firewall
13.0.71 Cenário
A fim de que ninguém acesse dados indevidos da empresa ou mesmo de seus cli-
entes, a empresa DEXTER COURIER deve contar com um excelente Firewall para
bloquear tentativas de invasão e liberar apenas o tráfego necessário aos serviços
que ficam na máquina “DMZ”.
Faremos a implementação do Firewall baseado no Iptables, gerenciando as políticas

de entrada de pacotes na empresa Dexter, bem como a liberação de acesso externo
ao servidor da DMZ.
O que é um firewall?
273
Um firewall faz o filtro de pacotes que passam na rede. Para configurar um firewall
é necessário o conhecimento sobre a estrutura da rede em questão e dos diferentes
protocolos envolvidos na comunicação, isto é, dos serviços que a rede usa para que
eles não percam a comunicação. O objetivo em ter uma máquina fazendo o papel
de Firewall Gateway em nossa é rede é minimizar as tentativas de ataques que elas
recebem, tentando impedir possíveis invasões e levantamento de informações.
Os sistema GNU/Linux com Kernel 2.6 trabalham com o "Iptables"para fazer o ge-
renciamento de regras de Firewall. Lembrando que o "Iptables"é apenas um "fron-
tend"que gerencia o suporte "Netfilter"no "Kernel".
Características do iptables :
• Filtro de pacotes statefull => isso significa que o iptables é capaz de atuar sobre
as camadas do protocolo TCP;
• Modularidade => a configuração do kernel é modular e com o netfilter não é di-

ferente, pois novas funcionalidades podem ser adicionadas sem muito esforço.
Um módulo só será usado se for da necessidade do administrador;
http://www.prefirolinux.com/iptables-firewall/74-firewall-e-iptables-tudo-que-
voce-precisa-saber-sem-duvidas-o-melhor-conteudo-da-internet-parte-1-9.html
13.0.74 Revisando os conceitos de Rede
Os dados são transmitidos na Internet agrupados em pacotes TCP (de maneira ge-
ral). Esses pacotes TCP podem conter até 1460 bytes de dados. Além dos dados,
40 bytes adicionais vão junto no pacote. Nesses 40 bytes a mais seguem:
1 - IP de origem

2 - IP de destino
3 - Porta de origem
4 - Porta de destino
5 - Có digos de verifica ção
6 - Nú mero do pacote
Os códigos de verificação servem para garantir a integridade dos dados que estão
sendo trafegados na rede. A função básica do IP é cuidar do endereçamento e en-
trega de pacotes. A função básica do TCP é fazer verificações de erros e numeração
de portas. Logo, os dados serão transmitidos de forma quebrada, em pacotes meno-
res.
Existem 65.536 portas TCP e UDP. Elas são numeradas de 0 e 65.535. As portas
baixas estão na faixa entre 0 a 1023. Elas estão reservadas para serviços mais
conhecidos como: servidor web, ftp, ssh, telnet, servidores de e-mail, compartilha-
mento de arquivos, como, por exemplo, Samba, NFS etc. Portas altas estão faixa
acima de 1023.
Relembrando...
1 As portas padr õ es de um servidor FTP : 21 e 20.

2 A porta padr ão de um servidor web : 80.
3 A porta padr ão de um servidor web com https : 443.
4 A porta padr ão do SMTP : 25.
5 A porta padr ão POP3 : 110.
6 A porta padr ão POP3S : 995.
7 A porta padr ão IMAP : 143.
8 A porta padr ão IMAPS : 995.
9 A porta padr ão do SSH : 22.
10 A porta padr ão para transfer ê ncia de zona do DNS : 53/ tcp .
11 A porta padr ão para consulta de DNS : 53/ udp .
12 A porta padr ão do OpenLDAP : 389.
13 A porta padr ão do proxy Squid : 3128.
14 A porta padr ão do OpenVPN : 5000
15 No arquivo "/ etc / services " podemos obter toda a rela ção de portas !

13.0.75 TTL
Através de um simples ping, conseguimos deduzir o Sistema Operacional de uma

máquina. Por exemplo:
1 root@firewall :~ # ping -c2 www . uol . com . br

2 PING www . uol . com . br (200.221.2.45) 56(84) bytes of data .
3 64 bytes from home . uol . com . br (200.221.2.45) : icmp_req =1 ttl =54 time
=15.0 ms
4 64 bytes from home . uol . com . br (200.221.2.45) : icmp_req =2 ttl =54 time
=16.1 ms
Neste exemplo temos uma TTL (Time to Live) no valor de 54.
Os valores de TTL (padrões) são seguidos por:
1 Roteadores Ciclades = 30
2 Linux = 64
3 Windows = 128
4 Cisco = 255
5 Linux + Iptables = 255
Por exemplo, quando executamos um ping em “www.uol.com.br” ele respondeu o

valor 54. O valor mais próximo desse valor de TTL é o valor 64, do Linux. Se
considerarmos que o pacote deu 10 hops (saltos) até chegar ao destino (passou por
10 roteadores) então temos o cálculo: 64-10=54.
Sendo assim, provavelmente o sistema operacional que o servidor do UOL está

usando é Linux. E para saber essa quantidade de hops que um pacote faz até

chegar ao seu destino, podemos usar ferramentas como traceroute e mtr.
Para sabermos o valor de TTL do SO, podemos executar:
1 root@firewall :~ # cat / proc / sys / net / ipv4 / ip_default_ttl

2 64
Outro comando para verificar o valor de TTL é:
1 root@firewall :~ # sysctl -a | grep ip_default

2 net . ipv4 . ip_default_ttl = 64
E se quisermos alterar esse valor de TTL, também podemos! Mas se alterarmos

simplesmente esse arquivo, não será o suficiente, porque ele não ficará fixo! Para
fixar um valor diferente do valor padrão, é necessário editar o arquivo abaixo e no
final dele acrescentar uma linha com o novo valor de TTL que você definir:
1 root@firewall :~ # vim / etc / sysctl . conf

2 net . ipv4 . ip_default_ttl = 64
Quando adicionamos a linha com o valor de TTL no arquivo /etc/sysctl.conf, temos

que usar o comando abaixo para validar a alteração:
1 root@firewall :~ # sysctl -p / etc / sysctl . conf
Vamos instalar os programas traceroute e mtr para teste:
1 root@firewall :~ # aptitude install traceroute mtr

2 root@firewall :~ # traceroute www . uol . com . br

3 traceroute to www . uol . com . br (200.221.2.45) , 30 hops max , 60 byte

packets
4
5 189.59.249.97. static . host . gvt . net . br (189.59.249.97) 29.581 ms
22.555 ms 22.796 ms
6 7 gvt -te -0 -3 -0 -0 - rt01 . spo . gvt . net . br (189.59.248.61) 24.095 ms
17.854 ms 17.721 ms
7 8 * * *
8 9 200 -147 -26 -113. static . uol . com . br (200.147.26.113) 21.413 ms
22.755 ms 22.924 ms
9 10 200.221.136.154 (200.221.136.154) 22.403 ms 23.011 ms 22.187
ms
10 11 * * *
11 ...
12 30 * * *
Cada linha que aparece um nome é um roteador por onde o pacote passa. Notem
que ele passa por vários lugares! E quando pingo para o site da uol, ele dá um valor
de TTL 54 + 10 hops dos pacotes = 64.
Por padrão o comando traceroute procura por até 30 hops, mesmo que ele não en-
contre nada, que é o caso de quando aparece ***.
Mas na linha de hop 8 por exemplo, apareceu *** e depois aparaceu um nome na
linha 9. Provavelmente temos uma máquina que está com o ping bloqueado ou então
uma máquina com firewall, portanto ela não aparece quando o comando traceroute
faz as buscas.
Verifique agora com o comando “mtr”:
1 root@firewall :~ # mtr uol . com . br

13.0.76 Tabelas do Iptables
O Iptables possui 4 tabelas, sendo elas:
• Filter - Como o nome sugere, trata-se de uma tabela de controle de conteúdo

dos pacotes. Serve para atribuir permissões de acessos essenciais (permitir/-
negar)
• Nat - Esta tabela é utilizada no compartilhamento de conexões, permitindo que

redes internas roteiem e possam acessar a Internet, por exemplo.
• Mangle - É utilizada para modificar uma propriedade de um pacote e seu uso

é avançado, como por exemplo influenciar na decisão de roteamento, filtro ou
controle de banda.
• Raw - Tabela usada para configurar exceções do rastreamento de conexões do

Kernel. Esse mecanismo é também conhecido como: "connection tracking".
A tabela "filter"é a tabela padrão do "Iptables".
Cada uma dessas tabelas possui o que chamamos de "chains". É nelas onde vão
ser definidas as regras para o nosso "firewall". A tradução literal seria "correntes",
assim cada tabela teria uma corrente, onde cada elo corresponderia a uma regra.
13.0.77 O que é uma chain?
Local onde vão ser definidas as regras para o nosso firewall. Cada Tabela possui
suas CHAINS. As da tabela filter são as seguintes:

1 INPUT - Regras de entrada de pacotes .

2 OUTPUT - Regras de sa í da de pacotes .
3 FORWARD - Regras de passagem de pacotes pelo firewall .
As CHAINS da tabela NAT são as seguintes:
1 PREROUTING - Regras que ser ão processadas antes do roteamento

dos pacotes nas interfaces do firewall .
2 POSTROUTING - Regras que ser ão processadas pós roteamento dos
pacotes nas interfaces do firewall .
3 OUTPUT - Regras de sa í da de pacotes .
13.0.78 Compreendendo as políticas básicas e o conceito das

exceções
A metodologia utilizada para implementação do "firewall"será a seguinte:
Iremos negar todo o tráfego para as "chains"de "INPUT", "OUTPUT"e "FORWARD"da

tabela "filter", posteriormente iremos definir a relação dos serviços que devem ser li-
berados no "firewall", as chamadas exceções. Todo o tráfego de pacotes que as nos-
sas exceções não cobrir será bloqueado por padrão. Em suma, o que não for oficial-
mente permitido já está expressa e previamente negado. Perceba que as "chains"são
descritas em letras maiúsculas.

Na 4Linux temos dois treinamentos de segurança da informação: 406 – Pen

Test, testes de vulnerabilidades de redes usando a OSSTMM 415 – Segurança de
servidores Linux usando a ISO27002
A Prova do LPI número 303 é focada em Segurança. Conceitos e comando básicos

do "iptables"são cobrados na prova 202.
A sintaxe do comando iptables é: iptables [-t tabela] [opção] [chain] [dados] -j

[alvo]
Parâmetros:
Alvos:

Vamos montar nosso "firewall", mas antes verifique como estão configuradas as po-
líticas básicas que estão definidas por padrão:
1 root@firewall :~ # iptables -t filter -nL

2 Chain INPUT ( policy ACCEPT )
3 target prot opt source destination
4
5 Chain FORWARD ( policy ACCEPT )
7
8 Chain OUTPUT ( policy ACCEPT )
10
11 root@firewall :~ # iptables -t nat -nL
12 Chain PREROUTING ( policy ACCEPT )
14
15 Chain POSTROUTING ( policy ACCEPT )
17
18 Chain OUTPUT ( policy ACCEPT )

Um detalhes muito importante é se o nosso firewall será o gateway da rede, ou

seja, a fronteira entre a sua rede e a internet. Se a resposta for positiva, devemos
estabelecer uma política que faça o repasse dos pacotes de uma rede para a outra
(forward). A primeira coisa que precisamos fazer é liberar o repasse de pacotes entre
as interfaces de rede, no kernel:
1 root@firewall :~ # sysctl -w net . ipv4 . ip_forward =1
Para deixar esse valor fixo, devemos deixar esse parâmetro dentro de /etc/sysctl.conf.
Basta descomentar a linha 28:
1 root@firewall :~ # vim +28 / etc / sysctl . conf

2 net . ipv4 . ip_forward =1
13.0.80 Script de firewall
Segue aqui um "script"com todas as regras necessárias para nosso servidor entrar
em produção. Esse "script"pode ser adicionado aos níveis de execução do sistema,
para ser carregado sempre que a máquina for ligada. Vamos chamar nosso "script"de
"firewall":
1 root@firewall :~ # vim / etc / init .d/ firewall

2 # !/ bin / bash
3 # Firewall personalizado - Curso 452 - 4 Linux
4 clear
5 ## Defini ção de variaveis
6 OK ="[ \E [01;32 mOK \E[m ]"
7 IPT =$( which iptables ) # ativando caminho completo do
Iptables
8 IPVALIDO =" 200.100.50. X" # IP vindo da Internet ( interface
externa )

9 # IPAMIGO ="200.100.50. X" # IP do amigo para conex ão da VPN

10 FIREWALL =" 192.168. X .1 " # IP do Firewall ( interface interna )
11 DATACENTER =" 192.168. X .2 " # IP da má quina Datacenter
12 DMZ =" 192.168. X .3 " # IP da má quina DMZ
13 STORAGE =" 192.168. X .4 " # IP da má quina STORAGE
14 SQUEEZE =" 192.168. X .10 " # IP da má quina SQUEEZE
15 WINXP =" 192.168. X .20 " # IP da má quina Windows XP
16 EXTERNA =" eth0 " # Placa de rede da Internet (
interface externa )
17 INTERNA =" eth1 " # Placa de rede da Rede Local (
interface interna )
18 PA =" 1024:65535 " # Portas altas
19 REDE =" 192.168. X .0/24 " # Defini ção da Rede interna
20
21 # Carregando mó dulos
22 modprobe ip_conntrack_ftp
23 modprobe ip_nat_ftp
24
25 ativar () {
26 # ## Limpando as regras
27 $IPT -F
28 $IPT -X
29 $IPT -t nat -F
30 $IPT -t nat -X
31 $IPT -P INPUT ACCEPT
32 $IPT -P OUTPUT ACCEPT
33 $IPT -P FORWARD ACCEPT
34 echo 0 > / proc / sys / net / ipv4 / ip_forward
35
36 ## Definindo a Pol í tica padr ão com DROP ( fecha tudo !)
37 $IPT -P INPUT DROP
38 $IPT -P OUTPUT DROP
39 $IPT -P FORWARD DROP
40 echo -e " Pol í tica padr ão - DROP \t\t\t $OK "
41
42 ## Ativando Forward

44
45 ## Liberando acesso a Internet para rede local
46 $IPT -A FORWARD -s $REDE -j ACCEPT
47 $IPT -A FORWARD -d $REDE -j ACCEPT
48 $IPT -t nat -A POSTROUTING -o $INTERNA -s $REDE -j MASQUERADE
49 $IPT -t nat -A POSTROUTING -o $EXTERNA -s $REDE -j MASQUERADE
50 echo -e " Liberando Acesso à Rede internet \t\t\t $OK "
51
52 # Regras de LOGs
53 $IPT -A INPUT -j LOG --log - prefix " Logs do Firewall : INPUT " --log
- level CRIT
54 $IPT -A OUTPUT -j LOG --log - prefix " Logs do Firewall : OUTPUT " --
log - level CRIT
55 $IPT -A FORWARD -j LOG --log - prefix " Logs do Firewall : FORWARD "
--log - level CRIT
56 echo -e " Iniciando regras de LOG \t\t\t $OK "
57 ## Liberando SSH na má quina Firewall
58 $IPT -t filter -A INPUT -p tcp -s 0/0 -- sport 1024:65535 -d
$IPVALIDO -- dport 50000 -j ACCEPT
59 $IPT -t filter -A OUTPUT -p tcp -s $IPVALIDO -- sport 50000 -d 0/0 --
dport 1024:65535 -j ACCEPT
60
61 ## Liberando SSH nas má quinas INTERNAS
62 $IPT -t nat -A PREROUTING -p tcp -s 0/0 -- sport 1024:65535 -d
$FIREWALL -- dport 51000 -j DNAT --to - destination $DATACENTER
:51000
$FIREWALL -- dport 52000 -j DNAT --to - destination $DMZ :52000
$FIREWALL -- dport 53000 -j DNAT --to - destination $STORAGE :53000
$FIREWALL -- dport 54000 -j DNAT --to - destination $SQUEEZE :54000
66 echo -e " Liberando Acesso às VM teste \t\t\t $OK "
67
68 ## Liberando LoopBack
69 $IPT -A OUTPUT -d 127.0.0.1 -j ACCEPT
70 $IPT -A INPUT -d 127.0.0.1 -j ACCEPT

71 echo -e " Liberando Acesso Localhost \t\t\t $OK "

72
73 ## Estabilizando as conex õ es
74 $IPT -A INPUT -m state -- state RELATED , ESTABLISHED -j ACCEPT
75 $IPT -A OUTPUT -m state -- state ESTABLISHED , RELATED -j ACCEPT
76 $IPT -A FORWARD -m state -- state RELATED , ESTABLISHED -j ACCEPT
77 echo -e " Estabilizando as conex õ es \t\t\t $OK "
78
79 ## Liberando Ping ( Sa í da de icmp 8 e Entrada de icmp 0)
80 $IPT -A OUTPUT -p icmp -- icmp - type 8 -s $FIREWALL -d 0/0 -j ACCEPT
81 $IPT -A OUTPUT -p icmp -- icmp - type 8 -s $IPVALIDO -d 0/0 -j ACCEPT
82 $IPT -A INPUT -p icmp -- icmp - type 0 -s 0/0 -d $FIREWALL -j ACCEPT
83 $IPT -A INPUT -p icmp -- icmp - type 0 -s 0/0 -d $IPVALIDO -j ACCEPT
84 $IPT -A INPUT -p icmp -- icmp - type 11 -s 0/0 -d $FIREWALL -j ACCEPT
85 $IPT -A INPUT -p icmp -- icmp - type 11 -s 0/0 -d $IPVALIDO -j ACCEPT
86 echo -e " Liberando Acesso ao ping \t\t\t $OK "
87 ## Liberando acesso ao proxy SQUID no Firewall
88 $IPT -A INPUT -s $REDE -p tcp -- dport 3128 -j ACCEPT
89 echo -e " Liberando Acesso ao Proxy Squid \t\t\t $OK "
90
91 ## Liberando acesso à VPN no Firewall
92 # $IPT -A INPUT -p tcp -s $IPAMIGO -- sport 5000 -d $IPVALIDO -- dport
5000 -j ACCEPT
93 # $IPT -A OUTPUT -p tcp -s $FW -- sport 5000 -d $IPAMIGO -- dport 5000
$IPVALIDO -j ACCEPT
94 # echo -e " Liberando Acesso à VPN \t\t\t $OK "
95
96 ## Liberando resolu ção de nomes
97 $IPT -A FORWARD -p udp -s $DMZ -- sport $PA -d 0/0 -- dport 53 -j
ACCEPT
98 # $IPT -A FORWARD -p udp -s 0/0 -- sport 53 -d $DMZ -- dport $PA -j
ACCEPT
99 echo -e " Liberando Acesso ao DNS \t\t\t $OK "
100
101 ## Liberando navega ção web ( INTERNET ) para a REDE INTERNA
102 $IPT -A FORWARD -p tcp -s $REDE -- sport $PA -d 0/0 -- dport 80 -j
ACCEPT

103 $IPT -A FORWARD -p tcp -s $REDE -- sport $PA -d 0/0 -- dport 443 -j
ACCEPT
104 echo -e " Liberando Acesso ao Servidor Web \t\t\t $OK "
105
106 ## Redirecionando acesso externo para o site , e - mail e ftp da DEXTER
na DMZ
107 for PORTA in 20 21 25 80 110 143 443 465 587 993 995; do
108 $IPT -t nat -A PREROUTING -d $IPVALIDO -p tcp -- dport $PORTA -j DNAT
-to - destination \ $DMZ : $PORTA
109 done
110 echo -e " Redirecionando Acesso ao Servidor Web \t\t\t $OK "
111 echo -e " Redirecionando Acesso ao Servidor MTA \t\t\t $OK "
112 echo -e " Redirecionando Acesso ao Servidor FTP \t\t\t $OK "
113
114 ## Redirecionando para o Servidor de DNS na DMZ
115 $IPT -t nat -A PREROUTING -d $IPVALIDO -p udp -- dport 53 -j DNAT --
to - destination $DMZ :53
116 echo -e " Redirecionando Acesso ao Servidor DNS \t\t\t $OK "
117 echo
118 echo " >>> Firewall ativado ! <<<"
119 echo
120 }
121 desativar () {
122 # ## Limpando as regras
123 $IPT -F
124 $IPT -X
125 $IPT -t nat -F
126 $IPT -t nat -X
127 $IPT -P INPUT ACCEPT
128 $IPT -P OUTPUT ACCEPT
129 $IPT -P FORWARD ACCEPT
131 echo -e " Limpando Regras da Tabela Filter \t\t\t $OK "
132 echo -e " Limpando Regras da Tabela NAT \t\t\t $OK "
133 echo -e " Definindo a pol í tica padr ão como ACCEPT \t\t\t $OK "
134 echo " >>> Firewall destativado ! <<<"
135 }

136 case " $1 " in

137 " start ") ativar ;;
138 " stop ") desativar ;;
139 *) echo " Use start para ativar ou stop para desativar o
firewall " ;;
140 esac
Para que ele seja iniciado junto com sistema quando a máquina for ligada, podemos
colocar o "script"nos níveis de execução:
1 root@firewall :/ etc / init .d# chmod +x firewall

2 root@firewall :/ etc / init .d# insserv -v firewall
3 root@firewall :/ etc / init .d# ls -l / etc / rc2 .d
Todas as regras que são feitas ficam na memória do computador. Caso ele seja
reiniciado, perderemos todas elas. Podemos utilizar os comandos "iptables-save"e
"iptables-restore".
1 root@firewall :# iptables - save

2 root@firewall :# iptables - save > / root / firewall
3 root@firewall :# service firewall stop
4 root@firewall :# iptables - restore / root / firewall
5 root@firewall :# iptables -nL ; sleep 5 ; iptables -t nat -n

Capítulo 14
Servidor OpenVPN
14.0.81 Cenário
Visto que a empresa DEXTER COURIER possui alguns colaboradores fora do am-
biente corporativo (home-office), ela precisa de uma forma segura para que eles
possam acessar a rede da empresa.
Com a flexibilidade das conexões proporcionadas com Internet hoje em dia, vimos
um crescente aumento de colaboradores que necessitam estar em muitos lugares e
ao mesmo tempo conectados na empresa. Para isto devemos montar uma estrutura
de VPN com autenticação criptografada, elevando assim a segurança dos acessos
externos.
14.0.83 Introdução Teórica
VPN (Virtual Private Network) é uma rede de comunicação particular, geralmente

utilizando canais de comunicação inseguros, como a "LAN"ou mesmo a WAN (Inter-
289
net). O que torna esta rede de comunicação particular é o fato das ferramentas de
"VPN"empregarem métodos e protocolos de criptografia, criando um túnel para pro-
ver acesso seguro a partes da rede ou mesmo ligação entre "LAN’s"geograficamente
separadas, eliminando a necessidade de um canal de comunicação privativo de alto
custo fornecido pela operadora de telecomunicações.
Também podemos utilizar uma ferramenta de "VPN"para implementar ou refor-

çar a segurança de acesso há algum serviço dentro de nossa rede.
Por exemplo, supomos que você possui um software de geração de notas fiscais
e os funcionários acessam este terminal via "telnet", que é um protocolo que não
implementa criptografia. Para corrigir esta situação e reforçar a segurança deste
ambiente, você poderia configurar uma "VPN"entre o computador dos usuários e o
servidor, melhorando assim a segurança deste serviço.
A VPN no passado já esteve associada a serviços remotos de conectividade, como

a Rede de Telefonia Pública Comutada (RTPC) ou os PVCs (Permanent Virtual
Circuits/Channel) do Frame Relay.

A VPN utiliza protocolos de tunelamento e procedimentos de encriptação, garantindo

a integridade e autenticidade dos dados.
14.0.84 Protocolos de tunelamento
Para se estabelecer um túnel é necessário que as suas extremidades utilizem o

mesmo protocolo de tunelamento. O tunelamento pode ocorrer na camada 2 ou
3 (respectivamente, enlace e rede) do Modelo de Referência OSI (Open Systems
Interconnection).
• Tunelamento em Nível 2 - Enlace - (PPP sobre IP)
O objetivo é transportar protocolos de nível 3, tais como o IP e IPX na Internet. Os

protocolos utilizam quadros como unidade de troca, encapsulando os pacotes da ca-

mada 3 (como IP/IPX) em quadros PPP (Point-to-Point Protocol). Como exemplos

podemos citar:
1.PPTP (Point-to-Point Tunneling Protocol) da Microsoft permite que o tráfego IP,

IPX e NetBEUI sejam criptografados e encapsulados para serem enviados através
de redes IP privadas ou públicas como a Internet;
2.L2TP (Layer 2 Tunneling Protocol) da IETF (Internet Engineering Task Force)

permite que o tráfego IP, IPX e NetBEUI sejam criptografados e enviados através de
canais de comunicação de datagrama ponto a ponto tais como IP, X25, Frame Relay
ou ATM.
3.L2F (Layer 2 Forwarding) da Cisco é utilizada para VPNs discadas. Tunelamento

em Nível 3 - Rede - (IP sobre IP)
Encapsulam pacotes IP com um cabeçalho adicional deste mesmo protocolo antes

de enviá-los através da rede.
O IP Security Tunnel Mode (IPSec) da IETF permite que pacotes IP sejam crip-
tografados e encapsulados com cabeçalho adicional deste mesmo protocolo para
serem transportados numa rede IP pública ou privada. O IPSec é um protocolo de-
senvolvido para IPv6, devendo, num futuro bem próximo, se constituir como padrão
para todas as formas de VPN. O IPSec sofreu adaptações possibilitando, também, a
sua utilização com o Ipv4. “
http://www.gta.ufrj.br/grad/00_1/pedro/vpns.htm
14.0.85 Arquitetura de VPNs
As VPNs podem ter as seguintes arquiteturas: gateway-gateway, host-to-host e host-

to-gateway.:

• Gateway-to-gateway: VPN criada para proteger a comunicação entre 2 redes,

por exemplo a rede da matriz de uma companhia interligada a rede de um
escritório da mesma companhia;
Host-to-host: VPN criada para proteger a comunicação entre dois computadores

específicos. Utilizada, geralmente, quando pequeno numero de usuários têm que
administrar remotamente um sistema;
Host-to-gateway: VPN criada para a proteção da conexão entre um ou mais usuá-

rios e uma rede específica, por exemplo, entre os funcionários longe da sede da
empresa e a rede da empresa.

http://www.gta.ufrj.br/grad/08_1/vpn/tiposarq.html
Nós trabalharemos neste laboratório com um par de chaves simétricas, ou seja,

usaremos a mesma chave tanto para o servidor "VPN"quanto para o cliente "VPN".
Logo, a chave deve ser gerada no servidor e replicada para o cliente via "SSH".
14.0.87 Configurando o servidor
O primeiro passo é instalar o software OpenVPN:
1 root@firewall :~ # aptitude install openvpn
Vamos gerar a chave:
1 root@firewall :~ # openvpn -- genkey -- secret / etc / openvpn / chave

Vamos gerar o arquivo de configuração do servidor:
1 root@firewall :~ # vim / etc / openvpn / server . conf

2 # Habilita suporte ao driver TUN / TAP ;
3 dev tun
4 # Endere ç os da VPN ( sempre na ordem local - remoto )
5 ifconfig 10.0.0.1 10.0.0.2
6 # Comando para chamar nossa chave criptografada e o local dela ;
7 secret / etc / openvpn / chave
8 # Define a porta que o OpenVPN vai rodar ;
9 port 5000
10 # Ativa suporte a compress ão;
11 comp - lzo
12 # Ní vel para depura ção de erros ;
13 verb 4
14 # Envia um ping a cada 10 segundos sem atividade e a VPN é
reiniciada depois de 120 segundos sem respostas ;
15 keepalive 10 120
16 # Assegura que o daemon mantenha as chaves carregadas , quando a VPN é
restabelecida depois de uma queda de conex ão;
17 persist - key
18 # Assegura que o daemon mantenha a interface tun aberta , quando a
VPN é restabelecida depois de uma queda de conex ão;
19 persist - tun
20 # Permite que o tú nel continue aberto mesmo que o endere ço IP da
outra má quina mude .
21 float
14.0.88 Configurando o cliente
Também é necessário ter o OpenVPN no cliente. Neste caso iremos usar a máquina
Squeeze para teste da VPN:

1 root@firewall :~ # aptitude install openvpn
Vamos entrar no diretório "/etc/openvpn"e copiar a chave do servidor:
1 root@squeeze :~ # cd / etc / openvpn

2 root@squeeze :/ etc / openvpn # scp - P50000 \
3 200.100.50. X :/ etc / openvpn / chave .
Vamos gerar o arquivo de configuração do cliente:
1 root@squeeze :~ # vim / etc / openvpn / client . conf

2 dev tun
3 ifconfig 10.0.0.2 10.0.0.1
4 # Endere ço do servidor VPN
5 remote 200.100.50. X
6 secret / etc / openvpn / chave
7 port 5000
8 comp - lzo
9 verb 4
10 keepalive 10 120
11 persist - key
12 persist - tun
13 float
Vamos iniciar a "VPN"no servidor... quanto no cliente.
1 root@firewall :~ # openvpn -- config / etc / openvpn / server . conf

2 Fri Aug 19 04:41:47 2011 us =606727 Local Options hash ( VER = V4 ): ’099
d04aa ’
3 Fri Aug 19 04:41:47 2011 us =606727 Expected Remote Options hash ( VER
= V4 ): ’ f1025742 ’
4 Fri Aug 19 04:41:47 2011 us =606728 UDPv4 link local ( bound ): [ undef ]

5 Fri Aug 19 04:41:47 2011 us =606728 UDPv4 link remote : [ undef ]

6 Fri Aug 19 04:42:10 2011 us =340543 Peer Connection Initiated with [
AF_INET ]192.168. X .10:5000
7 Fri Aug 19 04:42:10 2011 us =340617 Initialization Sequence Completed
Agora do lado do cliente:
1 root@squeeze :~ # openvpn -- config / etc / openvpn / client . conf

2 Fri Aug 19 04:42:12 2011 us =678990 Local Options hash ( VER = V4 ): ’
f1025742 ’
3 Fri Aug 19 04:42:12 2011 us =679035 Expected Remote Options hash ( VER
= V4 ): ’099 d04aa ’
4 Fri Aug 19 04:42:12 2011 us =679101 UDPv4 link local ( bound ): [ undef ]
5 Fri Aug 19 04:42:12 2011 us =679138 UDPv4 link remote : [ AF_INET
]192.168. X .1:5000
6 Fri Aug 19 04:42:19 2011 us =833812 Peer Connection Initiated with [
AF_INET ]192.168. X .1:5000
7 Fri Aug 19 04:42:19 2011 us =833936 Initialization Sequence Completed
Execute um "ifconfig"para ver se a interface tun0 foi criada:
1 root@firewall :~ # ifconfig | tail -n9

2 tun0 Link encap :Não Especificado Endere ço de HW
00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00
3 inet end .: 10.0.0.1 P -a -P :10.0.0.2 Masc :255.255.255.255
4 UP POINTOPOINT RUNNING NOARP MULTICAST MTU :1500 Mé trica
:1
5 RX packets :0 errors :0 dropped :0 overruns :0 frame :0
6 TX packets :0 errors :0 dropped :0 overruns :0 carrier :0
7 colis õ es :0 txqueuelen :100
8 RX bytes :0 (0.0 B) TX bytes :0 (0.0 B)

14.0.89 Certificados vpn
O OpenVPN oferece vários mecanismos para adicionar camadas adicionais de segu-

rança, como por exemplo rodar em chroot, uso de conexões TLSs, certificados, uso
de chaves com maiores bits. Todas essas camadas previnem ataques como “Man in
the Middle”, “DoS”, “Flooding”, “Port scanning” e “Buffer overflow”.
Vamos deixar o OpenVPN sem privilégios de root . Para isto adicione no final
da configuração do servidor e cliente as opções “user” e “group”, assim o
OpenVPN será executado como usuário nobody e grupo nogroup.

2 ...
3 # Remo ção dos privil é gios de root na conex ão VPN
4 user nobody
5 group nogroup
Faça o mesmo para no cliente:

2 ...
3 # Remo ção dos privil é gios de root na conex ão VPN
4 user nobody
5 group nogroup
14.0.90 TLS-Auth HMAC
Você pode adicionar uma assinatura que será verificada antes do processamento
de todos os pacotes UPD. Em nossa configuração do servidor vamos habilitar as
seguintes opções:

• tls-auth - Habilita o controle de conexões tls;
• tls-server - Ajuda a bloquear ataques DoS e flooding na porta do OpenVPN;
• ca - Certificado de autoridade (CA) que usa as bibliotecas do OpenSSL;
• cert - Certificado do servidor;
• key - Chave RSA de 2048 do servidor;
• dh - Parâmetros Diffie-Hellman utilizado para a troca das chaves criptografadas

durante a execução;
• cipher - Define um tipo de criptografia maior.
Para gerar os certificados e chaves, o OpenVPN traz junto à sua instalação uma série
de scripts chamados “easy-rsa”. Eles podem ser encontrados em /usr/share/doc/openvpn/examples
rsa/2.0/
1 root@firewall :~ # ls -lh / usr / share / doc / openvpn / examples / easy - rsa

/2.0/
Veja que na lista de scripts cada um tem uma função específica para criação de
certificados e chaves. Vamos copiar o diretório com os scripts para nossa instalação
do OpenVPN :
1 root@firewall :~ # cp -a / usr / share / doc / openvpn / examples / easy - rsa /2.0

2 / etc / openvpn /
Acesse o diretório com os scripts copiados e crie o subdiretório onde serão armaze-
nadas as chaves e certificado:

1 root@firewall :~ # cd / etc / openvpn /2.0

2 root@firewall :/ etc / openvpn /2.0 # mkdir keys
14.0.91 Gerando certificado CA e chave RSA
Utilizando os scripts vamos gerar os certificados e chaves, que serão utilizados em

nossa configuração do OpenVPN. Instale o pacote openssl, abra o arquivo “vars” e
deixe-o conforme modelo:
1 root@firewall :/ etc / openvpn /2.0 # aptitude install openssl

2 root@firewall :/ etc / openvpn /2.0 # vim vars
3 export KEY_SIZE =2048
4 export KEY_COUNTRY =" BR "
5 export KEY_PROVINCE =" SP "
6 export KEY_CITY =" SaoPaulo "
7 export KEY_ORG =" DEXTER "
8 export KEY_EMAIL =" root@dexter . com . br "
Use a sequência de comandos abaixo para gerar o certificado de autoridade:
1 root@firewall :/ etc / openvpn /2.0 # source vars

2 root@firewall :/ etc / openvpn /2.0 # ./ clean - all
3 root@firewall :/ etc / openvpn /2.0 # ./ build - ca
4 ...
5 Country Name (2 letter code ) [ BR ]: BR
6 State or Province Name ( full name ) [ SP ]: São Paulo
7 Locality Name (eg , city ) [ SaoPaulo ]: SaoPaolo
8 Organization Name (eg , company ) [ DEXTER ]: DEXTER
9 Organizational Unit Name (eg , section ) []: TI
10 Common Name (eg , your name or your server ’s hostname )[ DEXTER CA ]:
Admin

11 Name : Tux
12 Email Address [ root@dexter . com . br ]: root@dexter . com . br
13
14 root@firewall :/ etc / openvpn /2.0 # ./ build - key - server server
15 ...
17 State or Province Name ( full name ) [ SP ]: SP
18 Locality Name (eg , city ) [ SaoPaulo ]: SaoPaulo
20 Organizational Unit Name (eg , section ) []: Admin
21 Common Name (eg , your name or your server ’s hostname ) [ server ]:
22 Name []:
24 ...
25 Certificate is to be certified until Aug 16 08:41:49 2021 GMT (3650
days )
26 Sign the certificate ? [y/n ]: y
27
28 1 out of 1 certificate requests certified , commit ? [y/n]y
29 Write out database with 1 new entries
30 Data Base Updated
Liste o conteúdo do subdiretório keys e verifique o arquivo de certificado do servidor

(server.csr), o arquivo da chave do servidor (server.key) e o certificado auto assinado
(server.crt). Depois dê as devidas permissões de acesso:
1 root@firewall :/ etc / openvpn /2.0 # ls -lh keys / server *

2 -rw -r --r -- 1 root root 5 ,3 K Ago 19 05:42 keys / server . crt
3 -rw -r --r -- 1 root root 1 ,1 K Ago 19 05:41 keys / server . csr
4 -rw ------- 1 root root 1 ,7 K Ago 19 05:41 keys / server . key
5 root@firewall :/ etc / openvpn /2.0 # chmod 775 keys / server *

14.0.92 Gerando parâmetros Diffie-Hellman
Os parâmetros Diffie-Hellman são utilizados para a troca das chaves criptografadas

durante a execução do OpenVPN. Use o script abaixo para gerar os parâmetros:
1 root@firewall :/ etc / openvpn /2.0 # ./ build - dh

2 Generating DH parameters , 2048 bit long safe prime , generator 2
3 This is going to take a long time
Liste o conteúdo do subdiretório keys e verifique o arquivo com os parâmetros Diffie-

Hellman (dh2048.pem).
1 root@firewall :/ etc / openvpn /2.0/ keys # ls d *. pem

2 -rw -r --r -- 1 root root 424 Ago 19 05:48 dh2048 . pem
14.0.93 Configurando o servidor OpenVPN
Com os certificados e chaves gerados, abra o arquivo do servidor e adicione no

final as opções abaixo:

2 ...
3 # Configurando o certificado da VPN
4 tls - server
5 tls - auth chave 0
6 ca 2.0/ keys / ca . crt
7 cert 2.0/ keys / server . crt
8 key 2.0/ keys / server . key
9 dh 2.0/ keys / dh2048 . pem
10 cipher DES - EDE3 - CBC

Ainda na máquina servidor crie a chave e o certificado para a máquina cliente, com
o hostname da máquina cliente.
1 root@firewall :/ etc / openvpn /2.0/ keys # ./ build - key client

2 ...
4 State or Province Name ( full name ) [ SP ]: SP
5 Locality Name (eg , city ) [ SaoPaulo ]: SaoPaulo
7 Organizational Unit Name (eg , section ) []: TI
8 Common Name (eg , your name or your server ’s hostname ) [ client ]:
9 Name []:
11 ...
12 Sign the certificate ? [y/n ]: y
13 1 out of 1 certificate requests certified , commit ? [y/n]y
14 Write out database with 1 new entries
15 Data Base Updated
Faça a cópia dos arquivos abaixo via ssh para a máquina cliente.:
1 root@firewall :~ # cd / etc / openvpn /2.0/ keys

2 root@firewall :/ etc / openvpn /2.0/ keys # scp - P50000 client . key client .
crt \
3 ca . crt root@200 .100.50. X :/ etc / openvpn
Agora na máquina “Squeeze” , adicione no final do arquivo “client.conf”:

2 ...
3 # Configurando o certificado da VPN
4 ns - cert - type server
5 tls - client

6 tls - auth chave 1

7 ca ca . crt
8 cert client . crt
9 key client . key
10 cipher DES - EDE3 - CBC
Descrição das novas opções utilizadas:
• ns-cert-type -> Indica que certificado foi assinado pelo servidor;
• tls-client -> Habilita conexão TLS, ajudando a bloquear ataques DoS e flooding
na porta do OpenVPN.
Execute no servidor:
1 root@firewall :~ # service openvpn start
Execute no cliente:
1 root@squeeze :~ # service openvpn start
Checando a conexão no servidor...
1 root@firewall :~ # ifconfig
00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00
3 inet end .: 10.0.0.1 P -a -P :10.0.0.2 Masc :255.255.255.255
. . . e no cliente:

1 root@firewall :~ # ifconfig
00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00
3 inet end .: 10.0.0.2 P -a -P :10.0.0.1 Masc :255.255.255.255

Capítulo 15
Referências Bibliográficas
Julio Cesar Neves. Programação em Shell Linux. 6.ª edição. Brasport. 2006
The Linux documentation Project, website: http://www.tldp.org. Acesso em 28 de

março de 2008.
Pritchard, Pessanha, Langfeldt, Stranger and Dean. Certificação Linux LPI 2.ª edi-
ção. AltaBooks. 2007
Gagné, Moving to Linux.
1ª edição, Addilson Wesley
Rubem E. Ferreira, Guia de Administração Linux.
2ª edição, Novatec, 2008
Nelson Mendonça e Tiago Vilas Boas. GNU Linux.
Editora Brasport.
Sites pesquisados:
307
http://www.dicas-l.com.br
http://www.vivaolinux.com.br
http://pt.wikipedia.org/wiki/Sudo
http://wiki.ubuntu-br.org/RootSudo
http://pt.wikipedia.org/wiki/Pluggable_Authentication_Modules
http://ajmoreti.blogspot.com/2011/09/entendendo-e-configurando-o-pam.html
http://gnulinuxbr.com/2010/04/01/pam/
http://www.prefirolinux.com/pam/65-limitando-usuarios-com-o-pam.html
http://web.mit.edu/rhel-doc/3/rhel-sag-pt_br-3/s1-dhcp-configuring-server.html
http://www.isc.org/sw/dhcp/.
http://pt.wikipedia.org/wiki/Network-Attached_Storage
http://computerworld.uol.com.br/tecnologia/2007/10/30/ idgnoticia.2007-10-29.3996045044/
http://pt.wikipedia.org/wiki/Direct_Attached_Storage
http://pt.wikipedia.org/wiki/RAID
http://web.mit.edu/rhel-doc/3/rhel-sag-pt_br-3/s1-raid-approaches.html
http://placa-pai.blogspot.com/2011/02/raid-6.html
wester.com/linuxsamba.php
http://www.gta.ufrj.br/grad/99_1/guilherme/DNS_HTML/historia.htm

http://www.cooperati.com.br/wordpress/2011/10/20/dns-domain-name-system/
http://gnulinuxbr.com/2010/05/04/domain-name-system-servidor-dns-no-debian-parte-
1/
http://gnulinuxbr.com/2010/05/06/domain-name-system-%E2%80%93-servidor-dns-no-
debian-%E2%80%93-parte-2/
http://gnulinuxbr.com/2010/05/17/domain-name-system-%E2%80%93-servidor-dns-no-
debian-%E2%80%93-parte-3/
http://gnulinuxbr.com/2010/05/20/servidor-apache-no-debian-parte-1/
http://pt.kioskea.net/contents/crypto/ssl.php3
http://en.wikipedia.org/wiki/Secure_Sockets_Layer
http://www.prefirolinux.com/forum/viewtopic.php?f=2&t=12
http://www.vivaolinux.com.br/artigo/OpenLDAP-com-suporte-ao-MySQL

Integracao ContinuaServidor DNS

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

Integracao ContinuaServidor DNS

Enviado por

Direitos autorais:

Formatos disponíveis

452

Linux Network Servers

ence GED - ECM

Integração Continua PostgreSQL Monitoramento Alta Disponibilidade

Virtualização Groupware Yj Backup Infraestrutura Web

Auditoria e Análise Segurança Ensino à Distância Implantação garantida

1 Cenário e Propostas de Solução 1

2 Implementando Hardening e PAM em seu Servidor GNU/Linux 5

5 Implementando RAID + LVM 57

7 Servidor DNS 109

Página ii Linux Network Servers

7.0.23 Desativar recursão externa . . . . . . . . . . . . . . . . . . . 144

8 Servidor Apache 147

9 Servidor FTP 185

10 Servidor Postfix 197

Linux Network Servers Página iii

11 Servidor OpenLDAP 231

12 Servidor Proxy com Squid 247

Página iv Linux Network Servers

14 Servidor OpenVPN 289

15 Referências Bibliográficas 307

Linux Network Servers Página v

Cenário e Propostas de Solução

1.0.1 Cenário normalmente encontrado nas empresas

Todos sabemos que a área de TI (Tecnologia da Informação) de algumas empresas

O ambiente comumente utilizado nas pequenas e médias empresas é composto por

e banco de dados. Podemos observar isto na próxima figura.

Página 2 Linux Network Servers

Coloque os endereços Ips que irá utilizar durante o curso

1 eth0 => IP 200.100.50. ___ eth1 => IP 192.168. ___ .1

Linux Network Servers Página 3

5 IP 192.168. ___ .3 IP 192.168. ___ .2

Página 4 Linux Network Servers

Implementando Hardening e PAM em

2.0.4 Proposta de solução

A fim de atender às necessidades da empresa DEXTER COURIER , iremos aplicar

2.0.5 Introdução teórica – Ajustes iniciais

1 root@debian :~ # vi / etc / network / interfaces

Página 6 Linux Network Servers

Na distro RedHat: # vim /etc/sysconfig/network/ifcfg-eth0

2.0.7 Configurando a resolução de nomes

Edite o arquivo “/etc/resolv.conf” para colocarmos o endereço do servidor DNS que

1 root@debian :~ # vi / etc / resolv . conf

2.0.8 Configuração do Hostname

Em um servidor, a configuração correta do “hostname” e do arquivo “hosts” é essen-

1 root@debian :~ # vi / etc / hostname datacenter

Depois vamos parar e iniciar o serviço do hostname:

1 root@debian :~ # / etc / init .d/ hostname . sh

Faça o logout e efetue o login. Cairá no prompt já alterado!

Linux Network Servers Página 7

Edite o arquivo de /etc/hosts e adicione a linha em negrito:

1 root@datacenter :~ # vi / etc / hosts

2.0.9 Configurando o repositório de rede

Para instalar programas no “Debian GNU/Linux”, é necessário que o repositório de

1 root@datacenter :~ # vi / etc / apt / sources . list

Depois de configurado, faça o “update” do banco de dados do “aptitude”:

1 root@datacenter :~ # aptitude update

Vamos agora efetuar a atualização do servidor com o comando:

1 root@datacenter :~ # aptitude upgrade

Página 8 Linux Network Servers

1 root@datacenter :~ # aptitude install build - essential module -

1 root@datacenter :~ # vim / etc / vim / vimrc

Visto que o VIM não é o editor padrão do sistema, vamos configurá-lo:

1 eth0 => IP 200.100.50. _ eth1 => IP 192.168. _ .1

5 IP 192.168. _ .3 IP 192.168. _ .2