Apostila452 Cardapio QRcode

1.
2.
3.
4.
5.
6.
7.
8.
Linux Network Servers

452
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
http://va.mu/F http://va.mu/EuiT 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
-2
Sumário
Capítulo 1
Cenário e Propostas de Solução................................................................................................. 9
1.1. Objetivos......................................................................................................................... 9
1.2. Cenário normalmente encontrado nas empresas.........................................................10
1.3. Cenário.......................................................................................................................... 10
Capítulo 2
Instalando seu Servidor GNU/Linux no volume RAID+LVM....................................................13
2.1. Objetivos....................................................................................................................... 13
2.2. Cenário.......................................................................................................................... 14
2.3. Proposta de solução...................................................................................................... 14
2.4. Introdução Teórica - RAID............................................................................................. 14
2.4.1. Tipos de RAID...................................................................................................................... 16
2.4.2. Combinações de RAID......................................................................................................... 20
2.5. Introdução Teórica – LVM............................................................................................. 23
2.6. Laboratório.................................................................................................................... 25
Capítulo 3
Implementando Hardening + PAM em seu Servidor GNU/Linux............................................38
3.1. Objetivos....................................................................................................................... 38
3.2. Cenário.......................................................................................................................... 39
3.4. Introdução teórica – Ajustes iniciais............................................................................. 39
3.5. Laboratório.................................................................................................................... 39
3.6. Configurando a resolução de nomes............................................................................. 40
3.7. Configuração do Hostname........................................................................................... 40
3.8. Configurando o repositório de rede.............................................................................. 41
3.9. Introdução teórica - Hardening..................................................................................... 43
3.10. Laboratório.................................................................................................................. 44
3.10.1. Protegendo o sistema com bloqueios na partição..............................................................44
3.10.2. Configurando o SUDO....................................................................................................... 45
3.10.3. Configurando o SSH.......................................................................................................... 46
3.10.4. Configurando uma senha no GRUB2.................................................................................47
3.10.5. Melhorando nossas senhas................................................................................................ 48
3.10.6. Verificando portas e encerrando programas desnecessários............................................49
3.10.7. Bloqueando o CTRL+ALT+DEL......................................................................................... 50
3.10.8. Bloqueando as funções do SysRq......................................................................................51
-3
3.10.9. Logando o comando SU..................................................................................................... 52

3.11. Introdução teórica - PAM............................................................................................ 53
3.11.1. Tipos de PAM..................................................................................................................... 53
3.12. Módulos do PAM......................................................................................................... 54
3.13. Controles do PAM........................................................................................................ 54
3.14. Laboratório.................................................................................................................. 55
3.15. Extra – Servidor NTP.................................................................................................. 64
3.16. Extra – Cliente NTP..................................................................................................... 64
Capítulo 4
Servidor DHCP......................................................................................................................... 66
4.1. Objetivos....................................................................................................................... 66
4.2. Cenário.......................................................................................................................... 67
4.4. Introdução teórica......................................................................................................... 67
4.5. Laboratório.................................................................................................................... 69
4.5.1. Principais diretrizes do arquivo de configuração................................................................70
4.5.2. Configurando os LOGs......................................................................................................... 71
4.5.3. Configurando os clientes DHCP.......................................................................................... 72
4.6. Fixar IP via DHCP......................................................................................................... 72
4.6.1. Configurações adicionais..................................................................................................... 73
Capítulo 5
Servidor NFS............................................................................................................................ 76
5.1. Objetivos....................................................................................................................... 76
5.2. Cenário.......................................................................................................................... 77
5.5. Conhecendo o NAS....................................................................................................... 78
5.6. NAS versus SAN ........................................................................................................... 79
5.7. E o DAS?....................................................................................................................... 81
5.8. Laboratório.................................................................................................................... 81
5.8.1. Configurando o Servidor..................................................................................................... 81
5.8.2. Configurando o Cliente ....................................................................................................... 85
Capítulo 6
Implementando RAID + LVM................................................................................................... 87
6.1. Objetivos....................................................................................................................... 87
6.3. Laboratório – RAID........................................................................................................ 88
6.3.1. Configurando o RAID-0........................................................................................................ 91
-4
6.3.2. Configurando o RAID-1........................................................................................................ 95

6.3.3. Configurando o RAID-5...................................................................................................... 102
6.4. Laboratório – LVM....................................................................................................... 105
Capítulo 7
Servidor Samba...................................................................................................................... 117
7.1. Objetivos..................................................................................................................... 117
7.2. Cenário 1..................................................................................................................... 118
7.3. Proposta de solução 1................................................................................................. 118
7.4. Cenário 2 .................................................................................................................... 118
7.6. Cenário 3..................................................................................................................... 119
7.8. Introdução teórica....................................................................................................... 120
7.9. Laboratório 1............................................................................................................... 121
7.10. Laboratório 2............................................................................................................. 126
7.11. Laboratório 3............................................................................................................. 140
7.11.1. Adicionando máquina Windows XP ao PDC Samba.........................................................150
7.11.2. Adicionando máquina Windows 7 ao PDC Samba ..........................................................152
7.11.3. Adicionando máquina GNU/Linux ao PDC Samba...........................................................157
7.11.4. Configurando quota no servidor Storage.........................................................................160
7.11.5. Configurando quota no servidor Datacenter para o Samba............................................161
Capítulo 8
Servidor DNS......................................................................................................................... 164
8.1. Objetivos..................................................................................................................... 164
8.2. Cenário........................................................................................................................ 165
8.3. Proposta de solução.................................................................................................... 165
8.4.1. Características................................................................................................................... 167
8.5. Resolução.................................................................................................................... 168
8.5.1. Resolução Recursiva.......................................................................................................... 168
8.5.2. Resolução Iterativa............................................................................................................ 170
8.6. O arquivo "/etc/hosts"................................................................................................. 170
8.7. Ferramentas de consulta............................................................................................. 171
8.8. Prática dirigida........................................................................................................... 173
8.9. Introdução ao BIND + Laboratório............................................................................. 181
8.10. BIND como servidor cache........................................................................................ 183
8.11. Restringindo consultas.............................................................................................. 185
8.12. Servidor de zonas...................................................................................................... 186
-5
8.12.1. Tipos de zonas e Registros.............................................................................................. 186

8.13. Configuração do DNS primário................................................................................. 189
8.13.1. Configurando o RNDC..................................................................................................... 195
8.14. Configurando o DNS reverso.................................................................................... 199
8.15. Configurando o DNS secundário............................................................................... 200
8.16. Desativar recursão externa....................................................................................... 204
8.17. SPF - Sender Policy Framework................................................................................ 204
8.18. Mais testes................................................................................................................ 205
8.18.1. Arrumando o DHCP......................................................................................................... 205
Capítulo 9
Servidor Apache..................................................................................................................... 207
9.1. Objetivos..................................................................................................................... 207
9.2. Cenário........................................................................................................................ 208
9.3. Proposta de solução.................................................................................................... 208
9.5. MPM PreFork e MPM Worker .................................................................................... 209
9.5.1. MPM Pre Fork .................................................................................................................. 209
9.5.2. MPM Worker ..................................................................................................................... 209
9.5.3. O que é o Moodle? ............................................................................................................ 210
9.6. Laboratório.................................................................................................................. 210
9.7. Conhecendo a estrutura do Apache............................................................................211
9.7.1. Ajustes dos módulos Worker e PreFork............................................................................213
9.8. Suporte a PHP............................................................................................................. 214
9.9. Arrumando os diretórios............................................................................................. 215
9.10. Configurando o “php.ini”.......................................................................................... 217
9.11. VirtualHost? ............................................................................................................. 218
9.12. Criando Virtualhost para nossos domínios................................................................218
9.13. Fechando brechas de segurança............................................................................... 219
9.14. Configurando o Moodle............................................................................................. 221
9.15. Disponibilizando o site da Dexter Courier................................................................228
9.16. Ativando o SSL.......................................................................................................... 228
9.16.1. O que é um certificado digital? .......................................................................................229
9.16.2. Gerando o site seguro da Dexter.....................................................................................229
9.16.3. Gerando o site seguro do Mandark EaD..........................................................................235
9.17. Ativando o controle de banda................................................................................... 237
Capítulo 10
Servidor FTP.......................................................................................................................... 240
10.1. Objetivos................................................................................................................... 240
-6
10.2. Cenário...................................................................................................................... 241

10.3. Proposta de solução.................................................................................................. 241
10.4. Introdução teórica..................................................................................................... 241
10.5. Laboratório................................................................................................................ 243
10.6. Comandos em modo texto do FTP.............................................................................246
10.7. Cliente gráfico para FTP........................................................................................... 248
Capítulo 11
Servidor Postfix...................................................................................................................... 250
11.1. Objetivos................................................................................................................... 250
11.2. Cenário...................................................................................................................... 251
11.5. Introdução ao Postfix ............................................................................................... 252
11.6. Características do Postfix.......................................................................................... 253
11.7. Laboratório................................................................................................................ 253
11.7.1. MDA Courier - POP3 e IMAP para os clientes.................................................................259
11.7.2. Criando caixas postais..................................................................................................... 260
11.7.3. Criando alias no Postfix................................................................................................... 264
11.7.4. Configurando o Webmail................................................................................................. 266
11.7.5. Autenticando os usuários de e-mail.................................................................................273
11.7.6. Ativando maior segurança com TLS................................................................................274
Capítulo 12
Servidor OpenLDAP............................................................................................................... 284
12.1. Objetivos................................................................................................................... 284
12.2. Cenário...................................................................................................................... 285
12.5. Laboratório................................................................................................................ 288
12.5.1. O que é um LDIF? ........................................................................................................... 290
12.6. Backup da base de dados ......................................................................................... 296
Capítulo 13
Servidor Proxy com Squid...................................................................................................... 298
13.1. Objetivos................................................................................................................... 298
13.2. Cenário...................................................................................................................... 299
13.4. Introdução Teórica.................................................................................................... 299
13.5. Proxy Manual............................................................................................................ 300
-7
13.6. Proxy Transparente................................................................................................... 300

13.7. ACL - Access Control Lists........................................................................................ 301
13.8. Definindo ACL .......................................................................................................... 301
13.9. Tipos de ACL............................................................................................................. 302
13.10. Regras das ACLs..................................................................................................... 304
13.11. Laboratório.............................................................................................................. 304
13.12. Criando a estrutura do Squid.................................................................................. 308
13.13. Filtrando acessos com "Squid"................................................................................ 308
13.14. Blacklist e Whitelist................................................................................................ 313
13.15. Autenticação NCSA................................................................................................. 314
13.16. Auditoria de acesso com SARG............................................................................... 317
13.17. Squidguard ............................................................................................................. 320
13.18. Delay_pools ............................................................................................................ 324
13.18.1. Classes de Delay_pools ................................................................................................. 324
13.19. Autenticação via OpenLDAP .................................................................................. 326
Capítulo 14
Firewall.................................................................................................................................. 327
14.1. Objetivos................................................................................................................... 327
14.2. Cenário...................................................................................................................... 328
14.5. Revisando os conceitos de Rede............................................................................... 329
14.6. TTL ........................................................................................................................... 331
14.7. Tabelas do Iptables................................................................................................... 333
14.8. O que é uma chain? .................................................................................................. 334
14.9. Compreendendo as políticas básicas e o conceito das exceções..............................334
14.10. Laboratório.............................................................................................................. 336
14.11. Firewall como "gateway" de rede...........................................................................340
14.12. Script de firewall..................................................................................................... 342
Capítulo 15
Servidor OpenVPN................................................................................................................. 345
15.1. Objetivos................................................................................................................... 345
15.2. Cenário...................................................................................................................... 346
15.4. Introdução Teórica.................................................................................................... 346
15.5. Protocolos de tunelamento........................................................................................ 347
15.6. Arquitetura de VPNs ................................................................................................ 348
-8
15.7. Laboratório................................................................................................................ 349

15.7.1. Configurando o servidor.................................................................................................. 349
15.8. Configurando o cliente.............................................................................................. 350
15.9. Certificados vpn ....................................................................................................... 352
15.10. Tls-auth HMAC ....................................................................................................... 353
15.11. Gerando certificado CA e chave RSA .....................................................................354
15.12. Gerando parâmetros Diffie-Hellman ......................................................................357
15.13. Configurando o servidor OpenVPN ........................................................................358
REFERÊNCIAS
BIBLIOGRÁFICAS.................................................................................................................. 361
Índice de tabelas
Índice de Figuras
Capítulo 1 Cenário e Propostas de Solução - 9
Capítulo 1
Cenário e Propostas de Solução
1.1. Objetivos
• Conhecer o cenário encontrado no dia a dia das empresas;
• Conhecer e entender o cenário praticado com Software Livre;

1.2. 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 empresa. 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.3. 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 e banco de dados. Podemos observar isto na próxima figura.
Partindo deste cenário, iremos migrar toda a tecnologia para a plataforma

livre, conforme exemplificado na próxima figura.
Além das tecnologias exibidas na figura acima, podemos ainda implementar

redundâ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!
Capítulo 2
Instalando seu Servidor GNU/Linux no
volume RAID+LVM
2.1. Objetivos
• Como o cenário interfere em suas decisões;
• Entender o conceitos de RAID e LVM;
• Instalar o servidor no volume RAID+LVM;

Capítulo 2 Instalando seu Servidor GNU/Linux no volume RAID+LVM - 13
2.2. Cenário
A empresa DEXTER COURIER precisa montar seus servidores sem ter que se
preocupar com problemas nos discos rígidos e paralisações em suas atividades. Além
disto, a empresa não tem previsão inicial de crescimento, por isto não saberá dizer
como dividir o espaço nos discos.
2.3. Proposta de solução
A fim de solucionar eventuais paradas do servidor, instalaremos o sistema

GNU/Linux com redundância nos discos, ou seja, em cima de um volume RAID-1.
Como a empresa DEXTER não concluiu suas metas de crescimento, devemos
planejar a expansão no volume dos dados. Para que não haja troca de discos, backup,
formatações e todos os processos que envolvem mudanças de disco, vamos instalar o
sistema GNU/Linux sobre um volume LVM montado em cima do RAID-1, pois caso
haja qualquer tipo de redimensionamento nas partições, poderemos fazer isto de
forma rápida e segura.
2.4. Introdução Teórica - RAID
RAID, do inglês Redundant Array of Independent Disks, significa

Conjunto Redundante 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 desempenho 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.
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 de uma falha de 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.
2.4.1. 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ância. 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 praticamente 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.
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.
Características do RAID 0:
* Excelente gravação e leitura;
* Aproveitamento total de espaço;
* Nenhuma redundância!
• RAID 1 (Mirroring): O nível mais utilizado. Sua principal finalidade é prover

redundâ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 mantendo 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 partes 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.
RAID1 é backup? Não!!!!! É apenas redundância.
DICA DE SEGURANÇA: “RAID 1” espelhado não é backup. Se você apagar

um arquivo acidentalmente, esse arquivo vai ser apagado em todos os
discos. Sempre tenha uma CÓPIA dos dados.
Características do RAID 1:
* Redundância: se um dos discos falhar, o sistema continua funcionando;
* Você vai precisar de 2 HDs, mas só vai usar a área útil de um;
* 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.
A “mágica” do “RAID 5” está justamente na divisão e distribuição destes

blocos. Numa composição de três discos, os dados serão divididos em dois blocos,
“A1” e “B1”, sendo que os bits destes dois blocos serão comparados através de um
“XOR”, que é um identificador de exclusividade. O resultado será gravado no
terceiro volume como “P1”. Além disto, os blocos de paridade são alternadamente
gravados em cada disco, aumentando a tolerância.
• Exemplo:
A1 B1 P1
A2 P2 C2
P3 B3 C3
Qualquer um dos discos que falhar pode ser rapidamente reconstruído através
de novas operações “XOR” entre os dados restantes. Tomemos por exemplo “A1 =
01001100” e “B1 = 10100101”.
01001100 XOR
10100101
--------
11101001
Agora suponha que o bloco “B1” foi perdido. Para recuperá-lo, basta aplicar um
“XOR” entre “A1” e “P1”.
01001100 XOR
00010110
--------
01011010
A operação XOR significa que se são iguais "0 e 0" ou "1 e 1", então o resultado
é verdadeiro (0). Se houver mais de dois blocos para serem comparados, calcule a
paridade dos dois primeiros e com o resultado compare com o terceiro, e assim
sucessivamente. A principal desvantagem do “RAID 5” é o custo de processamento
da paridade. Portanto, “RAID 5” é menos eficiente na gravação que seus
antecessores.
A quantidade mínima de discos no “RAID 5” é 3, podendo suportar qualquer

número maior que 3, mesmo para discos de tamanhos diferentes. O volume
disponível para armazenamento é dado pela equação “(Q-1)*Dmenor”, onde Q é a
quantidade de discos, e “Dmenor” o tamanho do menor disco.
• RAID 6: É um padrão relativamente novo, suportado por apenas algumas

controladoras. 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

discos, 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 espaç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

normalmente 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.
2.4.2. 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 transferê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
armazenamento 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

dados 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 rendimento 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. No RAID 0+1, se um dos discos vier a falhar, 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, porém deixando de
ser RAID 0 + 1.
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

performance.
• 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.
2.5. 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 (um volume pode ser usado inclusive como
partição swap). 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
necessá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.
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
relação ao usuário, o mesmo nem saberá que tem toda esta estrutura por trás da
manipulação dos dados!
2.6. Laboratório
Após a introdução teórica, vamos realizar a instalação do sistema Debian

GNU/Linux versão 6.0 (codinome Squeeze), sobre um volume RAID + LVM.
Siga normalmente com a instalação, mas observe alguns detalhes importantes!

Uma dica importante sobre a instalação do Debian é NÃO configurar a rede

durante a instalação, pois ele baixa as atualizações, fazendo com que demore algum
tempo para seu término! Após detectar o hardware de rede, cancele o processo.
No decorrer da instalação, configure a conta de ROOT com a senha “123456” e

uma conta de usuário comum com login INFRA e senha “123456”. Depois da
instalação e hardening podemos alterar as senhas.
Agora vamos particionar os discos e configurá-los para trabalharem com RAID

e LVM. Para isto escolha o particionamento MANUAL.
Lembamos que o RAID funciona pareando as partições, por isso temos que criá-
las. Vamos utilizar como exemplo 2 discos de 80GB, fazendo uma partição /dev/sda1
e uma Swap no disco1 e uma partição /dev/sdb1 e uma Swap no disco2. O tipo de
partição usada em /dev/sdX1 será “Volume físico para RAID”. Veja:
Faça a mesma configuração no disco 2. Ficará desta forma:

Após isto, selecione “Configurar RAID via software” -> “Criar dispositivo MD”
Informe o nível de RAID desejado. No nosso caso será o RAID-1
Informe o número de dispositivos para o RAID...
... e depois os discos de SPARE.

Selecione as partições para o RAID-1.
Finalize esta etapa!!!!
Agora vamos configurar o LVM. Selecione a opção correspondente.

Selecione a opção “Criar grupo de volume”
E defina um nome para este grupo de volume...
… bem como qual será o “disco” a ser utilizado! No nosso caso iremos utilizar o
volume RAID-1 /dev/md0, previamente configurado.
Feito isto, selecione “Criar volume lógico”
Escolha de qual VG deverá ser utilizado o espaço.
Informe um nome para o volume lógico, como no exemplo lv_raiz

E conclua com o tamanho do volume.
Crie mais 3 volumes lógicos, sendo eles o lv_var com 2GB, o lv_srv com 5GB e o
lv_tmp com 1GB, conforme exibido no resumo abaixo:
Selecione Finalizar!
Podemos ver como ficará o esquema de particionamento dos discos na figura

abaixo. Agora podemos criar o ponto de montagem e o sistema de arquivo de cada
parte do volume lógico.
Veja que os procedimentos a partir de agora ficarão mais familiares ...

Faça o mesmo com as demais partições.
Finalize esta etapa, verifique o resumo e selecione SIM.
O restante da instalação segue normalmente. Apenas uma ressalva: na seleção de

pacotes desmarque tudo.
Pronto! Agora basta seguir a instalação e finalizar posteriormente. Depois é só deixar

o sistema dar boot sozinho.
Capítulo 3
Implementando Hardening + PAM em
seu Servidor GNU/Linux
3.1. Objetivos
• Ajustes iniciais no servidor;
• Entender os procedimentos de hardening e a configuração do “PAM”;
• Conhecer e aplicar seus “módulos” e “controles”;
• Aplicar checagem de “logs” e conhecer parâmetros de alguns arquivos;
• Impedir login de root via console e ssh;

Capítulo 3 Implementando Hardening + PAM em seu Servidor GNU/Linux - 38
3.2. 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 registros de login/logout, bem como as atividades realizadas nos servidores.
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.
3.4. Introdução teórica – Ajustes iniciais
Sempre que finalizamos a instalação de um servidor, temos que efetuar alguns

ajustes 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).
3.5. 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”:
root@debian:~# vim /etc/network/interfaces

# Interface Loopback
auto lo
iface lo inet loopback
# Interface de rede primária

auto eth0
iface eth0 inet static
address 192.168.X.1
netmask 255.255.255.0
network 192.168.X.0
broadcast 192.168.X.255
gateway 192.168.X.254
RedHat:
# vim /etc/sysconfig/network/ifcfg-eth0
3.6. 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:
root@debian:~# vim /etc/resolv.conf

nameserver 4.2.2.2
3.7. Configuração do Hostname
Em um servidor, a configuração correta do “hostname” e do arquivo “hosts” é

essencial para eliminar problemas em serviços de rede. Abra o arquivo
“/etc/hostname” e adicione o nome da máquina:
root@debian:~# vim /etc/hostname

datacenter
Depois vamos parar e iniciar o serviço do hostname:
root@debian:~# /etc/init.d/hostname stop

root@debian:~# /etc/init.d/hostname start
Faça o logout e efetue o login. Cairá no prompt já alterado!
root@datacenter:~#
Edite o arquivo de /etc/hosts:
root@datacenter:~# vim /etc/hosts

127.0.0.1 localhost
192.168.X.2 datacenter.com.br datacenter
3.8. 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:
root@datacenter:~# vim /etc/apt/sources.list

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”:
root@datacenter:~# aptitude update
Vamos agora efetuar a atualização do servidor com o comando:
root@datacenter:~# aptitude upgrade
Ok! Com o servidor atualizado, vamos agora instalar os programas necessários

para o andamento do curso:
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,

destaque de busca no texto, ignorar o case e deixar o texto colorido, facilitando a
leitura da configuração. Insira no final do arquivo:
root@datacenter:~# vim /etc/vim/vimrc

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

Existem 3 escolhas para a alternativa editor (disponibiliza
/usr/bin/editor).
Selecção Caminho Prioridade Estado

------------------------------------------------------------
0 /bin/nano 40 modo automático
1 /bin/nano 40 modo manual
2 /usr/bin/vim.basic 30 modo manual
* 3 /usr/bin/vim.tiny 10 modo manual
Pressione enter para manter a escolha actual[*], ou digite o número da

selecção: 3
Vamos ajustar algumas variáveis do sistema e alguns “alias” dentro do

arquivo /etc/profile. Abra o arquivo.
root@datacenter:~# vim /etc/profile

HISTSIZE=5000
TMOUT=120
export HISTSIZE TMOUT
alias ls='ls --color=auto'
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:
root@datacenter:~# source /etc/profile
A fim de ajudar na instalação de programas via aptitude e 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 as linhas 32, 33 e 34:
root@datacenter:~# aptitude install bash-completion

root@datacenter:~# vim /etc/bash.bashrc
31 # enable bash completion in interactive shells
32 if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
33 . /etc/bash_completion
34 fi
Agora vamos reler o arquivo para validar as alterações:
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.
3.9. 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, conhecidos também como “Hardening”,

serão discutidos no treinamento de Segurança 415 – ISO27002.
3.10. Laboratório
3.10.1. Protegendo o sistema com bloqueios na partição
Vamos começar a melhorar a segurança de nosso servidor bloqueando a

execução de binários na partição /tmp. Porquê? Por que é um diretório comum para
gravação e possui todas permissões, incluindo a de execução. Sendo assim, evitamos
que um usuário com más intenções tente executar algum programa que o ajude a
escalar privilégio no sistema, podendo apagar conteúdo ou mesmo roubar
informações sigilosas. Abaixo temos uma pequena descrição das opções que podemos
colocar no /etc/fstab:
• exec, noexec - Permite habilitar/desabilitar a execução de binários no

sistema de arquivos;
• rw - Monta o sistema de arquivos com a opção “Read-Write”, ou seja, leitura e

escrita;
• ro - Monta o sistema de arquivos com a opção “Read-Only, ou seja, somente

leitura;
•
• suid, nosuid - Habilita/desabilita o bit de “set-user-identifier” ou “set-group-
identifier”;
• dev, nodev - Serve para habilitar/desabilitar a interpretação de dispositivos

de blocos especiais em um sistema de arquivos;
Como devemos configurar nosso /etc/fstab? Simples, basta adicionar os

parâmetros na partição desejada (nosso caso o /tmp):
/dev/mapper/root_vg-lv_tmp /tmp ext3 defaults,noexec,nosuid,nodev 0 0
Agora remonte a partição:
root@datacenter:~# mount -o remount /tmp
E faça o seguinte teste:
root@datacenter:~# cp /bin/ls /tmp

root@datacenter:~# cd /tmp
root@datacenter:~# ./ls
-bash: ./ls: Permissão negada
Para relembrar: Porque no /tmp? Muitos “rootkits” procuram este tipo de

acesso através do “/tmp”, por isso é recomendado se ter o “/tmp” em uma
partiçõesão separada, já que seu permissionamento padrão é de gravação
universal.
Para relembrar: Montando o “/tmp” com “noexec” você impede que um

CRACKER jogue programas dentro do “/tmp” e os execute. Isso ajuda a
evitar muitos ataques de “escalação” de privilégios.
3.10.2. 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,
apenas 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:
root@datacenter:~# aptitude install sudo
O arquivo de configuração do sudo é o /etc/sudoers. Abra-o usando o vim:
root@datacenter:~# vim /etc/sudoers

Insira o usuário infra na linha 18, conforme abaixo:
16 # User privilege specification

17 root ALL=(ALL) ALL
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:
26 Defaults:infra timestamp_timeout=0
3.10.3. 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:
root@datacenter:/tmp# aptitude install openssh-server
Como todos sabem, o usuário root sempre acessa o sistema. Veja:
root@datacenter:~# ssh localhost

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

conforme abaixo:
4 # What ports, IPs and protocols we listen for

5 Port 51000
...
24 # Authentication:
25 LoginGraceTime 10
26 PermitRootLogin no
Respectivamente alteramos a porta padrão 22 para a 51000, mudamos o tempo

máximo para digitar a senha para apenas 10 segundos e negamos o login com o
usuário root! Para as novas regras entrarem em vigor, reinicie o serviço do ssh.
root@datacenter:~# /etc/init.d/ssh restart
Vamos aos testes?
root@datacenter:~# ssh root@localhost

ssh: connect to host localhost port 22: Connection refused
root@datacenter:~#
root@datacenter:~# ssh root@localhost -p51000
root@localhost's password:
Permission denied, please try again.
3.10.4. Configurando uma senha no GRUB2
O GRUB, ou GRand Unified Bootloader, é o boot loader mais utilizado em

sistemas GNU/Linux, porém por padrão ele vem configurado sem senha, o que
possibilita a qualquer usuário com conhecimentos em GNU/Linux acessar o sistema e
remover/trocar a senha do root. Vamos então proteger nosso sistema. Primeiramente
vamos gerar a senha do Grub2, sendo ela “123456” (sem aspas) para o curso:
root@datacenter:~# grub-mkpasswd-pbkdf2
Enter password:
Reenter password:
Your PBKDF2 is
grub.pbkdf2.sha512.10000.A254399AFA2A071BE3AA366EF37183E4A94920C29198B3D
6985ADBB4A4D0340E47E279898FDD588150A4042AB61AF02BC279188C547575D924F9F9B
0779FB8D9.22BF4158057ACF2E5B37A0F3AD87033321F68FFEA73DC57F2886D47ED936DA
8272A531834B523D9C99FBABC6829FD5F4AC29D7057995F1CF2219C7AE6B47C2EB
Copie o “hash” da senha (em negrito), pois essa é a senha criptografada. Abra o
arquivo que armazenara a senha do Grub2 e na ultima linha acrescente as seguintes

linhas:
root@datacenter:~# vim /etc/grub.d/00_header

...
cat << EOF
set superusers=”root”
password_pbkdf2 root <<Aqui deve ser colado o hash da senha do Grub2>>
EOF
Exemplo de como deve ficar:
cat << EOF
set superusers=”root”
password_pbkdf2 root grub.pbkdf2.sha512.10000.935D00429D7EE61B97C6854247142FC954

B797523AAFFD4ABAB22227FFB69AA9AD99986CB6D4CE45FA237E3C3F3EF4EFE4303C3254D882F2808CA12D
16B02D24.5C0FD49A3E497511863235E75FEDA822C8BA6222AD72FA81945149BAB752C1D34F30D71886D29
AF04936CD9B773F717C5C6F0249CD266818D256E382470B6EB1
EOF
Logo em seguida deve-se atualizar as configurações do Grub2
root@datacenter:~# update-grub2
root@datacenter:~# reboot
3.10.5. 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!
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!
root@datacenter:~# pwgen -1sync 15 4

!0E>,T]We`xSFDp
"DuI7"/\whdtan*
M=B>jQ;&#;M3;_)
W`vaJ2qAL_@)]Hr
3.10.6. 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:
root@datacenter:~# aptitude install nmap
Rode o seguinte comando do nmap:
root@datacenter:~# nmap -sV localhost

Starting Nmap 5.00 ( http://nmap.org ) at 2011-06-20 22:28 BRT
Interesting ports on localhost (127.0.0.1):
Not shown: 999 closed ports
PORT STATE SERVICE VERSION
25/tcp open smtp Exim smtpd 4.72
Service Info: Host: datacenter
Service detection performed. Please report any incorrect results at
http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.52 seconds
Verificamos aqui 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:
root@datacenter:~# insserv -rv exim4

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

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

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

All 1000 scanned ports on localhost (127.0.0.1) are closed

root@datacenter:~#
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 servidor. Execute:
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.
3.10.7. Bloqueando o CTRL+ALT+DEL
Por padrão, qualquer pessoa pode efetuar o reboot da máquina, mesmo sem
estar logado, por meio da combinação de teclas CTRL+ALT+DEL. Sabemos que o

servidor deverá ficar numa sala com acesso restrito, porém nem sempre é que vemos
na maioria das empresas. Portanto, temo que desabilitar esta função no sistema
GNU/Linux. Para isto, execute:
root@datacenter:~# vim +33 /etc/inittab

ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
Vamos desativar esta função alterando o comando “shutdown” para o “echo”.
ca:12345:ctrlaltdel:/bin/echo "Este recurso foi desabilitado..."
Para validar a alteração, execute o comando:
root@datacenter:~# init q
3.10.8. Bloqueando as funções do SysRq
SysRq, SysReq ou Sys Req (abreviação de System Request) está localizada

junto com a tecla Print Screen, no canto superior direito. Muitos não sabem o por
quê desta tecla existir, mas ela serve para executar algumas funções no sistema,
como reiniciar o computador, desligar, ou mesmo matar processos. Veja algumas
combinações:
Alt+SysRq+b –> Um reboot sem desmontar o sistema

Alt+SysRq+o –> Desligamento via APM
Alt+SysRq+k –> Mata todos os processos que estão rodando no momento.
Não é interessante fazer isso no terminal onde está
rodando o X (ou seja, tty7). A interface gráfica iria parar.
Alt+SysRq+r –> Tira o teclado e o mouse do controle do servidor X. Isso
pode ser bem viável quando o seu servidor X estiver
travado, você pode mudar para um terminal e matar o X
(ou ainda, verificar os logs).
Em se tratando de um servidor, onde nem sempre ele está numa sala fechada,
alguma pessoa com suficiente conhecimento sobre esta tecla poderia desligá-lo,
mesmo sem login! Portanto, vamos desativar esta função. Abra o arquivo e insira a
seguinte linha no final do arquivo:
root@datacenter:~# vim /etc/sysctl.conf

kernel.sysrq = 0
Para validar a alteração imediatamente, execute o comando abaixo e pode

refazer os testes:
root@datacenter:~# sysctl -p
3.10.9. 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 digitar 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:
root@datacenter:~# vim +67 /etc/login.defs

67 SULOG_FILE /var/log/sulog
Salve o arquivo e releia o mesmo, digitando:
root@datacenter:~# source /etc/login.defs
Agora crie o arquivo especificado como sendo o log:
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:
root@datacenter:~# splitvt
Deixe numa parte rodando o comando de visualização de logs:
root@datacenter:~# tail -f /var/log/sulog
Na outra execute os comandos com “su infra” e “su - infra”.

3.11. 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

desenvolvimento 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

dentro 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 dinamicamente.
3.11.1. 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

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

laborató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
3.12. Módulos do PAM
O PAM trabalha com módulos e controles, e cada tipo de módulo provê uma
funcionalidade 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

compartilhamento de arquivos remotos que contém o diretório “/home” do
usuário em questão, por exemplo.
3.13. 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,

somente 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

imediatamente 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

distribuições que não possuem são aquelas baseadas em “Slackware”.
3.14. 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:
root@datacenter:~# ls /lib/security/
Como descobrir se sua aplicação tem suporte no PAM?

R: Basta utilizar o comando “ldd”.
Execute:
root@datacenter:~# ldd /bin/login

linux-gate.so.1 => (0xb7712000)
libpam.so.0 => /lib/libpam.so.0 (0xb7701000)
libpam_misc.so.0 => /lib/libpam_misc.so.0 (0xb76fe000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb75b7000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb75b3000)
libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb7581000)
/lib/ld-linux.so.2 (0xb7713000)
Podemos verificar também quais serviços trabalham com o PAM listando os

arquivos do /etc/pam.d:
root@datacenter:~# ls -l /etc/pam.d
Vamos ativar um módulo 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 26:
root@datacenter:~# vim +36 /etc/pam.d/login

34 # Disallows other than root logins when /etc/nologin exists
35 # (Replaces the `NOLOGINS_FILE' option from login.defs)
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:
root@datacenter:~# touch /etc/nologin
Feito isso, crie um usuário chamado “teste” tente logar com ele 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 :
root@datacenter:~# vim +31 /etc/securetty

28 # Virtual consoles
29 tty1
30 tty2
31 tty3
32 tty4
Teste: Comente a linha 31 (tty3) e tente logar-se com o usuário root no

TTY3! Descomente a linha 31 após o teste.
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 descomente a linha 68:

64 # Uncomment and edit /etc/security/time.conf if you need to set
65 # time restrainst on logins.
66 # (Replaces the `PORTTIME_CHECKS_ENAB' option from login.defs
67 # as well as /etc/porttime)
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:
root@datacenter:~# vim /etc/security/time.conf

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!
Aproveitando 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:
root@datacenter:~# vim +9 /etc/pam.d/sshd

8 auth required pam_env.so envfile=/etc/default/locale
9 account required pam_time.so
Completando, abra o arquivo /etc/security/time.conf e adicione no final:
root@datacenter:~# vim +9 /etc/security/time.conf

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

sshd;*;root;!Al0000-2400
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:
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”
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”.
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 e adicione no final da linha 15
group=admins:
root@datacenter:~# vim +15 /etc/pam.d/su

15 auth required pam_wheel.so group=admins
Teste: Com o usuário chamado “teste”, logue e execute um “su -”.
teste@datacenter:~$ su -
Senha:
su: Permissão negada

teste@datacenter:~$
Faça o mesmo teste como usuário infra.
infra@datacenter:~$ su -
Senha:
root@datacenter:~#
Verifique o log do comando su:
root@datacenter:~# tail -f -n2 /var/log/sulog

SU 06/22 21:01 - /dev/pts/0 teste-root
SU 06/22 21:02 + /dev/pts/0 infra-root
1) Podemos limitar também quais usuários/grupos podem logar no sistema.

Edite o arquivo /etc/pam.d/common-auth e ative o módulo
“pam_listfile.so” da seguinte maneira:
root@datacenter:~# vim /etc/pam.d/common-auth

1 auth required pam_listfile.so onerr=fail item=group sense=deny file=/etc/grupos
2 # /etc/pam.d/common-auth - authentication settings common to all
services
3 #
Agora crie o arquivo “/etc/grupos” e coloque os nomes dos grupos que NÃO
podem fazer login:
root@datacenter:~# vim /etc/grupos

# Grupos que não podem fazer login no sistema
financeiro
rh
vendas
Faça alguns testes, criando alguns usuários e adicionando a estes grupos. Tente
efetuar o login e veja o resultado.
root@datacenter:~# adduser maria

root@datacenter:~# adduser maria rh
root@datacenter:~# login maria

Senha:
Login incorreto
Login datacenter:
Após os testes, podemos remover estes grupos e usuários!
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
determinar o tempo de consumo de CPU e memória RAM. Vejamos o módulo ativado
no /etc/pam.d/login:

75 # Sets up user limits according to /etc/security/limits.conf
76 # (Replaces the use of /etc/limits in old login)
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:
<usuario/grupo> <tipo_de_limite> <recurso> <valor_do_limite>
Em usuário/grupo, podemos colocar um “*” para especificar todos os usuários,

colocar 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!
core - Limite do tamanho do arquivo coredump (em KB). É a

mesma configuração que obtemos com o comando “ulimit
-c” do shell.
data - Tamanho máximo de segmento de dados que um
programa pode usar. Também como: “ulimit -d” no bash.
fsize - Tamanho máximo de algum arquivo que o usuário possa
criar. Também: “ulimit -f”.
memlock - Tamanho de memória alocada que os programas podem

usar (em KB). Também: “ulimit -l”.
nofiles - Número máximo de arquivos abertos ao mesmo tempo.
Também: “ulimit -n”.
rss - Tamanho máximo de memória compartilhada (em KB).
Também: “ulimit -m”.
stack - Valor máximo de um processo executado (em KB).
Também: “ulimit -s”.
cpu - Tempo máximo em minutos de uso da CPU. Também:
“ulimit -t”.
nproc - Número máximo de processos executados ao mesmo
tempo. “Também: ulimit -u”.
as - Limite em KB de espaço de endereçamento.
maxlogins - Número máximo de logins para esse usuário
maxsyslogins - Número máximo de logins no sistema
priority - Em qual prioridade padrão os processos desse usuário
devem rodar.
locks - Número máximo de arquivos de “locks” que podem ser
gerados pelo usuário. Também: “ulimit -x”.
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

consecutivos que um usuário pode utilizar. Abra o arquio /etc/security/limits.conf e
insira a seguinte linha:
root@datacenter:~# vim /etc/security/limits.conf

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

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

5000+0 registros de entrada
5000+0 registros de saída
5120000 bytes (5,1 MB) copiados, 0,253124 s, 20,2 MB/s
Criamos um arquivo de 5000KB. Agora vamos criar usando count=5001!
teste@datacenter:~$ dd if=/dev/zero of=arquivo bs=1024 count=5001

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 teste. A sintaxe é:
teste@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

teste hard fsize 5000
teste hard nproc 200
Após isto, faça novamente o teste usando o usuário teste. 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.
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:
root@datacenter:~# vim /etc/pam.d/common-password

24 # here are the per-package modules (the "Primary" block)

25 password requisite pam_cracklib.so retry=3 minlen=6 difok=3
26 #password [success=1 default=ignore] pam_unix.so obscure
use_authtok try_first_pass sha512
27 password [success=1 default=ignore] pam_unix.so use_authtok
nullok md5
Na linha 25 estamos especificando o seguinte:
retry=3 -> 3 tentativas de mudança de senha.;

minlen=6 -> Senha com no mínimo 6 caracteres.;
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:
teste@datacenter:~$ passwd
Mudando senha para teste.
Senha UNIX (atual):
Senha:
SENHA INCORRETA: é muito simples/sistemática
Senha:
Senha:
passwd : Esgotado o número máximo de tentativas para serviço
passwd: Palavra-passe inalterada
Agora mude a senha atendendo ao critério que configuramos:
teste@datacenter:~$ passwd
Mudando senha para teste.
Senha UNIX (atual):
Senha:
Redigite a nova senha:
passwd: senha atualizada com sucesso
Iremos estudar “Hardening” mais a fundo no Treinamento “Segurança em

Servidores 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 listas
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
3.15. Extra – Servidor NTP
A fim de deixarmos os horários dos servidores atualizados, vamos instalar um

servidor NTP. Para isto, vamos configurar um script:
root@datacenter:~# vim ntp.sh

#!/bin/bash
clear
aptitude install ntp -y
# Configurando o servidor para sincronismo...
linha=$(grep -n statsdir /etc/ntp.conf | awk -F: '{print$1}')
sed -i "$linha"s'/^#statsdir/statsdir/' /etc/ntp.conf
sed -i 21,24s'/debian/south-america/g' /etc/ntp.conf
echo "restrict 192.168.X.0 mask 255.255.255.0" >> /etc/ntp.conf
# Restartando o serviço
service ntp restart
3.16. Extra – Cliente NTP
Nos clientes NU/Linux, instale o serviço ntpdate e atualize o horário:
root@squeeze:~# aptitude ntpdate -y

root@squeeze:~# ntpdate 192.168.X.2
Crie um script no cron para atualizar o horário:

root@squeeze:~# vim ntpdate.sh

#!/bin/bash
# Criando agendamento no CRON
echo "ntpdate 192.168.X.2" > /etc/cron.daily/ntpdate
chmod +x /etc/cron.daily/ntpdate
Nos clientes Windows, basta configurar o endereço “ntp.dexter.com.br” (a

ser configurado na aula de DNS) nas propriedades do relógio.
Agora no Windows 7:
Capítulo 4
Servidor DHCP
4.1. Objetivos
• Entender o protocolo "DHCP";
• Entender os métodos de atribuição de endereços;
• Configurar um servidor "DHCP";
• Atribuir um endereço de acordo com o "MAC Address".

Capítulo 4 Servidor DHCP - 66
4.2. 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
computadores da rede mapeados com endereço IP fixo.
Uma grande vantagem que podemos encontrar no DHCP é o de “amarrar” o

endereç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 serão
bloqueados. Além disto, teremos um controle melhor sobre a origem dos acessos aos
serviços da empresa.
4.4. Introdução teórica
Criado e mantido pelo ISC (Internet Systems Consortium), um grupo sem

fins lucrativos dedicado a desenvolver serviços de infra-estrutura usados na Internet,
incluindo 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
Protocol) 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 endereç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 sejam 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
distribuí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.
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
endereç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.
Geralmente 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
configurados 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".
4.5. Laboratório
Primeiro iremos instalar o pacote do servidor dhcp:
root@datacenter:~# aptitude install isc-dhcp-server
Vamos renomear o arquivo original do DHCP para uma possível consulta:
root@datacenter:~# mv /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.orig
Agora vamos iniciar nossa configuração num arquivo zerado. Abra-o e insira o
conteúdo abaixo:
root@datacenter:~# vim /etc/dhcp/dhcpd.conf

ddns-update-style none;
deny unknown-clients;
log-facility local7;
subnet 192.168.X.0 netmask 255.255.255.0 {

range 192.168.X.100 192.168.X.110;
server-identifier datacenter;
authoritative;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.X.255;
option domain-name "dexter.com.br";
option domain-name-servers 4.2.2.2,8.8.8.8;
option routers 192.168.X.1;
default-lease-time 600;
max-lease-time 7200;
}
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:
root@datacenter:~# /etc/init.d/isc-dhcp-server restart
4.5.1. 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

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

subrede a ser fornecida aos clientes;
• option broadcast-address 192.168.X.255 - Essa opção define o endereço de

envio para requisições de "broadcast";
• option domain-name dexterX.com.br - O nome de domínio do cliente;
• option domain-name-servers 4.2.2.2,8.8.8.8 - Essa opção lista os servidores

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

informação do número do "gateway" de sua rede;
• 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);
4.5.2. Configurando os LOGs
No Debian, o arquivo de configuração do syslog fica em /etc/rsyslog.conf. A

seguinte entrada pode ser adiciona ao mesmo:
root@datacenter:~# vim /etc/rsyslog.conf

local7.* /var/log/dhcpd.log
root@datacenter:~# touch /var/log/dhcpd.log
root@datacenter:~# /etc/init.d/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.
4.5.3. Configurando os clientes DHCP
Do lado cliente, temos duas opções para fins de teste:
root@squeeze:~# dhclient eth0 -v
Caso não tenha o comando dhclient:

# aptitude install isc-dhcp-client
Ou editando o arquivo "/etc/network/interfaces", trocando "static" por

"dhcp". Ficará assim:
root@squeeze:~# vim /etc/network/interfaces

auto eth0
iface eth0 inet dhcp
Para visualizar a placa de rede que está utilizando:

# mii-tool
4.6. 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:
MÁQUINA MAC ADRESS IP FIXADO

Debian Squeeze ? 192.168.X.10
Windows XP ? 192.168.X.20
Windows 7 ? 192.168.X.30
Para esse cenário ser possível, seria necessária a respectiva entrada no final
do arquivo de configuração "/etc/dhcp/dhcpd.conf":
host debian {
hardware ethernet 00:00:00:00:00:00;
fixed-address 192.168.X.10;
}
host windowsxp {
}
host windows7 {
}
Você deve trocar o MAC Address informado aqui pelo de suas estações.
Para habilitar o suporte ao servidor dinâmico, utilize a opção:

dynamic-bootp
range dynamic-bootp 192.168.X.100 192.168.X.110;
4.6.1. Configurações adicionais
No que diz respeito ao servidor, podemos ainda verificar alguns arquivos para
diagnosticar problemas ou mesmo extrair relatórios. Vejamos:
root@datacenter:~# less /var/lib/dhcp/dhcpd.leases

lease 192.168.110.102 {
starts 2 2011/06/28 01:27:10;
ends 2 2011/06/28 01:28:13;
tstp 2 2011/06/28 01:28:13;
cltt 2 2011/06/28 01:27:10;
binding state free;
hardware ethernet 08:00:27:2e:f9:fa;
}
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
conhecidos 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 conforme abaixo:
root@datacenter:~# less /etc/default/isc-dhcp-server

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”:
root@datacenter:~# less /var/lib/dhcp/dhclient.leases

lease {
interface "eth0";
fixed-address 192.168.56.101;
option dhcp-lease-time 3600;
option dhcp-message-type 5;
option dhcp-server-identifier 192.168.56.100;

renew 2 2011/06/21 21:55:15;
rebind 2 2011/06/21 22:22:06;
expire 2 2011/06/21 22:29:36;
… ou o arquivo /var/lib/dhcp/dhclient.eth0.leases
lease {
interface "eth0";
fixed-address 192.168.56.101;
option dhcp-lease-time 3600;
option dhcp-message-type 5;
option dhcp-server-identifier 192.168.56.100;
renew 5 2011/06/24 00:14:42;
rebind 5 2011/06/24 00:14:42;
expire 5 2011/06/24 00:14:42;
}
E para finalizar, evite colocar 2 servidores DHCP na mesma rede, pois isto irá
gerar alguns transtornos para os clientes!
Capítulo 5
Servidor NFS
5.1. Objetivos
• Instalar o servidor NFS;
• Entender a configuração do NFS;
• Exportar um diretório para uso como Storage.
5.2. Cenário
Capítulo 5 Servidor NFS - 76
A empresa Dexter Courier precisa de um Storage de baixo custo para

compartilhar arquivos para os membros da rede, incluindo máquinas Windows.
Vamos utilizar um computador com GNU/Linux servindo como Storage da

rede, contendo 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
gerenciar as quotas por grupo.
Originalmente desenvolvido pela Sun Microsystems, o NFS (Network File

System) permite compartilhar diretórios e arquivos na rede, fazendo com que os
clientes acessem 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 recursos 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;
• 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);

5.5. Conhecendo o NAS
O termo NAS (Network-Attached Storage) foi introduzido com os primeiros

sistemas 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
(incluindo 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
mercado. Inspirados pelo sucesso dos servidores de arquivos da Novell, IBM e Sun,
várias empresas desenvolveram servidores dedicados para armazenamento de dados.
Enquanto a 3Com estava entre as primeiras empresas a fabricar NAS dedicados para
sistemas operacionais de desktop, a Auspex Systems foi a primeira a desenvolver
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
escalabilidade 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
tecnologia RAID (Redundant Arrays of Independent Disks), centralizando a
responsabilidade 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 redes domésticas, diversos produtos NAS surgiram para o mercado pessoal. Estes
dispositivos NAS de uso doméstico são baseados em processadores baratos rodando
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 o FreeNAS
(http://www.freenas.org/), o Openfiler (http://www.openfiler.com/) e o NASLite
(http://www.serverelements.com/).
Abaixo temos alguns exemplos de dispositivos NAS:
LG-N4B1-NAS-Blu-ray Seagate-Blackarmor-NAS 440
5.6. 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 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

aparelhos de armazenamento diretamente em uma rede de fibra permite diversas
conexõ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
aparelhos de storage em rede, como aumentar a disponibilidade, escalabilidade e
desempenho”, escreveu o consultor Barb Goldworm.
Os defensores da SAN dizem que a tecnologia é a melhor quando se busca

desempenho 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:

5.7. 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 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.
5.8. Laboratório
5.8.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:
root@storage:~# mkdir /srv/dexter ; mkdir /srv/lixeiras
Agora partiremos para a instalação do servidor NFS e suas configurações.

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

Interesting ports on localhost (127.0.0.1):
111/tcp open rpcbind
2049/tcp open rpcbind
Vejamos com o netstat:
root@storage:~# netstat -luptan

Conexões Internet Ativas (servidores e estabelecidas)
Proto Recv-Q Send-Q Endereço Local Endereço Remoto
Estado PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:*
OUÇA 1468/portmap
tcp 0 0 0.0.0.0:60630 0.0.0.0:*
OUÇA 1920/rpc.mountd
tcp 0 0 0.0.0.0:2049 0.0.0.0:*
OUÇA -
tcp 0 0 0.0.0.0:57409 0.0.0.0:*
OUÇA 1677/rpc.statd
udp 0 0 0.0.0.0:47545 0.0.0.0:*
1677/rpc.statd
udp 0 0 0.0.0.0:1005 0.0.0.0:*
1677/rpc.statd
udp 0 0 0.0.0.0:111 0.0.0.0:*
1468/portmap
udp 0 0 0.0.0.0:52472 0.0.0.0:*
-
udp 0 0 0.0.0.0:2049 0.0.0.0:*
Podemos observar que temos os serviços do portmap e nfs rodando,

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

.
75 sunrpc 111/tcp portmapper # RPC 4.0 portmapper
76 sunrpc 111/udp portmapper
.
298 nfs 2049/tcp # Network File System
299 nfs 2049/udp # Network File System
Podemos ver os serviços necessários ao funcionamento do NFS executando:
root@storage:~# rpcinfo -p
programa versão protocolo porta
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 47545 status
100024 1 tcp 57409 status
100021 1 udp 52472 nlockmgr
100021 1 tcp 39468 nlockmgr
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100005 1 udp 46126 mountd
100005 1 tcp 60630 mountd
100005 2 udp 46126 mountd
100005 2 tcp 60630 mountd
100005 3 udp 46126 mountd
100005 3 tcp 60630 mountd
Depois destes testes, vamos configurar o compartilhamento no arquivo

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

/srv/dexter 192.168.X.2(rw,root_squash,no_subtree_check,async)
/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
compartilhamento 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:
root@storage:~# exportfs -r
Pronto! Diretórios compartilhados. Para realizar uma verificação execute:
root@storage:~# showmount -e localhost

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

root@storage:~# service nfs-kernel-server restart
5.8.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”:
root@datacenter:~# aptitude install nfs-common
Antes de efetuarmos a montagem efetiva dos compartilhamentos NFS, vamos

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

root@datacenter:~# lvremove /dev/root_vg/lv_srv
Do you really want to remove active logical volume lv_srv? [y/n]: y
Logical volume "lv_srv" successfully removed
NÃO ESQUEÇA de remover a linha do /etc/fstab!!!
Agora crie o ponto de montagem:
root@datacenter:~# mkdir -p /srv/storage ; mkdir /srv/lixeiras
Verifique os compartilhamentos do servidor:
root@datacenter:~# showmount -e 192.168.X.4

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

root@datacenter:~# mount -t nfs 192.168.X.4:/srv/lixeiras /srv/lixeiras
Verifique a montagem do compartilhamento com o comando mount:
root@datacenter:~# mount
192.168.X.4:/srv/dexter on /srv/storage type nfs (rw,addr=192.168.X.4)
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:

root@datacenter:~# touch /srv/storage/teste_root

touch: não foi possível tocar "/mnt/rh/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”:
root@storage:~# vim /etc/exports

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

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

All mount points on 192.168.X.4:
192.168.X.2:/srv/dexter
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:
root@datacenter:~# vim /etc/fstab

192.168.X.4:/srv/dexter /srv/dexter nfs defaults,soft 0 0
192.168.X.4:/srv/lixeiras /srv/lixeiras nfs defaults,soft 0 0
Capítulo 6
Implementando RAID + LVM
6.1. Objetivos
• Instalação e configuração de volume RAID pela linha de comando;
• Instalação e configuração de LVM pela linha de comando;

Capítulo 6 Implementando RAID + LVM - 87
Vimos a configuração do RAID e LVM durante a instalação do GNU/Linux, mas

e se precisarmos montar o mesmo esquema de particionamento em um servidor que
já esteja em funcionamento ou mesmo adicionar mais um novo RAID ou LVM?
Tendo isto em vista este ambiente, vamos realizar os procedimentos via linha
de comando, tomando como base o que já aprendemos no capítulo 2 durante a
instalação do GNU/Linux.
6.3. Laboratório – RAID
Vamos adicionar 3 discos no Servidor DataCenter para realizarmos este

laboratório. Como este servidor já possui RAID-1 sem SPARE, vamos fazer alguns as
configurações com RAID-0, RAID-1 e RAID-5, além de verificarmos o arquivo de
monitoração.
Primeiro crie uma partição primária, do tipo Linux raid autodetect (fd) e
uma swap (82) em cada um dos discos:
root@datacenter:~# cfdisk /dev/sdc

root@datacenter:~# cfdisk /dev/sdd
root@datacenter:~# cfdisk /dev/sde
root@datacenter:~#
root@datacenter:~# cfdisk -Ps /dev/sdc
Partition Table for /dev/sdc
First Last
# Type Sector Sector Offset Length Filesystem Type
(ID) Flag
-- ------- ----------- ----------- ------ -----------
-------------------- ----
1 Primary 0 166015709 63 166015710 Linux raid auto
(FD) None
2 Primary 166015710 167766794 0 1751085 Linux swap / So
(82) None
root@datacenter:~# cfdisk -Ps /dev/sdd
Partition Table for /dev/sdd
First Last
(ID) Flag
-- ------- ----------- ----------- ------ -----------
-------------------- ----
(FD) None
(82) None
root@datacenter:~# cfdisk -Ps /dev/sde
Partition Table for /dev/sde
First Last
(ID) Flag
-- ------- ----------- ----------- ------ -----------
-------------------- ----
(FD) None
(82) None
Para reconhecer estas novas partições, instale o pacote parted e execute o

utilitário partprobe:
root@datacenter:~# aptitude install parted

root@datacenter:~# partprobe
Veja agora as partições:
root@datacenter:~# cat /proc/partitions

major minor #blocks name
8 32 83886080 sdc
8 33 83007823 sdc1
8 34 875542 sdc2
8 48 83886080 sdd
8 49 83007823 sdd1
8 50 875542 sdd2
8 64 83886080 sde
8 65 83007823 sde1
8 66 875542 sde2
8 16 83886080 sdb
8 17 82909184 sdb1
8 18 974848 sdb2
8 0 83886080 sda
8 1 82909184 sda1
8 2 974848 sda2
9 0 82908088 md0 # partição RAID sda1/sdb1
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 e /dev/sdd1.
Se for instalar num servidor sem RAID, terá que fazer a instalação do pacote:
root@datacenter:~# aptitude install mdadm splitvt
O utilitário splitvt 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:
6.3.1. Configurando o RAID-0
Em uma das telas execute o comando para monitoração do RAID:
root@datacenter:~# watch -n1 cat /proc/mdstat

Every 1,0s: cat /proc/mdstat Fri Jul 1 18:41:43 2011
Personalities : [raid1]
md0 : active raid1 sda1[0] sdb1[1]
82908088 blocks super 1.2 [2/2] [UU]
unused devices: <none>
Na outra tela execute o comando para a criação do RAID-0:
root@datacenter:~# mdadm --create /dev/md1 --level=0 \

--raid-devices=3 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
Veja a saída:

Every 1,0s: cat /proc/mdstat Fri Jul 1 18:47:46 2011
Personalities : [raid1] [raid0]

md1 : active raid0 sde1[2] sdd1[1] sdc1[0]
249019392 blocks super 1.2 512k chunks

82908088 blocks super 1.2 [2/2] [UU]
Depois de criarmos o volume RAID, é necessário editar o arquivo

/etc/mdadm/mdadm.conf para ser utilizado durante a administração do “RAID”:
root@datacenter:~# vim /etc/mdadm/mdadm.conf
Adicione no final do arquivo o seguinte conteúdo:

DEVICE /dev/sdc1 /dev/sdd1 /dev/sde1

ARRAY /dev/md1 devices=/dev/sdc1,/dev/sdd1,/dev/sde1
Agora vamos criar um diretório, efetuar a montagem, formatar e popular:
root@datacenter:~# mkdir /mnt/raid

root@datacenter:~# mkfs.ext4 -m .5 /dev/md1
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=128 blocks, Stripe width=384 blocks
15564800 inodes, 62254848 blocks
3112742 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
1900 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
2654208,
4096000, 7962624, 11239424, 20480000, 23887872
Writing inode tables: done

Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 37 mounts or

180 days, whichever comes first. Use tune2fs -c or -i to override.
root@datacenter:~# mount -t ext4 /dev/md1 /mnt/raid
root@datacenter:~# cp -v /bin/* /mnt/raid/ ; env ls /mnt/raid
Pronto! Nosso RAID-0 está em funcionamento! Vamos fazer uma verificação

dos discos, tanto individual (basta trocar o device por outro), como no geral. Execute
como no exemplo:
root@datacenter:~# mdadm -E /dev/sdc1

/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3f827e3c:7a14fd95:7597a177:46ab51b3
Name : datacenter:1 (local to host datacenter)
Creation Time : Fri Jul 1 19:12:48 2011
Raid Level : raid0
Raid Devices : 3
Avail Dev Size : 166013599 (79.16 GiB 85.00 GB)

Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 63125ebf:bd7afdc1:698374e3:78ccc43b
Update Time : Fri Jul 1 19:12:48 2011

Checksum : f44e0391 - correct
Events : 0
Chunk Size : 512K
Device Role : Active device 0

Array State : AAA ('A' == active, '.' == missing)
Veja os detalhes do volume RAID:
root@datacenter:~# mdadm --detail /dev/md1

/dev/md1:
Version : 1.2
Raid Level : raid0
Array Size : 249019392 (237.48 GiB 255.00 GB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Fri Jul 1 19:12:48 2011

State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Chunk Size : 512K

UUID : 3f827e3c:7a14fd95:7597a177:46ab51b3
Events : 0
Number Major Minor RaidDevice State

0 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
2 8 65 2 active sync /dev/sde1
Agora vamos desmontar e parar o RAID-0:
root@datacenter:~# umount /mnt/raid

root@datacenter:~# mdadm -S /dev/md1
mdadm: stopped /dev/md1
Caso deseje reiniciar o RAID, execute:
root@datacenter:~# mdadm -As /dev/md1

mdadm: /dev/md1 has been started with 3 drives.
Para remover o RAID, execute novamente:
Remova as linhas referentes ao RAID-0 no /etc/mdadm/mdadm.conf:

25 DEVICE /dev/sdc1 /dev/sdd1 /dev/sde1
26 ARRAY /dev/md1 devices=/dev/sdc1,/dev/sdd1,/dev/sde1
Reinicie o serviço abaixo:
root@datacenter:~# /etc/init.d/mdadm-raid restart
E tente reiniciar o RAID-0:

mdadm: /dev/md1 not identified in config file.
Vamos montar agora o RAID nível 1. Para isto vamos executar:

--raid-devices=2 --spare-devices=1 /dev/sdc1 /dev/sdd1 /dev/sde1
Veja a saída:
root@datacenter:~# cat /proc/mdstat

md1 : active (auto-read-only) raid1 sde1[2](S) sdd1[1] sdc1[0]
83006727 blocks super 1.2 [2/2] [UU]
resync=PENDING

82908088 blocks super 1.2 [2/2] [UU]
Neste exemplo criamos o RAID-1, porém ele ficou ativo como “somente
leitura”, conforme observado acima na opção auto-read-only. Neste caso não há
problema, pois quando executarmos alguma gravação no RAID, ele passará para o
modo leitura/escrita. O problema enfrentado aqui é a opção resync=PENDING,
como mostrado saída do comando anterior. Para resolver isto execute:
root@datacenter:~# mdadm --readwrite /dev/md1

Isto fará com que o volume RAID seja atualizado para leitura-escrita.

Every 2,0s: cat /proc/mdstat
Fri Jul 8 17:49:05 2011

md1 : active raid1 sde1[2](S) sdd1[1] sdc1[0]
83006727 blocks super 1.2 [2/2] [UU]
[>....................] resync = 2.6% (2178432/83006727)
finish=42.8min speed=31456K/sec

82908088 blocks super 1.2 [2/2] [UU]
Após alguns minutos, a atualização do modo read-only para read-write estará

terminada e poderemos observar algumas informações importantes em relação aos
discos. Podemos verificar na saída do comando acima a linha abaixo, onde nos
mostra a disposição dos discos no volume RAID. Vamos observar a linha:
md1 : active raid1 sde1[2](S) sdd1[1] sdc1[0]
Nesta linha temos a informação de que o disco sde1 é o terceiro disco e está
alocado como SPARE. O sdd1 é o segundo disco e o sdc1 o primeiro disco do RAID.
O disco SPARE é utilizado como “backup” do volume RAID, ou seja, caso um dos
discos falhe, ele assumirá de imediato o seu lugar e dará início ao sincronismo dos
dados.
Bom, agora que o volume RAID está criado e ajustado para gravação, vamos
configurar o arquivo /etc/mdadm/mdadm.conf:

Agora vamos formatar, montar e popular. Depois verifique a montagem!
root@datacenter:~# mkfs.ext4 -m .5 /dev/md1

mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
5193728 inodes, 20751681 blocks
First data block=0
634 block groups
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
2654208, 4096000, 7962624, 11239424, 20480000

root@datacenter:~#
root@datacenter:~# mount -t ext4 /dev/md1 /mnt/raid
root@datacenter:~# cp -v /bin/* /mnt/raid/ ; env ls /mnt/raid
root@datacenter:~# df -hT | grep raid
/dev/md1 ext4 78G 191M 78G 1% /mnt/raid
Pronto! Nosso RAID-1 está em funcionamento! Vamos fazer uma verificação

dos discos, tanto individual (basta trocar o device por outro), como no geral. Execute
como no exemplo:
root@datacenter:~# mdadm -E /dev/sdc1

/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 4f14d726:5b11ed80:7a0f799b:837616ae
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 166013599 (79.16 GiB 85.00 GB)

Array Size : 166013454 (79.16 GiB 85.00 GB)
Used Dev Size : 166013454 (79.16 GiB 85.00 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : f6e42588:d34bf5d5:9fae0753:ef71dc92
Update Time : Sat Jul 16 17:21:20 2011

Checksum : 95a8c810 - correct
Events : 32
Device Role : Active device 0

Array State : AA ('A' == active, '.' == missing)
Veja os detalhes do volume RAID:

/dev/md1:
Version : 1.2
Raid Level : raid1
Array Size : 83006727 (79.16 GiB 85.00 GB)
Raid Devices : 2
Total Devices : 3
Update Time : Sat Jul 16 17:21:20 2011

State : clean
Active Devices : 2
Working Devices : 3
Failed Devices : 0
Spare Devices : 1

UUID : 4f14d726:5b11ed80:7a0f799b:837616ae
Events : 32

2 8 65 - spare /dev/sde1
Vamos realizar uma simulação de falha em um dos discos do volume RAID-1,

causando assim a ativação do disco SPARE. Para checarmos se o RAID-1 continua em
funcionamento, crie um script em shell para gravar a data e a hora num arquivo na
partição do RAID-1 a cada 3 segundos.
root@datacenter:~# vim /root/testaRaid.sh

#!/bin/bash
while true ; do
date >> /mnt/raid/dados.txt ; sleep 3
done
Dê permissão de execução ao script e execute-o, verificando o resultado depois:
root@datacenter:~# chmod +x /root/testaRaid.sh

root@datacenter:~# ./testaRaid.sh &
root@datacenter:~# tail -f /mnt/raid/dados.txt
Execute o comando a seguir para simular a falha:
root@datacenter:~# mdadm /dev/md1 --fail /dev/sdc1

mdadm: set /dev/sdc1 faulty in /dev/md1
Agora veja a saída deste comando no /proc/mdstat:


Every 1,0s: cat /proc/mdstat Sat Jul 16 18:39:35 2011
md1 : active raid1 sdc1[0](F) sde1[2] sdd1[1]
83006727 blocks super 1.2 [2/1] [_U]
[>....................] recovery = 0.3% (304896/83006727)
Perceba que o disco /dev/sdc1 aparece com a letra “F” entre parênteses, o que
significa que ele está com falha! Ao apresentar esta “falha”, o disco de SPARE, no
caso o /dev/sde1, assumiu seu lugar e deu início ao sincronismo dos dados. Se você
verificar o terminal com o comando “tail” em execução, teremos:
root@datacenter:~# tail -f -n5 /mnt/raid/dados.txt

Sáb Jul 16 18:46:28 BRT 2011
Sáb Jul 16 18:46:31 BRT 2011
Sáb Jul 16 18:46:35 BRT 2011
Sáb Jul 16 18:46:38 BRT 2011
Sáb Jul 16 18:46:41 BRT 2011
Veja que pelo horário marcado passou-se cerca de 7 minutos e a gravação

ainda está acontecendo! Observe como ficou a saída do comando de detalhes do
volume RAID-1. Temos a informação de que o disco está com falha:
root@datacenter:~# mdadm --detail /dev/md1 | tail -n5

2 8 65 0 spare rebuilding /dev/sde1
0 8 33 - faulty spare /dev/sdc1
Agora teremos que remover este disco “problemático” e inserir um “novo”, ou

seja, vamos realizar a tarefa com o mesmo disco. Para isto execute os comando
abaixo:
root@datacenter:~# mdadm /dev/md1 --remove /dev/sdc1

mdadm: hot removed /dev/sdc1 from /dev/md1
Observe pelo arquivo /proc/mdstat que o disco /dev/sdc1 foi removido:

md1 : active raid1 sde1[2] sdd1[1]
83006727 blocks super 1.2 [2/1] [_U]
[======>..............] recovery = 31.5% (26208576/83006727)
Agora execute o comando abaixo para inserir um “novo” disco no RAID-1...
root@datacenter:~# mdadm /dev/md1 --add /dev/sdc1

mdadm: re-added /dev/sdc1
… e veja que o mesmo volto a ser parte do RAID-1, porém como disco SPARE!

md1 : active raid1 sdc1[0](S) sde1[2] sdd1[1]
83006727 blocks super 1.2 [2/1] [_U]
[=======>.............] recovery = 39.9% (33158080/83006727)
Com isto concluímos nosso teste de simulação de falha e inserção de disco no

volume RAID. Agora vamos desmontar e parar o RAID-1:
root@datacenter:~# jobs -l
[1]+ 3808 Executando ./testaraid.sh &
root@datacenter:~# kill -9 3808
root@datacenter:~# umount /mnt/raid
mdadm: stopped /dev/md1
Para remover o RAID-1, execute novamente:

Remova as linhas referentes ao RAID-1 no /etc/mdadm/mdadm.conf, como

exemplo abaixo as linhas 25 e 26...

25 DEVICE /dev/sdc1 /dev/sdd1 /dev/sde1
26 ARRAY /dev/md1 devices=/dev/sdc1,/dev/sdd1,/dev/sde1
Reinicie o serviço abaixo:
root@datacenter:~# /etc/init.d/mdadm-raid restart
E tente reiniciar o RAID-1:

mdadm: /dev/md1 not identified in config file.
Finalmente vamos montar o RAID nível 5 em definitivo!

–-raid-devices=3 /dev/sdc1 /dev/sdd1 /dev/sde1
Veja a saída:
root@datacenter:~# cat /proc/mdstat

Personalities : [raid1] [raid6] [raid5] [raid4]

md1 : active raid5 sdc1[0] sde1[3] sdd1[1]
166012928 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]

82908088 blocks super 1.2 [2/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:
root@datacenter:~# mdadm --readwrite /dev/md1
Isto fará com que o volume RAID seja atualizado. Veja a saída em:


166012928 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[>....................] recovery = 0.3% (282584/83006464)

82908088 blocks super 1.2 [2/2] [UU]
Após alguns minutos, a atualização estará terminada!
Bom, agora que o volume RAID está criado e ajustado para gravação, vamos
configurar o arquivo /etc/mdadm/mdadm.conf:

Verifique o status do volume RAID-5 com o comando:


166012928 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

82908088 blocks super 1.2 [2/2] [UU]
Agora verifique os detalhes do RAID-5

/dev/md1:
Version : 1.2
Creation Time : Sat Jul 16 19:30:27 2011
Raid Level : raid5
Array Size : 166012928 (158.32 GiB 170.00 GB)
Raid Devices : 3
Total Devices : 3
Update Time : Sun Jul 17 02:36:39 2011
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
UUID : 678e56df:88862d7f:df6f7580:22af52e0
Events : 440
3 8 65 2 active sync /dev/sde1
Como nossa intenção é adicionar o volume RAID-5 ao LVM, iremos apenas

realizar a configuração até aqui! A formatação e montagem do volume se dará em
cima do LVM. No próximo passo iremos configurar e testar o LVM.
6.4. 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:
root@datacenter:~# aptitude install lvm2
Os comandos utilizados para os testes com o LVM são:
PV (Phisical Volume)
pvs - saída resumida
pvscan - saída simples
pvdisplay - saída detalhada
VG (Volume Group)
vgs - saída resumida
vgscan - saída simples
vgdisplay - saída detalhada
LV (Logical Volume)
lvs - saída resumida
lvscan - saída simples
lvdisplay - saída detalhada
Vamos verificar nossos “Volumes Lógicos” por meio dos comandos detalhados,
tomando como base para a produção de relatórios. Primeiro do PV:
root@datacenter:~# pvdisplay
--- Physical volume ---
PV Name /dev/md0
VG Name root_vg
PV Size 79,07 GiB / not usable 952,00 KiB
Allocatable yes
PE Size 4,00 MiB
Total PE 20241
Free PE 15951
Allocated PE 4290
PV UUID r0e8hh-rjsx-8diG-LAvg-ftAM-rfzB-3Q3CXT
Agora do VG:
root@datacenter:~# vgdisplay
--- Volume group ---
VG Name root_vg
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 5
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 4
Open LV 4
Max PV 0
Cur PV 1
Act PV 1
VG Size 79,07 GiB
PE Size 4,00 MiB
Total PE 20241
Alloc PE / Size 4290 / 16,76 GiB
Free PE / Size 15951 / 62,31 GiB
VG UUID HHcDSF-MyYY-3Ewj-NJt6-nxCQ-jSTM-Mh7ox4
E finalmente os LVs:
root@datacenter:~# lvdisplay
--- Logical volume ---
LV Name /dev/root_vg/lv_raiz
VG Name root_vg
LV UUID Whr2xl-wNnH-eyvx-3f5R-Ed0m-2U5Z-11Vdye
LV Write Access read/write
LV Status available
# open 1
LV Size 9,31 GiB
Current LE 2384
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0

LV Name /dev/root_vg/lv_srv
VG Name root_vg
LV UUID 80jbk3-JhN3-3UtQ-mfLH-goEM-Ymv5-wS40fl
LV Status available
# open 1
LV Size 4,66 GiB
Current LE 1192
Segments 1
Allocation inherit
Block device 253:1

LV Name /dev/root_vg/lv_var
VG Name root_vg
LV UUID 7jzW75-90d8-qQS5-D3uj-YMGL-Atzc-cquVEa
LV Status available
# open 1
LV Size 1,86 GiB
Current LE 476
Segments 1
Allocation inherit

Block device 253:2

LV Name /dev/root_vg/lv_tmp
VG Name root_vg
LV UUID Pmn5wM-06Fo-UdqS-Ed1k-ftdn-Z6cJ-FDUJS8
LV Status available
# open 1
LV Size 952,00 MiB
Current LE 238
Segments 1
Allocation inherit
Block device 253:3
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:
root@datacenter:~# pvcreate /dev/md1

Physical volume "/dev/md1" successfully created
Vamos checar os PVs do sistema:
root@datacenter:~# pvdisplay
--- Physical volume ---
PV Name /dev/md0
VG Name root_vg
PV Size 79,07 GiB / not usable 952,00 KiB
Allocatable yes
PE Size 4,00 MiB
Total PE 20241
Free PE 15951
Allocated PE 4290
PV UUID r0e8hh-rjsx-8diG-LAvg-ftAM-rfzB-3Q3CXT
"/dev/md1" is a new physical volume of "158,32 GiB"

--- NEW Physical volume ---
PV Name /dev/md1
VG Name
PV Size 158,32 GiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID nX0d9f-cAQW-DbGV-1FS0-U4SX-mDt0-1tcoha
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, ou seja, o volume RAID-5:
root@datacenter:~# vgcreate samba_vg /dev/md1

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

Using volume group(s) on command line
Finding volume group "samba_vg"
--- Volume group ---
VG Name samba_vg
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 1
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 0
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 158,32 GiB
PE Size 4,00 MiB
Total PE 40530
Alloc PE / Size 0 / 0
Free PE / Size 40530 / 158,32 GiB
VG UUID bhbxMF-6cjA-Me0Y-1SQO-Z4t0-ieZ1-6qUXoS
--- Physical volumes ---

PV Name /dev/md1
PV UUID nX0d9f-cAQW-DbGV-1FS0-U4SX-mDt0-1tcoha
PV Status allocatable
Total PE / Free PE 40530 / 40530
Finalmente vamos criar um volume lógico (LV) dentro do VG samba_vg:
root@datacenter:~# lvcreate -L 10G -n samba_lv samba_vg

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

Using logical volume(s) on command line
LV Name /dev/samba_vg/samba_lv
VG Name samba_vg
LV UUID 982O70-Pvx3-a5nh-fXiC-65K3-rHCy-l2VbCL
LV Status available
# open 0
LV Size 10,00 GiB
Current LE 2560
Segments 1
Allocation inherit
Block device 253:4
Agora que temos um volume lógico criado, vamos formatar :
root@datacenter:~# mkfs.ext4 -m .5 /dev/samba_vg/samba_lv

mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
655360 inodes, 2621440 blocks
First data block=0
80 block groups
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632


Finalizando, vamos criar um ponto de montagem e montar:
root@datacenter:~# mkdir /mnt/lvm

root@datacenter:~# mount -t ext4 /dev/samba_vg/samba_lv /mnt/lvm/
root@datacenter:~# df -hT | tail -n2
/dev/mapper/samba_vg-samba_lv
ext4 9,9G 151M 9,7G 2% /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.
root@datacenter:~# cp -rv /boot/* /mnt/lvm ; cp -rv /sbin/* /mnt/lvm

root@datacenter:~# du -sh /mnt/lvm/
21M /mnt/lvm/
Vamos supor que o espaço alocado para a unidade lógica não irá atender às
necessidades 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:
root@datacenter:~# umount /mnt/lvm

root@datacenter:~# lvextend -L +15g /dev/samba_vg/samba_lv
Extending logical volume samba_lv to 25,00 GiB
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:
root@datacenter:~# e2fsck -f /dev/samba_vg/samba_lv

e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/samba_vg/samba_lv: 391/655360 files (0.3% non-contiguous),
84894/2621440 blocks
root@datacenter:~# resize2fs /dev/samba_vg/samba_lv
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/samba_vg/samba_lv to 6553600 (4k)
blocks.
The filesystem on /dev/samba_vg/samba_lv is now 6553600 blocks long.
Pronto! Agora monte a partição e veja o tamanho e o total dos dados que nela
estavam:
root@datacenter:~# mount -t ext4 /dev/samba_vg/samba_lv /mnt/lvm/


ext4 25G 176M 25G 1% /mnt/lvm
21M /mnt/lvm/
Observe os detalhes da partição redimensionada:
root@datacenter:~# lvdisplay /dev/samba_vg/samba_lv

LV Name /dev/samba_vg/samba_lv
VG Name samba_vg
LV UUID 982O70-Pvx3-a5nh-fXiC-65K3-rHCy-l2VbCL
LV Status available
# open 1
LV Size 25,00 GiB
Current LE 6400
Segments 1
Allocation inherit
Block device 253:1
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”.

e2fsck 1.41.12 (17-May-2010)
147856/6553600 blocks
root@datacenter:~# resize2fs -p /dev/samba_vg/samba_lv 15g
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/samba_vg/samba_lv to 3932160(4k)blocks.
Begin pass 3 (max = 200)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Neste exemplo temos uma partição de 25GB e eu desejo reduzir apenas 5GB.
Vamos supor que eu tenha cerca de 12GB 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 os comandos LVM que reduzirão de
fato o tamanho da partição:
root@datacenter:~# lvreduce -L -5g /dev/samba_vg/samba_lv

WARNING: Reducing active logical volume to 20,00 GiB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce samba_lv? [y/n]: y
Reducing logical volume samba_lv to 20,00 GiB
Logical volume samba_lv successfully resized
e2fsck 1.41.12 (17-May-2010)
106095/3932160 blocks
root@datacenter:~# resize2fs /dev/samba_vg/samba_lv
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/samba_vg/samba_lv to 5242880(4k)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!
root@datacenter:~# mount -t ext4 /dev/samba_vg/samba_lv /mnt/lvm

ext4 20G 176M 20G 1% /mnt/lvm
21M /mnt/lvm/
Para remover toda a estrutura dos testes, façamos o seguinte:

root@datacenter:~# lvremove /dev/samba_vg/samba_lv
Do you really want to remove active logical volume samba_lv? [y/n]: y
Logical volume "samba_lv" successfully removed
root@datacenter:~# vgremove samba_vg
Volume group "samba_vg" successfully removed
root@datacenter:~# pvremove /dev/md1
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:
root@datacenter:~# pvcreate /dev/md1

Physical volume "/dev/md1" successfully created
root@datacenter:~# vgcreate samba_vg /dev/md1
Volume group "samba_vg" successfully created
root@datacenter:~# lvcreate -L 20G -n samba_lv samba_vg
Logical volume "samba_lv" created
root@datacenter:~# mkfs.ext4 -m .5 /dev/samba_vg/samba_lv
root@datacenter:~# mkdir /srv/samba
root@datacenter:~# mount -t ext4 /dev/samba_vg/samba_lv /srv/samba/
ext4 20G 172M 20G 1% /srv/samba
Agora vamos editar o /etc/fstab e incluir no final do arquivo este novo ponto
de montagem:
root@datacenter:~# vim /etc/fstab

/dev/mapper/samba_vg-samba_lv /srv/samba ext4 defaults 0 0
O sistema ficará desta forma:
root@datacenter:~# df -hT
Sist. Arq. Tipo Size Used Avail Use% Montado em

/dev/mapper/root_vg-lv_raiz
ext4 9,2G 710M 8,1G 8% /
tmpfs tmpfs 188M 0 188M 0% /lib/init/rw
udev tmpfs 183M 208K 183M 1% /dev
tmpfs tmpfs 188M 0 188M 0% /dev/shm
/dev/mapper/root_vg-lv_tmp
ext4 938M 18M 873M 2% /tmp
/dev/mapper/root_vg-lv_var
ext4 1,9G 202M 1,6G 12% /var
192.168.110.4:/srv/dexter
nfs 79G 632M 74G 1% /srv/storage
192.168.110.4:/srv/lixeiras
nfs 79G 632M 74G 1% /srv/lixeiras
ext4 20G 172M 20G 1% /srv/samba
Capítulo 7
Servidor Samba
7.1. Objetivos
• Entender as funcionalidades do SAMBA;
• Entender seu arquivo de configuração;
• Criar compartilhamento simples de diretórios;
• Criar um Servidor Samba com autenticação de usuários;
• Criar um Servidor Samba como PDC (Primary Domain Controller);
7.2. Cenário 1
A empresa Dexter Courier possui máquinas com o Sistema Operacional

GNU/Linux e Microsoft Windows e pretende criar uma rede com estes dois
Capítulo 7 Servidor Samba - 117
ambientes. Precisa de um compartilhamento público. A empresa não deseja gastar

com licença de um servidor arquivos. A rede possui máquinas com Windows XP e
Windows 7. Os arquivos precisam ser gravados no Storage, para fins de backup.
7.3. Proposta de solução 1
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. Sendo assim, o servidor deverá atender aos
seguintes requisitos:
• compartilhamento simples de arquivos; grupo de trabalho; nome netbios;

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.
7.4. Cenário 2

ambientes. Pensando em questões de segurança, deseja que todos os acessos aos
compartilhamentos sejam autenticados e logados. Ela necessita de um
compartilhamento público e um para cada setor da empresa, além de uma
impressora. A empresa não deseja gastar com licença de um servidor arquivos. A
rede possui máquinas com Windows XP e Windows 7. Os arquivos precisam ser
gravados no Storage, para fins de backup.

servidores com código proprietário. O servidor deverá atender aos seguintes
requisitos:
• compartilhamento de arquivos (gravados no Storage) para cada grupo com

autenticação de usuário; grupo de trabalho; nome netbios; 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; escutará apenas na interface da rede local; sistema de lixeira para
cada compartilhamento; impressora compartilhada.
7.6. Cenário 3

ambientes. Como a empresa necessita de flexibilidade, deseja que seus usuários
possam se logar no sistema em qualquer computador, podendo acessar os arquivos
do compartilhamento público, do respectivo setor e possibilidade de impressão.
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 arquivos. A rede possui máquinas com Windows XP e
Windows 7. Os arquivos precisam ser gravados no Storage, para fins de backup, e o
“profile” dos usuários precisa ter disponibilidade.

servidores com código proprietário. O servidor deverá atender aos seguintes
requisitos:
• domínio com perfil móvel (roaming profile); autenticação de usuários; nome

netbios; 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; escutará apenas na interface da rede local; sistema
de lixeira para cada compartilhamento; impressora compartilhada; restrição de
acesso à rede local; mapeamento de unidade de rede para cada usuário;
possibilidade do usuário alterar sua senha; criação de arquivo/diretório em
letra minúscula; compartilhamento oculto para uso da equipe de suporte;
codificação dos caracteres para ambos os sistemas; script de logon para

mapear os compartilhamentos; gerar relatório de quem está conectado ao
servidor.
O Samba é um servidor para Linux (e outros sistemas baseados em Unix) que

permite o gerenciamento e compartilhamento de recursos em redes formadas por
computadores 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
precisava 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
arquivos 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

depois, 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
projeto. 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
"scramble", 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
programadores e com milhares de usuários de sua solução espalhados pelo mundo.
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”.
7.9. Laboratório 1
Neste laboratório iremos compartilhar de forma bem simples alguns diretórios.

Primeiro vamos instalar o samba.
root@datacenter:~# aptitude install samba samba-doc smbclient smbfs
Renomeie o arquivo padrão do samba para efeito de consulta e abra um novo

arquivo smb.conf:
root@datacenter:~# mv /etc/samba/smb.conf /etc/samba/smb.conf.original

root@datacenter:~# vim /etc/samba/smb.conf
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 serão cobradas na prova
do LPI.
Neste “lab” iremos montar um compartilhamento simples de arquivos, de

domínio público, apontando para nosso STORAGE (192.168.X.4) montado em
/srv/storage. Agora vamos criar o arquivo /etc/samba/smb.conf:

[global]
workgroup = dexter
netbios name = servidor

server string = Servidor de Arquivos Linux
security = share
wins support = yes
client lanman auth = yes
log file = /var/log/samba/%m.log
log level = 1
max log size = 1000
posix locking = no
[publico]
comment = Publico
path = /srv/storage/publico
public = yes
force user = smbuser
force group = users
read only = no
guest ok = yes
force create mode = 664
force directory mode = 755
veto files = /*.mp3/*.mpg/*.mpeg/*.avi/*.wav/*.jpg/
hide files = /*.ini/*.log/
Para esta configuração devemos criar um usuário chamado smbuser e

adicioná-lo ao grupo users existente no sistema, além de criarmos o diretório a ser
compartilhado e definirmos suas permissões de acesso. Para isto execute:
root@datacenter:~# useradd -g users smbuser

root@datacenter:~# mkdir -pv /srv/storage/publico
root@datacenter:~# chown -Rv smbuser:users /srv/storage/publico
root@datacenter:~# chmod -Rv 770 /srv/storage/publico
root@datacenter:~# ls -lh /srv/storage
drwxrwx--- 2 smbuser users 4,0K Jul 25 13:09 publico
Toda configuração do samba pode ser testada antes de entrar em produção,

basta executar o comando testparm:
root@datacenter:~# testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)
Processing section "[publico]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions
Agora reinicie o serviço do samba:
root@datacenter:~# service samba restart

Stopping Samba daemons: nmbd smbd.
Starting Samba daemons: nmbd smbd.
DICA
Ao executar o testparm, aparece o erro abaixo:
rlimit_max: rlimit_max (1024) below minimum Windows limit
(16384)
Isto é causado pelo número de processos padrão e o mínimo que o Windows

necessita. Para resolver isto, coloque no /etc/profile o comando "ulimit -n
16384" (sem as aspas). A mensagem de erro não aparecerá mais!
Inicie a máquina “WindowsXP” para fazer os testes. Abra o compartilhamento

e crie um arquivo e uma pasta. Verifique depois no diretório do GNU/Linux:
Agora inicie a máquina “Windows7” para fazer os testes. Abra o

compartilhamento e crie alguns arquivos e uma pasta. Verifique depois no diretório
do GNU/Linux:
Inicie a máquina “SQUEEZE” para testarmos a montagem do diretório do

samba no cliente. Instale o cliente samba e crie um ponto de montagem:
root@squeeze:~# aptitude install smbclient

root@squeeze:~# mkdir /mnt/publico
Verifique o compartilhamento do servidor samba:
root@squeeze:~# smbclient -L 192.168.X.2

Enter root's password:
Domain=[DEXTER] OS=[Unix] Server=[Samba 3.5.6]
Sharename Type Comment

--------- ---- -------
publico Disk Publico
IPC$ IPC IPC Service (Servidor de Arquivos Linux)
Domain=[DEXTER] OS=[Unix] Server=[Samba 3.5.6]
Server Comment
--------- -------
SERVIDOR Servidor de Arquivos Linux
Workgroup Master
--------- -------
DEXTER SERVIDOR
GRUPO WINDOWS-XP
Para montar o compartilhamento, execute o mount e dê ENTER na senha:
root@squeeze:~# mount -t cifs //192.168.X.2/Publico /mnt/publico
Crie um diretório e um arquivo para testar:
root@squeeze:~# mkdir /mnt/publico/4linux

root@squeeze:~# touch /mnt/publico/teste-samba
root@squeeze:~# ls -lh /mnt/publico/
drwxr-xr-x 2 1002 users 0 Jul 26 2011 4linux
-rwxrwx--- 1 1002 users 0 Jul 25 17:09 arq-samba.txt
drwxrwx--- 2 1002 users 0 Jul 25 17:15 dir-samba
-rwxrw-r-- 1 1002 users 444K Jun 27 22:32 putty.exe
-rwxrw-r-- 1 1002 users 179 Jul 26 15:56 teste2.doc

-rw-rw-r-- 1 1002 users 0 Jul 26 16:31 teste-samba
Para utilizar este compartilhamento no boot, basta configurar o /etc/fstab:
root@squeeze:~# vim /etc/fstab

//192.168.X.2/publico /mnt/publico cifs guest,rw,user,auto 0 0
7.10. Laboratório 2
Para criar os grupos e usuários, devemos nos atentar para nosso cenário, ou
seja, a empresa Dexter Courier. Ela possui o seguinte quadro de funcionários:
Presidente Comercial
Dexter Clem Chris Cavanaugh
Candi Milo
Adminitrativo Allison Moore
Mandark Glory
Levinsky Mitch Logística
Douglas Mordechai Eddie Deezen
Frank Welker
RH Luzinsky Brooks
Kathryn Cressida
Kath Soucie Suporte TI
Jeff Bennett VOCÊ
Para nos ajudar nessa árdua tarefa, vamos compor uma lista com o nome e o
login de cada membro da empresa Dexter Courier. Ademais, gere uma lista somente
com o login de cada usuário e salve como /root/lista_users.txt, assim poderemos
utilizar scripts na criação e administração do Samba.
Dexter Clem – dexterclem

Mandark Glory – mandarkglory
Levinsky Mitch – levinskymitch
Douglas E. Mordechai – douglasmordechai
Chris Cavanaugh – chriscavanaugh

Candi Milo – candimilo
Allison Moore – allisonmoore
Kathryn Cressida – kathryncressida
Kath Soucie – kathsoucie
Jeff Bennett – jeffbennett
Eddie Deezen – eddiedeezen
Frank Welker – frankwelker
Luzinsky Brooks – luzinskybrooks
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...
root@datacenter:~# addgroup –-gid 2001 administrativo

root@datacenter:~# addgroup –-gid 2002 comercial
root@datacenter:~# addgroup –-gid 2003 logistica
root@datacenter:~# addgroup --gid 2004 rh
root@datacenter:~# addgroup –-gid 2005 suporte
root@datacenter:~# tail -n5 /etc/group
administrativo:x:2001:
comercial:x:2002:
logistica:x:2003:
rh:x:2004:
suporte:x:2005:
… e adicionar os usuários aos grupos criados;
root@datacenter:~# useradd -g administrativo -G

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

dexterclem:x:1001:2001::/home/dexterclem:/bin/false
mandarkglory:x:1002:2001::/home/mandarkglory:/bin/false
levinskymitch:x:1003:2001::/home/levinskymitch:/bin/false
douglasmordechai:x:1004:2001::/home/douglasmordechai:/bin/false
chriscavanaugh:x:1005:2002::/home/chriscavanaugh:/bin/false
candimilo:x:1006:2002::/home/candimilo:/bin/false
allisonmoore:x:1007:2002::/home/allisonmoore:/bin/false
kathryncressida:x:1008:2004::/home/kathryncressida:/bin/false
kathsoucie:x:1009:2004::/home/kathsoucie:/bin/false
jeffbennett:x:1010:2004::/home/jeffbennett:/bin/false
eddiedeezen:x:1011:2003::/home/eddiedeezen:/bin/false
frankwelker:x:1012:2003::/home/frankwelker:/bin/false
luzinskybrooks:x:1013:2003::/home/luzinskybrooks:/bin/false
voce:x:1014:2005::/home/voce:/bin/false
Agora que temos os grupos e usuários, vamos criar os diretórios...

root@datacenter:~# mkdir -p \
/srv/storage/{administrativo,rh,comercial,logistica,suporte}
… e definir as permissões de acesso:
root@datacenter:~# chown -Rv root:administrativo \

/srv/storage/administrativo
root@datacenter:~# chown -Rv root:rh /srv/storage/rh
root@datacenter:~# chown -Rv root:comercial /srv/storage/comercial
root@datacenter:~# chown -Rv root:logistica /srv/storage/logistica
root@datacenter:~# chown -Rv root:suporte /srv/storage/suporte
root@datacenter:~#
root@datacenter:~# chmod -Rv 3770 /srv/storage/*
root@datacenter:~# chmod -Rv 770 /srv/storage/publico
root@datacenter:~# chmod -s /srv/storage/publico/*
Agora devemos adicionar os usuários ao Samba para poder autenticar nos

compartilhamentos. Para isto faça um script com base em nossa lista de usuários em
/root/lista_users.txt.
root@datacenter:~# vim /root/smbuser.sh

#!/bin/bash
for lista in $(cat /root/lista_users.txt); do
(echo 123456 ; echo 123456) | smbpasswd -a -s $lista
done
Agora execute o script:
root@datacenter:~# sh /root/smbuser.sh
Devemos criar também os diretórios da lixeira de cada usuário. Para isto faça
um script com base em nossa lista de usuários em /root/lista_users.txt.
root@datacenter:~# vim /root/lixeiras.sh

#!/bin/bash
rm -r /srv/lixeiras/$lista 2> /dev/null
mkdir -p /srv/lixeiras/$lista
chown -R $lista:users /srv/lixeiras/$lista

chmod -R 770 /srv/lixeiras/$lista
done
Agora execute o script:
root@datacenter:~# sh /root/lixeiras.sh
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:

[global]
workgroup = DEXTER
netbios name = Servidor
log level = 1
max log size = 1000
security = user
username level = 2
wins support = yes
encrypt passwords = yes
smb passwd file = /etc/samba/smbpasswd
posix locking = no
# Habilitando o Samba a imprimir
printing = cups
load printers = yes
# Habilitando o usuário a trocar sua senha
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n
*Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
# Habilitando o Samba responder em determinada interface de rede

interfaces = eth0
bind interfaces only = yes
# Nomes de arquivos e diretórios todos em minúsculos
preserve case = no
default case = lower
# Habilitando o Samba a usar lixeiras em todos os compartilhamentos
vfs objects = recycle
recycle:keeptree = yes
recycle:versions = yes
recycle:repository = /srv/lixeiras/%U
recycle:exclude = *.tmp,*.log,*obj,~*.*,*.bak
recycle:exclude_dir = tmp, cache
[administrativo]
path = /srv/storage/administrativo
available = yes
writable = yes
public = no
only guest = no
valid users = @administrativo
write list = @administrativo
[comercial]
path = /srv/storage/comercial
available = yes
writable = yes
public = no
only guest = no
valid users = @comercial
write list = @comercial
[logistica]
path = /srv/storage/logistica
available = yes
writeable = yes
public = no
only guest = no
valid users = @logistica
write list = @logistica
[rh]
path = /srv/storage/rh
available = yes
writeable = yes
public = no
only guest = no
valid users = @rh
write list = @rh
[suporte]
path = /srv/storage/suporte
available = yes
writeable = yes
public = no
only guest = no
valid users = @suporte
write list = @suporte
[publico]
comment = Publico
public = yes

force group = users
read only = no
guest ok = yes
[lixeiras]
path = /srv/lixeiras/%U
writable = yes
browseable = no
[printers]
comment = Samsung ML-2010
path = /var/spool/samba
browseable = yes
writable = no
print ok = yes
guest ok = yes
Rode o comando testparm para verificar se não há erros na configuração:
rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)
Processing section "[administrativo]"
Processing section "[comercial]"
Processing section "[logistica]"
Processing section "[rh]"
Processing section "[suporte]"
Processing section "[lixeiras]"
Processing section "[printers]"

WARNING: You have some share names that are longer than 12 characters.
These may not be accessible to some older clients.
(Eg. Windows9x, WindowsMe, and smbclient prior to Samba 3.0.)
Server role: ROLE_STANDALONE
Reinicie o serviço do samba.

Faça um teste com um dos usuários criados na máquina “Windows XP”.

Aperte a tecla com o “logo do Windows+R” e digite “\\servidor” (sem aspas).
Agora entre com um login de usuário criado e depois a senha.
Acesse o compartilhamento do setor e crie um arquivo e diretório (pasta).

Criando arquivos/diretórios:
Agora teste acessar uma pasta na qual o usuário não tem permissão. Veja o
erro que aparece!
Dica!
Se criar os usuários no sistema “MS Windows” e colocar a mesma senha
do samba, o usuário conseguirá abrir o compartilhamento no servidor
segundo seu setor, sem pedir senha, mas ao tentar abrir outro receberá
uma mensagem de erro, conforme visto na figura anterior!
Vamos acessar a máquina “Windows7”. Aperte a tecla com o “logo do

Wndows+R” e depois entre com o login/senha.
Acesse o compartilhamento do setor e crie um arquivo e diretório (pasta).
Acessando o compartilhamento e criando arquivo e pasta:

Tentando acessar outro compartilhamento:
Caso não coloque o login/senha corretos, dará o seguinte erro:

Agora vamos fazer os teste com a máquina “Squeeze”. Para isto crie um ponto
de montagem e monte o compartilhamento do suporte:
root@squeeze:~# mkdir /mnt/suporte

root@squeeze:~# mount -t cifs //192.168.110.2/suporte /mnt/suporte/
Password:
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Perceba que agora gerou um erro ao entrar com a senha padrão. Isto se dá por
que não passamos o login/senha como opção de montagem! Veja agora:
root@squeeze:~# mount -t cifs //192.168.110.2/suporte /mnt/suporte/ \

-o username=voce,passwd=123456
Confirme a montagem com o comando mount:
root@squeeze:~# mount | grep mnt

//192.168.110.2/publico/ on /mnt/samba type cifs
(rw,mand,noexec,nosuid,nodev)
//192.168.110.2/suporte/ on /mnt/suporte type cifs (rw,mand)
Como um bom administrador de sistemas GNU/Linux, você ficou “encucado”

em ter que digitar a senha em texto plano direto no console, não é mesmo? Saiba que
para isto podemos gerar um arquivo contendo login/senha do usuário do
compartilhamento e “invocar” este arquivo na montagem, podendo o mesmo ser feito
no /etc/fstab. Vejamos com fazer isto!
Desmonte o compartilhamento e crie o arquivo:
root@squeeze:~# umount /mnt/suporte ; vim /etc/samba/user

username=voce
password=123456
domain=
Dê permissão de leitura apenas para o root:
root@squeeze:~# chmod 400 /etc/samba/user
Agora monte o compartilhamento da seguinte forma:

root@squeeze:~# mount -t cifs //192.168.110.2/suporte /mnt/suporte/ \

-o credentials=/etc/samba/user
No /etc/fstab configure assim:
root@squeeze:~# vim /etc/fstab

//192.168.110.2/suporte /mnt/suporte cifs \
credentials=/etc/samba/user,rw,user,auto,noexec 0 0
7.11. Laboratório 3
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 conta de máquina?
Todas as máquinas Windows vão agora pertencer ao Domínio DEXTER, mas

para isso acontecer temos que ir em cada uma delas e acrescentá-las. Para ela poder
pertencer ao domínio, seu PDC tem que saber que ela existe, e saber que há
permissão para isso.
Uma conta de máquina nada mais é que um usuário com um parâmetro

especial, que criamos com o smbpasswd. Regra importante: o “usuário” conta de
máquina tem que ter o nome da máquina Windows! Primeiro crie um grupo e depois
insira as máquinas Windows no Samba.
root@datacenter:~# addgroup –-gid 2006 pdc

root@datacenter:~# useradd -g pdc -s /dev/null -d /dev/null winxp$
root@datacenter:~# smbpasswd -a -m winxp
Added user winxp$.
root@datacenter:~# useradd -g pdc -s /dev/null -d /dev/null win7$
root@datacenter:~# smbpasswd -a -m win7
Added user win7$.
Visto que não será nada cômodo ficar ingressando todas as máquinas da rede
no Samba, vamos ver mais adiante como colocar esta etapa diretamente no arquivo
smb.conf!
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.
Para configurarmos nosso Samba como PDC, primeiramente vamos entender o

arquivo de configuração e o que mudou em relação ao laboratório anterior. As
alterações estão em negrito:
root@squeeze:~# vim /etc/samba/smb.conf

[global]
workgroup = DEXTER
netbios name = Servidor
# Habilitando o Samba como PDC

os level = 100
preferred master = yes
domain logons = yes
domain master = yes
local master = yes
# Habilitando os LOGs
log level = 1
max log size = 1000
# Nível de segurança
enable privileges = yes
security = user
username level = 2
smb passwd file = /etc/samba/smbpasswd

admin users = root
hosts allow = 192.168.X.
# hosts deny = 192.168.X.20
# Acesso a máquinas com Windows98

lanman auth = yes
# Permissão de gravação no Storage NFS

posix locking = no
# Servidor Wins
wins support = yes
wins proxy = no
dns proxy = no
max wins ttl = 518400
min wins ttl = 21600
# Melhorando o desempenho do Samba

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE
SO_RCVBUF=8192 S0_SNDBUF=8192
read raw = yes
write raw = yes
oplocks = yes
max xmit = 65536
getwd cache = yes
# Mapear unidade para arquivos pessoais do usuário

logon drive = H:
logon home = \\%L\homes\%U
logon path = \\%L\profiles\%U
logon script = logon.cmd
# Script para criar conta de máquina

add machine script = /usr/sbin/useradd -r -g pdc -c "SAMBA
PDC" -d /dev/null -s /bin/false %u
# Samba falando português

dos charset = CP850
unix charset = UTF-8
display charset = CP850
# Habilitando o Samba a imprimir

printing = cups
load printers = yes
# Samba responde em determinada interface de rede

interfaces = eth0
bind interfaces only = yes
# Habilitando o usuário a trocar sua senha

passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n
*Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
# Habilitando o Samba a deixar os nomes de arquivos e diretórios todos

em minúsculos
preserve case = yes
short preserve case = yes
case sensitive = no
# Habilitando o Samba a usar lixeiras em todos os compartilhamentos

vfs objects = recycle
recycle:keeptree = yes
recycle:versions = yes
recycle:repository = /srv/lixeiras/%U
recycle:exclude = *.tmp,*.log,*obj,~*.*,*.bak
recycle:exclude_dir = tmp, cache
[administrativo]
path = /srv/storage/administrativo
available = yes
writable = yes
public = no
only guest = no
valid users = @administrativo
write list = @administrativo
[comercial]
path = /srv/storage/comercial
available = yes
writable = yes
public = no
only guest = no
valid users = @comercial
write list = @comercial
[logistica]
path = /srv/storage/logistica
available = yes
writeable = yes
public = no
only guest = no
valid users = @logistica
write list = @logistica
[rh]
path = /srv/storage/rh
available = yes
writeable = yes
public = no
only guest = no
valid users = @rh
write list = @rh
[suporte]
path = /srv/storage/suporte
available = yes
writeable = yes
public = no
only guest = no
[publico]
comment = Publico
public = yes
force group = users
read only = no
guest ok = yes

[lixeiras]
path = /srv/lixeiras/%U
writable = yes
browseable = no
[printers]
comment = Samsung ML-2010
path = /var/spool/samba
browseable = yes
writable = no
print ok = yes
guest ok = yes
[netlogon]
comment = Network logon service
path = /srv/samba/netlogon
writable = no
browseable = no
[homes]
comment = Diretorio pessoal
path = /srv/samba/homes/%U
public = no
valid users = %U
read only = no
browseable = no
[profiles]
comment = Perfis móveis

path = /srv/samba/profiles
public = no
guest ok = yes
read only = no
browseable = no
create mask = 0600
directory mask = 0700
[drivers$]
comment = Arquivos
path = /srv/storage/drivers
public = no
inherit permissions = yes
only guest = no
writable = yes
Agora iremos preparar o ambiente para a configuração do PDC, começando

com a criação dos diretórios:
root@datacenter:~# mkdir -p /srv/samba/{homes,profiles,netlogon}

root@datacenter:~# mkdir -p /srv/storage/drivers
Agora ajuste as permissões dos diretórios:
root@datacenter:~# chown -R root:users \

/srv/samba/{homes,profiles,netlogon}
root@datacenter:~# chown -R root:suporte /srv/storage/drivers
root@datacenter:~# chmod -R 3770 /srv/storage/drivers
root@datacenter:~#
root@datacenter:~# chmod -R 770 /srv/samba/{homes,profiles,netlogon}
Vamos criar os diretórios dos usuários para poderem gravar seus dados na rede
e ingressá-los no samba. Para isto criaremos um script. Depois basta executá-lo:
root@datacenter:~# vim /root/samba-pdc.sh

#!/bin/bash
mkdir -p /srv/samba/profiles/$lista
chown -R $lista:users /srv/samba/profiles/$lista
chmod -R 700 /srv/samba/profiles/$lista
mkdir -p /srv/samba/homes/$lista
chown -R $lista:users /srv/samba/homes/$lista
chmod -R 700 /srv/samba/homes/$lista
usermod -d /srv/samba/homes/$lista $lista
pdbedit -x -u $lista
(echo 123456 ; echo 123456) | smbpasswd -a -s $lista
done
Vamos criar também o script de logon para mapearmos as unidades de rede:
root@datacenter:~# vim /srv/samba/netlogon/logon.cmd

net use l: \\servidor\administrativo /yes
net use m: \\servidor\comercial /yes
net use n: \\servidor\logistica /yes
net use o: \\servidor\rh /yes
net use p: \\servidor\publico /yes
net use q: \\servidor\suporte /yes
Agora faça a conversão de formato “Unix to DOS” para o Windows ler:
root@datacenter:~# aptitude install tofrodos

root@datacenter:~# todos -u /srv/samba/netlogon/logon.cmd
root@datacenter:~# file /srv/samba/netlogon/logon.cmd
logon.cmd: ASCII text, with CRLF line terminators
Vamos adicionar o root ao Samba para ingressar as estações no Domínio:
root@datacenter:~# smbpasswd -a root
Finalmente execute o testparm para testearmos as configurações...

Processing section "[administrativo]"
Processing section "[comercial]"
Processing section "[logistica]"
Processing section "[rh]"
Processing section "[suporte]"
Processing section "[lixeiras]"
Processing section "[printers]"
Processing section "[homes]"
Processing section "[profiles]"
Processing section "[netlogon]"
Processing section "[drivers$]"
WARNING: You have some share names that are longer than 12 characters.
These may not be accessible to some older clients.
(Eg. Windows9x, WindowsMe, and smbclient prior to Samba 3.0.)
Server role: ROLE_DOMAIN_PDC
… e reinicie o serviço do samba:

Rode o comando pdbedit para verificar os usuários do domínio:
root@datacenter:~# pdbedit -Lw

nobody:65534:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXX:[U ]:LCT-00000000:
root:0:44EFCE164AB921CAAAD3B435B51404EE:32ED87BDB5FDC5E9CBA88547376818D4:
[U ]:LCT-4E33012F:
dexterclem:1003:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:32ED87BDB5FDC5E9CBA885
47376818D4:[U ]:LCT-4E31B8A9:
levinskymitch:1005:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:32ED87BDB5FDC5E9CBA
88547376818D4:[U ]:LCT-4E31B8A9:
...
7.11.1. Adicionando máquina Windows XP ao PDC Samba
Vamos ingressar a máquina Windows-XP no domínio. Primeiro mude os

seguintes parâmetros para que a máquina possa acessar o domínio. Acesse o
"Painel de controle > 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:
7.11.2. Adicionando máquina Windows 7 ao PDC Samba
Primeiro precisa alterar o registro no Windows 7, isso é possível editando

manualmente o registro do Windows com os seguintes valores:
• HKLM\System\CCS\Services\LanmanWorkstation\Parameters
DWORD DomainCompatibilityMode = 1
DWORD DNSNameResolutionRequired = 0
A outra alternativa de forma automática é 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”
de digite o usuário do Domínio DEXTER:
7.11.3. Adicionando máquina GNU/Linux ao PDC Samba
Esta configuração é um pouco mais complexa, porém é possível logar clientes

GNU/Linux no domínio, já que o Samba pode ser usado como cliente de um PDC
Samba (ou de um PDC Windows!). Isto faz com que a estação Linux acesse os
recursos do domínio normalmente e utilize o PDC como um servidor de autenticação
na hora de compartilhar arquivos com a rede, da mesma forma que as máquinas
Windows, assim você elimina a necessidade de cadastrar os logins de usuários em
todas as máquinas Linux que precisarem compartilhar arquivos, já que todo o
processo de autenticação é centralizado no servidor. Primeiro vamos cadastrar o
nome da máquina no Servidor SAMBA, o mesmo usado em /etc/hostname:
root@datacenter:~# useradd -d /dev/null -s /bin/false squeeze$

root@datacenter:~# passwd -l squeeze$
passwd: password expiry information changed.
root@datacenter:~# smbpasswd -a -m squeeze
Added user squeeze$.
Esta é a única configuração que precisa ser feita no servidor. Os passos

seguintes são feitos no próprio cliente. Inicie a instalação normal do Samba,
instalando os pacotes "samba" e "samba-client" (ou smbclient) da mesma forma que
faria ao instalar um servidor Samba para a rede. É necessário cadastrar pelo
menos uma conta de usuário existente no Samba da estação, com a mesma
senha definida no sistema, usando o comando smbpasswd, como em:
root@squeeze:~# adduser cliente

root@squeeze:~# smbpasswd -a cliente
Agora edite o arquivo smb.conf, deixando-o desta forma:
root@squeeze:~# vim /etc/samba/smb.conf

[global]
netbios name = squeeze
workgroup = dexter
security = domain
password server = 192.168.X.2
username map = /etc/samba/smbusermap
# [arquivos]
# path = /arquivos
# writable = yes
A seção global deve conter as linhas "security = domain" (nível de segurança

que permite que o Samba atue como cliente de um PDC), "encrypt passwords =
yes" e a linha "password server =" que indica o endereço IP (ou o nome netbios) do
servidor PDC. É importante também que a linha "workgroup" inclua o nome correto
do domínio e a linha "netbios name" contenha o nome da máquina (cliente), como
cadastrado no servidor e salvo no arquivo "/etc/hostname".
Você ainda incluir os compartilhamentos de arquivos e impressoras desejados,

como no exemplo comentado no compartilhamento [arquivos]. Salve o arquivo e
reinicie o serviço do samba da máquina cliente:
root@squeeze:~# service samba restart
Agora é hora de adicionar a máquina ao domínio, o que é feito usando o

comando abaixo (executado na estação):
root@squeeze:~# net join -U root

Enter root's password:
Joined domain DEXTER.
A senha de root solicitada é a senha de root cadastrada no Servidor Samba,

que é checada ao cadastrar a estação como uma forma de provar que você é o
administrador da rede.
Possíveis erros que podem acontecer:
• Se o comando exibir a mensagem "Joined domain DOMINIO." sem solicitar a

senha, rode-o novamente, pois isso acontece quando (por qualquer motivo) ele
não conseguiu contactar o servidor.
• Se ele reclamar que a senha está incorreta, ou exibir um erro de permissão,

verifique a configuração do servidor. Isso acontece, por exemplo, quando a
linha "invalid users = root" está presente na configuração.
Uma vez inserida no domínio, a instância do Samba rodando na estação

passará a encaminhar todos os pedidos de autenticação para o servidor. Se o servidor
autoriza o acesso, então o servidor Samba local permite o acesso ao
compartilhamento. Com isso, um novo usuário cadastrado no servidor PDC, ganha
acesso também aos compartilhamentos da estação, sem que você precise cadastrá-lo
duas vezes. Para que isso funcione, é necessário duas coisas
• Especificar o endereço IP ou nome do servidor, para que a estação consiga

contactá-lo, o que é feito através da opção "password server".
• Criar um arquivo com um mapa dos usuários na estação. O arquivo pode ser
armazenado em qualquer pasta e especificado sua localização opção
"username map" do smb.conf, como em:
username map = /etc/samba/smbusermap
Este arquivo relaciona os logins cadastrados no Servidor Samba com a

conta cadastrada no servidor Samba local, explicando a ele como acessar os
arquivos no sistema depois que o acesso é autorizado pelo PDC. Sem isso o sistema
bloqueia o acesso, já que as contas cadastradas no PDC SAMBA não existem
localmente. O arquivo com o username map segue uma estrutura muito simples,
onde você especifica uma conta por linha, sempre seguindo a sintaxe:
conta_local = nome_do_dominioconta_no_dominio
como em:
cliente = DEXTERdexterclem
cliente = DEXTERmandarkglory
cliente = DEXTERlevinskymitch
cliente = DEXTERvoce
Basta criar um arquivo de texto usando qualquer editor e salvá-lo, prestando

atenção no uso de barras invertidas. Quando qualquer usuário especificado no
arquivo é autorizado pelo PDC, o Servidor Samba local realiza a leitura no sistema
de arquivos utilizando a conta "cliente", que é a única cadastrada localmente. Com
isso, você precisa apenas manter o arquivo atualizado, sem se preocupar com as
senhas. Ao serem acessados através do ambiente de rede, os compartilhamentos

(caso existam!) das estações de trabalho Linux ficam disponíveis para as demais
máquinas do domínio sem necessidade de autenticação adicional, já que a
autenticação é centralizada no PDC.
DICA:
Se precisar remover a máquina do domínio, basta alterar novamente o
smb.conf (na estação), mudando a linha "workgroup = ", para que ela
passe a indicar o nome do grupo de trabalho (e não mais do domínio) e
alterar a linha "security = domain" para "security = user".
Depois de reiniciar o Samba (ou aguardar o tempo de atualização após a

mudança no arquivo), a estação deixa o domínio e volta a fazer parte do grupo de
trabalho.
7.11.4. Configurando quota no servidor Storage
A fim de que não haja abusos em relação ao armazenamento dos dados no

disco do Storage, vamos colocar quota para os grupos! Vamos automatizar esta
tarefa por meio do script abaixo:
root@storage:~# vim /root/quota.sh

#!/bin/bash
clear
aptitude install quota quotatool -y
sed -i 's/remount-ro/remount-ro,usrquota,grpquota/g' /etc/fstab
mount -o remount /
quotacheck -cugmf
quotaon /
# Zerando as quotas
for i in $(seq 2001 2005) 100; do
quotatool -g $i -b -l +0MB -q +0MB -v /dev/sda1
quotatool -g $i -i -l +0 -q +0 -v /dev/sda1
done
# Configurando quota para os grupos
for i in $(seq 2001 2005) 100; do
quotatool -g $i -b -l +10000MB -q +9000MB -v /dev/sda1
quotatool -g $i -i -l +500000 -q +450000 -v /dev/sda1

done
Depois de executar o script, verifique a aplicação das quotas:
root@storage:~# mount | grep sda

/dev/sda1 on / type ext4 (rw,errors=remount-ro,usrquota,grpquota)
root@storage:~# ls -lh /aquota.*
-rw------- 1 root root 9,0K Jul 30 18:02 /aquota.group
-rw------- 1 root root 9,0K Jul 30 18:02 /aquota.user
root@storage:~# repquota -vga
Group used soft hard grace used soft hard grace
----------------------------------------------------------------------
...
users -- 3900 9216000 10240000 41 450000 500000
...
administrativo -- 16 9216000 10240000 4 450000 500000
comercial -- 1348 9216000 10240000 7 450000 500000
logistica -- 904 9216000 10240000 6 450000 500000
rh -- 904 9216000 10240000 6 450000 500000
suporte -- 48 9216000 10240000 12 450000 500000
...
Statistics:
Total blocks: 9
Data blocks: 2
Entries: 22
Used average: 11,000000
7.11.5. Configurando quota no servidor Datacenter para o Samba
Também podemos aplicar quota no Servidor Samba em relação ao mapeamento

dos arquivos dos usuários e do “roaming profile”. Vamos adaptar o script anterior:
root@datacenter:~# vim /root/quota-samba.sh

#!/bin/bash
aptitude install quota quotatool -y
# Configurando o servidor para acesso a quota

linha=$(grep -n samba /etc/fstab | awk -F: '{print$1}')
sed -i "$linha"s'/defaults/defaults,usrquota,grpquota/' /etc/fstab
# Remontando a partição
mount -o remount /dev/mapper/samba_vg-samba_lv
quotacheck -vacumfg
quotaoff /dev/mapper/samba_vg-samba_lv
quotaon /dev/mapper/samba_vg-samba_lv
# Zerando as quotas
for i in `seq 2001 2005` 100; do
quotatool -g $i -b -l +0MB -q +0MB -v /dev/mapper/samba_vg-
samba_lv
quotatool -g $i -i -l +0 -q +0 -v /dev/mapper/samba_vg-samba_lv
done
# Configurando quota para os grupos
for i in `seq 2001 2005` 100; do
quotatool -g $i -b -l +10000MB -q +9000MB -v
quotatool -g $i -i -l +500000 -q +450000 -v
done
Agora verifique a aplicação das quotas:
root@storage:~# mount | grep samba

/dev/mapper/samba_vg-samba_lv on /srv/samba type ext4
(rw,usrquota,grpquota)
root@storage:~# ls -lh /srv/samba/aquota.*
-rw------- 1 root root 7,0K Jul 30 19:09 /srv/samba/aquota.group
-rw------- 1 root root 8,0K Jul 30 19:09 /srv/samba/aquota.user
root@storage:~# repquota -vga
...
Group used soft hard grace used soft hard grace
----------------------------------------------------------------------
root -- 4 0 0 1 0 0
users -- 5764 9216000 10240000 488 450000 500000
administrativo -- 0 9216000 10240000 0 450000 500000
comercial -- 0 9216000 10240000 0 450000 500000

logistica -- 0 9216000 10240000 0 450000 500000
rh -- 0 9216000 10240000 0 450000 500000
suporte -- 0 9216000 10240000 0 450000 500000
...
Capítulo 8
Servidor DNS
8.1. Objetivos
• Entender o esquema de resolução de nomes;
• Realizar consultas DNS;
• Configurar uma zona de domínio DNS;
• Configurar uma zona reversa de domínio DNS;
• Sincronizar as zonas entre o DNS primário e secundário.

Capítulo 8 Servidor DNS - 164
8.2. Cenário
A empresa DEXTER COURIER precisa configurar um servidor DNS para que

os serviços disponibilizados por ela possam ser acessados externamente (Internet)
por nomes ao invés de IP. A empresa pretende registrar dois domínios junto ao
http://registro.br. Os domínios serão www.dexter.com.br e www.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 por meio do DNSSEC. Faremos o seguinte:
1 - Neste projeto, dois servidores, o primário e o secundário, devem ter um

mecanismo 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;
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

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

partir de ele 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

"explodiu". E passaram a existir muitos problemas com o HOST.TXT:
• Tráfego e Carga : os problemas com tráfego na rede e carga do processador

tornaram-se insuportáveis.
• 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
mesmos. 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
conseguia 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.
Ironicamente, 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.
8.4.1. Características
• Banco de dados hierárquico e distribuído representado no formato de uma

árvore 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 letras);
• 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
arquivo é 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".
8.5. Resolução
Soluçã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
"nameserver" consultado, pode ser:
• recursiva
• iterativa
8.5.1. Resolução Recursiva

Tomando um navegador web como exemplo, a resolução para acesso a um

"website" 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

"nameservers" 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

servidor 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.
8.5.2. 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
definitivamente ao questionamento apresentado, os servidores ".", "br.", "com.br.",
apenas informam que conhecem alguém mais preciso que eles. Essa é uma consulta
iterativa. Iteração, nesse caso, significa "apontar para o mais próximo
conhecido".
8.6. O arquivo "/etc/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:
Endereco_IP Hostname_canonico Aliases

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

opcionalmente "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, é

adequado 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
árvore. 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
arquivo "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. Por exemplo:
127.0.0.1 localhost
192.168.1.50 micro50.dexter.com.br. micro50
Pode ser acrescentadas quantas entradas forem necessárias, inclusive para IPs
externos. Atualmente, os sistemas baseados em Debian já contém entradas para
endereçamento "IPv6", que seguem a mesma lógica. Poderá ver isto executando:
root@dmz:~# cat /etc/hosts

127.0.0.1 localhost
127.0.1.1 debian. debian
# The following lines are desirable for IPv6 capable hosts

::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
8.7. Ferramentas de consulta
Caso ainda não estejam presentes, vamos instalar as ferramentas de pesquisa

de "DNS".
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
comportamento 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 problemas.
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 problemas 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

consultar 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.
8.8. Prática dirigida
Vamos fazer alguns testes com os comandos de pesquisa em DNS, começando

pelo "nslookup":
root@dmz:~# nslookup
> server
Default server: 4.2.2.2
Address: 4.2.2.2#53
> set all
Default server: 4.2.2.2
Address: 4.2.2.2#53
Set options:
novc nodebug nod2
search recurse
timeout = 0 retry = 3 port = 53
querytype = A class = IN
srchlist =
Buscando por registros de endereços IP, entrega de e-mails, autoridade sobre o

domínio e dados adicionais:
> www.uol.com.br.
Server: 4.2.2.2
Address: 4.2.2.2#53
Non-authoritative answer:
Name: www.uol.com.br
Address: 200.221.2.45
Name: www.uol.com.br
Address: 200.147.67.142
> set type=MX
> gmail.com.
Server: 4.2.2.2
Address: 4.2.2.2#53
gmail.com mail exchanger = 40 alt4.gmail-smtp-in.l.google.com.

gmail.com mail exchanger = 5 gmail-smtp-in.l.google.com.
Authoritative answers can be found from:
Exibir as informações do registro do domínio e SPF (item que iremos estudar

mais a frente):
> set type=SOA
> uol.com.br.
Server: 4.2.2.2
Address: 4.2.2.2#53
uol.com.br
origin = eliot.uol.com.br
mail addr = root.uol.com.br
serial = 2011072900
refresh = 7200
retry = 3600
expire = 432000
minimum = 3600

> set type=TXT
> terra.com.br.
Server: 4.2.2.2
Address: 4.2.2.2#53
terra.com.br text = "v=spf1 ip4:200.176.10.0/23 ip4:200.176.2.0/23
ip4:200.154.152.0/24 ip4:208.84.242.0/23 include:tmp-spf.terra.com.br
include:ti-spf.terra.com.br -all"

> exit
Antes de testarmos os comandos “host” e “dig”, devemos saber o significado de

algumas siglas, facilitando assim o entendimento e melhor aproveitamento deles.
SOA - Start Of Authotity (Autoridade Inicial) - Indica onde

começa a autoridade da zona;
NS - Name Server (Servidor de nomes) - Indica um servidor
de nomes para a zona;
A - Address (endereço IP) - Mapeamento de nome a
endereço (IPv4);
AAAA - Address (endereço IP) - Mapeamento de nome a
endereço (IPv6);
MX - Mail eXchanger (Smtp) - Indica um mail exchanger
para um nome (servidor de email);
CNAME - Canonical Name (Alias) - Mapeia um nome alternativo
(apelido);
PTR - Pointer Record (IP reverso);
Agora vamos experimentar o objetivo comando "host":
root@dmz:~# host -v www.4linux.com.br.

Trying "www.4linux.com.br"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48524
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.4linux.com.br. IN A
;; ANSWER SECTION:
www.4linux.com.br. 300 IN A 66.118.142.41
Received 51 bytes from 4.2.2.2#53 in 252 ms

;www.4linux.com.br. IN AAAA
;; AUTHORITY SECTION:
4linux.com.br. 60 IN SOA ns1.4linux.com.br.
postmaster.4linux.com.br. 2012030920 3600 3600 604800 86400

;www.4linux.com.br. IN MX
root@dmz:~# host -v -t mx 4linux.com.br.

Trying "4linux.com.br"
;4linux.com.br. IN MX
;; ANSWER SECTION:
4linux.com.br. 60 IN MX 10 boca.4linux.com.br.
root@dmz:~# host -v -t soa 4linux.com.br


;4linux.com.br. IN SOA
;; ANSWER SECTION:
root@dmz:~# host -v -t any 4linux.com.br

;4linux.com.br. IN ANY
;; ANSWER SECTION:
4linux.com.br. 58 IN TXT "v=spf1 ip4:200.212.122.137
ip4:200.212.122.142 ip4:201.6.255.3 ip4:200.212.122.139 ip4:66.118.187.158
ip4:64.16.195.45 ip4:64.16.195.44 include:spf.aknamail.com.br -all"
4linux.com.br. 298 IN A 66.118.142.41
4linux.com.br. 58 IN MX 10 boca.4linux.com.br.
4linux.com.br. 58 IN NS ns1.4linux.com.br.
4linux.com.br. 58 IN NS ns1.testdrive.4linux.com.br.
E finalmente, o "verborrágico" comando "dig":
root@dmz:~# dig www.4linux.com.br.

; <<>> DiG 9.7.3 <<>> www.4linux.com.br.

;; global options: +cmd
;; Got answer:
;; ANSWER SECTION:
;; Query time: 392 msec

;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Sun Jul 31 18:36:32 2011
;; MSG SIZE rcvd: 51
root@dmz:~# dig @8.8.8.8 www.4linux.com.br.

; <<>> DiG 9.7.3 <<>> @8.8.8.8 www.4linux.com.br.
; (1 server found)
;; Got answer:
;; ANSWER SECTION:

;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Jul 31 18:39:18 2011
root@dmz:~# dig -t mx gmail.com.

; <<>> DiG 9.7.3 <<>> -t mx gmail.com
;; Got answer:
;gmail.com. IN MX
;; ANSWER SECTION:
gmail.com. 1425 IN MX 40 alt4.gmail-smtp-in.l.google.com.
gmail.com. 1425 IN MX 5 gmail-smtp-in.l.google.com.
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Sun Jul 31 18:40:39 2011
root@dmz:~# dig -x 200.212.122.137

; <<>> DiG 9.7.3 <<>> -x 200.212.122.137
;; Got answer:
;137.122.212.200.in-addr.arpa. IN PTR
;; ANSWER SECTION:
137.122.212.200.in-addr.arpa. 43200 IN CNAME 137.128-
191.122.212.200.in-addr.arpa.
137.128-191.122.212.200.in-addr.arpa. 3600 IN PTR boca.4linux.com.br.

;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Sun Jul 31 18:41:29 2011
root@dmz:~# dig +trace www.4linux.com.br.

; <<>> DiG 9.7.3 <<>> +trace www.4linux.com.br.
. 30820 IN NS h.root-servers.net.
. 30820 IN NS l.root-servers.net.
. 30820 IN NS m.root-servers.net.
. 30820 IN NS i.root-servers.net.
. 30820 IN NS j.root-servers.net.
. 30820 IN NS d.root-servers.net.
. 30820 IN NS f.root-servers.net.
. 30820 IN NS e.root-servers.net.
. 30820 IN NS c.root-servers.net.
. 30820 IN NS a.root-servers.net.
. 30820 IN NS b.root-servers.net.
. 30820 IN NS k.root-servers.net.
. 30820 IN NS g.root-servers.net.
;; Received 228 bytes from 4.2.2.2#53(4.2.2.2) in 132 ms
br. 172800 IN NS c.dns.br.

br. 172800 IN NS f.dns.br.
br. 172800 IN NS a.dns.br.
br. 172800 IN NS d.dns.br.
br. 172800 IN NS b.dns.br.
br. 172800 IN NS e.dns.br.
;; Received 287 bytes from 192.5.5.241#53(f.root-servers.net) in 216 ms

;; Received 103 bytes from 200.189.40.10#53(b.dns.br) in 32 ms

4linux.com.br. 60 IN NS ns1.testdrive.4linux.com.br.
;; Received 147 bytes from 200.212.122.137#53(ns1.4linux.com.br) in 44
ms
8.9. 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
arquitetura 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:
root@dmz:~# aptitude install bind9
O arquivo principal chama-se "/etc/bind/named.conf" mas contém apenas

configuraçõ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.
root@dmz:~# ls -lh /etc/bind | tail -n7

-rw-r--r-- 1 root root 3,0K Mai 27 18:28 db.root
-rw-r--r-- 1 root bind 463 Mai 27 18:28 named.conf
-rw-r--r-- 1 root bind 490 Mai 27 18:28 named.conf.default-zones
-rw-r--r-- 1 root bind 165 Mai 27 18:28 named.conf.local
-rw-r--r-- 1 root bind 572 Mai 27 18:28 named.conf.options
-rw-r----- 1 bind bind 77 Jul 31 18:45 rndc.key
-rw-r--r-- 1 root root 1,3K Mai 27 18:28 zones.rfc1918
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 comandos 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:
root@dmz:~# netstat -nltup

tcp 0 0 192.168.110.3:53 0.0.0.0:* OUÇA 1602/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* OUÇA 1602/named
tcp 0 0 127.0.0.1:953 0.0.0.0:* OUÇA 1602/named
tcp6 0 0 :::53 :::* OUÇA 1602/named
tcp6 0 0 ::1:953 :::* OUÇA 1602/named
udp 0 0 192.168.110.3:53 0.0.0.0:* 1653/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 1653/named
udp 0 0 192.168.110.3:53 0.0.0.0:* 1602/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 1602/named
udp6 0 0 :::53 :::* 1653/named
udp6 0 0 :::53 :::* 1602/named
Instale o sniffer tcpdump:
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:
root@dmz:~# tcpdump -i eth0 -n port 53

tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet),capture size 65535 bytes
Em outro terminal execute:
root@dmz:~# dig @localhost -t any wikipedia.com
Verifique a saída do tcpdump:

19:11:52.396000 IP 192.168.X.3.33625 > 198.41.0.4.53: 12121 [1au] ANY?

wikipedia.com. (42)
19:11:52.396000 IP 192.168.X.3.29726 > 192.33.4.12.53: 39309 [1au] NS? .

(28)
19:11:52.544000 IP 192.33.4.12.53 > 192.168.110.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)
19:11:52.552000 IP 198.41.0.4.53 > 192.168.110.3.33625: 12121- 0/15/16

(737)
Os logs de seu servidor DNS estão em "/var/log/daemon.log". Verifique-os:
root@dmz:~# tail /var/log/daemon.log
No RedHat e Suse os eventos do serviço serão logados diretamente no

"/var/log/messages".
8.10. BIND como servidor cache
As bibliotecas do resolvedor da maioria dos sistemas operacionais não são

capazes 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
capacidade.
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
estaçã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 sobre 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:
root@dmz:~# dig @localhost -t soa kernel.org | tail -n6

;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Jul 31 19:33:54 2011
root@dmz:~# dig @localhost -t soa kernel.org | tail -n6

;; SERVER: 127.0.0.1#53(127.0.0.1)
;; 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:
root@dmz:~# vim /etc/resolv.conf

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/resolv.conf, podemos adicionar um atributo de proteção a ele, não permitindo
qualquer tipo de alteração:
root@dmz:~# chattr +i /etc/resolv.conf
8.11. 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á
liberado 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!
Para evitar este comportamento, vamos acrescentar a seguinte restrição no

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

allow-query { 127.0.0.1; 192.168.X.0/24; };
Para recarregar as modificações no "BIND", execute:
root@dmz:~# service bind9 restart

Stopping domain name service...: bind9 waiting for pid 1602 to die.
Starting domain name service...: bind9.
Dessa forma, o servidor só responderá para consultas originadas localmente!
Para carregar as modificações nos arquivos confs do Bind:

# rndc reconfig
É 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":

forwarders {
200.176.2.10;
};
Onde IP_DO_PROVEDOR é um servidor "DNS" capaz de fazer consultas

recursivas.
8.12. Servidor de zonas
Cada domínio na Internet tem sua autoridade, que nada mais é do que um
servidor 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.
8.12.1. 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 apenas 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 endereços dos 13 "root servers".
• forward - Serve para orientar o "BIND" a encaminhar a consulta sobre uma

determinada "zona" para outro servidor em especial. O encaminhamento de
consultas també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.
8.13. 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":
root@dmz:~# vim /etc/bind/named.conf.local

zone "dexter.com.br" {
type master;
file "db.dexter";
};
zone "mandark.com.br" {
type master;
file "db.mandark";
};
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.”
root@dmz:~# vim /var/cache/bind/db.dexter

$TTL 86400 ; default para todos os registros sem TTL
@ IN SOA ns1.dexter.com.br root.dexter.com.br. (
2011073101; serial
8h ; refresh
1h ; retry
3d ; expire
3h); negative caching ttl
;
@ IN NS ns1.dexter.com.br.
@ IN MX 10 mail.dexter.com.br.
ns1 IN A 192.168.X.3
www IN A 192.168.X.3
ftp IN CNAME www

mail IN A 192.168.X.3
smtp IN CNAME mail
webmail IN CNAME mail
pop IN CNAME mail
imap IN CNAME mail
Agora o domínio “mandark.com.br”:
root@dmz:~# vim /var/cache/bind/db.mandark

@ IN SOA ns1.mandark.com.br root.mandark.com.br. (
2011073101; serial
8h ; refresh
1h ; retry
3d ; expire
;
@ IN NS ns1.mandark.com.br.
ns1 IN A 192.168.X.3
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

secundário pára de responder por essa zona;
• negative caching TTL - Se a zona expirar, esse será o tempo pelo qual um
servidor "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:
root@dmz:~# named-checkconf /etc/bind/named.conf.options

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:
root@dmz:~# named-checkzone dexter.com.br db.dexter

zone dexter.com.br/IN: loaded serial 2011073101
OK
root@dmz:~# named-checkzone mandark.com.br db.mandark
zone mandark.com.br/IN: loaded serial 2011073101
OK
Reinicie o serviço do Bind9:

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

; <<>> DiG 9.7.3 <<>> @127.0.0.1 -t soa dexter.com.br
; (1 server found)
;; Got answer:
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;dexter.com.br. IN SOA
;; ANSWER SECTION:
dexter.com.br. 86400IN SOA ns1.dexter.com.br.dexter.com.br.
root.dexter.com.br. 2011073101 28800 3600 259200 10800
dexter.com.br. 86400IN NS ns1.dexter.com.br.
;; ADDITIONAL SECTION:
ns1.dexter.com.br. 86400IN A 192.168.110.3

;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Aug 1 13:04:16 2011
Agora com o domínio mandark.com.br:
root@dmz:~# dig @127.0.0.1 -t soa mandark.com.br

; <<>> DiG 9.7.3 <<>> @127.0.0.1 -t soa mandark.com.br
; (1 server found)
;; Got answer:
;mandark.com.br. IN SOA
;; ANSWER SECTION:
mandark.com.br. 86400IN SOA
ns2.mandark.com.br.mandark.com.br. root.mandark.com.br. 2011073101
28800 3600 259200 10800
mandark.com.br. 86400IN NS ns2.mandark.com.br.
ns2.mandark.com.br.86400IN A 192.168.110.3

;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Aug 1 13:10:46 2011
Vamos testar as configurações referente ao e-mail:
root@dmz:~# dig @127.0.0.1 -t mx dexter.com.br

; <<>> DiG 9.7.3 <<>> @127.0.0.1 -t mx dexter.com.br
; (1 server found)
;; Got answer:
;dexter.com.br. IN MX
;; ANSWER SECTION:
dexter.com.br. 86400IN MX 10 mail.dexter.com.br.
dexter.com.br. 86400IN NS ns1.dexter.com.br.
mail.dexter.com.br.86400IN A 192.168.110.3
ns1.dexter.com.br. 86400IN A 192.168.110.3

;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Aug 1 13:12:16 2011
Vamos efetuar um ping no domínio dexter.com.br:
root@dmz:~# ping -c2 www.dexter.com.br

PING www.dexter.com.br (192.168.110.3) 56(84) bytes of data.
64 bytes from 192.168.110.3: icmp_req=1 ttl=64 time=0.457 ms
--- www.dexter.com.br ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 999ms

rtt min/avg/max/mdev = 0.136/0.296/0.457/0.161 ms
Veja outros serviços do dexter.com.br:
root@dmz:~# ping -c2 mail.dexter.com.br

PING mail.dexter.com.br (192.168.200.3) 56(84) bytes of data.
--- mail.dexter.com.br ping statistics ---
root@dmz:~# ping -c2 ftp.dexter.com.br

PING www.dexter.com.br (192.168.200.3) 56(84) bytes of data.
--- www.dexter.com.br ping statistics ---
Agora no domínio mandark.com.br:
root@dmz:~# ping -c2 www.mandark.com.br

PING www.mandark.com.br (192.168.110.3) 56(84) bytes of data.
--- www.mandark.com.br ping statistics ---

Reinicie o Bind9 novamente e verifique o log:

root@dmz:~# tail -f /var/log/daemon.log
root@dmz:/var/cache/bind# tail -f /var/log/daemon.log
Aug 1 13:23:35 dmz named[1370]: zone 127.in-addr.arpa/IN: loaded
serial 1
Aug 1 13:23:35 dmz named[1370]: zone 255.in-addr.arpa/IN: loaded
serial 1
Aug 1 13:23:35 dmz named[1370]: zone dexter.com.br/IN: loaded serial
2011073101
Aug 1 13:23:35 dmz named[1370]: zone mandark.com.br/IN: loaded serial
2011073101
Aug 1 13:23:35 dmz named[1370]: zone localhost/IN: loaded serial 2
Aug 1 13:23:35 dmz named[1370]: managed-keys-zone ./IN: loading from
master file managed-keys.bind failed: file not found
Aug 1 13:23:35 dmz named[1370]: managed-keys-zone ./IN: loaded serial
0
Aug 1 13:23:35 dmz named[1370]: running
Aug 1 13:23:35 dmz named[1370]: zone dexter.com.br/IN: sending
notifies (serial 2011073101)
Aug 1 13:23:35 dmz named[1370]: zone mandark.com.br/IN: sending
8.13.1. Configurando o RNDC
O comando rndc (Remote Named Daemon Control) é uma ferramenta de

gerenciamento 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.”

include "/etc/bind/rndc.key";
controls {
inet 127.0.0.1 port 953 allow { localhost; } keys { "rndc-key"; };
};
type master;
file "db.dexter";
};
type master;
file "db.mandark ";
};
Para configurar o RNDC devemos primeiro gerar a chave criptográfica. Sendo

assim, execute:
root@dmz:~# cd /etc/bind
root@dmz:/etc/bind# rndc-confgen -r /dev/urandom -a
wrote key file "/etc/bind/rndc.key"
Veja a chave gerada:
root@dmz:/etc/bind# cat rndc.key

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

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

version: 9.7.3
CPUs found: 1
worker threads: 1
number of zones: 20
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running
Agora podemos executar os comando re reload com o rndc:
root@dmz:~# rndc reload

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

root@dmz:~# cat /var/cache/bind/named_dump.db
;
; Start view _default
;
;
; Cache dump of view '_default' (cache _default)
;
$DATE 20110802214224
;
; Address database dump
;
;
; Unassociated entries
;
;
; Bad cache
;
;
; Start view _bind
;
;
; Cache dump of view '_bind' (cache _bind)
;
$DATE 20110802214224
;
; Address database dump
;
;
; Unassociated entries
;
;
; Bad cache
;
; Dump complete
E para limpar o cache execute:
root@dmz:~# rndc flush
Lembramos que o arquivo de LOG é o “/var/log/daemon.log”. Execute:
root@dmz:~# tail -f -n12 /var/log/daemon.log

Aug 2 18:49:14 dmz named[1123]: managed-keys-zone ./IN: loading from
master file managed-keys.bind failed: file not found
Aug 2 18:49:14 dmz named[1123]: managed-keys-zone ./IN: loaded serial
0
Aug 2 18:49:14 dmz named[1123]: running
Aug 2 18:49:14 dmz named[1123]: zone dexter.com.br/IN: sending
Aug 2 18:49:14 dmz named[1123]: zone mandark.com.br/IN: sending
Aug 2 18:49:17 dmz named[1123]: received control channel command
'reload'
Aug 2 18:49:17 dmz named[1123]: loading configuration from
'/etc/bind/named.conf'
Aug 2 18:49:17 dmz named[1123]: reading built-in trusted keys from
file '/etc/bind/bind.keys'
Aug 2 18:49:17 dmz named[1123]: using default UDP/IPv4 port range:
[1024, 65535]
Aug 2 18:49:17 dmz named[1123]: using default UDP/IPv6 port range:
[1024, 65535]
Aug 2 18:49:17 dmz named[1123]: reloading configuration succeeded
Aug 2 18:49:17 dmz named[1123]: reloading zones succeeded
8.14. Configurando o DNS reverso
DNS reverso é um recurso que permite que outros servidores verifiquem a

autenticidade 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:

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

@ IN SOA ns1.dexter.com.br. root.dexter.com.br. (
2011073101; serial
8h ; refresh
1h ; retry
3d ; expire
;
ns1 IN A 192.168.X.3
3 IN PTR mail.dexter.com.br.
… inclua no final do arquivo da zona dexter.com.br …

...
@ IN MX 20 mail2.dexter.com.br.
mail2 IN A 192.168.X.2
Reinicie o Bind9:

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

...
;3.X.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
3.X.168.192.in-addr.arpa. 86400 IN PTR mail.dexter.com.br.
X.168.192.in-addr.arpa. 86400 IN NS ns1.dexter.com.br.
...
Como vimos, nosso DNS reverso está corretamente configurado!
8.15. Configurando o DNS secundário
Para registrarmos um domínio público, precisamos de pelo menos dois

servidores "DNS" respondendo pelo seu domínio. Isso significa um servidor
master (mestre) 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

disponibilidade, 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 mestre 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 escravo (secundário). Esta máquina será a “Datacenter”
Antes de configuramos a máquina slave, vamos deixar nosso bind autorizado a

transferir as zonas para esta máquina. Acrescente no arquivo “named.conf.local” o
que está em negrito:

include "/etc/bind/rndc.key";
controls {
inet 127.0.0.1 port 953 allow { localhost; } keys { "rndc-key"; };
};
type master;
file "db.dexter";
allow-transfer { 192.168.X.2; };
notify yes;
also-notify { 192.168.X.2; };
};
type master;
file "db.mandark";
allow-transfer { 192.168.X.2; };
notify yes;
also-notify { 192.168.X.2; };
};
zone "200.168.192.in-addr.arpa" {
type master;
file "db.rev";
};
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 servidores 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 chaves.
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:

...
; configuração do DNS secundário
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:
root@dmz:~# vim /var/cache/bind/db.mandark

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

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

Vamos agora efetuar a instalação e configuração do Bind9 na máquina

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

type slave;
file "db.dexter";
masters { 192.168.X.3; };
};
type slave;
file "db.mandark";
masters { 192.168.X.3; };
};
Reinicie o Bind9:
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:
root@datacenter:~# cat /var/log/daemon.log | grep named | grep trans

Aug 2 21:19:54 datacenter named[1815]: transfer of 'dexter.com.br/IN'
from 192.168.110.3#53: connected using 192.168.110.2#59881
Aug 2 21:19:54 datacenter named[1815]: zone dexter.com.br/IN:
transferred serial 2011073101
Aug 2 21:19:54 datacenter named[1815]: transfer of 'dexter.com.br/IN'
from 192.168.110.3#53: Transfer completed: 1 messages, 15 records, 397
bytes, 0.008 secs (49625 bytes/sec)
Aug 2 21:19:54 datacenter named[1815]: transfer of 'mandark.com.br/IN'
from 192.168.110.3#53: connected using 192.168.110.2#54614
Aug 2 21:19:54 datacenter named[1815]: zone mandark.com.br/IN:
transferred serial 2011073101
Aug 2 21:19:54 datacenter named[1815]: transfer of 'mandark.com.br/IN'

from 192.168.110.3#53: Transfer completed: 1 messages, 7 records, 216
bytes, 0.010 secs (21600 bytes/sec)
8.16. 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 somente na nossa rede:

...
allow-query { 127.0.0.1; 192.168.X.0/24; };
allow-recursion { 192.168.X.0/24; };
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
8.17. 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 ”:
root@dmz:~# vim /etc/bind/db.dexter

...
; configuração do SPF
@ 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.0/24 - Qualquer "host" da rede 192.168.X.0/24; qualquer outra

origem, descarte.
8.18. Mais testes...
Vamos agora testar os arquivos de configuração novamente:
root@dmz:~# named-checkconf /etc/bind/named.conf.options

root@dmz:~# named-checkconf /etc/bind/named.conf.local
root@dmz:~# named-checkzone dexter.com.br /var/cache/bind/db.dexter
OK
root@dmz:~# named-checkzone dexter.com.br /var/cache/bind/db.rev
OK
root@dmz:~# named-checkzone mandark.com.br /var/cache/bind/db.mandark
zone mandark.com.br/IN: loaded serial 2011073101
OK
Agora reinicie o Bind9:

8.18.1. 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:
root@datacenter:~# vim /etc/dhcp/dhcpd.conf

...
option domain-name-servers 192.168.X.3,192.168.X.2;

...
Agora basta reinicializar o serviço do DHCP:
root@datacenter:~# /etc/init.d/isc-dhcp-server restart
Vá na máquina “Squeeze” e rode comando abaixo:
root@squeeze:~# dhclient eth0 -v
Com isto iremos atualizar nosso “/etc/resolv.conf”, apontando para o DNS

localizado na rede. Visualize o arquivo:
root@squeeze:~# cat /etc/resolv.conf

domain dexter.com.br
search dexter.com.br
Capítulo 9
Servidor Apache
9.1. Objetivos
• Entender a configuração básica do Apache e realizar ajustes finos;
• Instalar PHP e o SGBD MySQL;
• Configurar Virtualhost (domínio virtual) para o site da Dexter e Mandark;
• Instalação do Moodle;
• Habilitar suporte a SSL;
• Ativar o módulo BW para limitar a banda para download.

Capítulo 9 Servidor Apache - 207
9.2. 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.
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";
• multi plataforma;
• possui suporte a várias funcionalidades providas por módulos;

• pode trabalhar com multi "threads", isto é, multi processos.
9.5. 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
compatibilidade com aplicações antigas, por exemplo. Vamos entender as
particularidades dos modos "PreFork" e "Worker".
9.5.1. 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 existentes. Este modo é ideal para quem precisa manter compatibilidade
com aplicações e bibliotecas que NÃO SUPORTAM o modo "thread".
9.5.2. 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.
9.5.3. O que é o Moodle?
Moodle é um Sistema Open Source de Gerenciamento de Cursos - Course

Management 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.
9.6. 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 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”:
root@dmz:~# mount -o remount,rw,exec /tmp

root@dmz:~# aptitude install apache2 libapache2-mod-php5
root@dmz:~# aptitude install php5 php5-curl php5-gd php5-intl \
php5-xmlrpc php5-mysql php-pear
root@dmz:~# mount -o remount,rw,noexec /tmp
Após a instalação, abra um browser e digite:
http://192.168.X.3
9.7. 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:
root@dmz:~# vim /etc/apache2/apache2.conf
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
Já a variável "DocumentRoot" diz ao Apache aonde procurar os sites que devem

ser apresentados aos usuários. Por padrão, os sites serão armazenados em
"/var/www":
DocumentRoot /var/www
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":
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:
• %h - "Hostname" ou endereço IP do visitante;
• %l - Hífen;
• %u - Nome de usuário, caso exista;
• %t - Horário de acesso;
• %r - Requisição solicitada;
• %>s - O resultado da solicitação ;
• %b - O tamanho em bytes da resposta;
• Refereri - O site anterior a visita, se informado;
• User-Agenti - O navegador do visitante, se informado.
A prova pode perguntar sobre as variáveis "ErrorLog", "CustomLog",

"ServerRoot" e "DocumentRoot".
9.7.1. 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 configurado para trabalhar em "MPM Worker", então, vamos entender suas
configurações:
StartServers 2 - configura o número inicial de servidores;

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

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

desenvolvedores 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:
root@dmz:~# ls -lh /etc/apache2/mods-enabled | grep php

lrwxrwxrwx 1 root root 27 Ago 3 20:21 php5.conf -> ../mods-
available/php5.conf
lrwxrwxrwx 1 root root 27 Ago 3 20:21 php5.load -> ../mods-
available/php5.load
root@dmz:~# apache2ctl -M | grep php
Syntax OK
php5_module (shared)
O PHP5 é ativado por padrão durante a instalação do módulo, porém, caso

necessário, habilite o suporte manualmente:
root@dmz:~# a2enmod php5
Se precisar descarregar um módulo, use a sintaxe:

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:
root@dmz:~# service apache2 restart

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":
root@dmz:~# vim /var/www/index.php

<?
phpinfo()
?>
Agora, acesse o browser e digite na URL o endereço do servidor Web e o

arquivo que acabou de criar:
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

funcionamento 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.
9.9. Arrumando os diretórios
Vamos criar a seguinte estrutura na máquina “DMZ” (192.168.X.3):
root@dmz:~# mkdir -p /srv/www/dexter

root@dmz:~# mkdir -p /srv/www/mandark
root@dmz:~# ls -lh /srv/www/
drwxr-xr-x 2 root root 4,0K Ago 3 21:53 dexter

drwxr-xr-x 2 root root 4,0K Ago 3 21:54 mandark
Baixe do servidor da sala de aula o pacote do Moodle chamado moodle.tgz e

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

root@dmz:~# mkdir -p /srv/www/mandark/moodledata
Vamos criar o usuário “webdesign” para ter acesso ao nosso site e ao Moodle.
root@dmz:~# adduser webdesign
Agora vamos mudar as permissões de acesso:
root@dmz:~# chown -R webdesign:webdesign /srv/www/dexter

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

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

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

utf8_unicode_ci;
Query OK, 1 row affected (0.04 sec)
Dê privilégios para o usuário moodleuser em localhost:

mysql> grant all privileges on moodle.* to moodleuser@'%' identified by

'123456' with grant option;
Query OK, 0 rows affected (0.03 sec)
Caso haja algum problema e você deseje remover os privilégios do usuário na

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

+--------------------+
| Database |
+--------------------+
| information_schema |
| moodle |
| mysql |
+--------------------+
3 rows in set (0.00 sec)
Reinicie o serviço do mysql:
root@datacenter:~# service mysql restart

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

safe_mode = Off # linha 338
memory_limit = 128M # linha 458
register_globals = Off # linha 691
post_max_size = 16M # linha 728 => alterar
magic_quotes_gpc = Off # linha 744
magic_quotes_runtime = Off # linha 748

file_uploads = On # linha 870
upload_max_filesize = 100M # linha 879 => alterar
session.save_handler = files # linha 1401
session.auto_start = 0 # linha 1452
session.bug_compat_warn = Off # linha 1536
###### Acrescente no final do arquivo:
extension = mysql.so
extension = gd.so
9.11. VirtualHost?
O que é um VirtualHost? É um Domínio Virtual (ou VirtualHost) é uma

funcionalidade que permite ao seu WebServer responder 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 correta 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 limitados!
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 arquivos de configuração localizados no diretório citado anteriormente).
9.12. Criando Virtualhost para nossos domínios
Vamos configurar o Virtualhost do domínio mandark.com.br:
root@dmz:~# vim /etc/apache2/sites-available/mandark.com.br

<VirtualHost *:80>
DocumentRoot /srv/www/mandark/moodle/
ServerName www.mandark.com.br
ServerAdmin root@mandark.com.br
ErrorLog /var/log/apache2/mandark-error.log
CustomLog /var/log/apache2/mandark-access.log common

</VirtualHost>
Agora vamos configurar o Virtualhost do domínio dexter.com.br:
root@dmz:~# vim /etc/apache2/sites-available/dexter.com.br

<VirtualHost *:80>
DocumentRoot /srv/www/dexter/
ServerName www.dexter.com.br
ServerAdmin root@dexter.com.br
ErrorLog /var/log/apache2/dexter-error.log
CustomLog /var/log/apache2/dexter-access.log common
</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:
root@dmz:~# a2ensite dexter.com.br

Enabling site dexter.com.br.
Run '/etc/init.d/apache2 reload' to activate new configuration!
root@dmz:~# a2ensite mandark.com.br
Enabling site mandark.com.br.

9.13. Fechando brechas de segurança
Antes de reforçarmos a segurança do servidor , vamos executar o nmap:

root@dmz:~# nmap -sV localhost

...
53/tcp open domain ISC BIND 9.7.3
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!
root@dmz:~# vim /etc/apache2/conf.d/security

ServerTokens Prod
ServerSignature Off
TraceEnable Off
As opções do “ServerTokens” são: (em negrito a melhor opção)
ServerTokens Prod - Revela somente o nome do produto;

caso scaneado só apareceria o nome
"Apache"
ServerTokens Min - Revela Produto e a versão:

Apache 2.2.29
ServerTokens OS - Revela: Produto, Versão e o Sistema

Operacional: Apache/2.2.9 (Unix)
ServerTokens Full - Revela: Produto, Versão, OS e Módulos
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:

root@dmz:~# nmap -sV localhost

...
53/tcp open domain ISC BIND 9.7.3
80/tcp open http Apache httpd
...
Vamos testar a configuração do Apache.
root@dmz:~# apache2ctl -S
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:80 is a NameVirtualHost
default server dmz.dexter.com.br (/etc/apache2/sites-
enabled/000-default:1)
port 80 namevhost dmz.dexter.com.br (/etc/apache2/sites-
enabled/000-default:1)
port 80 namevhost www.dexter.com.br (/etc/apache2/sites-
enabled/dexter.com.br:1)
port 80 namevhost www.mandark.com.br (/etc/apache2/sites-
enabled/mandark.com.br:1)
Syntax OK
9.14. Configurando o Moodle
Vamos realizar a configuração do Moodle, que deverá ser acessado através do

domínio mandark.com.br. Abra o browser e acesse o site do Moodle:
No Navegador, 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! Vamos lá!
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.
9.15. Disponibilizando o site da Dexter Courier
Baixe do servidor o arquivo contendo o site da Dexter e depois descompacte-o:
root@dmz:~# tar xzvf site.dextercourier.tar.gz -C /srv/www/
9.16. Ativando o SSL
SSL (Secure Socket Layer) é o protocolo que encripta toda a transmissão

entre o cliente 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

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

referentes 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.
9.16.2. Gerando o site seguro da Dexter
Para instalar e configurar as chaves e o certificado, execute:
root@dmz:~# aptitude install openssl

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

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

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

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

campos conforme forem pedidos:
root@dmz:~# openssl req -new -key /etc/ssl/dexter.key -out

/etc/ssl/dexter.csr
You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a
DN. There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:BR
State or Province Name (full name) [Some-State]:São Paulo
Locality Name (eg, city) []:São Paulo
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Dexter
Courier
Organizational Unit Name (eg, section) []:Depto. TI
Common Name (eg, YOUR name) []:Admin
Email Address []:root@dexter.com.br
Please enter the following 'extra' attributes to be sent with your
certificate request
A challenge password []:
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:
root@dmz:~# openssl x509 -req -days 365 -in /etc/ssl/dexter.csr

-signkey /etc/ssl/dexter.key -out /etc/ssl/dexter.crt
Signature ok
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
Getting Private key
Agora basta adicionar a configuração do certificado digital no final do arquivo

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

...
<VirtualHost *:443>
DocumentRoot /srv/www/dexter/
ServerName www.dexter.com.br
ErrorLog /var/log/apache2/dexter-error.log
CustomLog /var/log/apache2/dexter-access.log common
SSLEngine on
SSLCertificateFile /etc/ssl/dexter.crt
SSLCertificateKeyFile /etc/ssl/dexter.key
</VirtualHost>
Crie um arquivo chamado .htaccess dentro do diretório /srv/www/dexter/ e

coloque o seguinte conteúdo:
root@dmz:~# vim /srv/www/dexter/.htaccess

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.dexter.com.br/$1 [R,L]
Explicando:
RewriteEngine - Ativa o modo rewrite.
RewwriteCond - Força https para você poder usar com segurança a

autenticação HTTP no diretório.
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.
Sobre a linha ( RewriteRule ^(.*)$ https://www.dexter.com.br/$1 [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
automaticamente redirecionado para o site com HTTPS ativado:
root@dmz:~# a2enmod rewrite

Enabling module rewrite.
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.
Acesse o endereço ...
http://www.dexter.com.br
… e você será redirecionado para o site seguro.

Clique em “Adicionar exceção”.

Clique em “Obter Certificado”, depois deve ticar a opção “Salvar esta exceção
permanentemente” e por último em “Confirmar exceção de segurança”.
9.16.3. Gerando o site seguro do Mandark EaD
Vamos agora gerar o certificado digital do Mandark Ead, nosso ambiente de

aprendizagem no Moodle. Vamos iniciar criando a chave que será usada para assinar
o certificado:
root@dmz:~# openssl genrsa -out /etc/ssl/mandark.key 1024

................................................................++++++
..........................................++++++
e is 65537 (0x10001)
Crie o certificado digital:
root@dmz:~# openssl req -new -key /etc/ssl/mandark.key -out

/etc/ssl/mandark.csr
-----
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Mandark EaD
Please enter the following 'extra' attributes
to be sent with your certificate request
Depois de criar o certificado, vamos auto assinar:

root@dmz:~# openssl x509 -req -days 365 -in /etc/ssl/mandark.csr

-signkey /etc/ssl/mandark.key -out /etc/ssl/mandark.crt
Signature ok
subject=/C=BR/ST=S\xC3\xA3o Paulo/L=S\xC3\xA3o Paulo/O=Mandark
EaD/OU=Depto. TI/CN=Admin/emailAddress=root@dexter.com.br
Getting Private key
Abra o arquivo referente ao domínio mandark.com.br e acrescente no final:

...
<VirtualHost *:443>
DocumentRoot /srv/www/mandark/
ErrorLog /var/log/apache2/mandark-error.log
CustomLog /var/log/apache2/mandark-access.log common
SSLEngine on
SSLCertificateFile /etc/ssl/mandark.crt
SSLCertificateKeyFile /etc/ssl/mandark.key
</VirtualHost>
Crie o arquivo .htaccess dentro do diretório /srv/www/mandark e coloque o

seguinte conteúdo:
root@dmz:~# vim /srv/www/mandark/.htaccess

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.mandark.com.br/$1 [R,L]
Reinicie o Apache para testar:
O comando "openssl" e suas funções e opções podem ser cobrados no

Exame da LPI.
Não podemos de esquecer de utilizar sempre o "SSL", para que os dados

sejam transmitidos através de uma conexão criptografada, verificando a
autenticação do servidor e do cliente através dos certificados.
9.17. Ativando o controle de banda
O que é o módulo BW? É um módulo muito útil para controle de banda, ou

seja, você pode limitar a taxa de download em um Virtualhost. Vamos à instalação:
root@dmz:~# aptitude install libapache2-mod-bw
Com o módulo instalado, vamos ativá-lo:
root@dmz:~# a2enmod bw
Module bw already enabled
Opções do módulo bw:
• BandWidthModule [On|Off] - On – ativa o módulo (por padrão o módulo é

desabilitado);
• ForceBandWidthModule [On|Off] - On – Qualquer requisição será processada

pelo módulo bw;
• BandWidth [From] [bytes/s] - Limitar a velocidade de transferência de arquivos

para um host, rede ou domínio em bytes por segundo.
Exemplo:
BandWidth localhost 10240 - o localhost fica limitado a 10kbps
BandWidth 192.168.0.5 0 - o host 192.168.0.5 não tem limite por

causa do zero
• LargeFileLimit [Type] [Minimum Size] [bytes/s] -
Exemplo:
LargeFileLimit .avi 500 10240 - Limita arquivos “.avi” maiores ou igual a

500kb para 10kbps
• MinBandWidth [From] [bytes/s]

Exemplo:
BandWidth all 102400

MinBandWidth all 50000
A velocidade máxima será de 100kbps para um cliente. Se mais clientes

fizerem download, a velocidade mínima será de 50kbps para cada.
Exemplo:
BandWidth all 50000

MinBandWidth all -1
Neste exemplo, qualquer terá no máximo 50kbps de velocidade máxima.
Vamos configurar o Apache para limitar qualquer usuário para um máximo de

100kbps de download:
root@dmz:# vim /etc/apache2/sites-available/mandark.com.br

<VirtualHost *:80>
ErrorLog /var/log/apache2/teste-mandark-error.log
CustomLog /var/log/apache2/teste-mandark-access.log common
BandwidthModule On
ForceBandWidthModule On
Bandwidth all 102400
MinBandwidth all -1
</VirtualHost>
Limitando todos os usuários da rede local para 1000 kbps com um mínimo de
50 kbps e arquivos maiores que 500 kb para 50kbps:

<VirtualHost *:80>
BandwidthModule On
Bandwidth all 1024000

MinBandwidth all 50000
LargeFileLimit * 500 50000
</VirtualHost>
Limita arquivos com extensão avi e mpg para 20kbps:

<VirtualHost *:80>
BandwidthModule On
LargeFileLimit .avi 1 20000
LargeFileLimit .mpg 1 20000
</VirtualHost>
Após alterar as configurações do virtualhost, recarregue o Apache:
root@dmz:~# service apache2 reload

Reloading web server config: apache2.
Agora, é só testar como cliente tentando fazer download de um arquivo grande

que deve ser colocado em /srv/www/mandark.
Observação: Você deve ajustar as velocidades dos exemplos dos slides

anteriores de acordo com as possibilidades do seu link.
Capítulo 10
Servidor FTP
10.1. Objetivos
• Instalar e configurar um servidor FTP;
• Entender as diferenças entre FTP passivo e ativo;
• Utilizar linha de comando para download e upload de aquivos;
• Permitir a utilização do FTP pelo WebDesigner para update do site;
• Configurar o FTP com proteção a “chroot”.

Capítulo 10 Servidor FTP - 240
10.2. 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
Apache, 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
bloquearmos o acesso aos demais diretórios do sistema com proteção “chroot”.
O FTP (File Transfer Protocol) é um protocolo simples para transferência de

arquivos. O cliente "FTP" faz uma solicitação ao servidor "FTP", a seção é
estabelecida e 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 "anonymous" 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
funcionamento 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
momento, 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

empresas 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/Linux, 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 seguro 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.
10.5. 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:
root@dmz:~# mount -o remount,rw,exec /tmp

root@dmz:~# aptitude install vsftpd
root@dmz:~# mount -o remount,rw,noexec /tmp
Após instalar, vamos abrir o arquivo de configuração “/etc/vsftpd.conf ” e

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

listen=Yes
## Permite a utilização do FTP com o usuário anonymous

anonymous_enable=No
## Habilitar a variável que permite que os usuários do sistema possam

## usar o servidor FTP:
local_enable=Yes
## Variável que permite o upload para os usuários:

write_enable=Yes
## Permite a exibição de mensagens aos usuários

dirmessage_enable=Yes
## Ativa os logs para downloads e uploads

xferlog_enable=Yes
## Utiliza a porta FTP-DATA para transferência de arquivos (vamos usar

## FTP Passivo)
connect_from_port_20=No
## Definindo timeout para sessão e conexão de dados em 2 minutos (120

## segundos)
idle_session_timeout=120
data_connection_timeout=120
## Não permitir que o usuário veja arquivos que não sejam seus
chroot_local_users=YES
## Habilita o uso do PAM

pam_service_name=vsftpd
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á:
/srv/www/dexter
Verifique as permissões, dono e grupo deste diretório e...
root@dmz:~# ls -ld /srv/www/dexter

drwxr-xr-x 5 webdesign webdesign 4,0K Ago 5 20:13 /srv/www/dexter
… realize as alterações abaixo depois verifique as mudanças:
root@dmz:~# chown -R webdesign.webdesign /srv/www/dexter/

root@dmz:~# chmod -R 775 /srv/www/dexter/
root@dmz:~# ls -ld /srv/www/dexter/
drwxrwxr-x 5 webdesign webdesign 4,0K Ago 5 20:13 /srv/www/dexter
root@dmz:~# usermod -d /srv/www/dexter webdesign
root@dmz:~# grep web /etc/passwd
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:
root@dmz:~# grep root /etc/ftpusers

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:
root@dmz:~# vim /srv/www/dexter/.message

============================================================
## Este sistema é para uso exclusivo da empresa DEXTER.
## Todas as atividades serão registradas.
## É vetada a utilização deste sistema para transferência de
## arquivos protegidos por qualquer lei de direito autoral
## ou arquivos que infrinjam a legislação vigente.
============================================================
Após escrever a mensagem, salve o arquivo e reinicie o serviço FTP:

root@dmz:~# service vsftpd restart

Stopping FTP server: vsftpd.
Starting FTP server: vsftpd.
Verifique em qual porta o servidor "FTP" está escutando:
root@dmz:~# netstat -ltupan

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 “Squeeze”:
root@squeeze:~# aptitude install ftp
Concluída a instalação, acesso o FTP pelo modo texto:
root@squeeze:~# ftp ftp.dexter.com.br

Connected to www.dexter.com.br.
220 (vsFTPd 2.3.2)
Name (ftp.dexter.com.br:root): webdesign
331 Please specify the password.
Password:
230-============================================================
230-## Este sistema é para uso exclusivo da empresa DEXTER.
230-## Todas as atividades serão registradas.
230-## É vetada a utilização deste sistema para transferência de
230-## arquivos protegidos por qualquer lei de direito autoral
230-## ou arquivos que infrinjam a legislação vigente.
230-============================================================
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
10.6. 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 implementam. A maioria dos clientes "FTP" comerciais

implementam apenas um pequeno 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 comandos, 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":
## Para saber em qual diretório se encontra:

ftp> pwd
## Para saber em qual diretório se encontra (lado cliente):

ftp> !pwd
## Para trocar de diretórios dentro do servidor:

ftp> cd <diretório>
## Para voltar um diretório:

ftp> cd ..
## Para listar o conteúdo do diretório atual:

ftp> ls
## Para listar os diretórios locais (lado cliente):

ftp> !ls
## Para mudar de diretório na máquina cliente:

ftp> lcd <diretório>
## Para realizar o download de um arquivo:

ftp> get <arquivo>
## Para realizar múltiplos downloads:

ftp> mget *
## Para realizar o upload de um arquivo:

ftp> put <arquivo>
## Para realizar múltiplos uploads:

ftp> mput *
## Para uma lista completa de comandos:

ftp> help
Para verificar os logs do ftp, execute:
root@dmz:~# cat /var/log/vsftpd.log

Tue Aug 9 22:35:50 2011 [pid 2] CONNECT: Client "192.168.110.10"
Tue Aug 9 22:35:56 2011 [pid 1] [webdesign] OK LOGIN: Client
"192.168.110.10"
Tue Aug 9 22:36:12 2011 [pid 3] [webdesign] OK DOWNLOAD: Client
"192.168.110.10", "/index.php", 4621 bytes, 282.04Kbyte/sec
10.7. 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, Windows e Mac OS. Para instalar no GNU/Linux basta digitarmos na
máquina “Squeeze”:
root@dmz:~# aptitude install filezilla
Para abrir o aplicativo, vá em Aplicativos → Internet → Filezilla. Na tela que

abrir, entre com os seguintes dados:
Host: ftp.dexter.com.br
Usuário: webdesign
Senha: 123456
Porta: 21
Será estabelecida a conexão e nosso Webdesign poderá atualizar o site!

Capítulo 11
Servidor Postfix
11.1. Objetivos
• Entender os conceitos sobre MTA, MUA e MDA;
• Instalar e configurar o MTA Postfix;
• Uso de Mailbox e Maildir;
• Configurando contas de e-mail e criação de alias;
• Acesso via POP, IMAP e pelo Webmail;
• Autenticando os usuários no MTA;
• O que é e como configurar o TLS.

Capítulo 11 Servidor Postfix - 250
11.2. Cenário
Hoje em dia é muito raro uma empresa não possuir uma conta de e-mail! A
comunicaçã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.
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 comando executado sobre o protocolo TCP, cujo objetivo é transmitir mensagens
de e-mail dentre dois computadores. A porta utilizada pelo protocolo SMTP é a 25.
11.5. Introdução ao Postfix
Na década de 70, as primeiras mensagens eram enviadas pela "ARPAnet",

antecessora da atual Internet. A troca de mensagens era feita em sua maioria por
estudantes, 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
funcionamento. 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
executado 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.
11.6. Características do Postfix
• Sistema multitarefa - O "Postfix" possui um conjunto de módulos que

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

restringe 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.
11.7. Laboratório
Na máquina “DMZ”, execute:
root@dmz:~# aptitude install postfix

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

Remover os pacotes a seguir:
1) exim4
2) exim4-base
3) exim4-config
4) exim4-daemon-light
Aceitar esta solução? [Y/n/q/?] Y

Os NOVOS pacotes a seguir serão instalados:
postfix python{a} python-minimal{a} python2.6{a} python2.6-
minimal{a}
Os pacotes a seguir serão REMOVIDOS:
exim4{a} exim4-base{a} exim4-config{a} exim4-daemon-light{a}
0 pacotes atualizados, 5 novos instalados, 4 a serem removidos e 32 não
atualizados.
É preciso obter 5341 kB de arquivos. Depois do desempacotamento, 14,3
MB serão usados.
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”, onde o e-mail será enviado e recebido
utilizando o protocolo SMTP.
Depois, na tela abaixo, digite o domínio da Dexter – dexter.com.br
Somente por curiosidade, veja as configurações de seu MTA e depois o total:
root@dmz:~# postconf | tail -n15 ; echo ; postconf | wc -l
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,

exceto se a mensagem a ser excluída for a última);
• 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:
root@dmz:~# vim /etc/postfix/main.cf

## Banner que será mostrado nas conexões. É importante mudar.
smtpd_banner = MTA da Dexter - Servidor $myhostname
## Modificar o domínio caso o MUA não fizer corretamente, mas
## deixamos ativado, pois isso é trabalho do próprio MUA.
append_dot_mydomain = yes
## Nessa opção, precisamos colocar o hostname da máquina e o
## domínio que é conhecido como FQDN.
myhostname = dmz
## Arquivos onde são configurados os alias de e-mails.
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
## Define a origem local, que por padrão é o mesmo FQDN que está em
## /etc/mailname.
myorigin = dexter.com.br
## Domínios que o seu servidor pode receber mensagens.
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
## Essa opção só é usada se o seu servidor faz Relay para outros
## servidores de e-mail.
relayhost =
## Nesse campo deveremos colocar apenas os IP's que podem realmente
## fazer relay em seu servidor. CUIDADO, se adicionarmos IP's ou
## classes demais, o servidor poderá virar alvo de spammers.
mynetworks = 127.0.0.0/8 192.168.X.0/24
## Padrão de entrega das mensagens. Nesse caso é usado o mbox.
mailbox_command = procmail -a "$EXTENSION"
## Tamanho máximo de caixa-postal para entrega local
mailbox_size_limit = 0
## Interfaces de rede na qual o Postfix pode fazer bind, ou seja,
## estabelecer conexões. O padrão do Debian seria todas as interfaces.
inet_interfaces = all
## Tamanho máximo da mensagem
message_size_limit = 25000000
## Em alguns clientes, podemos adicionar um sinal espacial ao endereço
## de e-mail para direcionar mensagens a uma determinada pasta

recipient_delimiter = +
Agora vamos reiniciar o Postfix:
root@dmz:~# service postfix restart

Stopping Postfix Mail Transport Agent: postfix.
Starting Postfix Mail Transport Agent: postfix.
Veja se a porta 25 (smtp) está pronta para receber conexões:
root@dmz:~# netstat -nltup | grep master

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:
root@dmz:~# vim postfix-users.sh

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

root@dmz:~# telnet mail.dexter.com.br 25
Trying 192.168.110.3...
Connected to mail.dexter.com.br.
Escape character is '^]'.
220 MTA da Dexter - Servidor dmz.dexter.com.br
helo mail
250 dmz.dexter.com.br
mail from: neo@matrix.com
250 2.1.0 Ok
rcpt to: dexterclem@dexter.com.br
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
subject: Teste de e-mail
Nosso MTA é dezzzzzzzz...
.
250 2.0.0 Ok: queued as 4E20069
quit
221 2.0.0 Bye
Connection closed by foreign host.
Agora verifique o e-mail enviado para o usuário Dexter Clem:
root@dmz:~# cat /var/spool/mail/dexterclem

From neo@matrix.com Thu Aug 11 20:15:02 2011
Return-Path: <neo@matrix.com>
X-Original-To: dexterclem@dexter.com.br
Delivered-To: dexterclem@dexter.com.br
Received: from mail (dmz.dexter.com.br [192.168.110.3])
by dmz (Postfix) with SMTP id 5CC607CF
for <dexterclem@dexter.com.br>; Thu, 11 Aug 2011 20:14:02 -0300
(BRT)
subject: teste de e-mail
Message-Id: <20110811231420.5CC607CF@dmz>
Date: Thu, 11 Aug 2011 20:14:02 -0300 (BRT)
From: neo@matrix.com
To: undisclosed-recipients:;
Nosso MTA é dezzzzz.....
Para verificar a lista de e-mails no servidor, execute:
root@dmz:~# mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
E96607C9 2218 Thu Aug 11 20:09:18 MAILER-DAEMON
(host mx.matrix.com.br[200.196.28.57] refused to talk to me: 450 4.7.1
Client host rejected: cannot find your hostname, [187.37.193.136])
neo@matrix.com.br
-- 2 Kbytes in 1 Request.
11.7.1. 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:
root@dmz:~# aptitude install courier-authdaemon courier-authlib

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

### comentar:
# mailbox_command = procmail -a "$EXTENSION"
### adicionar:
home_mailbox = Maildir/
DEFAULT=$HOME/Maildir/
MAILDIR=$HOME/Maildir/
Reinicie o serviço do Postfix:
Precisamos também criar mais um arquivo do PAM referente ao "smtp":
root@dmz:~# cat /etc/pam.d/pop3

@include common-auth
@include common-account
@include common-password
@include common-session
root@dmz:~# cat /etc/pam.d/imap
@include common-auth
@include common-account
@include common-password
@include common-session
root@dmz:~# cp /etc/pam.d/pop3 /etc/pam.d/smtp
11.7.2. Criando caixas postais
Vamos agora criar as caixas postais. Para isto vamos criar uma script:
root@dmz:~# vim maildir.sh

#!/bin/bash
maildirmake /home/$lista/Maildir
maildirmake /home/$lista/Maildir/.Enviadas
maildirmake /home/$lista/Maildir/.Rascunhos
maildirmake /home/$lista/Maildir/.lixeira
maildirmake /home/$lista/Maildir/.Spam
chown -R $lista:users /home/$lista
done
O comando "maildirmake" faz parte do pacote "Courier", veja este site:

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

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

tcp6 0 0 :::110 :::* OUÇA 3742/couriertcpd
Agora teste a nova caixa postal:
root@dmz:~# echo "Reuniao amanha as 15hs." | mail -s "Reuniao com \

Cliente 4Linux" -r mandarkglory@dexter.com.br dexterclem@dexter.com.br
root@dmz:~# cat \
/home/dexterclem/Maildir/new/1313109656.Vfd00I607a1M156000.dmz
Return-Path: <mandarkglory@dexter.com.br>
Received: by dmz (Postfix, from userid 0)
id 222E07E1; Thu, 11 Aug 2011 21:40:56 -0300 (BRT)
Date: Thu, 11 Aug 2011 21:40:56 -0300
From: mandarkglory@dexter.com.br
To: dexterclem@dexter.com.br
Subject: Reuniao com Cliente 4Linux
Message-ID: <4e447698.M8zZc0OB8yim8VHd%mandarkglory@dexter.com.br>
User-Agent: Heirloom mailx 12.4 7/29/08
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reuniao amanha as 15hs.
Teste com o telnet a conexão POP3 na porta 110:
root@dmz:~# telnet localhost 110

Trying 127.0.0.1...
Connected to localhost.
+OK Hello there.
user dexterclem <<<------ Comando para logar com usuário
+OK Password required.
pass 123456 <<<------ Comando para inserir a senha do usuário
+OK logged in.
list <<<------ Comando para listar as mensagens
+OK POP3 clients that break here, they violate STD53.
1 592
.
Retr 1 <<<<<<------------ Comando para ver a mensagem nº “x”
+OK 592 octets follow.
id 222E07E1; Thu, 11 Aug 2011 21:40:56 -0300 (BRT)
Date: Thu, 11 Aug 2011 21:40:56 -0300
MIME-Version: 1.0

.
quit <<<------ Comando para deslogar do telnet
+OK Bye-bye.
Teste agora com o telnet a conexão IMAP na porta 143:
root@dmz:~# telnet localhost 143

Trying 127.0.0.1...
Connected to localhost.
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE
THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION]
Courier-IMAP ready. Copyright 1998-2010 Double Precision, Inc. See
COPYING for distribution information.
a login dexterclem 123456 <<<------ Comando para logar: usuário +
senha; o “a” é apenas entrada de comando
* OK [ALERT] Filesystem notification initialization error -- contact
your mail administrator (check for configuration errors with the
FAM/Gamin library)
a OK LOGIN Ok.
a select inbox <<<------ Comando selecionar caixa postal
* FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent)
* OK [PERMANENTFLAGS (\* \Draft \Answered \Flagged \Deleted \Seen)]
Limited
* 1 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1313110404] Ok
* OK [MYRIGHTS "acdilrsw"] ACL
a OK [READ-WRITE] Ok
a fetch 1 rfc822.header <<<------ Comando para seleciona
mensagem
* 1 FETCH (RFC822.HEADER {567}
id 222E07E1; Thu, 11 Aug 2011 21:40:56 -0300 (BRT)
Date: Thu, 11 Aug 2011 21:40:56 -0300
MIME-Version: 1.0
)
a OK FETCH completed.
a fetch 1 rfc822.text <<<------ Selecionar corpo da mensagem
* 1 FETCH (RFC822.TEXT {25}
)
a logout <<<------ Comando para deslogar
* BYE Courier-IMAP server shutting down
a OK LOGOUT completed
Se você conseguir ler as mensagens, significa que o seu servidor está pronto
para receber e transmitir mensagens.
Não esqueça de publicar o registro "MX" no seu DNS, configurar

corretamente o campo "TXT" e também o DNS REVERSO.
11.7.3. 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":
root@dmz:~# vim /etc/aliases

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

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

ou
root@dmz:~# newaliases
Verifique se o arquivo "aliases.db" foi atualizado:
root@dmz:~# stat /etc/aliases.db

File: "/etc/aliases.db"
Size: 12288 Blocks: 24 IO Block: 4096 arquivo comum
Device: fd00h/64768d Inode: 264422 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2011-08-11 22:05:41.028000893 -0300
Modify: 2011-08-11 22:05:41.028000893 -0300
Change: 2011-08-11 22:05:41.028000893 -0300
Agora podemos fazer um teste enviando um e-mail para o usuário de "alias":
root@dmz:~# echo "Teste de Alias" | mail -s "Teste de alias" -r \

dexterclem@dexter.com.br ouvidoria@dexter.com.br
root@dmz:~# cat \
/home/mandarkglory/Maildir/new/1313111359.Vfd00I607a6M816000.dmz
Return-Path: <dexterclem@dexter.com.br>
X-Original-To: ouvidoria@dexter.com.br
Delivered-To: ouvidoria@dexter.com.br
id C06207E1; Thu, 11 Aug 2011 22:09:19 -0300 (BRT)
Date: Thu, 11 Aug 2011 22:09:19 -0300
From: dexterclem@dexter.com.br
To: ouvidoria@dexter.com.br
Subject: Teste de alias
Message-ID: <4e447d3f.+kR8VGISl9eSI9ON%dexterclem@dexter.com.br>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Teste de Alias
Repare que a visualização foi feita no arquivo do usuário Mandark Glory!

11.7.4. 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...
root@dmz:~# aptitude install squirrelmail
Com a instalação concluída, vamos adicionar ao arquivo

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

Alias /webmail "/usr/share/squirrelmail/"
DirectoryIndex index.php
Agora vamos configurar o SquirrelMail. Execute:
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:
root@dmz:~# vim /etc/apache2/sites-available/webmail.dexter.com.br

<VirtualHost *:80>
DocumentRoot /usr/share/squirrelmail
ServerName webmail.dexter.com.br
ErrorLog /var/log/apache2/webmail-error.log
CustomLog /var/log/apache2/webmail-access.log common
</VirtualHost>
<VirtualHost *:443>
DocumentRoot /usr/share/squirrelmail
ServerName webmail.dexter.com.br
ErrorLog /var/log/apache2/webmail-error.log
CustomLog /var/log/apache2/webmail-access.log common
SSLEngine on
SSLCertificateFile /etc/ssl/dexter.crt
SSLCertificateKeyFile /etc/ssl/dexter.key
</VirtualHost>
Ative o novo site :
root@dmz:~# a2ensite webmail.dexter.com.br

Enabling site webmail.dexter.com.br.
Reinicie o Apache:

Restarting web server: apache2[Thu Aug 11 22:46:11 2011] [warn]
_default_ VirtualHost overlap on port 443, the first has precedence
... waiting [Thu Aug 11 22:46:13 2011] [warn] _default_ VirtualHost
overlap on port 443, the first has precedence
Acesse nosso webmail: https://www.dexter.com.br/webmail
Acessando com o usuário dexterclem, veja a mensagem:

11.7.5. 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

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

libdb4.6 procmail
Vamos renomear o arquivo configuração e criar um diretório de spool:
root@dmz:~# mv /etc/default/saslauthd /etc/default/saslauthd.backup

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

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

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

Short name (NAME) undefined in /etc/default/saslauthd, using
default ... (warning).
Stopping : default.
Starting : default.
Inclua o usuário “postfix” no grupo sasl:
root@dmz:~# adduser postfix sasl
Acrescente no final do arquivo principal do Postfix:

smtpd_sasl_local_domain =
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks, reject_unauth_destination
smtpd_tls_auth_only = no
Reinicie novamente o Postfix:

Short name (NAME) undefined in /etc/default/saslauthd, using
default ... (warning).
Stopping : default.
Starting : default.
11.7.6. Ativando maior segurança com TLS
TLS significa Transport Layer Security e é uma camada de segurança para o

sistema 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 senhas
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 diretório:
root@dmz:~# mkdir -p /etc/postfix/ssl

root@dmz:~# cd /etc/postfix/ssl/
root@dmz:/etc/postfix/ssl/# openssl genrsa -des3 -rand /etc/hosts -out\
smtpd.key 1024
271 semi-random bytes loaded

.++++++
..............++++++
e is 65537 (0x10001)
Enter pass phrase for smtpd.key: 123456 <<<--- Adicione uma senha
Verifying - Enter pass phrase for smtpd.key: 123456 <<<--- Confirme
Altere a permissão do arquivo de chave para que somente o root tenha acesso:
root@dmz:/etc/postfix/ssl/# chmod -v 600 smtpd.key

modo de "smtpd.key" alterado para 0600 (rw-------)
Agora vamos criar o certificado de autenticidade para os acessos :
root@dmz:~/etc/postfix/ssl# openssl req -new -key smtpd.key -out \

smtpd.csr
Enter pass phrase for smtpd.key: 123456
incorporated
into your certificate request.
DN.
There are quite a few fields but you can leave some blank
-----
A challenge password []:123456
An optional company name []:Dexter
Agora vamos assinar nosso certificado digital:
root@dmz:~/etc/postfix/ssl# openssl x509 -req -days 365 -in smtpd.csr\

-signkey smtpd.key -out smtpd.crt
Signature ok
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
Getting Private key
E finalmente, a chave sem criptografia:
root@dmz:~/etc/postfix/ssl# openssl rsa -in smtpd.key -out \

smtpd.key.unencrypted
writing RSA key
Sobrescreva a chave criada anteriormente para a chave de mesmo nome:
root@dmz:~/etc/postfix/ssl# mv smtpd.key smtpd.key-original

root@dmz:~/etc/postfix/ssl# mv smtpd.key.unencrypted smtpd.key
Agora vamos gerar o certificado “.pem”:
root@dmz:~/etc/postfix/ssl# openssl req -new -x509 -extensions v3_ca \

-keyout cakey.pem -out cacert.pem -days 365
Generating a 1024 bit RSA private key
......++++++
........++++++
writing new private key to 'cakey.pem'
Enter PEM pass phrase: 123456
Verifying - Enter PEM pass phrase: 123456
-----
incorporated
into your certificate request.
DN.
There are quite a few fields but you can leave some blank
-----
Acrescente no final do arquivo principal do Postfix:

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

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:

root@dmz:~#
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:
root@squeeze:~# tar xjvf thunderbird-5.0.tar.bz2 -C /opt

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 do certificado digital, 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 12
Servidor OpenLDAP
12.1. Objetivos
• O que é o OpenLDAP e em que ele nos ajudará?
• O que é um diretório afinal?
• Instalação e configuração através do arquivo slapd.conf
• Usando scripts para migrar base de dados dos arquivos /etc/passwd e

/etc/group para o OpenLDAP;
• O que é um LDIF?
• Os comandos: ldapadd, ldapsearch, ldapmodify;
• Implementação de ferramenta para manipulação da base via "browser";
• Como fazer backup/restore da base de dados;
• Autenticação de cliente em base do OpenLDAP;

Capítulo 12 Servidor OpenLDAP - 284
12.2. Cenário
A empresa DEXTER COURIER precisa de agilidade em suas conexões, mas

principalmente 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 OpenLDAP, 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 flexível, o compartilhamento, a manutenção e o gerenciamento de grandes
volumes de 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
compartilhar 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árquica, interligando departamentos e filiais de uma grande multinacional por
exemplo. A organização dos servidores neste caso é similar ao DNS: é especificado
um servidor 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
O que é o OpenLDAP?
O projeto OpenLDAP é um serviço de diretório que utiliza o protocolo LDAP,

baseado 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 vantagens 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.
Como o LDAP, utiliza o trafego 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
configurado 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

ferramentas
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.
Resumindo...
As características de um sistema de diretórios são:
- Centraliza e organiza informações;

- Evita redundância;
- É otimizado para fazer pesquisas, pois utiliza algoritmos de busca
sofisticados;
- Podem ser distribuídos, isto é, não precisam necessariamente armazenar
suas informações em um mesmo local.
Podemos destacar alguns atributos de diretórios:
c - Representa país (country)
o - Representa uma organização como uma empresa (organization)
ou -Representa um departamento (organization unit)
Alguns atributos de entradas:

cn - Representa um nome (common name)
uid - Representa a identidade de um usuário (user ID)
gn - Representa o nome próprio de uma pessoa (given name)
sn - Representa o sobrenome de uma pessoa (surname)
12.5. Laboratório
Vamos iniciar a instalação do OpenLDAP. Para isto execute na máquina

“Datacenter”:
root@datacenter:~# aptitude install slapd ldap-utils libldap-2.4-2
Vamos gerar o hash da senha do administrador para inserirmos na diretiva

rootpw que estará no arquivo /etc/ldap/slapd.conf:
root@datacenter:~# slappasswd | tee /root/ldap.txt

New password: 123456
Re-enter new password: 123456
{SSHA}yb9Xs4qy9rtG4CSd/hph62qo6X1LFxmW
Agora vamos criar o arquivo /etc/ldap/slapd.conf conforme abaixo,

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

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
allow bind_v2
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel none
modulepath /usr/lib/ldap
moduleload back_bdb
sizelimit 500
tool-threads 1
backend bdb
database bdb
suffix “dc=dexter,dc=com,dc=br”
rootdn “cn=admin,dc=dexter,dc=com,dc=br”
rootpw {SSHA}yb9Xs4qy9rtG4CSd/hph62qo6X1LFxmW
directory “/var/lib/ldap”
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
index objectClass eq
lastmod on
checkpoint 512 30
access to attrs=userPassword,shadowLastChange
by dn="cn=admin,dc=dexter,dc=com,dc=br" write
by anonymous auth
by self write
by * none
access to dn.base="" by * read
access to *
by dn="cn=admin,dc=dexter,dc=com,dc=br" write
by * read
Após criar o arquivo slapd.conf em /etc/ldap, vamos parar o serviço slapd e

fazer nossas alterações:
root@datacenter:~# service slapd stop

Stopping OpenLDAP: slapd.
root@datacenter:~# cd /etc/ldap
Faça backup do diretório original antes de alterá-lo:
root@datacenter:~# cp -r slapd.d slapd.d.backup
Remova o diretório antigo:
root@datacenter:~# rm -r slapd.d
Crie um novo:
root@datacenter:~# mkdir slapd.d
Teste se o arquivo novo está OK:
root@datacenter:~# slaptest -f slapd.conf -F slapd.d

slapd.conf: line 36: rootdn is always granted unlimited privileges.
slapd.conf: line 42: rootdn is always granted unlimited privileges.
config file testing succeeded
Se aparecer essa mensagem está tudo certo! As linhas 36 e 42 são apenas

informaçõ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:
root@datacenter:~# chown -R openldap:openldap slapd.d
Inicie novamente o slapd:
root@datacenter:~# service slapd start

Starting OpenLDAP: slapd.
Veja se a porta do serviço está em escuta:
root@datacenter:~# netstat -putan | grep 389

tcp 0 0 0.0.0.0:389 0.0.0.0:* OUÇA 12484/slapd
tcp6 0 0 :::389 :::* OUÇA 12484/slapd
12.5.1. 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 migraçã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 instalação:
root@datacenter:~# aptitude install migrationtools
Localize as linhas 71 e 74, respectivamente, e as deixe exatamente assim:
root@datacenter:~# vim +71 /usr/share/migrationtools/migrate_common.ph

$DEFAULT_MAIL_DOMAIN = “dexter.com.br”;
$DEFAULT_BASE = “dc=dexter,dc=com,dc=br”;
Agora entre no diretório e execute os scripts abaixo:
root@datacenter:~# cd /usr/share/migrationtools/
root@datacenter:/usr/share/migrationtools# ./migrate_passwd.pl \
/etc/passwd /etc/ldap/users.ldif
root@datacenter:/usr/share/migrationtools# ./migrate_group.pl \
/etc/group /etc/ldap/groups.ldif
root@datacenter:/usr/share/migrationtools# ./migrate_base.pl > \
/etc/ldap/base.ldif
Vamos agora verificar se o arquivo /etc/ldap/base.ldif está com o cabeçalho

correto:
root@datacenter:~# head /etc/ldap/base.ldif
O arquivo tem que começar assim:
dn: dc=dexter,dc=com,dc=br
dc: dexter
objectClass: top
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

OpenLDAP. Você precisará da senha de administrador da base. Inicie pelo arquivo da
base, depois insira os grupos e finalmente os usuários:
root@datacenter:~# ldapadd -x -D cn=admin,dc=dexter,dc=com,dc=br -f \

/etc/ldap/base.ldif -W
/etc/ldap/groups.ldif -W
/etc/ldap/users.ldif -W
Parâmetros do comando “ldapadd”:
-x – autenticação simples
-D – específica o domínio
-f – indica o arquivo ldif
-W – chama o prompt de autenticação
-w senha – executa o comando sem solicitar a senha
Faça uma busca simples na base à procura de um determinado “uid”:
root@datacenter:~# ldapsearch -x -b dc=dexter,dc=com,dc=br \

uidNumber=1002
# extended LDIF
#
# LDAPv3
# base <dc=dexter,dc=com,dc=br> with scope subtree
# filter: uidNumber=1002
# requesting: ALL
#
# dexterclem, People, dexter.com.br

dn: uid=dexterclem,ou=People,dc=dexter,dc=com,dc=br
uid: dexterclem
cn: dexterclem
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/false
uidNumber: 1002
gidNumber: 2001
homeDirectory: /srv/samba/homes/dexterclem
# search result
search: 2
result: 0 Success
# numResponses: 2
# 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:
root@datacenter:~# vim /root/loginShell.ldif

dn: uid=mandarkglory,ou=People,dc=dexter,dc=com,dc=br
changetype: modify
replace: loginShell
loginShell: /bin/bash
Neste exemplo, o shell do usuário “mandarkglory” será alterado para

/bin/bash. Vamos então aplicar a alteração:
root@datacenter:~# ldapmodify -x -D cn=admin,dc=dexter,dc=com,dc=br \

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

uid=mandarkglory | grep login -A4 -B3
uidNumber: 1003
gidNumber: 2001
homeDirectory: /srv/samba/homes/mandarkglory
loginShell: /bin/bash
# search result
search: 2
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:
root@datacenter:~# aptitude install apache2 php5 php-pear php5-ldap \

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:

12.6. Backup da base de dados
Inicialmente, pare o servidor OpenLDAP:
Para realizar o backup, simplesmente realize o seguinte comando:
root@datacenter:~# slapcat -l /root/backup_ldap.ldif
Gerando uma cópia de segurança:
root@datacenter:~# cp /root/backup_ldap.ldif \
/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:
root@datacenter:~# ldapdelete -x -D cn=admin,dc=dexter,dc=com,dc=br \

-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:
root@datacenter:~# slapcat
Pare o servidor:

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

.#################### 100.00% eta none elapsed none fast!
Closing DB...
Inicie o slapd:
Execute o comando slapcat novamente para termos certeza que o backup foi
restaurado:
root@datacenter:~# slapcat
Capítulo 13
Servidor Proxy com Squid
13.1. Objetivos
• Funções do Squid: Cache / Filtro de conteúdo;
• Entender ACL's e seus tipos básicos;
• Instalar e configurar o Squid;
• Configuração da estrutura do cache em disco e memória RAM;
• Configuração de um exemplo de filtro de conteúdo;
• Proxy com autenticação via NCSA;
• SARG para monitorar os Log's de acesso;
• Como usar o Squidguard;
• Limitação de banda com o Squid (delay_pools);
• Autenticando o Squid pelo OpenLDAP;

Capítulo 13 Servidor Proxy com Squid - 298
13.2. 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,
possibilitando assim suprir as necessidades da empresa Dexter. Além disto, faremos
uso do SquidGuard, um poderoso filtro de conteúdo.
13.4. 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 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

problema. 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
servidor "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.

13.5. 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.
A imagem a seguir mostra como funciona um proxy manualmente configurado.
13.6. 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 regra 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 internet, por exemplo.
Em compensação, perderemos a flexibilidade dos logs e autenticação, já que o

navegador 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:
13.7. 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!
13.8. Definindo ACL
As ACLs são dispostas de seguinte forma:
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.
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 tratadas com CASE-SENSITIVE. Para definir como CASE-
INSENTIVE, utilize a opção “-i” logo após o tipo de ACL.
13.9. 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.
acl ESTACAO_DIRETOR src 192.168.200.100/255.255.255.255

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

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.
acl SITE_INTEGRAL dstdomain .terra.com.br

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

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
expressões regulares, porém é preciso conhecer muito bem sobre o assunto.
acl EXTENSAO_PROIBIDA url_regex ?i \.exe$
• port => ACL do tipo port (porta) trata da porta de destino da navegação.
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
autenticação.
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
absolutamente nada. Durante o laboratório veremos como tornar as "ACL's" úteis
com configurações que permitem utilizá-las para bloqueio e liberação de sites,
domínios e horários.
LEMBRETE – Tipos de ACL
src – Filtro por rede ou endereço IP;

time – Filtro por hora e dia da semana;
urlpath_regex – filtro de complemento de uma "url";
url_regex – Filtro de uma "string" na "url";
dstdomain – Filtro de uma "url";
proxy_auth – Filtro por usuários autenticados;
arp – Filtro por "MAC Address";
maxconn – Filtro por conexões;
proto – Filtro por protocolos;
port – Filtro por porta.
13.10. 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
http_access allow DIRETOR
• Acesso liberado ao site do UOL exceto no horário do almoço
http_access allow UOL !HORARIO_ALMOCO
• Extensão proibida baseado em expressão regular
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!
# squid -k reconfigure
13.11. Laboratório
Vamos instalar nosso PROXY na máquina “Firewall”. Para isto, execute:
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

mencionados.
root@firewall:~# ls -lh /etc/squid

total 168K
-rw------- 1 root root 166K Ago 17 15:27 squid.conf
root@firewall:~# ls -lh /var/log/squid
total 4,0K
-rw-r----- 1 proxy proxy 0 Ago 17 15:27 access.log
-rw-r----- 1 proxy proxy 2,3K Ago 17 15:27 cache.log
-rw-r----- 1 proxy proxy 0 Ago 17 15:27 store.log
root@firewall:~# ls -lh /var/spool/squid
total 68K
drwxr-x--- 258 proxy proxy 4,0K Ago 17 15:27 00
drwxr-x--- 258 proxy proxy 4,0K Ago 17 15:27 0A
drwxr-x--- 258 proxy proxy 4,0K Ago 17 15:27 0B
drwxr-x--- 258 proxy proxy 4,0K Ago 17 15:27 0C
drwxr-x--- 258 proxy proxy 4,0K Ago 17 15:27 0D
drwxr-x--- 258 proxy proxy 4,0K Ago 17 15:27 0E
drwxr-x--- 258 proxy proxy 4,0K Ago 17 15:27 0F
-rw-r----- 1 proxy proxy 48 Ago 17 15:27 swap.state
Para posterior consulta, renomeie o arquivo de configuração original:
root@firewall:~# mv /etc/squid/squid.conf /etc/squid/squid.conf.backup
A configuração padrão do "Squid" não permite nenhum tipo de navegação por

medidas 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 fazer isso. Vamos então configurar nosso proxy
com as regras abaixo:
root@firewall:~# vim /etc/squid/squid.conf

## Para que o "Squid" ouça apenas uma rede, troque o valor do
## parâmetro "http_port 3128" para:
http_port 192.168.X.1:3128
## Este parâmetro diz qual será o hostname que o "Squid" utilizará

## para resolver seu endereço local e também o endereço que será
## apresentado nas páginas de informação.
visible_hostname proxy.dexter.com.br
## Espaço em memória RAM para o cache de páginas

cache_mem 64 MB
## Espaço em disco para o cache de páginas

## ufs = sistema de arquivo padrao do squid
## 5120 = 5GB para cache de pagina, se precisar de Windows Update e
## antivirus, tera que aumentar este valor
## 128 = 128 diretorios
## 256 = subdiretorios dentro dos diretórios acima criados
## utiliza esta divisao para indexar mais rapido quando lotar o cache
## de disco, descartando os arquivos mais antigos!
cache_dir ufs /var/spool/squid 5120 128 256
## Log de acesso à páginas

access_log /var/log/squid/access.log
## Inibe a informação da versão do Squid quando um site é bloqueado

httpd_suppress_version_string on
## Páginas de bloqueios exibidos em Português

error_directory /usr/share/squid/errors/Portuguese
## Tamanho máximo do arquivo no cache em RAM e disco, respectivamente

maximum_object_size_in_memory 64 KB
maximum_object_size 700 MB
minimum_object_size 0 KB
## Porcentagem de uso do cache de disco mínimo e máximo,respectivamente

cache_swap_low 90
cache_swap_high 95
## Log de uso do cache em disco

cache_access_log /var/log/squid/cache.log
###### Declaração das ACL's ######
###### ACL's do próprio Squid ######

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
## As acl's "SSL_ports" e a "Safe_ports" são as responsáveis por

## limitar as portas que podem
## ser usadas através do proxy. Na documentação do Squid, que prevê o
## uso de diversos protocolos
## conhecidos e também o uso de portas altas
acl SSL_ports port 443 563
acl Safe_ports port 21 80 443 563 70 210 280 488 59 777 901 1025-65535
## Exclui os objetos que foram armazenados no cache do squid

acl purge method PURGE
## Permite ao Squid deixar fazer a conexão direta quem fizer parte da

## ACL connect
acl CONNECT method CONNECT
###### Minhas ACL's ######
###### Aplicação das ACL's ######

# Permite acesso ao gerenciamento do cache vindo somente do localhost
http_access allow manager localhost

http_access deny manager
# Permite acesso a exclusão dos objetos no cache vindo somente do

# localhost
http_access allow purge localhost
http_access deny purge
# Nega acesso a requisições de portas desconhecidas

http_access deny !Safe_ports
# Nega conexão exceto para portas SSL

http_access deny CONNECT !SSL_ports
# Libera acesso ao localhost

http_access allow localhost
# Nega qualquer outra rede

http_access deny all
13.12. Criando a estrutura do Squid
Execute os comandos abaixo para criar a estrutura de diretórios do Squid:
root@firewall:~# service squid stop

root@firewall:~# squid -z
2011/08/17 16:56:05| Creating Swap Directories
root@firewall:~# service squid start
Starting Squid HTTP proxy: squid.
13.13. 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 possamos 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”:

...
###### Minhas ACL's ######
acl RedeDexter src 192.168.X.0/24
acl Internacional dstdomain .com
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:

# Libera acesso ao localhost
http_access allow localhost
###### Minhas regras ######

http_access allow RedeDexter Globo
http_access deny RedeDexter Internacional
http_access allow RedeDexter
# Nega qualquer outra rede

http_access deny all
Para checar se há erros na configuração, execute o comando abaixo. Se

retornar ao prompt, sua configuração está OK:
root@firewall:~# squid -k parse
Visto que não é recomendável efetuar um restart no serviço do Squid devido à

demora em checar todas as suas entradas em cache, execute o comando abaixo para
reler o arquivo squid.conf:
root@firewall:~# squid -k reconfigure
Configure o navegador no cliente:
Acesse as opções na sequência abaixo:

2 3
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" importa, sim.
Lembre-se disso quando fizer "troubleshooting" ou criar novas regras.
13.14. 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, mas que casam com a
"blacklist".
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" :

...
###### Minhas ACL's ######
acl RedeDexter src 192.168.110.0/24
acl blacklist url_regex linux
acl whitelist dstdomain www.linux.com www.4linux.com.br
...
###### Minhas regras ######
http_access allow RedeDexter whitelist
http_access deny RedeDexter blacklist
http_access allow RedeDexter Globo
http_access deny RedeDexter Internacional
http_access allow RedeDexter
Reinicie o squid:
Agora, tente acessar os sites:
www.4linux.com.br
www.vivaolinux.com.br
www.linux.com
www.br-linux.org
Para aprender mais, acesse http://www.squid-cache.org e leia a

documentação oficial do projeto "Squid".
13.15. Autenticação NCSA
O "Squid" possui um mecanismo de autenticação que pode trabalhar de

diversas maneiras, e uma delas, a NCSA, utiliza o mesmo mecanismo de autenticação
do servidor 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,
adicionado o conteúdo abaixo no início do arquivo /etc/squid/squid.conf:

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd
auth_param basic children 5
auth_param basic realm >>> Servidor Proxy Squid - Dexter <<<
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:
...
##### Minhas ACL's ######
acl RedeDexter src 192.168.110.0/24
acl password proxy_auth REQUIRED
###### Aplicação das ACL's ######

# Devemos dar permissão para a ACL "passwd" antes de qualquer outra, a
# a fim de solicitar a autenticação
http_access deny !password
...
Gerando o arquivo de senhas:
root@firewall:~# aptitude install apache2-utils

root@firewall:~# htpasswd -bc /etc/squid/passwd mandarkglory 123456
Reinicie o serviço do Squid e tente acessar qualquer site!

Solicitação de usuário e senha:
Cancelando a tela de autenticação:

Após o logar com o usuário válido no proxy:
13.16. 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/access.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:
root@firewall:~# vim /etc/apt/sources.list

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

root@firewall:~# aptitude -t squeeze-backports install sarg
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

comentários para entender as funções do "SARG".
root@firewall:~# vim /usr/sbin/sarg-reports
Para que a página de relatório seja acessada, instale o Apache2:
root@firewall:~# aptitude install apache2 -y
Edite o arquivo abaixo com o conteúdo apontando para o diretório do Sarg:
root@firewall:~# vim /etc/apache2/httpd.conf

Alias /squid-reports "/var/lib/sarg/"
DirectoryIndex index.html
Reinicie o Apache:
root@firewall:~# service apache2 restart
Agora, acesse o endereço e veja os acessos dos usuários:
http://192.168.X.1/squid-reports
Veja nas próximas figuras a página inicial do Sarg e o s acessos do usuário!

Tela inicial do Sarg com as datas 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:
13.17. Squidguard
O Squidguard é um redirecionador de URL, livre e rápido, que trabalha com

blacklists e funciona como um plugin para o Squid. Você pode facilmente bloquear
páginas pornográficas, redes sociais, sites que hospedam banners, páginas que
hospedam vídeos e músicas, chats, páginas para baixar softwares piratas, etc., sem
ter que adicionar filtro por filtro, o que seria inviável!
Para instalar o Squidguard, execute:
root@firewall:~# aptitude install squidguard
Vamos fazer o download das listas no diretório “/var/lib/squidguard/db” e

depois descompacte:
root@firewall:~# cd /var/lib/squidguard/db/
root@firewall:~# wget -c \
http://squidguard.mesd.k12.or.us/blacklists.tgz
root@firewall:~# wget -c \
http://www.shallalist.de/Downloads/shallalist.tar.gz
root@firewall:~# tar xzvf blacklists.tgz
root@firewall:~# tar xzvf shallalist.tar.gz
root@firewall:~# rm blacklists.tgz
root@firewall:~# rm shallalist.tar.gz
Vamos usar listas para bloquear a maioria dos sites pornográficos, redes sociais
e proxys usados para acessar páginas indevidas. Insira no final do arquivo:
root@firewall:~# vim /etc/squid/squidGuard.conf

...
dbhome /var/lib/squidguard/db/blacklists
logdir /var/log/squid
...
dest porn {
domainlist porn/domains
urllist porn/urls
}
dest proxy {
domainlist proxy/domains
urllist proxy/urls
}
acl {
default {
pass !porn !proxy all
redirect http://www.dexter.com.br
}
}
As duas primeiras linhas indicam o diretório contendo as blacklists e o diretório

onde serão armazenados os logs. No exemplo, estou usando as duas listas baixadas,
daí o "/var/lib/squidguard/db" e estou orientando o SquidGuard a salvar o log no
mesmo diretório utilizado pelo Squid, gerando o arquivo
"/var/log/squid/squidGuard.log".
Em seguida, temos as ACLs porn e proxy, cada uma incluindo os dois arquivos
da categoria correspondente dentro das listas. Para que fossem adicionadas mais
seções, bastaria adicionar uma nova ACL para cada uma.
No final, a opção "pass" indica como as ACLs serão usadas. No exemplo, a linha
"pass !porn !proxy all" indica que os acessos às páginas citadas nas listas devem ser
bloqueados, mas o acesso a outras páginas será aceito.
Concluindo, usei a linha "redirect http://www.dexter.com.br", que faz com que

todos os acessos bloqueados sejam redirecionados de forma transparente à URL
especificada. Dessa forma, o usuário tentando acessar páginas impróprias é
sutilmente direcionado à página da empresa ou mesmo pela página de aviso!
Embora não seja necessário em muitas configurações, é recomendável usar

também o comando abaixo para ajustar as permissões de acesso aos arquivos,
garantindo que o Squid tenha acesso a eles. O "proxy:proxy" indica o usuário e o
grupo utilizados pelo Squid, que podem eventualmente ser diferentes, de acordo com
a distribuição usada:
root@firewall:~# chown -R proxy:proxy /var/lib/squidguard/db/*
Os dois comandos a seguir complementam a configuração, fazendo com que

todos os arquivos dentro da pasta sejam configurados com permissões 644 e as
pastas com 755, que é a configuração correta. Isso previne o aparecimento de erros
diversos relacionados a permissões incorretas para os arquivos:
root@firewall:~# find /var/lib/squidguard/db -type f | xargs chmod 644

root@firewall:~# find /var/lib/squidguard/db -type d | xargs chmod 755
Concluindo, sempre que você incluir novas listas, execute o seguinte comando:
root@firewall:~# squidGuard -C all
Não deixe de checar o log e verificar se não há erro em algum diretório ou

arquivo. Execute o comando abaixo:
root@firewall:~# tail -f -n15 /var/log/squid/squidGuard.log

2011-08-18 11:51:21 [1333] New setting: dbhome:
/var/lib/squidguard/db/blacklists
2011-08-18 11:51:21 [1333] New setting: logdir: /var/log/squid

2011-08-18 11:51:21 [1333] destblock good missing active content, set
inactive
2011-08-18 11:51:21 [1333] destblock local missing active content, set
inactive
2011-08-18 11:51:21 [1333] init domainlist
/var/lib/squidguard/db/blacklists/porn/domains
2011-08-18 11:51:41 [1333] create new dbfile
/var/lib/squidguard/db/blacklists/porn/domains.db
2011-08-18 11:51:43 [1333] init urllist
/var/lib/squidguard/db/blacklists/porn/urls
/var/lib/squidguard/db/blacklists/porn/urls.db
2011-08-18 11:51:43 [1333] init domainlist
/var/lib/squidguard/db/blacklists/proxy/domains
/var/lib/squidguard/db/blacklists/proxy/domains.db
2011-08-18 11:51:43 [1333] init urllist
/var/lib/squidguard/db/blacklists/proxy/urls
2011-08-18 11:51:43 [1333] urllist empty, removed from memory
2011-08-18 11:51:43 [1333] squidGuard 1.4 started (1313679081.694)
2011-08-18 11:51:43 [1333] db update done
2011-08-18 11:51:43 [1333] squidGuard stopped (1313679103.837)
Agora abra o arquivo squid.conf e adicione a diretivas em negrito ANTES da

ACL RedeDexter:

...
###### Minhas ACL's ######
redirect_program /usr/bin/squidGuard
redirect_children 8
redirector_bypass on
...
A posição da regra que ativa o SquidGuard é importante, pois se ela for

colocada depois da regra "http_access allow RedeDexter" (ou similar), as requisições
serão liberadas antes de passarem pelo SquidGuard, fazendo com que ele nunca seja
usado. Colocamos como opção as duas linhas abaixo, logo após a linha que ativa o
SquidGuard:
redirect_children 8
A opção "redirect_children" ajusta o número de processos do SquidGuard que o

servidor Squid manterá abertos. Aumentar o número ajuda a melhorar o desempenho
do proxy em grandes redes, onde o servidor recebe um volume muito grande de
requisições.
A opção "redirector_bypass on" faz com que o Squid continue funcionando

mesmo que o SquidGuard trave ou deixe de funcionar por qualquer motivo. Usá-la
tem seus prós e contras, já que pode ser preferível que o acesso pare
completamente, até que você consiga solucionar o problema, do que permitir que o
Squid funcione com os bloqueios desativados.
13.18. Delay_pools
Este tópico irá tratar como o Squid poderá gerenciar o uso da banda de
internet. O Squid pode definir o quanto cada usuário pode usar e com isso manter
uma parte do link livre para os demais. Para isso ele utiliza um recurso chamado
"delay pools".
Imagine, por exemplo, que você tem um link de 1 megabit para uma rede com
20 usuários. Se cada um puder baixar o que quiser, é bem provável que a rede ficará
saturada em determinados horários implicando em uma navegação lenta para o resto
dos usuários.
13.18.1. Classes de Delay_pools
• Classe 1 – Especifica largura máxima de banda para todos os clientes;

• Classe 2 – Especifica largura máxima de banda por cliente (individualmente)
• Classe 3 – Especifica largura máxima de banda por rede e cliente

(individualmente). É compatível apenas com o endereçamento da classe C.
Um link de 2 megabit (2 x 1024 kbits) corresponde a 262144 bytes por

segundo. Como que fiz essa conta?
(2 x 1024 x 1024) / 8 = 262144 bytes por segundo

1 byte = 8 bits
Nas regras do Squid sempre usamos bytes, por isso lembre-se de fazer a
conversão, dividindo o valor em kbits por 8 e multiplicando por 1024 para ter o valor
em bytes. Neste caso, o arquivo de configuração ficaria assim:

...
###### Minhas ACL's ######
redirect_children 8
delay_pools 1
delay_class 1 2
delay_parameters 1 229376/229376 32768/32768
delay_access 1 allow RedeDexter
Salve o arquivo e reinicie o serviço, faça um download na Internet e veja se o

limite de velocidade é ultrapassado.
Vamos agora fazer com que o computador do Presidente da Dexter fique livre
das restrições do proxy. Antes da ACL RedeDexter, coloque o que está em negrito:

...
###### Minhas ACL's ######
redirect_children 8
acl presidente src 192.168.X.10
http_access allow presidente
delay_pools 1
delay_class 1 2
delay_parameters 1 229376/229376 32768/32768
...
Salve o arquivo, reinicie o Squid e faça o teste na máquina do Presidente!
13.19. 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/squid/passwd) para a linha abaixo:

auth_param basic program /usr/lib/squid/ldap_auth -b \
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
autenticação, pois agora a base usada será a do OpenLDAP. Faça o login com os
usuários “allissonmore” e “candimilo”!
Capítulo 14
Firewall
14.1. Objetivos
• Entender o que é um firewall e as tabelas principais do "iptables";
• O que é um firewall gateway;
• Revisão básica de redes;
• Importância do comando traceroute;
• Definição de TTL;
• Criar regras de exceções para liberar os serviços atrás do Firewall;
• Criar o controle de repasse de pacotes do servidor firewall gateway entre a

rede interna e externa (Internet) e fazer NAT para que as máquinas da rede
local possam “aparecer” para o mundo externo.
Capítulo 14 Firewall - 327
14.2. Cenário
A fim de que ninguém acesse dados indevidos da empresa ou mesmo de seus

clientes, 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?
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
gerenciamento de regras de Firewall. Lembrando que o "Iptables" é apenas um
"frontend" 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 é

diferente, pois novas funcionalidades podem ser adicionadas sem muito
esforço. Um módulo só será usado se for da necessidade do administrador;
14.5. Revisando os conceitos de Rede
Os dados são transmitidos na Internet agrupados em pacotes TCP (de maneira

geral). 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:
- IP de origem
- IP de destino
- Porta de origem
- Porta de destino
- Códigos de verificação
- 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
entrega 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 menores.
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,
compartilhamento de arquivos, como, por exemplo, Samba, NFS etc. Portas altas
estão faixa acima de 1023.
Relembrando...
As portas padrões de um servidor FTP: 21 e 20.

A porta padrão de um servidor web: 80.
A porta padrão de um servidor web com https: 443.
A porta padrão do SMTP: 25.
A porta padrão POP3: 110.
A porta padrão POP3S: 995.
A porta padrão IMAP: 143.
A porta padrão IMAPS: 995.
A porta padrão do SSH: 22.
A porta padrão para transferência de zona do DNS: 53/tcp.
A porta padrão para consulta de DNS: 53/udp.
A porta padrão do OpenLDAP: 389.
A porta padrão do proxy Squid: 3128.
A porta padrão do OpenVPN: 5000
No arquivo “/etc/services” podemos obter toda a relação de portas!

Importante dizer também que os dados são transmitidos através de conexões.

Tudo começa com o cliente enviando o pacote "SYN", que solicita a abertura da
conexão. Caso a porta esteja fechada, o que servidor responde com um pacote "RST"
e a comunicação se encerra. Se existir algum serviço disponível na porta solicitada
(um servidor http, por exemplo), ele responde com outro pacote "SYN", seguido de
um um pacote "ACK", a fim de avisar que a porta está disponível e abre a conexão.
O cliente responderá então com outro pacote "ACK", o que abre oficialmente a
conexão. Daí é iniciada a transferência dos dados, que como já dito anteriormente
são organizados em pacotes. Para cada pacote recebido, a máquina cliente irá enviar
um pacote de confirmação. Se um pacote se perder, ela solicita a retransmissão.
Depois que todos os dados são transmitidos, o servidor envia um pacote "FYN" que
avisa que não tem mais nada a transmitir. O cliente responde com outro pacote
"FYN" e a conexão é oficialmente encerrada.
Porta disponível no servidor:
SYN
SYN/ACK
ACK
Porta indisponível no servidor:
SYN
SYN/ACK
RST
• SYN: solicita a abertura da conexão ou confirma o recebimento e avisa que a
porta está disponível;
• ACK: inicia a conexão ou faz confirmação;

• FYN: solicita o fechamento da conexão ou confirma o fechamento;
14.6. TTL
Através de um simples ping, conseguimos deduzir o Sistema Operacional de

uma máquina. Por exemplo:
root@firewall:~# ping -c2 www.uol.com.br

PING www.uol.com.br (200.221.2.45) 56(84) bytes of data.
64 bytes from home.uol.com.br (200.221.2.45): icmp_req=1 ttl=54
time=15.0 ms
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:
Roteadores Ciclades = 30
Linux = 64
Windows = 128
Cisco = 255
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:
root@firewall:~# cat /proc/sys/net/ipv4/ip_default_ttl

64
Outro comando para verificar o valor de TTL é:

root@firewall:~# sysctl -a | grep ip_default

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:
root@firewall:~# vim /etc/sysctl.conf

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:
root@firewall:~# sysctl -p /etc/sysctl.conf
Vamos instalar os programas traceroute e mtr para teste:
root@firewall:~# aptitude install traceroute mtr

root@firewall:~# traceroute www.uol.com.br
traceroute to www.uol.com.br (200.221.2.45), 30 hops max, 60 byte
packets
1 192.168.56.1 (192.168.56.1) 3.915 ms 0.493 ms 1.258 ms
2 192.168.1.1 (192.168.1.1) 6.811 ms 7.338 ms 8.277 ms
3 gvt-l0.b9.grs.gvt.net.br (186.214.4.1) 22.440 ms 23.123 ms 23.491
ms
4 186.215.146.193.static.host.gvt.net.br (186.215.146.193) 24.265 ms
24.734 ms 25.188 ms
5 gvt-ge-4-3-rd02.grs.gvt.net.br (189.59.249.242) 27.428 ms 27.300
ms 27.345 ms
6 189.59.249.97.static.host.gvt.net.br (189.59.249.97) 29.581 ms
22.555 ms 22.796 ms
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
8 * * *
9 200-147-26-113.static.uol.com.br (200.147.26.113) 21.413 ms 22.755
ms 22.924 ms
10 200.221.136.154 (200.221.136.154) 22.403 ms 23.011 ms 22.187 ms
11 * * *
...
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
encontre 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”:
root@firewall:~# mtr uol.com.br
14.7. 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.
14.8. 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:
INPUT - Regras de entrada de pacotes.

OUTPUT - Regras de saída de pacotes.
FORWARD - Regras de passagem de pacotes pelo firewall.
As CHAINS da tabela NAT são as seguintes:
PREROUTING - Regras que serão processadas antes do roteamento

dos pacotes nas interfaces do firewall.
POSTROUTING - Regras que serão processadas pós roteamento dos
pacotes nas interfaces do firewall.
OUTPUT - Regras de saída de pacotes.
14.9. 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 liberados no "firewall", as chamadas exceções. Todo o tráfego de
pacotes que as nossas exceções não cobrir será bloqueado por padrão. Em suma, o
que não for oficialmente 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:
Parâmetros para o iptables Descrição do parâmetro
-P --policy Estabelece a política de acesso de uma chain
-t --table Seleciona tabela
-A --append Adiciona como última regra da sequência de uma chain
-I --insert Insere como primeira regra da sequência de uma chain
-N --new-chain Cria uma nova chain
-D --delete Remove uma regra
-X --delete-chain Elimina todas as regras presentes em chains de usuário
-F --flush Elimina todas as regras presentes em uma chain

padrão (INPUT, FORWARD etc) ou tabela (para todas as
chains)
-s --source Determina a origem do pacote
-d --destination Determina o destino do pacote

--dport --destination-port Define a porta de destino
--sport --source-port Define a porta de origem
-i --in-interface Define a interface de entrada (input), exemplos: eth0,

eth1, ppp0 etc.
-o --out-interface Define a interface de saída (output)
-p --protocol Seleciona protocolo (tcp, udp, icmp etc)
Alvos:
Alvo (target) Descrição do alvo
ACCEPT O pacote é aceito
REJECT O pacote é rejeitado imediatamente
DROP O pacote é negado silenciosamente (mais interessante,

pois diminui a eficiência de um ataque DOS/DDOS, isto
é, o host de origem fica sem resposta até cair por
tempo esgotado
LOG Permite que qualquer pacote que se encaixe na regra

do iptables seja enviado para o syslog ou dmesg
14.10. Laboratório
Vamos montar nosso "firewall", mas antes verifique como estão configuradas as
políticas básicas que estão definidas por padrão:
root@firewall:~# iptables -t filter -nL

Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)

Chain OUTPUT (policy ACCEPT)

root@firewall:~# iptables -t nat -nL

Chain PREROUTING (policy ACCEPT)
Chain POSTROUTING (policy ACCEPT)

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:
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:
root@firewall:~# vim +28 /etc/sysctl.conf

net.ipv4.ip_forward=1
14.11. 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 "fw.sh":
root@firewall:~# vim /etc/init.d/firewall.sh

#!/bin/bash
# Firewall personalizado - Curso 457 – 4Linux

clear
# Limpando as regras
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
echo 0 > /proc/sys/net/ipv4/ip_forward
# Carregando módulos
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp
## Definição de variaveis
IPFIREWALL="192.168.X.1"
IPDATACENTER="192.168.X.2"
IPDMZ="192.168.X.3"
IPVALIDO="200.100.X.1"
INTERNA="eth1"
EXTERNA="eth0"
NET="0/0"
PA="1024:65535"
REDE="192.168.110.0/24"
ativar() {
## Fechando as Políticas
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
## Liberando LoopBack
iptables -A OUTPUT -d 127.0.0.1 -j ACCEPT
iptables -A INPUT -d 127.0.0.1 -j ACCEPT
## Estabilizando as conexões
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
## Liberando Ping (Saída de icmp 8 e Entrada de icmp 0)

iptables -A OUTPUT -p icmp --icmp-type 8 -s $IPFIREWALL -d 0/0 -j
ACCEPT
iptables -A OUTPUT -p icmp --icmp-type 8 -s $IPVALIDO -d 0/0 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 0 -s 0/0 -d $IPFIREWALL -j
ACCEPT
iptables -A INPUT -p icmp --icmp-type 0 -s 0/0 -d $IPVALIDO -j ACCEPT
## Liberando acesso ao proxy SQUID no Firewall

iptables -A FORWARD -o eth1 -s 192.168.110.0/24 -p tcp --dport 3128 -j
ACCEPT
iptables -A INPUT -p tcp --dport 3128 -j ACCEPT
## Liberando acesso ao SSH no Firewall

iptables -A OUTPUT -p tcp --dport 50000 -j ACCEPT
iptables -A INPUT -p tcp --dport 50000 -j ACCEPT
## Liberando consultas mtr

iptables -A INPUT -p icmp --icmp-type 11 -s $IPFIREWALL -j ACCEPT
## Liberando resolução de nomes

iptables -A OUTPUT -p udp -s $IPFIREWALL --sport $PA -d 0/0 --dport 53
-j ACCEPT
iptables -A INPUT -p udp -s 0/0 --sport 53 -d $IPFIREWALL --dport $PA
-j ACCEPT
iptables -A OUTPUT -p udp -s $IPVALIDO --sport $PA -d 0/0 --dport 53 -j
ACCEPT
iptables -A INPUT -p udp -s 0/0 --sport 53 -d $IPVALIDO --dport $PA -j
ACCEPT
## Liberando navegação web para IP da REDE INTERNA

iptables -A OUTPUT -p tcp -s $IPFIREWALL --sport $PA -d 0/0 --dport 80
-j ACCEPT
iptables -A OUTPUT -p tcp -s $IPFIREWALL --sport $PA -d 0/0 --dport 443
-j ACCEPT
iptables -A INPUT -p tcp -s 0/0 --sport 80 -d $IPFIREWALL --dport $PA
-j ACCEPT
iptables -A INPUT -p tcp -s 0/0 --sport 443 -d $IPFIREWALL --dport $PA
-j ACCEPT
## Liberando navegação web para IP BRIDGE

iptables -A OUTPUT -p tcp -s $IPVALIDO --sport $PA -d 0/0 --dport 80 -j
ACCEPT
iptables -A OUTPUT -p tcp -s $IPVALIDO --sport $PA -d 0/0 --dport 443
-j ACCEPT
iptables -A INPUT -p tcp -s 0/0 --sport 80 -d $IPVALIDO --dport $PA -j
ACCEPT
iptables -A INPUT -p tcp -s 0/0 --sport 443 -d $IPVALIDO --dport $PA -j
ACCEPT
## Ativando Forward
## Liberando acesso a Internet para rede local

iptables -A FORWARD -s $REDE -j ACCEPT
iptables -A FORWARD -d $REDE -j ACCEPT
iptables -t nat -A POSTROUTING -o $EXTERNA -s $REDE -j MASQUERADE
iptables -t nat -A POSTROUTING -o $INTERNA -s $REDE -j MASQUERADE
## Se tivessemos um IP valido para a INTERNET ao inves de usarmos

$IPFIREWALL nas regras abaixo, usariamos $IPVALIDO. Como nao temos,
vamos testar dentro da rede interna mesmo.
## Redirecionando para o SMTP na DMZ

iptables -A INPUT -p tcp -s $NET -d $IPFIREWALL --dport 25 -j ACCEPT
iptables -A FORWARD -p tcp -d $IPDMZ --dport 25 -j ACCEPT
iptables -t nat -A PREROUTING -d $IPFIREWALL -p tcp --dport 25 -j DNAT
--to-destination $IPDMZ:25
## Redirecionando para o POP3 na DMZ

## Redirecionando para o IMAP na DMZ

## Redirecionando para o IMAPS na DMZ

## Redirecionando para o POP3S na DMZ

## Redirecionando para o FTP na DMZ

## Redirecionando para o Servidor WEB na DMZ


## Redirecionando para o Servidor de DNS na DMZ1

iptables -A FORWARD -p tcp -d $IPDATACENTER --dport 53 -j ACCEPT
--to-destination $IPDATACENTER:53
iptables -A INPUT -p udp -s $NET -d $IPFIREWALL --dport 53 -j ACCEPT

iptables -A FORWARD -p udp -d $IPDATACENTER --dport 53 -j ACCEPT
iptables -t nat -A PREROUTING -d $IPFIREWALL -p udp --dport 53 -j DNAT
--to-destination $IPDATACENTER:53
echo "Firewall ativado!"

}
desativar() {
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
echo "Firewall destativado!"
}
case "$1" in
"start") ativar ;;
"stop") desativar ;;
*) echo "Use start para ativar ou stop para desativar o firewall";;
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:
root@firewall:/etc/init.d# insserv -v firewall.sh

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", mas ele não é um "script" profissional.
Capítulo 15
Servidor OpenVPN
15.1. Objetivos
• Entender como funciona uma "VPN";
• Configurar uma "VPN host to host";
• Aplicar autenticação TLS.

Capítulo 15 Servidor OpenVPN - 344
15.2. Cenário
Visto que a empresa DEXTER COURIER possui alguns colaboradores fora do

ambiente 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.
15.4. 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 (Internet). 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 prover 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.
15.5. 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
camada 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.
1. O IP Security Tunnel Mode (IPSec) da IETF permite que pacotes IP sejam

criptografados e encapsulados com cabeçalho adicional deste mesmo protocolo
para serem transportados numa rede IP pública ou privada. O IPSec é um
protocolo desenvolvido 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.
15.6. 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.
15.7. Laboratório
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".
15.7.1. Configurando o servidor
O primeiro passo é instalar o software OpenVPN:
root@firewall:~# aptitude install openvpn
Vamos gerar a chave:
root@firewall:~# openvpn --genkey --secret /etc/openvpn/chave

Vamos gerar o arquivo de configuração do servidor:
root@firewall:~# vim /etc/openvpn/server.conf

# Habilita suporte ao driver TUN/TAP;
dev tun
# Endereços da VPN (sempre na ordem local - remoto)
ifconfig 10.0.0.1 10.0.0.2
# Comando para chamar nossa chave criptografada e o local dela;
secret /etc/openvpn/chave
# Define a porta que o OpenVPN vai rodar;
port 5000
# Ativa suporte a compressão;
comp-lzo
# Nível para depuração de erros;
verb 4
# Envia um ping a cada 10 segundos sem atividade e a VPN é reiniciada
depois de 120 segundos sem respostas;
keepalive 10 120
#Assegura que o daemon mantenha as chaves carregadas, quando a VPN é
restabelecida depois de uma queda de conexão;
persist-key
# Assegura que o daemon mantenha a interface tun aberta, quando a VPN
é restabelecida depois de uma queda de conexão;
persist-tun
# Permite que o túnel continue aberto mesmo que o endereço IP da outra
máquina mude.
float
15.8. Configurando o cliente
Também é necessário ter o OpenVPN no cliente. Neste caso iremos usar a

máquina Squeeze para teste da VPN:
root@firewall:~# aptitude install openvpn
Vamos entrar no diretório "/etc/openvpn" e copiar a chave do servidor:

root@squeeze:~# cd /etc/openvpn
root@squeeze:/etc/openvpn# scp -P50000 \
192.168.X.1:/etc/openvpn/chave .
Vamos gerar o arquivo de configuração do cliente:
root@squeeze:~# vim /etc/openvpn/client.conf

dev tun
ifconfig 10.0.0.2 10.0.0.1
# Endereço do servidor VPN
remote 192.168.X.1
secret /etc/openvpn/chave
port 5000
comp-lzo
verb 4
keepalive 10 120
persist-key
persist-tun
float
Vamos iniciar a "VPN" no servidor... quanto no cliente.
root@firewall:~# openvpn --config /etc/openvpn/server.conf

Fri Aug 19 04:41:47 2011 us=606727 Local Options hash (VER=V4):
'099d04aa'
Fri Aug 19 04:41:47 2011 us=606727 Expected Remote Options hash
(VER=V4): 'f1025742'
Fri Aug 19 04:41:47 2011 us=606728 UDPv4 link local (bound): [undef]
Fri Aug 19 04:41:47 2011 us=606728 UDPv4 link remote: [undef]
Fri Aug 19 04:42:10 2011 us=340543 Peer Connection Initiated with
[AF_INET]192.168.X.10:5000
Fri Aug 19 04:42:10 2011 us=340617 Initialization Sequence Completed
Agora do lado do cliente, na máquina Squeeze:
root@squeeze:~# openvpn --config /etc/openvpn/client.conf

Fri Aug 19 04:42:12 2011 us=678990 Local Options hash (VER=V4):
'f1025742'
Fri Aug 19 04:42:12 2011 us=679035 Expected Remote Options hash

(VER=V4): '099d04aa'
Fri Aug 19 04:42:12 2011 us=679101 UDPv4 link local (bound): [undef]
Fri Aug 19 04:42:12 2011 us=679138 UDPv4 link remote:
[AF_INET]192.168.X.1:5000
Fri Aug 19 04:42:19 2011 us=833812 Peer Connection Initiated with
[AF_INET]192.168.X.1:5000
Fri Aug 19 04:42:19 2011 us=833936 Initialization Sequence Completed
Execute um "ifconfig" para ver se a interface tun0 foi criada:
root@firewall:~# ifconfig | tail -n9

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
inet end.: 10.0.0.1 P-a-P:10.0.0.2 Masc:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Métrica:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
15.9. Certificados vpn
O OpenVPN oferece vários mecanismos para adicionar camadas adicionais de

seguranç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.

...
# Remoção dos privilégios de root na conexão VPN
user nobody
group nogroup
Faça o mesmo para no cliente:

...
# Remoção dos privilégios de root na conexão VPN
user nobody
group nogroup
15.10. 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/easy-rsa/2.0/
root@firewall:~# ls /usr/share/doc/openvpn/examples/easy-rsa/2.0/
-rwxr-xr-x 1 root root 121 Mar 31 2010 build-ca
-rwxr-xr-x 1 root root 354 Mar 31 2010 build-dh
-rwxr-xr-x 1 root root 190 Mar 31 2010 build-inter
-rwxr-xr-x 1 root root 165 Mar 31 2010 build-key
-rwxr-xr-x 1 root root 159 Mar 31 2010 build-key-pass
-rwxr-xr-x 1 root root 251 Mar 31 2010 build-key-pkcs12

-rwxr-xr-x 1 root root 270 Mar 31 2010 build-key-server
-rwxr-xr-x 1 root root 215 Mar 31 2010 build-req
-rwxr-xr-x 1 root root 160 Mar 31 2010 build-req-pass
-rwxr-xr-x 1 root root 430 Mar 31 2010 clean-all
-rwxr-xr-x 1 root root 1,5K Mar 31 2010 inherit-inter
-rwxr-xr-x 1 root root 297 Mar 31 2010 list-crl
-rw-r--r-- 1 root root 389 Mar 31 2010 Makefile
-rw-r--r-- 1 root root 3,0K Mar 31 2010 openssl-0.9.6.cnf.gz
-rw-r--r-- 1 root root 8,2K Mar 31 2010 openssl.cnf
-rwxr-xr-x 1 root root 13K Abr 28 2010 pkitool
-rw-r--r-- 1 root root 3,7K Mar 31 2010 README.gz
-rwxr-xr-x 1 root root 920 Mar 31 2010 revoke-full
-rwxr-xr-x 1 root root 180 Mar 31 2010 sign-req
-rw-r--r-- 1 root root 1,7K Mar 31 2010 vars
-rwxr-xr-x 1 root root 190 Mar 31 2010 whichopensslcnf
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 :
root@firewall:~# cp -a /usr/share/doc/openvpn/examples/easy-rsa/2.0 \
/etc/openvpn/
Acesse o diretório com os scripts copiados e crie o subdiretório onde serão

armazenadas as chaves e certificado:
root@firewall:~# cd /etc/openvpn/2.0
root@firewall:/etc/openvpn/2.0 # mkdir keys
15.11. 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:
root@firewall:/etc/openvpn/2.0 # aptitude install openssl

root@firewall:/etc/openvpn/2.0 # vim vars
export KEY_SIZE=2048
export KEY_COUNTRY="BR"
export KEY_PROVINCE="SP"
export KEY_CITY="SaoPaulo"
export KEY_ORG="DEXTER"
export KEY_EMAIL="root@dexter.com.br"
Use a sequência de comandos abaixo para gerar o certificado de autoridade:
root@firewall:/etc/openvpn/2.0 # source vars

root@firewall:/etc/openvpn/2.0 # ./clean-all
root@firewall:/etc/openvpn/2.0 # ./build-ca
.....................................+++
..........................................................+++
writing new private key to 'ca.key'
-----
For some fields there will be a default value, If you enter '.', the
field will be left blank.
-----
Country Name (2 letter code) [BR]:BR
State or Province Name (full name) [SP]:São Paulo
Locality Name (eg, city) [SaoPaulo]:SaoPaolo
Organization Name (eg, company) [DEXTER]:DEXTER
Organizational Unit Name (eg, section) []:TI
Common Name (eg, your name or your server's hostname)[DEXTER CA]:Admin
Name []:Tux
Email Address [root@dexter.com.br]:root@dexter.com.br
root@firewall:/etc/openvpn/2.0# ./build-key-server server

..............................................+++
...................................................................+++
writing new private key to 'server.key'
-----
-----
State or Province Name (full name) [SP]:SP
Locality Name (eg, city) [SaoPaulo]:SaoPaulo
Organizational Unit Name (eg, section) []:Admin
Common Name (eg, your name or your server's hostname) [server]:
Name []:

Using configuration from /etc/openvpn/2.0/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'BR'
stateOrProvinceName :PRINTABLE:'SP'
localityName :PRINTABLE:'SaoPaulo'
organizationName :PRINTABLE:'DEXTER'
organizationalUnitName:PRINTABLE:'Admin'
commonName :PRINTABLE:'server'
emailAddress :IA5STRING:'root@dexter.com.br'
Certificate is to be certified until Aug 16 08:41:49 2021 GMT (3650
days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y

Write out database with 1 new entries
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).
root@firewall:/etc/openvpn/2.0# ls -lh keys/server*

-rw-r--r-- 1 root root 5,3K Ago 19 05:42 keys/server.crt
-rw-r--r-- 1 root root 1,1K Ago 19 05:41 keys/server.csr
-rw------- 1 root root 1,7K Ago 19 05:41 keys/server.key
15.12. 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:
root@firewall:/etc/openvpn/2.0# ./build-dh
Generating DH parameters, 2048 bit long safe prime, generator 2
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).
root@firewall:/etc/openvpn/2.0/keys# ls d*.pem
-rw-r--r-- 1 root root 424 Ago 19 05:48 dh2048.pem
15.13. Configurando o servidor OpenVPN
Com os certificados e chaves gerados, abra o arquivo do servidor e adicione

no final as opções abaixo:

...
# Configurando o certificado da VPN
tls-server
tls-auth chave 0
ca 2.0/keys/ca.crt
cert 2.0/keys/server.crt
key 2.0/keys/server.key
dh 2.0/keys/dh2048.pem
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.
root@firewall:/etc/openvpn/2.0/keys#./build-key client
..........................................................+++
..................+++
writing new private key to 'client.key'
-----
-----
State or Province Name (full name) [SP]:SP

Locality Name (eg, city) [SaoPaulo]:SaoPaulo
Organizational Unit Name (eg, section) []:TI
Common Name (eg, your name or your server's hostname) [client]:
Name []:
Using configuration from /etc/openvpn/2.0/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'BR'
stateOrProvinceName :PRINTABLE:'SP'
localityName :PRINTABLE:'SaoPaulo'
organizationName :PRINTABLE:'DEXTER'
organizationalUnitName:PRINTABLE:'TI'
commonName :PRINTABLE:'client'
emailAddress :IA5STRING:'root@dexter.com.br'
Certificate is to be certified until Aug 16 09:12:28 2021 GMT (3650
days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Faça a cópia dos arquivos abaixo via ssh para a máquina cliente.:
root@firewall:~# cd /etc/openvpn/2.0/keys
root@firewall:/etc/openvpn/2.0/keys#scp -P54000 client.key client.crt \
ca.crt root@192.168.X.10:/etc/openvpn
Agora na máquina “Squeeze” , adicione no final do arquivo “client.conf”:


...
# Configurando o certificado da VPN
ns-cert-type server
tls-client
tls-auth chave 1
ca ca.crt
cert client.crt
key client.key
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:
root@firewall:~# /etc/init.d/openvpn start
Execute no cliente:
root@squeeze:~# /etc/init.d/openvpn start
Checando a conexão no servidor...
root@firewall:~# ifconfig
00-00-00-00-00-00-00-00-00-00-00
inet end.: 10.0.0.1 P-a-P:10.0.0.2 Masc:255.255.255.255
… e no cliente:
root@squeeze:~# ifconfig
00-00-00-00-00-00-00-00-00-00-00
inet end.: 10.0.0.2 P-a-P:10.0.0.1 Masc:255.255.255.255
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.

Apostila452 Cardapio QRcode

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

Apostila452 Cardapio QRcode

Enviado por

Direitos autorais:

Formatos disponíveis

1.

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

3.10.9. Logando o comando SU..................................................................................................... 52

6.3.2. Configurando o RAID-1........................................................................................................ 95

8.12.1. Tipos de zonas e Registros.............................................................................................. 186

10.2. Cenário...................................................................................................................... 241

13.6. Proxy Transparente................................................................................................... 300

15.7. Laboratório................................................................................................................ 349

Cenário e Propostas de Solução

• Conhecer o cenário encontrado no dia a dia das empresas;

• Conhecer e entender o cenário praticado com Software Livre;

1.2. Cenário normalmente encontrado nas empresas

Todos sabemos que a área de TI (Tecnologia da Informação) de algumas

O ambiente comumente utilizado nas pequenas e médias empresas é composto

Partindo deste cenário, iremos migrar toda a tecnologia para a plataforma

Além das tecnologias exibidas na figura acima, podemos ainda implementar

Instalando seu Servidor GNU/Linux no

• Como o cenário interfere em suas decisões;

• Entender o conceitos de RAID e LVM;

• Instalar o servidor no volume RAID+LVM;

2.3. Proposta de solução

A fim de solucionar eventuais paradas do servidor, instalaremos o sistema

2.4. Introdução Teórica - RAID

RAID, do inglês Redundant Array of Independent Disks, significa

O conceito fundamental do RAID é que os dados podem ser distribuídos ao

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 de uma falha de disco

Temos 2 formas de se montar um sistema em RAID:

• Via Software: Feito por aplicativos e módulos do sistema operacional. O

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.

2.4.1. Tipos de RAID

Os principais níveis de “RAID” utilizados hoje no mercado são os níveis 0, 1, 5,

• RAID 0 (Stripping): Este é o único nível de “RAID” que não implementa

Então o RAID 0 garante redundância?

Não!!! Esta é a desvantagem, pois se qualquer um dos discos falhar, o sistema

* Excelente gravação e leitura;

* Aproveitamento total de espaço;

• RAID 1 (Mirroring): O nível mais utilizado. Sua principal finalidade é prover

RAID1 é backup? Não!!!!! É apenas redundância.

DICA DE SEGURANÇA: “RAID 1” espelhado não é backup. Se você apagar

* Redundância: se um dos discos falhar, o sistema continua funcionando;

* Reduz um pouco o desempenho da escrita, pois o mesmo dado é gravado

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

• RAID 5: Neste nível de “RAID” teremos um balanço das vantagens e

A “mágica” do “RAID 5” está justamente na divisão e distribuição destes

A quantidade mínima de discos no “RAID 5” é 3, podendo suportar qualquer

• RAID 6: É um padrão relativamente novo, suportado por apenas algumas

controladoras. Ele é semelhante ao RAID 5, porém usa o dobro de bits de paridade,

A percentagem de espaço sacrificado decai conforme são acrescentados mais

Tanto no caso do RAID 5, quanto no RAID 6, o servidor continua funcionando