Pr aticas de Seguranca para Administradores de Redes Internet

NIC BR Security Ofce

nbso@nic.br
Vers ao 1.1.1
24 de setembro de 2002
Copyright c 2002 NBSO
Resumo
Este documento e destinado a administradores de redes ligadas ` a Internet, incluindo provedores de acesso
e de conte udo. O seu prop osito e ser um guia com informac oes para congurar, administrar e operar estas
redes de forma mais segura.
Sum ario
1 Introduc ao 4
1.1 Organizac ao do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Como Obter este Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Nota de Copyright e Distribuic ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Polticas 6
2.1 Polticas de Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Polticas de Uso Aceit avel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Instalac ao e Congurac ao Segura de Sistemas 9
3.1 Preparac ao da Instalac ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Estrat egias de Particionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Documentac ao da Instalac ao e Congurac ao . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Senhas de Administrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 Instalac ao Mnima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1
3.6 Desativac ao de Servicos N ao Utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.7 Instalac ao de Correc oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.8 Prevenc ao de Abuso de Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.8.1 Controle de Relay em Servidores SMTP . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.8.2 Controle de Acesso a Proxies Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4 Administrac ao e Operac ao Segura de Redes e Sistemas 17
4.1 Ajuste do Rel ogio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1 Sincronizac ao de Rel ogios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2 Timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Equipes de Administradores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.1 Comunicac ao Eciente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.2 Controle de Alterac oes na Congurac ao . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.3 Uso de Contas Privilegiadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.1 Gerac ao de Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.2 Armazenamento de Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.3 Monitoramento de Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.1 Limitac ao de Transfer encias de Zona . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.2 Separac ao de Servidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.3 Uso de Privil egios Mnimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.4 Cuidado com Informac oes Sensveis no DNS . . . . . . . . . . . . . . . . . . . . . . 22
4.4.5 DNS Reverso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.5 Informac oes de Contato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5.1 Enderecos Eletr onicos Padr ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5.2 Contato no DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5.3 Contatos no WHOIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.6 Eliminac ao de Protocolos sem Criptograa . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2
4.7 Cuidados com Redes Reservadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.8 Polticas de Backup e Restaurac ao de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.9 Como Manter-se Informado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.10 Precauc oes contra Engenharia Social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.11 Uso Ecaz de Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.11.1 A Escolha de um Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.11.2 Localizac ao dos Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.11.3 Crit erios de Filtragem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.11.4 Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
A Refer encias Adicionais 35
A.1 URLs de Interesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.2 Livros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Indice Remissivo 37
3
1 Introduc ao
Este documento procura reunir um conjunto de boas pr aticas em congurac ao, administrac ao e operac ao
segura de redes conectadas ` a Internet. A implantac ao destas pr aticas minimiza as chances de ocorrerem pro-
blemas de seguranca e facilita a administrac ao das redes e recursos de forma segura.

E importante frisar que
este conjunto representa o mnimo indispens avel dentro de um grande universo de boas pr aticas de seguranca,
o que equivale a dizer que a sua adoc ao e um bom comeco mas n ao necessariamente e suciente em todas as
situac oes.
As recomendac oes apresentadas s ao eminentemente pr aticas e, tanto quanto possvel, independentes de
plataforma de software e hardware. A maioria dos princpios aqui expostos e gen erica; a sua efetiva aplicac ao
requer que um administrador determine como estes princpios podem ser implementados nas plataformas que
ele utiliza.
Este documento e dirigido ao pessoal t ecnico de redes conectadas ` a Internet, especialmente aos adminis-
tradores de redes, sistemas e/ou seguranca, que s ao os respons aveis pelo planejamento, implementac ao ou
operac ao de redes e sistemas. Tamb em podem se beneciar da sua leitura gerentes com conhecimento t ecnico
de redes.
1.1 Organizac ao do Documento
O restante deste documento est a organizado da seguinte maneira. A sec ao 2 apresenta polticas importantes
para respaldar e viabilizar os procedimentos t ecnicos descritos nas sec oes subseq uentes. A sec ao 3 mostra como
congurar sistemas e redes de forma mais segura. Na sec ao 4 s ao discutidos m etodos para se ter seguranca na
administrac ao e operac ao de redes e sistemas. O ap endice A traz sugest oes de material de consulta para quem
queira obter conhecimentos mais aprofundados sobre algum dos temas abordados nas sec oes de 2 a 4.
1.2 Como Obter este Documento
Este documento pode ser obtido em http://www.nbso.nic.br/docs/seg-adm-redes.html. Como ele
e periodicamente atualizado, certique-se de ter sempre a vers ao mais recente.
No mesmo endereco tamb em est a disponvel um checklist que resume as principais pr aticas apresentadas
neste documento, e que pode ser usado para o acompanhamento da sua implantac ao.
Caso voc e tenha alguma sugest ao para este documento ou encontre algum erro nele, entre em contato
atrav es do endereco doc@nic.br.
1.3 Nota de Copyright e Distribuic ao
Este documento e Copyright c 2002 NBSO. Ele pode ser livremente copiado desde que sejam respeitadas
as seguintes condic oes:
1.

E permitido fazer e distribuir c opias inalteradas deste documento, completo ou em partes, contanto que
esta nota de copyright e distribuic ao seja mantida em todas as c opias, e que a distribuic ao n ao tenha ns
comerciais.
4
2. Se este documento for distribudo apenas em partes, instruc oes de como obt e-lo por completo devem ser
includas.
3.

E permitido o uso dos exemplos de documentos e de congurac ao includos neste texto. Tal uso e
completamente livre e n ao est a sujeito a nenhuma restric ao.
4.

E vedada a distribuic ao de vers oes modicadas deste documento, bem como a comercializac ao de c opias,
sem a permiss ao expressa do NBSO.
Embora todos os cuidados tenham sido tomados na preparac ao deste documento, o NBSO n ao garante
a correc ao absoluta das informac oes nele contidas, nem se responsabiliza por eventuais conseq u encias que
possam advir do seu uso.
5
2 Polticas
2.1 Polticas de Seguranca
Uma poltica de seguranca e um instrumento importante para proteger a sua organizac ao contra ameacas ` a
seguranca da informac ao que a ela pertence ou que est a sob sua responsabilidade. Uma ameaca ` a seguranca
e compreendida neste contexto como a quebra de uma ou mais de suas tr es propriedades fundamentais (con-
dencialidade, integridade e disponibilidade).
A poltica de seguranca n ao dene procedimentos especcos de manipulac ao e protec ao da informac ao,
mas atribui direitos e responsabilidades ` as pessoas (usu arios, administradores de redes e sistemas, funcion arios,
gerentes, etc.) que lidam com essa informac ao. Desta forma, elas sabem quais as expectativas que podem ter
e quais s ao as suas atribuic oes em relac ao ` a seguranca dos recursos computacionais com os quais trabalham.
Al em disso, a poltica de seguranca tamb em estipula as penalidades ` as quais est ao sujeitos aqueles que a des-
cumprem.
Antes que a poltica de seguranca seja escrita, e necess ario denir a informac ao a ser protegida. Usualmente,
isso e feito atrav es de uma an alise de riscos, que identica:
recursos protegidos pela poltica;
ameacas ` as quais estes recursos est ao sujeitos;
vulnerabilidades que podem viabilizar a concretizac ao destas ameacas, analisando-as individualmente.
Uma poltica de seguranca deve cobrir os seguintes aspectos:
aspectos preliminares:
abrang encia e escopo de atuac ao da poltica;
denic oes fundamentais;
normas e regulamentos aos quais a poltica est a subordinada;
quem tem autoridade para sancionar, implementar e scalizar o cumprimento da poltica;
meios de distribuic ao da poltica;
como e com que freq u encia a poltica e revisada.
poltica de senhas:
requisitos para formac ao de senhas;
perodo de validade das senhas;
normas para protec ao de senhas;
reuso de senhas;
senhas default.
direitos e responsabilidades dos usu arios, tais como:
utilizac ao de contas de acesso;
utilizac ao de softwares e informac oes, incluindo quest oes de instalac ao, licenciamento e copyright;
6
protec ao e uso de informac oes (sensveis ou n ao), como senhas, dados de congurac ao de sistemas
e dados condenciais da organizac ao;
uso aceit avel de recursos como email, news e p aginas Web;
direito ` a privacidade, e condic oes nas quais esse direito pode ser violado pelo provedor dos recursos
(a organizac ao);
uso de antivrus.
direitos e responsabilidades do provedor dos recursos, como:
backups;
diretrizes para congurac ao e instalac ao de sistemas e equipamentos de rede;
autoridade para conceder e revogar autorizac oes de acesso, conectar e desconectar sistemas e equi-
pamentos de rede, alocar e registrar enderecos e nomes de sistemas e equipamentos;
monitoramento de sistemas e equipamentos de rede;
normas de seguranca fsica.
ac oes previstas em caso de violac ao da poltica:
diretrizes para tratamento e resposta de incidentes de seguranca;
penalidades cabveis.
Cabe ressaltar que a lista de t opicos acima n ao e exaustiva nem tampouco se aplica a todos os casos.
Cada organizac ao possui um ambiente distinto e os seus pr oprios requisitos de seguranca, e deve, portanto,
desenvolver uma poltica de seguranca que se molde a essas peculiaridades.
Alguns fatores importantes para o sucesso de uma poltica de seguranca s ao:
apoio por parte da administrac ao superior;
a poltica deve ser ampla, cobrindo todos os aspectos que envolvem a seguranca dos recursos computaci-
onais e da informac ao sob responsabilidade da organizac ao;
a poltica deve ser periodicamente atualizada de forma a reetir as mudancas na organizac ao;
deve haver um indivduo ou grupo respons avel por vericar se a poltica est a sendo respeitada;
todos os usu arios da organizac ao devem tomar conhecimento da poltica e manifestar a sua concord ancia
em submeter-se a ela antes de obter acesso aos recursos computacionais;
a poltica deve estar disponvel em um local de f acil acesso aos usu arios, tal como a intranet da organiza-
c ao.
Dentre os itens acima, o apoio por parte da administrac ao superior e essencial. Se a poltica de
seguranca n ao for encampada pela administrac ao, ela rapidamente ser a deixada de lado pelos demais seto-
res da organizac ao. Al em disso, e importante que os seus membros d eem o exemplo no que diz respeito ` a
observ ancia da poltica de seguranca.
Os seguintes fatores inuem negativamente na aceitac ao de uma poltica de seguranca e podem lev a-la ao
fracasso:
a poltica n ao deve ser demasiadamente detalhada ou restritiva;
7
o excesso de detalhes na poltica pode causar confus ao ou diculdades na sua implementac ao;
n ao devem ser abertas excec oes para indivduos ou grupos;
a poltica n ao deve estar atrelada a softwares e/ou hardwares especcos.
2.2 Polticas de Uso Aceit avel
A poltica de uso aceit avel (AUPAcceptable Use Policy) e o documento que dene como os recursos
computacionais da organizac ao podem ser utilizados. Ela deve ser p ublica e estar disponvel a todos os que
utilizam a infra-estrutura computacional da organizac ao, sendo recomend avel que a autorizac ao para uso dos
recursos seja condicionada a uma concord ancia expressa com os seus termos.
A AUP e geralmente parte integrante da poltica de seguranca global. Para muitas organizac oes, ela ser a
composta pelos itens da poltica que afetamdiretamente os usu arios de recursos computacionais, principalmente
os que denem seus direitos e responsabilidades.
Por outro lado, organizac oes que oferecem acesso a usu arios externos (tais como provedores de acesso
Internet) devem denir uma poltica de uso aceit avel para esses usu arios que seja independente da AUP ` a qual
est ao sujeitos os seus usu arios internos.

E importante que os usu arios externos tomem conhecimento dessa
poltica e saibam que o uso dos recursos est a condicionado ao seu cumprimento.
8
3 Instalac ao e Congurac ao Segura de Sistemas
Uma vez estabelecidas as polticas de seguranca apropriadas para a sua rede (conforme exposto na sec ao 2),
a etapa seguinte deve ser a congurac ao segura dos sistemas que estar ao nessa rede.
Caso n ao exista uma documentac ao atualizada que detalhe a congurac ao de alguns ou todos os sistemas
em uso na sua rede, e aconselh avel que estes sistemas sejam reinstalados observando-se as recomendac oes aqui
expostas, ou, pelo menos, que a sua congurac ao seja revisada e a documentac ao correspondente atualizada.
IMPORTANTE: um sistema s o dever a ser conectado ` a Internet ap os os passos descritos nas sec oes 3.1 a 3.8
terem sido seguidos. A pressa em disponibilizar um sistema na Internet pode levar ao seu comprometi-
mento.
3.1 Preparac ao da Instalac ao
A instalac ao de um sistema deve ser feita com ele isolado do mundo externo. Para tanto, os seguintes
princpios devem ser seguidos:
planeje a instalac ao, denindo itens como:
o prop osito do sistema a ser instalado;
os servicos que este sistema disponibilizar a;
a congurac ao de hardware da m aquina;
como o disco ser a particionado, etc.
providencie de antem ao todos os manuais e mdias de instalac ao que ser ao utilizados;
instale o sistema a partir de dispositivos de armazenamento locais (CD, ta ou disco), desconectado da
rede;
caso voc e precise ligar o sistema em rede (para fazer download de atualizac oes, por exemplo), coloque-o
em uma rede isolada, acessvel apenas pela sua rede interna.
Caso seja possvel, evite concentrar todos os servicos de rede em uma unica m aquina, dividindo-os entre
v arios sistemas. Isto e desej avel pois aumenta a disponibilidade dos servicos na sua rede e reduz a extens ao de
um eventual comprometimento a partir de um deles.
3.2 Estrat egias de Particionamento
Conforme mencionado na sec ao 3.1, um dos aspectos que devem ser includos no planejamento da ins-
talac ao e como ser a feito o particionamento do(s) disco(s) do sistema. Embora isso dependa basicamente da
utilizac ao pretendida para o sistema, existem alguns fatores que devem ser levados em considerac ao no mo-
mento de decidir como o disco deve ser particionado.
Um princpio b asico e dividir o disco em v arias partic oes em vez de usar uma unica partic ao ocupando o
disco inteiro. Isto e recomend avel por diversas raz oes:
9
Um usu ario ou um programa mal-comportado pode lotar uma partic ao na qual tenha permiss ao de escrita
( areas tempor arias e de armazenamento de logs s ao suscetveis a este problema). Se os programas do
sistema estiverem em outra partic ao eles provavelmente n ao ser ao afetados, evitando que o sistema trave.
Caso uma partic ao seja corrompida por alguma raz ao, as outras partic oes provavelmente n ao ser ao afe-
tadas.
Em alguns sistemas (notadamente sistemas UNIX), e possvel denir algumas caractersticas individuais
para cada partic ao. Por exemplo, algumas partic oes podem ser usadas em modo read-only, o que e util
para partic oes que contenham bin arios que s ao modicados com pouca freq u encia.
Em alguns casos a exist encia de v arias partic oes permite m ultiplas operac oes de disco em paralelo e/ou o
uso de otimizac oes individuais para cada partic ao, o que pode aumentar signicativamente o desempenho
do sistema.
O uso de v arias partic oes geralmente facilita o procedimento de backup do sistema, pois simplica
func oes como:
copiar partic oes inteiras de uma s o vez;
excluir partic oes individuais do procedimento;
fazer backups a intervalos diferentes para cada partic ao.
As partic oes especcas que devem ser criadas variam de sistema para sistema, n ao existindo uma regra que
possa ser sempre seguida. Entretanto, recomenda-se avaliar a conveni encia da criac ao de partic oes separadas
para as areas onde s ao armazenados itens como:
programas do sistema operacional;
dados dos usu arios;
logs;
arquivos tempor arios;
las de envio e recepc ao de emails (servidores SMTP);
las de impress ao (servidores de impress ao);
reposit orios de arquivos (servidores FTP);
p aginas Web (servidores HTTP).
Note que a lista acima n ao e exaustiva, podendo existir outras areas do sistema que merecam uma partic ao
separada. Da mesma forma, existem itens dentre os acima que n ao se aplicam a determinados casos. Consulte a
documentac ao do seu sistema operacional para ver se ela cont em recomendac oes a respeito do particionamento
adequado dos discos.
As partic oes devem ser dimensionadas de acordo com os requisitos de cada sistema. Em muitos ca-
sos, o tamanho ocupado pelo sistema operacional e fornecido na sua documentac ao, o que pode auxiliar na
determinac ao do tamanho de algumas partic oes.
Qualquer que seja a estrutura de particionamento escolhida, e recomend avel que voc e tenha pelo menos
um esboco dela por escrito antes de comecar a instalac ao. Isto agiliza o processo de instalac ao e reduz a
probabilidade de que se faca uma determinada escolha sem que as suas conseq u encias sejam adequadamente
previstas.
10
3.3 Documentac ao da Instalac ao e Congurac ao
Uma medida importante para permitir uma r apida avaliac ao da situac ao de um sistema e a documentac ao
de sua instalac ao e congurac ao. A id eia e ter uma esp ecie de logbook (ou di ario de bordo), que detalhe os
componentes instalados no sistema e todas as modicac oes na sua congurac ao global.
Esse logbook pode ser particularmente util para determinar qual vers ao de determinado pacote est a instalada
no sistema ou para reconstituir uma dada instalac ao. Muitas vezes um administrador precisa consultar diversas
fontes e realizar v arias tentativas antes de instalar e/ou congurar corretamente um determinado pacote de
software. Aexist encia de umdocumento que relate quais os passos exatos que tiveramque ser seguidos para que
a instalac ao/congurac ao fosse bem sucedida permite que esse mesmo pacote possa ser instalado com correc ao
e rapidez em outro sistema ou ocasi ao. Conforme ser a visto na sec ao 4.2, a import ancia deste documento cresce
na medida em que a responsabilidade pela administrac ao dos sistemas seja compartilhada por diversas pessoas.
O formato e o grau de sosticac ao do logbook dependem de diversos fatores, e cada administrador deve
determinar qual a melhor maneira de manter essas informac oes. Um simples arquivo texto pode revelar-se
extremamente ecaz, como mostram os exemplos da gura 1. O que realmente importa e que esse documento
esteja disponvel em caso de falha (acidental ou provocada) do sistema, e que ele contenha informac oes su-
cientes para que, a partir dele, seja possvel reconstituir a exata congurac ao que o sistema possua antes da
falha, sem que seja necess ario recorrer a backups.
1

E essencial que alterac oes na congurac ao do sistema e de seus componentes estejam documentadas neste
logbook. A entrada referente a estas alterac oes deve conter, no mnimo, os seguintes itens:
data da modicac ao;
respons avel pela modicac ao;
justicativa para a modicac ao;
descric ao da modicac ao.
Deve ser possvel, ainda, reconstituir a situac ao antes da mudanca na congurac ao a partir dessa entrada.
A gura 1 mostra um exemplo com algumas entradas do logbook de um servidor FTP. A primeira entrada
registra a instalac ao inicial do sistema, realizada no dia 26/02 por um administrador chamado Joe, e descreve
ainda:
o sistema operacional utilizado;
como ele foi instalado;
como o disco foi particionado;
onde pode ser encontrada a lista de pacotes instalados;
quais as portas que caram ativas ap os a instalac ao;
quais os usu arios criados (com seus respectivos UIDs e GIDs).
1
A exist encia do logbook n ao diminui a import ancia dos backups, que ser ao tratados na sec ao 4.8.
11
Logbook para vangogh.example.org (IP 192.0.2.24)
================================================
26/Fev/2002 Responsavel: Joe
Instalacao de vangogh.example.org, servidor FTP de example.org. Instalado o
sistema operacional GoodBSD versao 6.5. A instalacao foi feita usando a opcao
custom do menu de instalacao. O disco foi particionado da seguinte maneira:
Filesystem Size Mount point | Filesystem Size Mount point
/dev/wd0a 100M / | /dev/wd0f 2.0G /usr
/dev/wd0d 3.0G /var | /dev/wd0g 400M /home
/dev/wd0e 500M /tmp | /dev/wd0h 4.0G /home/ftp
Uma lista dos pacotes instalados esta em /usr/local/sysadm/pkg.inst. As portas
abertas apos a instalacao sao (netstat -a):
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 0 0 *.ftp *.* LISTEN
tcp 0 0 *.ssh *.* LISTEN
udp 0 0 vangogh.example.org.ntp *.*
udp 0 0 localhost.ntp *.*
udp 0 0 *.ntp *.*
udp 0 0 *.syslog *.*
Criados os usuarios joe (UID=501), alice (UID=502), bob (UID=503) e caio
(UID=504). Cada usuario pertence ao seu proprio grupo (GID=UID) e joe, alice e
bob pertencem tambem ao grupo wheel.
------------------------------------------------------------------------
01/Mar/2002 Responsavel: Alice
Instalado o foo-1.2.3, uma ferramenta para analise de logs de FTP. Os fontes
estao em /usr/local/src/foo-1.2.3. Os comandos necessarios para a instalacao foram:
$ ./configure
$ make
# make install
Para usar o programa, foi necessario criar o usuario foo (UID=300,GID=100/users)
e o diretorio /usr/local/share/foo (owner=foo, group=users), com permissoes 0755.
------------------------------------------------------------------------
03/Mar/2002 Responsavel: Bob
Criado o grupo foobar (GID=300), para os usuarios do pacote foo. O diretorio
/usr/local/share/foo teve seu grupo alterado de users para foobar e as
permissoes de 0755 para 0750. Modificacao necessaria para que apenas usuarios
pertencentes ao grupo foobar tenham acesso aos programas do pacote foo. Os
usuarios alice, bob e caio foram adicionados ao grupo foobar.
------------------------------------------------------------------------
03/Mar/2002 Responsavel: Alice
Modificado o /etc/rc.local para carregar o daemon bard (usado pelo pacote
foo) no boot. Um diff da modificacao esta em /usr/local/sysadm/rc.local-bard.diff.
Figura 1: Exemplos de entradas no logbook
12
Ap os a instalac ao inicial do sistema operacional, no dia 01/03 foi instalado um pacote chamado foo, vers ao
1.2.3. A entrada correspondente no logbook descreve os passos que foram seguidos para compilar e instalar o
pacote e para preparar o sistema para o seu uso (criac ao de um usu ario e um diret orio, com suas respectivas
informac oes).
A terceira entrada registra algumas alterac oes que tiveram que ser feitas na congurac ao do sistema pa-
ra que o pacote foo pudesse ser usado corretamente. Por sua vez, a ultima entrada do exemplo apresenta
uma modicac ao na inicializac ao do sistema para carregar um daemon (software servidor) usado pelo paco-
te. Observe que ambas as entradas permitem que a situac ao anterior do sistema (ou seja, a situac ao antes das
modicac oes descritas) seja restaurada, caso isso se revele necess ario ou desej avel.
IMPORTANTE: o logbook de um sistema e um documento sensvel, pois cont em informac oes que podem
ser usadas para comprometer mais facilmente a seguranca deste sistema. Sendo assim, ele deve ser armazenado
e manipulado com cuidado, de acordo com a poltica para documentos sensveis da sua organizac ao.
3.4 Senhas de Administrador
Durante a instalac ao de um sistema, em determinado momento ser a solicitado que voc e informe uma senha
de administrador (root ou Administrator). Na maioria dos casos, e o pr oprio programa de instalac ao que
solicita a escolha da senha. Em outros casos, a senha de administrador deve ser denida ap os o primeiro boot
do sistema.
Procure estabelecer esta senha t ao cedo quanto possvel durante a instalac ao do sistema. De prefer encia,
tenha uma senha j a em mente quando comecar a instalac ao.
Uma senha adequada e aquela f acil de ser lembrada e difcil de ser adivinhada. Ela deve respeitar, no
mnimo, os seguintes crit erios:
ter um comprimento mnimo de 8 caracteres;
ser formada por letras, n umeros e caracteres especiais;
n ao ser derivada de seus dados pessoais, tais como nomes de membros da famlia (incluindo animais de
estimac ao), n umeros de telefone, placas de carros, n umeros de documentos e datas;
n ao dever ser adivinhada por quem conheca suas prefer encias pessoais (time para o qual torce, escritor,
ator ou cantor favorito, nomes de livros, lmes ou m usicas, etc.);
n ao estar presente em dicion arios (de portugu es ou de outros idiomas).
Uma sugest ao para formar senhas que se encaixem nos requisitos acima e usar as primeiras ou ultimas letras
das palavras de uma frase, adicionando n umeros e smbolos e trocando min usculas e mai usculas para dicultar
ataques baseados em forca bruta. Por exemplo, a partir das iniciais de the book is on the table obt em-se,
inicialmente, tbiott. A partir da, e possvel trocar a letra o por um 0 (zero) e o pen ultimo t por um
smbolo +, colocar algumas letras em mai usculo e acrescentar outras letras, chegando a tBi0+TbL, uma
senha bastante difcil de ser adivinhada ou obtida por forca bruta.
2
2
Evidentemente esta deixou de ser uma senha segura por constar neste documento.
13
3.5 Instalac ao Mnima
Um sistema mais seguro comeca pela instalac ao do mnimo possvel de pacotes e componentes, especial-
mente os que implementam servicos de rede. Este mnimo depende fundamentalmente do prop osito do sistema
em quest ao e do ambiente de rede no qual ele est a inserido. Por exemplo, em princpio um sistema dedicado
a servir p aginas Web n ao precisa de um software servidor SMTP, assim como uma estac ao de trabalho n ao
precisa de um servidor HTTP.
A justicativa para esta recomendac ao e bastante simples.

E comum que servicos n ao utilizados n ao se-
jam monitorados por falhas de seguranca, o que aumenta a possibilidade de n ao ser aplicada uma correc ao
necess aria. A reduc ao no n umero de pacotes instalados diminui a chance de que o sistema possua uma vulne-
rabilidade que possa vir a ser explorada por um atacante.
Muitas vezes, administradores preferem instalar componentes cujo prop osito ou funcionalidade desconhe-
cam por receio de que alguma coisa deixe de funcionar no sistema. Entretanto, a maioria dos sistemas atuais
possui algum mecanismo de controle de depend encias que avisa quando determinado componente precisa de
outro para funcionar. Em outras palavras, freq uentemente e possvel deixar de instalar v arios componentes sem
comprometer a funcionalidade do sistema. Consulte a documentac ao do seu sistema ou o suporte t ecnico do
seu fornecedor para saber se isto se aplica ao seu caso.
Alguns programas de instalac ao permitem que o administrador escolha entre uma instalac ao tpica e uma
personalizada (para experts). Quando possvel, opte pela personalizada, evitando instalar componentes cuja
funcionalidade seja desconhecida ou que voc e n ao esteja certo quanto ` a sua necessidade.
Em outros sistemas a instalac ao se d a em duas etapas, a instalac ao do sistema base (sobre a qual o admi-
nistrador tem mnimo ou nenhum controle) e a instalac ao de pacotes ou componentes adicionais. Neste caso,
instale o sistema base e selecione cuidadosamente quais os componentes extras que ser ao adicionados ao siste-
ma. Neste tipo de sistema, a desativac ao de servicos n ao utilizados (sec ao 3.6) e muito importante e deve ser
realizada com especial atenc ao.
3.6 Desativac ao de Servicos N ao Utilizados
O passo seguinte a uma instalac ao mnima e a desativac ao de servicos (locais e, principalmente, de rede)
que n ao ser ao imediatamente utilizados no sistema. A l ogica por tr as desta recomendac ao e a mesma por tr as
da instalac ao mnima de pacotes: reduzir a exposic ao do sistema a vulnerabilidades.
Embora possa parecer que exista redund ancia entre este passo e o anterior, na pr atica surgem situac oes
nas quais o administrador e forcado a instalar um pacote ou componente completo para poder utilizar um
subconjunto das funcionalidades oferecidas por esse pacote. Al em disso, muitos programas de instalac ao de
sistemas operacionais optam por maximizar a funcionalidade disponibilizada aos usu arios, e a congurac ao
padr ao do sistema traz ativados todos os servicos que foram instalados. Caso uma dessas situac oes ocorra, as
funcionalidades que n ao ser ao utilizadas dever ao ser desativadas ou mesmo removidas do sistema.
Por exemplo, suponha que um pacote de servicos de impress ao contenha tanto um cliente quanto um servi-
dor de impress ao remota. Se o sistema necessitar apenas do software cliente, o administrador deve desabilitar
a parte referente ao software servidor neste sistema.
Caso n ao seja possvel desativar servicos individualmente, uma alternativa e usar um ltro de pacotes para
bloquear as portas TCP/UDP usadas por esses servicos, impedindo que eles sejam acessados atrav es da rede.
Isto ser a discutido em maiores detalhes na sec ao 4.11.
14
IMPORTANTE: a desativac ao de servicos e/ou a remoc ao de arquivos efetuadas nesta fase dever ao ser
documentadas no logbook do sistema.
3.7 Instalac ao de Correc oes
Depois de um sistema ter sido corretamente instalado e congurado, e necess ario vericar se n ao existem
correc oes (patches, xes, service packs) para vulnerabilidades conhecidas nos componentes instalados. A mai-
oria dos fornecedores de software libera correc oes para problemas de seguranca que sejam descobertos em um
sistema, sem que se tenha de esperar pela sua pr oxima vers ao. Na maioria das vezes, estas correc oes est ao
disponveis atrav es da Internet. Consulte seu fornecedor para saber como manter-se informado a respeito de
correc oes para o seu sistema e de que forma elas podem ser obtidas.
Nem sempre todas as correc oes disponveis precisam ser instaladas. Restrinja-se ` aquelas que corrigem
problemas em componentes que estejam efetivamente instalados no seu sistema. Em caso de d uvida, recorra ao
suporte t ecnico do seu fornecedor. A instalac ao indiscriminada de atualizac oes pode enfraquecer a seguranca
do sistema ao inv es de fortalec e-la.
Registre no logbook a instalac ao de correc oes. Mantenha em sua rede um reposit orio das atualizac oes que
j a foram utilizadas, para facilitar a instalac ao das mesmas em outros sistemas.
IMPORTANTE: muitas vezes algumas congurac oes do sistema s ao alteradas durante o processo de instala-
c ao de correc oes. Sendo assim, e recomend avel que voc e reveja a congurac ao do seu sistema ap os instalar
uma correc ao para certicar-se de que a instalac ao n ao tenha revertido eventuais modicac oes que voc e tenha
feito (especialmente aquelas destinadas a desativar servicos).
IMPORTANTE: a instalac ao de correc oes deve ser realizada n ao s o como parte da instalac ao inicial do
sistema, mas tamb em durante o seu tempo de vida, a intervalos peri odicos ou sempre que surgirem vulnerabi-
lidades que o afetem. A sec ao 4.9 traz algumas recomendac oes sobre como manter-se informado a respeito de
novas vulnerabilidades que afetem os seus sistemas.
3.8 Prevenc ao de Abuso de Recursos
Existem alguns servicos que, se mal congurados, podem permitir que usu arios externos abusem dos re-
cursos da sua rede, ainda que isso n ao implique na ocorr encia de uma invas ao. Dois destes servicos s ao o email
e os proxies de Web.
A congurac ao incorreta destes servicos pode causar v arios efeitos indesej aveis. Um deles e que recursos
computacionais da organizac aoa comecar pelo link Internet, mas incluindo CPU, discos e mem oria dos
servidoress ao consumidos por terceiros sem que eles paguem por esse uso. Em muitos casos, esses recursos
s ao exauridos de forma que usu arios legtimos n ao possam utilizar o servico.
Al em disso, servidores mal congurados s ao muitas vezes usados para disseminar conte udo ilegal, tal como
pornograa envolvendo criancas. Se um conte udo deste tipo for encontrado em sistemas sob sua responsabili-
dade, existe a possibilidade de que voc e e/ou sua organizac ao venham a ser legalmente implicados no caso.
15
3.8.1 Controle de Relay em Servidores SMTP
Na sua congurac ao padr ao, muitos servidores SMTP v em com o relay aberto, permitindo que eles sejam
usados para enviar mensagens de e para qualquer rede ou domnio, independente dos enderecos envolvidos
serem da sua rede ou n ao. Estes servidores s ao amplamente explorados para envio de SPAM.
Al em das conseq u encias j a mencionadas, diversas redes bloqueiam a recepc ao de mensagens a partir de
servidores que tenhamsido ou estejamsendo usados para envio de SPAM, fazendo comque usu arios do servidor
com relay aberto n ao possam enviar mensagens a usu arios dessas redes. H a que se considerar tamb em que o
uso de servidores SMTP de terceiros torna mais difcil a localizac ao e identicac ao dos spammers, diminuindo
as chances de que eles sejam punidos por estes abusos.
Para resolver este problema de relay aberto voc e precisa congurar os seus servidores SMTP corretamente.
A congurac ao adequada deve permitir apenas:
envio de mensagens com endereco de origem local e endereco de destino local ou externo;
recepc ao de mensagens com endereco de origem local ou externo e endereco de destino local.
Informac oes sobre como corrigir este problema para diferentes servidores SMTP est ao disponveis em
http://www.mail-abuse.org/tsi/.
Na maioria dos casos, e possvel fechar o relay mesmo quando a rede possui roaming users, usando me-
canismos como POP-before-SMTP e SMTP AUTH. Caso a sua rede necessite suportar usu arios deste tipo,
consulte a documentac ao do seu servidor SMTP ou o seu fornecedor para saber como fechar o relay sem
prejudicar a utilizac ao do servico por parte deles.
3.8.2 Controle de Acesso a Proxies Web
Assim como no caso dos servidores SMTP, softwares que fazem proxy de Web (tais como Squid, Wingate
e Microsoft Proxy Server) tamb em podem ser abusados se n ao forem tomadas as devidas precauc oes.
Um proxy mal congurado pode ser usado por usu arios externos como um trampolim para acessar recur-
sos de forma an onima. Esta anonimidade pode ser usada para cometer crimes, tais como envio de mensagens
caluniosas, difamat orias ou ameacadoras e divulgac ao de pornograa envolvendo criancas.
A congurac ao correta para um proxy Web e aquela que libera o acesso somente aos enderecos IP de
usu arios autorizados (pertencentes ` a sua rede). Consulte a documentac ao do seu software ou o suporte t ecnico
do seu fornecedor para obter maiores informac oes sobre como congurar o controle de acesso no seu proxy.
16
4 Administrac ao e Operac ao Segura de Redes e Sistemas
4.1 Ajuste do Rel ogio
4.1.1 Sincronizac ao de Rel ogios
Os rel ogios de todos os sistemas da sua rede (incluindo as estac oes de trabalho) dever ao estar sincronizados,
ou seja, dever ao ter exatamente o mesmo hor ario. Para que isso aconteca, voc e deve usar um protocolo de
sincronizac ao de rel ogios, tal como o NTP (Network Time Protocol). Este protocolo e o mais recomendado,
pois existem implementac oes dele para os mais variados sistemas operacionais, como pode ser visto em http:
//www.ntp.org/.
Para obter maior precis ao no ajuste e para minimizar o tr afego desnecess ario na rede, sugere-se que a
sincronizac ao via NTP seja implementada observando-se as seguintes recomendac oes:
1. Procure manter em sua rede um servidor NTP local. Esse servidor e quem ir a realizar a sincronizac ao
com um servidor externo. As demais m aquinas da sua rede, por sua vez, ter ao seus rel ogios sincronizados
com o rel ogio do servidor local.
2. Muitos backbones disponibilizam um servidor NTP a seus clientes. Consulte o suporte t ecnico do seu
backbone para vericar se ele oferece este servico e como voc e pode fazer para utiliz a-lo.
4.1.2 Timezone
Caso voc e trabalhe com servidores UNIX, ajuste o rel ogio de hardware destes sistemas para a hora padr ao
de Greenwich (GMT) e congure adequadamente o seu fuso hor ario (timezone) para que a hora local seja
exibida corretamente.
O uso do timezone certo tamb em possibilita o ajuste automatizado do rel ogio por conta do hor ario de ver ao.
Para que isso seja possvel, voc e dever a criar ou obter um arquivo de informac oes de timezone com as datas
corretas de incio e m do hor ario de ver ao. Para maiores informac oes, consulte a documentac ao do comando
zic.
4.2 Equipes de Administradores
Em muitas redes, a administrac ao de sistemas e uma responsabilidade dividida entre v arias pessoas. Nesses
casos, e necess ario estabelecer algumas regras para garantir a eci encia do trabalho em equipe.
4.2.1 Comunicac ao Eciente
Em primeiro lugar, e essencial que os diferentes administradores comuniquem-se de maneira eciente. Um
bom modo de fazer isto e estabelecer listas de discuss ao por email que sejam internas ` a sua organizac ao. Es-
tas listas podem ser usadas para, entre outros prop ositos, comunicar alterac oes na congurac ao dos sistemas,
noticar os demais administradores a respeito de ocorr encias relevantes e servir como mecanismo de acompa-
nhamento da divis ao de tarefas.
17
A grande vantagem de usar listas de discuss ao e que elas possibilitam a comunicac ao entre os adminis-
tradores mesmo que alguns trabalhem em diferentes turnos ou locais. O hist orico das listas pode servir para
documentar decis oes tomadas e para atualizar um administrador que tenha passado algum tempo afastado de
suas atividades.
4.2.2 Controle de Alterac oes na Congurac ao
A partir do momento em que v arias pessoas cam encarregadas da administrac ao de um sistema, torna-se
necess ario dispor de meios que possibilitem a identicac ao de quem foi o respons avel por cada alterac ao na sua
congurac ao. Isso permite resolver problemas de forma mais eciente, pois a pessoa que realizou determinada
modicac ao e a mais indicada para ajudar na resoluc ao de eventuais complicac oes dela decorrentes.
Conforme mostrado na sec ao 3.3, o logbook pode auxiliar nessa tarefa. Para isso, e necess ario que em cada
entrada no logbook conste o nome da pessoa respons avel pelas modicac oes ali descritas.
Uma forma mais automatizada de fazer isso e atrav es do uso de ferramentas de controle de vers ao como
o RCS (http://www.cs.purdue.edu/homes/trinkle/RCS/) e o CVS (http://www.cvshome.org). Es-
sas ferramentas tamb em permitem manter um hist orico de arquivos de congurac ao, de forma a possibilitar a
recuperac ao de antigas vers oes desses arquivos. Recomenda-se que, sempre que possvel, este tipo de ferra-
menta seja usado em sistemas que possuam m ultiplos administradores.
4.2.3 Uso de Contas Privilegiadas
Umproblema que surge emsistemas comm ultiplos administradores e a diculdade de se manter umregistro
do uso de contas privilegiadas, tais como root e Administrator.
Sempre que possvel, estas contas n ao devem ser usadas diretamente. Um administrador deve entrar no
sistema usando sua conta pessoal e a partir dela realizar suas tarefas, usando os privil egios mais elevados
apenas quando estritamente necess ario. Em sistemas UNIX, isso e realizado atrav es do comando su. O su traz
como benefcio adicional o fato de que o seu uso normalmente ca registrado nos logs do sistema, permitindo
que se identique quem acessou a conta de root em um determinado perodo.
O sudo (http://www.courtesan.com/sudo/) e uma ferramenta que permite que o administrador do sis-
tema conceda a determinados usu arios a possibilidade de executar comandos predenidos como se eles fossem
root (ou outro usu ario), registrando nos logs do sistema a utilizac ao desses comandos. O uso do sudo reduz
a necessidade de compartilhamento da senha de root, uma vez que os usu arios entram com sua pr opria senha
para utilizar os comandos disponveis atrav es dele. Isso pode ser usado, por exemplo, quando existem contas
de operador que s ao usadas para a realizac ao de backups ou para invocar o procedimento de desligamento do
sistema.
O sudo e extremamente congur avel, possibilitando, entre outros recursos, a denic ao de grupos de usu a-
rios, de comandos e de hosts e o uso de restric oes por host ou grupo de hosts (permitindo que o mesmo arquivo
de congurac ao seja usado em sistemas diferentes).
IMPORTANTE: o uso de uma conta administrativa unica com senha compartilhada, que n ao permita
determinar qual dos administradores acessou o sistema, deve ser evitado ao m aximo.
18
4.3 Logs
Logs s ao muito importantes para a administrac ao segura de sistemas, pois registram informac oes sobre o
seu funcionamento e sobre eventos por eles detectados. Muitas vezes, os logs s ao o unico recurso que um
administrador possui para descobrir as causas de um problema ou comportamento an omalo.
4.3.1 Gerac ao de Logs
Para que os logs de um sistema sejam uteis para um administrador, eles devem estar com o hor ario sin-
cronizado via NTP, ser t ao detalhados quanto possvel, sem no entanto gerar dados em excesso. Informac oes
especialmente uteis s ao aquelas relacionadas a eventos de rede, tais como conex oes externas e registros de
utilizac ao de servicos (arquivos transferidos via FTP, acessos a p aginas Web, tentativas de login sem sucesso,
avisos de disco cheio, etc.).
Para registrar estas informac oes, e necess ario congurar o sistema da maneira apropriada. A forma de fazer
isto geralmente varia para cada componente especco; consulte a documentac ao para descobrir como habilitar
o logging de informac oes no seu sistema e em softwares especcos como rewalls e servidores HTTP.
4.3.2 Armazenamento de Logs
Armazenamento on-line
Os logs s ao tradicionalmente armazenados em disco, no pr oprio sistema onde s ao gerados. Essa e a opc ao
mais obvia, mas ela possui alguns riscos inerentes que devem ser compreendidos.
O primeiro deles diz respeito ` a possibilidade dos logs serem destrudos durante uma invas ao do sistema
(uma ocorr encia bastante comum). Em alguns sistemas, isso pode ser contornado atrav es da instalac ao de um
loghost centralizado.
Um loghost centralizado e um sistema dedicado ` a coleta e ao armazenamento de logs de outros sistemas
em uma rede, servindo como um reposit orio redundante de logs. Via de regra, o loghost n ao disponibiliza
nenhum outro servico, nem mesmo acesso remoto para os administradores, para minimizar a possibilidade de
que ele seja comprometido. Outra vantagem de loghosts centralizados e que eles facilitam a an alise dos logs e
correlac ao de eventos ocorridos em sistemas distintos. Sempre que possvel, o uso de loghosts centralizados
e fortemente recomendado.
Um segundo risco e a possibilidade de um atacante usar o logging para executar um ataque de negac ao de
servico contra um determinado sistema, gerando eventos em excesso at e que o disco onde s ao armazenados
os logs que cheio e o sistema trave em conseq u encia disto. Conforme discutido na sec ao 3.2, o uso de uma
partic ao separada para armazenar os logs pode minimizar o impacto deste problema.
Outro ponto que merece atenc ao e a rotac ao autom atica de logs. Quando este recurso e utilizado, deve-se
garantir que os logs sejam movidos para o armazenamento off-line antes que eles sejam removidos do sistema
pela rotac ao, evitando assim a perda de registros. Alguns sistemas trazem a rotac ao autom atica habilitada na
sua congurac ao padr ao; ao instalar um destes sistemas, verique se esta congurac ao e compatvel com os
seus procedimentos de backup e armazenamento off-line de logs.
Armazenamento off-line
19
Evidentemente, os logs n ao podem ser mantidos on-line por tempo indeterminado, pois acabam por consu-
mir muito espaco em disco. A melhor estrat egia para resolver esta quest ao e transferir periodicamente os logs
do disco para dispositivos de armazenamento off-line, tais como ta, CD-R ou CD-RW.

E recomend avel gerar um checksum criptogr aco (tal como MD5 ou SHA-1) dos logs que s ao armazenados
off-line. Esse checksumdeve ser mantido separado dos logs, para que possa ser usado para vericar a integridade
destes caso eles venham a ser necess arios.
Os logs armazenados off-line devem ser mantidos por um certo perodo de tempo, pois podem vir a ser ne-
cess arios para ajudar na investigac ao de incidentes de seguranca descobertos posteriormente. O Comit e Gestor
da Internet no Brasil recomenda que logs de conex oes de usu arios de provedores de acesso estejam disponveis
por pelo menos 3 anos (vide http://www.cg.org.br/acoes/desenvolvimento.htm).

E aconselh avel que
os demais logs sejam mantidos no mnimo por 6 meses.

E importante que os logs armazenados on-line sejam includos no procedimento de backup dos seus siste-
mas (backups s ao tratados na sec ao 4.8).
4.3.3 Monitoramento de Logs
Os logs possibilitam o acompanhamento do que acontece com a sua rede e com os seus sistemas. Para
tanto, e importante que eles sejam monitorados com freq u encia para permitir que eventuais problemas sejam
rapidamente identicados.
Existem algumas pr aticas recomend aveis no que diz respeito ao monitoramento de logs:
incorpore o h abito de inspecionar os logs ` a sua rotina de trabalho;
faca isso pelo menos uma vez por dia, mas tenha em mente que sistemas muito importantes ou que geram
muita informac ao podem precisar ter seus logs analisados com maior freq u encia;
procure investigar as causas de qualquer registro que lhe pareca incorreto ou an omalo, por mais insigni-
cante que ele aparente ser;
procure identicar o padr ao de comportamento normal dos seus sistemas, para poder encontrar eventuais
anomalias com maior rapidez.
Quando estiver analisando logs, voc e deve certicar-se do timezone usado para registrar o hor ario dos
eventos. Por exemplo, alguns softwares (como o Microsoft IIS, dependendo da congurac ao adotada) registram
eventos com a hora de Greenwich (GMT), e n ao com a hora local. O desconhecimento do timezone em que
est ao os logs pode facilmente invalidar uma an alise e lev a-lo a conclus oes equivocadas.
`
A medida em que voc e venha a adquirir pr atica com a an alise dos seus logs, voc e poder a escrever scripts
ou pequenos programas para auxili a-lo nesta tarefa, automatizando assim parte do processo. Estes scripts s ao
uteis, por exemplo, para pr e-processar os logs em busca de determinados conte udos e para elaborar um resumo
que pode ser enviado por email para o administrador do sistema.
Uma outra opc ao s ao ferramentas que permitem monitorar logs em tempo real, tais como o swatch (http:
//www.oit.ucsb.edu/eta/swatch). O swatch requer que voc e especique um conjunto de padr oes a serem
monitorados e as ac oes a serem tomadas quando um destes padr oes e registrado nos logs. As ac oes podem ser
de diversos tipos, como exibir a informac ao registrada, noticar um determinado usu ario por email e invocar um
programa do sistema. A capacidade de execuc ao de comandos arbitr arios do swatch torna-o muito atraente, pois
permite, por exemplo, que sejam tomadas medidas como ltragem de um endereco IP que gere determinado
log e envio de uma mensagem de alerta para um telefone celular.
20
4.4 DNS
O DNS (Domain Name System) e hoje um servico essencial para o funcionamento da Internet. Essa im-
port ancia, associada ` a natureza das informac oes que ele armazena, o tornam um dos alvos mais atraentes para
atacantes. Desse modo, uma congurac ao adequada dos servidores DNS e crucial para aumentar a seguranca e
colaborar para o bom funcionamento da rede.
Servidores DNS expostos ` a Internet est ao sujeitos a uma s erie de riscos, dentre os quais destacam-se:
Vazamento de informac oes sensveis sobre a rede da organizac ao atrav es de transfer encias de zonas DNS.
Essas informac oes podem ajudar um atacante a identicar os pontos fracos da rede e a escolher futuros
alvos.
Ataques de envenenamento de cache (cache poisoning), que levam um servidor a armazenar informac oes
forjadas. Tais informac oes podem ser usadas para comprometer a seguranca de clientes que facam con-
sultas a esse servidor.
Comprometimento do servidor atrav es de vulnerabilidades no software de DNS, o que pode facilitar
outras quebras de seguranca no restante da rede da organizac ao.
Esta sec ao apresenta os principais mecanismos usados para eliminar ou minimizar estas ameacas, trazendo
tamb em recomendac oes sobre a congurac ao de DNS reverso. Informac oes mais detalhadas podem ser obti-
das no documento Securing an Internet Name Server, do CERT/CC (disponvel em http://www.cert.org/
archive/pdf/dns.pdf) e nas refer encias do ap endice A.
4.4.1 Limitac ao de Transfer encias de Zona
Transfer encias de zona s ao usadas para que os servidores DNS escravos (secund arios) atualizem suas
informac oes sobre uma determinada zona DNS em relac ao ao servidor mestre (prim ario) para essa zona. Res-
tringir os enderecos que podem fazer transfer encias de zona e uma importante medida para evitar que atacantes
obtenham informac oes detalhadas sobre a rede da organizac ao, tais como enderecos de roteadores, servidores
de correio eletr onico e outros servidores DNS.
As limitac oes de transfer encias de zona devem ser aplicadas a todos os servidores com autoridade para um
domnio, independente de eles serem mestres ou escravos. Um equvoco comum e limitar as transfer encias de
zona no servidor mestre e n ao faz e-lo nos servidores escravos.
Preferencialmente, as transfer encias de zona devem ser limitadas atrav es da congurac ao de controles de
acesso no software servidor DNS. No BIND, por exemplo, isso e feito no named.boot (BIND 4) ou named.conf
(BIND 8 e 9). Consulte a documentac ao do seu software ou o suporte t ecnico do seu fornecedor para obter
informac oes sobre como limitar transfer encias de zona da maneira mais apropriada.
IMPORTANTE: uma concepc ao err onea, infelizmente bastante difundida, e a de que a limitac ao de trans-
fer encias de zona deve ser feita ltrando o tr afego para a porta 53/TCP do servidor DNS. Como a porta 53/TCP
tamb em e usada na resoluc ao de nomes, essa ltragem pode comprometer seriamente a funcionalidade do seu
servico de nomes.
21
4.4.2 Separac ao de Servidores
Servidores DNS possuem duas func oes principais. A primeira delas e a de disponibilizar informac oes a
respeito de zonas sobre as quais possuem autoridade (caso dos servidores mestres e escravos para uma deter-
minada zona). A segunda func ao e a de resolver nomes para clientes na sua rede (neste caso, o servidor e dito
recursivo). Muitas vezes, o mesmo servidor desempenha ambas func oes.
Uma pr atica recomend avel e separar a func ao de servidor com autoridade (mestre ou escravo) da func ao
de servidor recursivo. Isso minimiza a ec acia de ataques de envenenamento de cache DNS. Na pr atica, essa
separac ao signica que os servidores que possuem autoridade para uma ou mais zonas respondem somente a
consultas relativas a essas zonas; por sua vez, os servidores recursivos n ao possuem autoridade sobre nenhuma
zona DNS.
A forma mais simples de se fazer essa separac ao e congurar os servidores DNS com autoridade em
m aquinas distintas dos servidores DNS recursivos. Alguns softwares servidores DNS podem ser congura-
dos para permitir que essa separac ao seja feita na mesma m aquina; um exemplo e a vers ao 9 do BIND, que
implementa isso atrav es de vis oes (views).
4.4.3 Uso de Privil egios Mnimos
Os softwares servidores de DNS est ao entre os alvos mais visados pelos atacantes, e j a foram respons aveis
por comprometimentos de seguranca no passado. Dessa forma, uma medida recomend avel e minimizar os
privil egios com os quais o software servidor DNS e executado.
Em ambientes UNIX, muitas vezes e possvel executar o servidor DNS em uma jaula chroot(). Vers oes
mais recentes do BIND permitem tamb em que ele seja executado com permiss oes de um usu ario diferente de
root. Consulte a documentac ao do seu software ou o suporte t ecnico do seu fornecedor para ver se uma dessas
opc oes pode ser utilizada.
4.4.4 Cuidado com Informac oes Sensveis no DNS
O DNS oferece alguns tipos de registros de recursos que armazenam informac oes adicionais sobre os nomes
de domnio, tais como HINFO, TXT e WKS. Estes registros n ao s ao necess arios para o funcionamento correto
da resoluc ao de nomes, sendo geralmente usados para facilitar a administrac ao e a manutenc ao da rede.
Conforme e discutido em maiores detalhes na sec ao 4.10, informac oes sobre congurac ao de sistemas na
sua rede devem ser consideradas sensveis, pois podem ser usadas por um atacante para facilitar o compro-
metimento desses sistemas (ajudando-o a identicar m aquinas com sistemas que possuam vulnerabilidades
conhecidas, por exemplo). Em vista disso, o mais prudente e evitar registrar esse tipo de informac ao no DNS.
Caso voc e deseje usar estes tipos de registros para facilitar a administrac ao da rede, recomenda-se fortemen-
te que essas informac oes n ao estejam disponveis para usu arios externos ` a sua rede. Isso pode ser conseguido
usando-se servidores DNS inacessveis externamente ou, para o BIND 9, atrav es do uso adequado de vis oes.
4.4.5 DNS Reverso
O uso mais freq uente do DNS e a traduc ao de nomes em enderecos IP. Entretanto, ele tamb em permite
descobrir o nome associado a um determinado endereco IP. Isso e chamado DNS reverso, e possibilita a
identicac ao do domnio de origem de um endereco IP.
22
Um DNS reverso mal congurado ou inexistente pode causar alguns transtornos. O primeiro deles e que
muitos sites negam o acesso a usu arios com enderecos sem DNS reverso ou com o reverso incorreto.
3
Em
segundo lugar, erros na congurac ao do DNS dep oem contra a compet encia t ecnica da equipe de administrac ao
de redes respons avel pelo domnio, e isso pode vir a causar diculdades quando for necess ario interagir com
equipes de outras redes.

E recomend avel que voc e mantenha atualizado o DNS reverso dos enderecos sob sua responsabilidade. Em
alguns casos a administrac ao do DNS reverso dos seus blocos pode ser delegada ` a sua rede, enquanto em outros
o seu provedor de backbone e quem e respons avel pelo DNS reverso dos seus enderecos. Entre em contato com
o seu provedor de backbone para obter informac oes sobre como atualizar o seu DNS reverso.
4.5 Informac oes de Contato
Existem na Internet alguns enderecos eletr onicos (emails) que s ao usados para entrar em contato com
administradores quando se deseja comunicar determinadas ocorr encias relacionadas ` a seguranca de suas redes
e sistemas.

E extremamente importante que estas informac oes sejam v alidas e estejam sempre atualizadas,
pois assim garante-se que estas comunicac oes ser ao recebidas pela pessoa certa no menor espaco de tempo
possvel, o que pode muitas vezes impedir um incidente de seguranca ou limitar as conseq u encias. Esta sec ao
mostra quais s ao essas informac oes e como voc e deve proceder para atualiz a-las.
4.5.1 Enderecos Eletr onicos Padr ao
A RFC 2142
4
dene uma s erie de emails padr ao que devem existir em todas as redes e que podem ser
usados para contatar os seus respons aveis. Dentre os enderecos padr ao, existem dois que est ao relacionados
com seguranca: abuse e security.
O endereco abuse e usado para reportar abusos de recursos na rede. O endereco security, por sua vez, e
utilizado para comunicar incidentes e alertar sobre problemas de seguranca.
Mensagens enviadas para estes enderecos dever ao chegar at e os respons aveis por lidar com essas ocorr en-
cias. N ao e necess ario criar usu arios com estes nomes, basta que sejam congurados aliases redirecionando as
mensagens enviadas a estes enderecos para os usu arios apropriados.
Cabe observar que muitas vezes estes enderecos n ao s ao usados da maneira mais apropriada, com abuse
recebendo reclamac oes de incidentes de seguranca e security relatos de abusos, ou ambos os enderecos sendo
usados na mesma noticac ao. Sendo assim, e importante que sua rede possua ambos os enderecos e que eles
sejam constantemente monitorados pela sua equipe de seguranca.
4.5.2 Contato no DNS
Cada domnio registrado em um servidor DNS possui uma s erie de par ametros de congurac ao no registro
de SOA (Start of Authority). Um destes par ametros e o email do respons avel pelo domnio, que muitas vezes
tamb em e usado para comunicar problemas de seguranca envolvendo esse domnio.
3
O caso mais comum de incorrec ao e quando existe um nome para resolver um dado IP mas este mesmo nome n ao est a registrado
em nenhum DNS direto, ou ent ao resolve para outro endereco IP. Um exemplo disso seria o endereco IP 192.0.2.34 resolver para
foo.example.org mas este nome resolver para o IP 192.0.2.76.
4
D. Crocker, Mailbox Names for Common Services, Roles and Functions, RFC 2142, Internet Mail Consortium, May 1997.
Disponvel em ftp://ftp.isi.edu/in-notes/rfc2142.txt.
23
Um exemplo de registro SOA para o domnio example.org pode ser visto na gura 2. Nesta gura, ns.
example.org e o nome do servidor DNS prim ario e joe.example.org representa o endereco joe@example.
org, que seria o endereco de contato para o domnio example.org.
example.org. IN SOA ns.example.org. joe.example.org. (
2002030101 ; serial (yyyymmddnn)
10800 ; refresh (3h)
3600 ; retry (1h)
6084800 ; expire (1 semana)
86400 ) ; TTL (1 dia)
Figura 2: Exemplo de registro SOA
Mantenha esse endereco do campo de SOA atualizado em todos os domnios sob sua responsabilidade,
incluindo os de DNS reverso. Se preferir, use um alias em vez de um email real. N ao se esqueca que o formato
e usu ario.domnio, e n ao usu ario@domnio.
4.5.3 Contatos no WHOIS
Cada domnio ou bloco de enderecos IP registrado possui uma lista de informac oes de contato que remetem
` as pessoas respons aveis por estes domnios ou blocos. Geralmente existem tr es tipos de contatos:
contato t ecnico: respons avel t ecnico pela administrac ao e operac ao do domnio ou bloco;
contato administrativo: quem tem autoridade sobre o domnio ou bloco;
contato de cobranca: quem recebe correspond encias de cobranca das despesas de registro e manutenc ao
do domnio ou bloco.
Os enderecos de email destes contatos devemestar sempre atualizados e ser v alidos. No caso do contato t ecnico,
isso signica dizer que mensagens enviadas para este endereco devem ser recebidas por um administrador de
redes respons avel pelo bloco ou domnio, e n ao por pessoal administrativo ou jurdico da organizac ao. Este
contato e usado com muita freq u encia para noticac ao de incidentes de seguranca e outros problemas com a
infra-estrutura de rede envolvendo o domnio ou bloco.
Estas informac oes de contato s ao mantidas em uma base de dados chamada WHOIS. Esta base de dados e
normalmente gerenciada por entidades que registram domnios (informac oes sobre domnios) e por provedores
de backbone (informac oes sobre enderecos IP). No Brasil, estas informac oes s ao administradas e disponibili-
zadas pelo Registro .br (http://registro.br).
O procedimento de atualizac ao dos contatos no WHOIS varia de acordo com a entidade de registro ou pro-
vedor de backbone. Entre em contato com a sua entidade de registro ou o seu provedor para obter informac oes
detalhadas sobre como efetuar essa atualizac ao. Para domnios registrados no Brasil, informac oes sobre como
atualizar os contatos est ao disponveis em http://registro.br/faq/faq2.html.
24
4.6 Eliminac ao de Protocolos sem Criptograa
Uma medida de seguranca muito importante na operac ao de redes e a substituic ao de protocolos onde
n ao haja autenticac ao atrav es de senhas, ou onde senhas trafeguem em claro, por outros que corrijam estas
deci encias. A lista de protocolos cuja utilizac ao deve ser evitada na medida do possvel inclui:
Telnet;
FTP;
POP3;
IMAP;
rlogin;
rsh;
rexec.
A maioria dos protocolos citados pode ser substituda pelo SSH.
5
Essa substituic ao, al em de fazer com
que o tr afego entre cliente e servidor passe a ser criptografado, traz ainda outras vantagens, como protec ao da
sess ao contra ataques tipo man-in-the-middle e seq uestro de conex oes TCP.
Em relac ao ao POP3, existem diversas possibilidades de substituic ao:
1. Usar uma das variantes do protocolo (APOP, KPOP, RPOP) que tornam a autenticac ao de usu arios mais
segura, pois eliminam o tr afego de senhas em claro. As desvantagens desta opc ao s ao que nem todos
os clientes de email suportam estas variantes e o conte udo dos emails (que pode conter informac oes
sensveis) n ao e criptografado.
2. Usar POP3 atrav es de um t unel SSH ou SSL. A primeira opc ao e interessante quando o servidor POP3
e o servidor SSH residem na mesma m aquina. Para a segunda, podem ser usadas ferramentas como
o stunnel (http://stunnel.mirt.net). Alguns clientes de email j a suportam SSL diretamente, n ao
sendo necess ario o uso de t uneis.
3. Usar uma soluc ao de Webmail sobre HTTPS (HTTP+SSL). Esta soluc ao tamb em e v alida para o IMAP.
4.7 Cuidados com Redes Reservadas
Existem alguns blocos de enderecos IP que s ao reservados pelo IANA (Internet Assigned Numbers Au-
thority) para prop ositos especcos. N ao existe um documento unico que registre todos estes blocos; alguns
est ao documentados em RFCs, enquanto que outros s ao considerados reservados por raz oes de compatibilida-
de hist orica. A lista atual de redes reservadas conhecidas e mostrada na tabela 1, juntamente com um breve
coment ario sobre a nalidade cada rede.
Enderecos pertencentes a estes blocos n ao devem ser propagados atrav es da Internet, devendo ser ltrados
no permetro da sua rede, tanto para entrada quanto para sada.
5
Implementac oes de SSH para diversos sistemas operacionais est ao disponveis em http://www.openssh.com.
25
Rede Coment ario
0.0.0.0/8 usada por sistemas antigos para broadcast
127.0.0.0/8 loopback
192.0.2.0/24 TEST-NET; usada para exemplos em documentac ao
10.0.0.0/8 usada em redes privadas (RFC 1918)
172.16.0.0/12 usada em redes privadas (RFC 1918)
192.168.0.0/16 usada em redes privadas (RFC 1918)
169.254.0.0/16 usada para autocongurac ao (est a relacionada ao protocolo DHCP)
192.88.99.0/24 usada para 6to4 Relay Anycast (RFC 3068)
198.18.0.0/15 usada para testes de desempenho de equipamentos de rede (RFC 2544)
224.0.0.0/4 classe D
240.0.0.0/5 classe E
Tabela 1: Lista de redes reservadas pelo IANA
Caso voc e possua redes privadas com IPs reservados, certique-se de que os enderecos utilizados sejam os
especicados na RFC 1918
6
(10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16).
Enderecos reservados n ao devem estar associados a nomes em servidores DNS p ublicos. Se voc e utiliz a-los
em redes privadas e quiser usar nomes para as m aquinas, congure um servidor DNS privado ou utilize tabelas
de hosts (/etc/hosts ou C:\WINDOWS\HOSTS).
Caso voc e detecte um ataque proveniente de uma das redes da tabela 1 e estes enderecos estiverem sendo
ltrados no permetro, os pacotes correspondentes s o podem ter partido de dentro da sua pr opria rede. A causa
mais freq uente para isso e a exist encia de erros de congurac ao que fazem com que os enderecos reservados
vazem de uma ou mais de suas redes privadas. Logo, deve-se procurar internamente a cusa do problema em
vez de tentar contactar o IANA (que e a entidade listada nos contatos de WHOIS para estes blocos).
4.8 Polticas de Backup e Restaurac ao de Sistemas
A import ancia dos backups na administrac ao de sistemas nunca pode ser minimizada. Sem eles, muitos
dados s ao simplesmente irrecuper aveis caso sejam perdidos devido a uma falha acidental ou a uma invas ao.
Os backups devem fazer parte da rotina de operac ao dos seus sistemas e seguir uma poltica determinada.
O melhor e faz e-los da forma mais automatizada possvel, de modo a reduzir o seu impacto sobre o trabalho
dos administradores e operadores de sistemas.
A lista de itens cujo backup deve ser feito com freq u encia inclui:
dados;
arquivos de congurac ao;
logs.
Um ponto que merece especial cuidado e o backup de bin arios (execut aveis e bibliotecas), que geralmente
deve ser evitado. Uma excec ao a essa regra e uma c opia completa do sistema logo ap os a sua instalac ao,
6
Y. Rekhter et.al., Address Allocation for Private Internets, RFC 1918, February 1996. Disponvel em ftp://ftp.isi.edu/
in-notes/rfc1918.txt.
26
antes que ele seja colocado em rede. Backups que incluem bin arios n ao s ao aconselh aveis porque abrem a
possibilidade de que eventuais Cavalos de Tr oia ou execut aveis corrompidos sejam reinstalados na restaurac ao
do sistema.
Alguns cuidados devem ser tomados em relac ao ao local onde s ao guardados os backups:
o acesso ao local deve ser restrito, para evitar que pessoas n ao autorizadas roubem ou destruam backups;
o local deve ser protegido contra agentes nocivos naturais (poeira, calor, umidade);
se possvel, e aconselh avel que o local seja tamb em ` a prova de fogo.
Os backups devem ser vericados logo ap os a sua gerac ao e, posteriormente, a intervalos regulares. Isto
possibilita a descoberta de defeitos em dispositivos e meios de armazenamento e pode evitar que dados sejam
perdidos por problemas com backups que n ao podem ser restaurados.
Algumas organizac oes providenciam meios para armazenar backups fora das suas instalac oes, como em
cofres de bancos, por exemplo. Essa e uma boa maneira de garantir a disponibilidade dos backups em caso de
problemas nas instalac oes. Entretanto, isso pode comprometer a condencialidade e integridade desses back-
ups. Uma possvel soluc ao e criptografar o backup e gerar um checksum (MD5 ou SHA-1, por exemplo) dele
antes que seja entregue a pessoas de fora da organizac ao. Uma vericac ao do checksum antes da restaurac ao
pode servir como prova de que o backup n ao foi alterado desde que foi feito.
Quando for necess ario restaurar um sistema, isto deve ser feito com a m aquina isolada da rede. Caso o
sistema em quest ao tenha sido comprometido, revise a sua congurac ao ap os a restaurac ao para certicar-se de
que n ao tenha cado nenhuma porta de entrada previamente instalada pelo invasor.
4.9 Como Manter-se Informado
Administradores envolvidos com a seguranca de redes e sistemas necessitam buscar informac oes de forma
a se manterem atualizados em relac ao a novas vulnerabilidades e correc oes de seguranca. Devido ` a sua natureza
din amica, o principal meio de obtenc ao de tais informac oes e a pr opria Internet, atrav es de listas de discuss ao
por email e sites especializados.
Os tipos mais indicados de listas de discuss ao para um administrador incluem:
lista de an uncios de seguranca de fornecedores de software e hardware cujos produtos s ao usados na sua
rede;
listas de administradores e/ou usu arios desses produtos;
lista de alertas de seguranca do CERT/CC.
7
Destas, as listas de an uncios de seguranca de fornecedores e a lista de alertas do CERT/CC s ao fortemente
recomendadas a qualquer administrador. As listas destinadas a administradores e usu arios de produtos, por
sua vez, podem ajud a-lo a conhecer melhor as ferramentas disponveis no seu ambiente computacional, muitas
vezes levando-o a descobrir formas mais ecientes de trabalhar com elas.
8
7
Veja http://www.cert.org/contact_cert/certmaillist.html.
8
A sec ao 4.10 mostra alguns cuidados que devem ser tomados por quem utiliza listas de discuss ao por email.
27
Existem outras listas que s ao indicadas para administradores que possuam alguma experi encia e bons co-
nhecimentos de programac ao. Essas listas costumam ter um alto tr afego e o conte udo das suas discuss oes
e bastante t ecnico, muitas vezes envolvendo o uso de conceitos avancados. A principal (e tamb em a mais
conhecida) destas listas e a Bugtraq.
9
A Web tamb em oferece boas fontes de informac oes atualizadas na area de seguranca, tais como:
http://www.cert.org/advisories/;
http://www.cert.org/current/current_activity.html;
http://online.securityfocus.com/;
http://www.incidents.org/.
IMPORTANTE: e recomend avel que voc e tome cuidado com a proced encia de informac oes relacionadas
com seguranca, procurando se restringir a fontes con aveis. Existem diversos relatos de informac oes proposi-
talmente erradas terem sido divulgadas com o objetivo de abrir brechas na seguranca da rede daqueles que as
tenham seguido.
4.10 Precauc oes contra Engenharia Social
Engenharia social e a t ecnica (ou arte) de aproveitar-se da boa f e de pessoas para obter informac oes que
possibilitem ou facilitem o acesso aos recursos computacionais de uma organizac ao por parte de usu arios n ao
autorizados. Dentre as informac oes procuradas destacam-se as seguintes:
senhas de acesso;
topologia da rede;
enderecos IP em uso;
nomes de hosts em uso;
listas de usu arios;
tipos e vers oes de sistemas operacionais usados;
tipos e vers oes de servicos de rede usados;
dados sigilosos sobre produtos e processos da organizac ao.
Existem diversas formas de se efetuar um ataque de engenharia social, mas todas elas t em em comum a
caracterstica de usarem basicamente psicologia e perspic acia para atingir os seus prop ositos. Atualmente, as
mais populares s ao:
usar telefone ou email para se fazer passar por uma pessoa (geralmente algu em da equipe de suporte
t ecnico ou um superior da pessoa atacada) que precisa de determinadas informac oes para resolver um
suposto problema;
9
Veja http://online.securityfocus.com/.
28
aproveitar informac oes divulgadas em um f orum p ublico da Internet (lista de discuss ao por email, news-
group, IRC) por um administrador ou usu ario que busca ajuda para resolver algum problema na rede;
enviar programas maliciosos ou instruc oes especialmente preparadas para um administrador ou usu ario,
com o objetivo de abrir brechas na seguranca da rede ou coletar o m aximo de informac oes possvel sobre
ela (esta t ecnica e particularmente ecaz quando a pessoa pede auxlio em algum f orum de discuss ao
pela Internet);
navegar por websites ou reposit orios FTP em busca de informac oes uteismuitas vezes e possvel en-
contrar descric oes detalhadas da infra-estrutura computacional e/ou documentos que, por descuido ou
esquecimento, n ao foram removidos do servidor.
A principal maneira de se prevenir contra estes ataques e orientando os usu arios e administradores de redes
e sistemas sobre como agir nestas situac oes. A poltica de seguranca da organizac ao (sec ao 2.1) desempenha
um papel importante neste sentido, pois e nela que s ao denidas as normas para protec ao da informac ao na
organizac ao.
Recomenda-se fortemente que os administradores tenham cuidado ao buscar ajuda em listas de discuss ao e
outros f oruns na Internet. Estes recursos podem ser valiosos na resoluc ao de problemas, mas tamb em podem
ser usados por terceiros para coleta de informac oes.
Procure reduzir a exposic ao da sua rede em f oruns p ublicospor exemplo, use enderecos IP, nomes de
hosts e usu arios hipot eticos, e tente n ao revelar mais sobre a topologia da rede do que o estritamente necess ario
para resolver um dado problema. Tome cuidado com orientac oes passadas por pessoas desconhecidas, e evite
executar programas de origem obscura ou n ao con aveleles podem ser uma armadilha.
4.11 Uso Ecaz de Firewalls
Antes de apresentar t ecnicas para aumentar a ec acia de rewalls, e importante denir o que um rewall
e e o que ele n ao e. Um rewall bem congurado e um instrumento importante para implantar a poltica
de seguranca da sua rede. Ele pode reduzir a informac ao disponvel externamente sobre a sua rede, ou, em
alguns casos, at e mesmo barrar ataques a vulnerabilidades ainda n ao divulgadas publicamente (e para as quais
correc oes n ao est ao disponveis).
Por outro lado, rewalls n ao s ao infalveis. A simples instalac ao de um rewall n ao garante que sua
rede esteja segura contra invasores. Um rewall n ao pode ser a sua unica linha de defesa; ele e mais um
dentre os diversos mecanismos e procedimentos que aumentam a seguranca de uma rede.
Outra limitac ao dos rewalls e que eles protegem apenas contra ataques externos ao rewall, nada podendo
fazer contra ataques que partem de dentro da rede por ele protegida.
Esta sec ao apresenta apenas alguns aspectos importantes da utilizac ao de rewalls. Maiores informac oes
podem ser obtidas em http://www.interhack.net/pubs/fwfaq/ e nas refer encias do ap endice A.
4.11.1 A Escolha de um Firewall
Existemdiversas soluc oes de rewall disponveis no mercado. Aescolha de uma delas est a atrelada a fatores
como custo, recursos desejados e exibilidade, mas um ponto essencial e a familiaridade com a plataforma
operacional do rewall. A maioria dos rewalls est a disponvel para um conjunto reduzido de plataformas
29
operacionais, e a sua escolha deve se restringir a um dos produtos que roda sobre uma plataforma com a qual
os administradores da rede tenham experi encia. Por exemplo, se voc e utiliza basicamente servidores UNIX, e
aconselh avel que voc e escolha um rewall que rode sobre a sua variante favorita de UNIX, e n ao um produto
que requeira Windows NT.
Existem, basicamente, duas raz oes para esta recomendac ao. A primeira delas e que voc e deve estar fa-
miliarizado o suciente com o sistema onde o rewall ser a executado para congur a-lo de forma segura. A
exist encia de um rewall instalado em um sistema inseguro pode ser at e mais perigosa do que a aus encia do
rewall na rede. A segunda raz ao e que os produtos tendem a seguir a losoa da plataforma onde rodam; por
exemplo, a maioria dos rewalls para Windows e congurada atrav es de menus e janelas, ao passo que muitos
rewalls para UNIX s ao congurados por meio de arquivos texto.
Administradores experientes em UNIX t em ` a disposic ao diversas ferramentas de software livre que podem
ser usadas para implementar rewalls, conforme mostra a tabela 2. Estas ferramentas permitem construir
rewalls ecientes a um custo relativamente baixo, uma vez que seus requisitos de hardware s ao modestos.
Ferramenta Plataforma Caracterstica
ipchains Linux ltro de pacotes (stateless)
iptables Linux ltro de pacotes (stateful)
ipfw FreeBSD ltro de pacotes (stateful)
pf OpenBSD ltro de pacotes (stateful)
iplter v arios UNIX ltro de pacotes (stateful)
TIS Firewall Toolkit v arios UNIX proxy para v arios protocolos
Squid v arios UNIX proxy Web/FTP
Tabela 2: Ferramentas de software livre para a construc ao de rewalls
4.11.2 Localizac ao dos Firewalls
A localizac ao dos rewalls na rede depende normalmente da sua poltica de seguranca. Entretanto, existem
algumas regras que se aplicam ` a grande maioria dos casos:
Todo o tr afego deve passar pelo rewall. Um rewall s o pode atuar sobre o tr afego que passa por ele.
A ec acia de um rewall pode ser severamente comprometida se existirem rotas alternativas para dentro
da rede (modens, por exemplo). Caso n ao seja possvel eliminar todas esses caminhos, eles devem ser
documentados e fortemente vigiados atrav es de outros mecanismos de seguranca.
Tenha um ltro de pacotes no permetro da sua rede. Esse ltro pode estar localizado entre o seu
roteador de borda e o interior da rede ou no pr oprio roteador, se ele tiver esta capacidade e voc e se sentir
confort avel utilizando-o para esta tarefa. O ltro de pacotes de borda e importante para tarefas como
bloqueio global de alguns tipos de tr afego (vide sec ao 4.11.3) e bloqueio r apido de servicos durante a
implantac ao de correc oes ap os a descoberta de uma nova vulnerabilidade.
Coloque os servidores externos em uma DMZ.

E recomend avel que voc e coloque os seus servidores
acessveis externamente (Web, FTP, correio eletr onico, etc.) em um segmento de rede separado e com
acesso altamente restrito, conhecido como DMZ (DeMilitarized Zone, ou zona desmilitarizada). A prin-
cipal import ancia disso e proteger a rede interna contra ataques provenientes dos servidores externos
uma precauc ao contra a eventualidade de que um destes servidores seja comprometido. Por exemplo,
30
suponha que um atacante invada o servidor Web e instale um sniffer na rede. Se este servidor Web es-
tiver na rede interna, a probabilidade dele conseguir capturar dados importantes (tais como senhas ou
informac oes condenciais) e muito maior do que se ele estiver em uma rede isolada.
Considere o uso de rewalls internos. Em alguns casos, e possvel identicar na rede interna grupos
de sistemas que desempenham determinadas tarefas comuns, tais como desenvolvimento de software,
webdesign e administrac ao nanceira. Nestes casos, recomenda-se o uso de rewalls internos para isolar
estas sub-redes umas das outras, com o prop osito de aumentar a protec ao dos sistemas internos e conter
a propagac ao de ataques bem-sucedidos.
4.11.3 Crit erios de Filtragem
Existem basicamente dois crit erios de ltragem que podem ser empregados em rewalls. O primeiro e o
de default deny, ou seja, todo o tr afego que n ao for explicitamente permitido e bloqueado. O segundo, default
allow, e o contr ario, ou seja, todo o tr afego que n ao for explicitamente proibido e liberado.
A congurac ao dos rewalls deve seguir a poltica de seguranca da rede. Se a poltica permitir, e reco-
mend avel adotar uma postura de default deny. Esta abordagem e, geralmente, mais segura, pois requer uma
intervenc ao explcita do administrador para liberar o tr afego desejado, o que minimiza o impacto de eventuais
erros de congurac ao na seguranca da rede. Al em disso, ela tende a simplicar a congurac ao dos rewalls.
No permetro da rede, pelo menos as seguintes categorias de tr afego devem ser ltradas:
tr afego de entrada (ingress ltering): pacotes com endereco de origem pertencente a uma rede reservada
(sec ao 4.7) ou a um dos blocos de enderecos da sua rede interna;
tr afego de sada (egress ltering): pacotes com endereco de origem pertencente a uma rede reservada ou
que n ao faca parte de um dos blocos de enderecos da rede interna.
Um aspecto que deve ser considerado com cuidado e a ltragem do protocolo ICMP. O bloqueio indiscri-
minado de ICMP pode prejudicar o funcionamento da rede. Por outro lado, o ICMP pode ser usado para revelar
a um possvel atacante informac oes sobre a rede e seus sistemas. Observe que muitos rewalls do tipo state-
ful permitem a passagem de mensagens ICMP de erro associadas a conex oes estabelecidas, o que minimiza o
impacto da ltragem.
O tr afego para a DMZ deve ser altamente controlado. As unicas conex oes permitidas para os sistemas
dentro da DMZ devem ser as relativas aos servicos p ublicos (acessveis externamente). Conex oes partindo
da DMZ para a rede interna devem ser, na sua maioria, tratadas como conex oes oriundas da rede externa,
aplicando-se a poltica de ltragem correspondente.
IMPORTANTE: a DMZ e a rede interna n ao podem estar no mesmo segmento de rede (ligadas ao mesmo
hub ou switch, por exemplo).

E imprescindvel que estas redes estejam em segmentos de rede separados.
4.11.4 Exemplos
Diversas arquiteturas podem ser empregadas para a implantac ao de rewalls em uma rede. A opc ao por uma
delas obedece a uma s erie de fatores, incluindo a estrutura l ogica da rede a ser protegida, custo, funcionalidades
pretendidas e requisitos tecnol ogicos dos rewalls.
31
Esta sec ao apresenta duas destas arquiteturas. A intenc ao n ao e cobrir todas as possibilidades de uso de
rewalls, mas fornecer exemplos de arquiteturas que funcionam e que podem eventualmente ser adotados (na
sua forma original ou ap os passarem por adaptac oes) em situac oes reais.
A gura 3 mostra um exemplo simples de uso de rewall. Neste exemplo, o rewall possui tr es interfaces de
rede: uma para a rede externa, uma para a rede interna e outra para a DMZ. Por default, este rewall bloqueia
tudo o que n ao for explicitamente permitido (default deny). Al em disso, o rewall usado e do tipo stateful,
que gera dinamicamente regras que permitam a entrada de respostas das conex oes iniciadas na rede interna;
portanto, n ao e preciso incluir na congurac ao do rewall regras de entrada para estas respostas.
O tr afego liberado no exemplo da gura 3 e o seguinte:
DNS
DMZ
Rede Interna
FW
SMTP
Internet
WWW
Figura 3: Um exemplo simples de rewall
interface externa:
sada: tudo com excec ao de
pacotes com enderecos de origem pertencentes a redes reservadas;
pacotes com enderecos de origem n ao pertencentes aos blocos da rede interna.
entrada: apenas os pacotes que obedecem ` as seguintes combinac oes de protocolo, endereco e porta
de destino:
25/TCP para o servidor SMTP;
53/TCP e 53/UDP para o servidor DNS;
80/TCP para o servidor WWW.
interface interna:
sada: tudo;
entrada: nada;
interface da DMZ:
32
sada: portas 25/TCP (SMTP), 53/UDP e 53/TCP (DNS) e 113 (IDENT);
entrada: al em das mesmas regras de entrada da interface externa, tamb em e permitido o tr afego para
todos os servidores na com porta de destino 22/TCP (SSH) e endereco de origem na rede interna.
A gura 4 ilustra o uso de rewalls em uma situac ao mais complexa do que a anterior. Neste segundo
exemplo, al em dos servidores externos na DMZ, h a tamb em servidores na intranet e no setor nanceiro da
organizac ao. Devido ` a import ancia das informac oes mantidas neste setor, a sua rede conta com a protec ao
adicional de um rewall interno, cujo objetivo principal e evitar que usu arios com acesso ` a rede interna da
organizac ao (mas n ao ` a rede do setor nanceiro) possam comprometer a integridade e/ou o sigilo dessas
informac oes.
WWW
Rede Interna
FW
FW
SMTP
DMZ
Setor Financeiro
SMTP
DNS
WWW
Intranet
DNS
Internet
Figura 4: Um exemplo mais complexo de rewall
A congurac ao do rewall externo neste segundo exemplo e quase id entica ao primeiro. Entretanto, no
presente caso sup oe-se que o servidor SMTP visvel externamente (o da DMZ) repassa as mensagens recebidas
para o servidor SMTP da intranet. Para que isso seja possvel, e necess ario mudar a regra de ltragem para a
interface interna, liberando o tr afego do servidor SMTP da DMZ para a porta 25/TCP do servidor SMTP da
intranet.
A congurac ao do rewall interno, por sua vez, e bastante simples. O servidor da rede do setor nanceiro
permite apenas acesso via HTTPS para que os funcion arios da organizac ao possam consultar seus contrache-
ques; outros tipos de acesso n ao s ao permitidos. O tr afego liberado por este rewall e o seguinte:
interface externa (rede interna):
33
sada: tudo;
entrada: apenas pacotes para o servidor do setor nanceiro com porta de destino 443/TCP (HTTPS)
e endereco de origem na rede interna;
interface interna (rede do setor nanceiro):
sada: tudo;
entrada: tudo (a ltragem e feita na interface externa).
34
A Refer encias Adicionais
A.1 URLs de Interesse
CERT Security Improvement Modules: Security Knowledge in Practice. http://www.cert.org/
security-improvement/skip.html.
Apresenta, de forma gr aca, os passos que est ao envolvidos na obtenc ao de uma rede mais
segura. Cont em uma grande quantidade de material que aborda de forma mais aprofundada
v arios dos assuntos discutidos neste documento.
Security Links. http://www.nbso.nic.br/links/.
Uma compilac ao de URLs sobre diversos aspectos de administrac ao e seguranca de redes e
sistemas, incluindo diversos apresentados neste documento, e que e atualizada periodicamen-
te.
Pr aticas de Seguranca para Administradores de Redes Internet. http://www.nbso.nic.br/docs/
seg-adm-redes.html.
P agina a partir da qual pode ser obtida a vers ao mais recente deste documento e do checklist
que o acompanha. Cont em tamb em um hist orico de revis oes dos documentos.
A.2 Livros
Nelson Murilo de O. Runo. Seguranca Nacional. Novatec, 2001.
Uma boa refer encia sobre seguranca computacional em portugu es, com enfoque em aspectos
pr aticos.
W. Richard Stevens. TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley, 1994.
A melhor obra disponvel sobre TCP/IP. O texto e claro e did atico, e numerosos exemplos
(usando tcpdump) ajudam a compreender o funcionamento dos protocolos na pr atica.
Simson Garnkel e Gene Spafford. Practical UNIX and Internet Security, 2nd Edition. OReilly &
Associates, 1996.
Apesar de um pouco desatualizado em alguns aspectos, este livro e considerado refer encia
obrigat oria em seguranca de sistemas UNIX.
Paul Albitz e Cricket Liu. DNS and BIND, 4th Edition. OReilly & Associates, 2001.
Este livro possui bastante informac ao sobre o protocolo DNS e a sua principal implementac ao,
o BIND. A quarta edic ao cont em um captulo sobre seguranca de servidores DNS.
Elizabeth D. Zwicky, Simon Cooper e D. Brent Chapman. Building Internet Firewalls, 2nd Edition.
OReilly & Associates, 2000.
Um dos melhores livros disponveis sobre rewalls, recheado com informac oes pr aticas sobre
como constru-los.
35
Evi Nemeth, Garth Snyder, Scott Seebass e Trent R. Hein. UNIX System Administration Handbook, 3rd
Edition. Prentice Hall, 2001.
O cl assico sobre administrac ao de sistemas UNIX, recentemente atualizado. Traz explicac oes
claras e objetivas sobre como realizar, de forma eciente, as diferentes tarefas que competem
a um administrador de sistemas UNIX.
Charles B. Rutstein. Windows NT Security: A Practical Guide to Securing Windows NT Servers &
Workstations. McGraw-Hill, 1997.
Um bom livro sobre seguranca de Windows NT, incluindo instalac ao, congurac ao, uso do
Registry, logging, entre outros assuntos.
Roberta Bragg. Windows 2000 Security. New Riders Publishing, 2000.
Este livro discute seguranca no Windows 2000, dando maior enfase aos aspectos pr aticos. Os
temas abordados incluem IPsec, Kerberos, Active Directory, RAS e RRAS.
Scott Barman. Writing Information Security Policies. New Riders Publishing, 2001.
Este livro explica como escrever e implementar uma poltica de seguranca. Cont em v arios
exemplos extrados de polticas reais, que podem ser usados como guia para a formulac ao de
novas polticas.
S erie OReilly sobre administrac ao de servicos de rede e sistemas operacionais especcos. http://
www.oreilly.com.
A editora OReilly e conhecida pela qualidade t ecnica dos seus livros, que geralmente abor-
dam um assunto especco com bastante profundidade e com um enfoque bem pr atico. Exis-
tem guias para servidores como Apache (Web) e Sendmail (SMTP), al em de diversos ttulos
sobre uso e administrac ao de sistemas operacionais (incluindo UNIX, Linux e Windows).
36

Indice Remissivo
A
abuso de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
conseq u encias. . . . . . . . . . . . . . . . . . . . . . . . . . . 15
implicac oes legais . . . . . . . . . . . . . . . . . . . . . . . 15
administradores
equipe . . . . . . . veja equipes de administradores
Administrator . . . . . . . . . . . veja contas privilegiadas
an alise de riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
AUP . . . . . . . . . . . . . . . veja poltica de uso aceit avel
B
backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2627
armazenamento . . . . . . . . . . . . . . . . . . . . . . . . . 27
bin arios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
checksum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
itens importantes . . . . . . . . . . . . . . . . . . . . . . . . 26
logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
off-site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
partic oes individuais . . . . . . . . . . . . . . . . . . . . . 10
polticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
restaurac ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
vericac ao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . veja DNS
C
Charles B. Rutstein . . . . . . . . . . . . . . . . . . . . . . . . . . 36
congurac ao
controle de alterac oes . . . . . . . . . . . . . . . . . . . . 18
DNS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2123
documentac ao. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
proxy Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
revis ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
servidores SMTP . . . . . . . . . . . . . . . . . . . . 16, 23
conta Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . 18
conta root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
contas privilegiadas . . . . . . . . . . . . . . . . . . . . . . . . . . 18
contatos . . . . . . . . . . . . . veja informac oes de contato
correc oes de seguranca . . . . . . . . . . . . . . . . . . . . . . . 15
periodicidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
precauc oes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
reposit orio local . . . . . . . . . . . . . . . . . . . . . . . . . 15
Cricket Liu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
D
D. Brent Chapman. . . . . . . . . . . . . . . . . . . . . . . . . . . 35
di ario de bordo . . . . . . . . . . . . . . . . . . . . veja logbook
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2123
cache poisoning . . . . . . . . . . . . . . . . . . . . . . . . . 22
contato no SOA . . . . . . . . . . . . . . . . . . . . . . . . . 23
exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
envenenamento de cache . . . . . . . . . . . . . . . . . 22
ltragem de tr afego. . . . . . . . . . . . . . . . . . . . . . 21
HINFO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
informac oes sensveis . . . . . . . . . . . . . . . . . . . . 22
jaula chroot() . . . . . . . . . . . . . . . . . . . . . . . . . 22
problemas de congurac ao . . . . . . . . . . . . . . . 22
reverso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
atualizac ao . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
servidor com autoridade. . . . . . . . . . . . . . . . . . 22
servidor com privil egios mnimos . . . . . . . . . 22
servidor privado . . . . . . . . . . . . . . . . . . . . . . . . . 26
servidor recursivo . . . . . . . . . . . . . . . . . . . . . . . 22
transfer encia de zona . . . . . . . . . . . . . . . . . . . . 21
TXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
WKS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
E
Elizabeth D. Zwicky . . . . . . . . . . . . . . . . . . . . . . . . . 35
enderecos reservados . . . . . . . veja redes reservadas
endereco reverso . . . . . . . . . . . . . . . . . . . . . . veja DNS
enderecos eletr onicos padr ao . veja informac oes de
contato
engenharia social . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
formas de ataque . . . . . . . . . . . . . . . . . . . . . . . . 28
prevenc ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
equipes de administradores . . . . . . . . . . . . . . . . . . . 17
comunicac ao. . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
contas privilegiadas . . . . . . . . . . . . . . . . . . . . . . 18
listas de discuss ao . . . . . . . . . . . . . . . . . . . . . . . 17
vantagens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Evi Nemeth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
F
ferramentas
BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . veja DNS
CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
rewalls de software livre . . . . . . . . . . . . . . . . 30
OpenSSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
RCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
stunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
37
sudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
swatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
rewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2934
crit erios de escolha . . . . . . . . . . . . . . . . . . . . . . 29
crit erios de ltragem. . . . . . . . . . . . . . . . . . . . . 31
default allow. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
default deny . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30, 31
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
egress ltering . . . . . . . . . . . . . . . . . . . . . . . . . . 31
exemplos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3134
ferramentas de software livre . . . . . . . . . . . . . 30
ltragem de permetro . . . . . . . . . . . . . . . . . . . 30
ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
ingress ltering . . . . . . . . . . . . . . . . . . . . . . . . . 31
internos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31, 33
limitac oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
localizac ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
servicos n ao utilizados . . . . . . . . . . . . . . . . . . . 14
zona desmilitarizada . . . . . . . . . . . . . . . . . . . . . 30
xes . . . . . . . . . . . . . . . . . veja correc oes de seguranca
FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
fuso hor ario. . . . . . . . . . . . . . . . . . . . . . . veja timezone
G
Garth Snyder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Gene Spafford. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
H
hor ario de ver ao . . . . . . . . . . . . . . . . . . . veja timezone
I
IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
ICMP
ltragem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
informac oes de contato. . . . . . . . . . . . . . . . . . . . . . . 23
aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
endereco abuse . . . . . . . . . . . . . . . . . . . . . . . . . 23
endereco security. . . . . . . . . . . . . . . . . . . . . . 23
monitoramento. . . . . . . . . . . . . . . . . . . . . . . . . . 23
RFC 2142 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
SOA do DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
WHOIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
atualizac ao . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
tipos de contato . . . . . . . . . . . . . . . . . . . . . . . 24
instalac ao
de correc oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
de pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
desativac ao de servicos . . . . . . . . . . . . . . . . . . 14
documentac ao. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
mnima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
vantagens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
personalizada . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
planejamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
preparac ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
IPs reservados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
L
listas de discuss ao
alertas de seguranca . . . . . . . . . . . . . . . . . . . . . 27
Bugtraq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
cuidados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28, 29
internas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
para manter-se informado . . . . . . . . . . . . . . . . 27
logbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1113
cuidados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
formato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
informac oes essenciais . . . . . . . . . . . . . . . . . . . 11
uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14, 15, 18
logs
armazenamento off-line . . . . . . . . . . . . . . . . . . 19
armazenamento on-line . . . . . . . . . . . . . . . . . . 19
riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
checksum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
gerac ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18, 19
import ancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
integridade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
loghosts centralizados. . . . . . . . . . . . . . . . . . . . 19
monitoramento. . . . . . . . . . . . . . . . . . . . . . . . . . 20
eventos anormais . . . . . . . . . . . . . . . . . . . . . . 20
timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
perodo de armazenamento . . . . . . . . . . . . . . . 20
rel ogio sincronizado . . . . . . . . . . . . . . . . . . . . . 19
rotac ao autom atica . . . . . . . . . . . . . . . . . . . . . . 19
N
Nelson Murilo de O. Runo . . . . . . . . . . . . . . . . . . 35
NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
ajuste mais preciso . . . . . . . . . . . . . . . . . . . . . . 17
reduc ao de tr afego . . . . . . . . . . . . . . . . . . . . . . . 17
servidor local . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
P
particionamento de disco . . . . . . . . . . . . . . . . . . . . . . 9
vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
patches . . . . . . . . . . . . . . veja correc oes de seguranca
Paul Albitz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
38
poltica
an alise de riscos . . . . . . . . . . . . . . . . . . . . . . . . . . 6
de backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
de seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
de senhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
de uso aceit avel . . . . . . . . . . . . . . . . . . . . . . . . . . 8
fatores de sucesso . . . . . . . . . . . . . . . . . . . . . . . . 7
inu encias negativas . . . . . . . . . . . . . . . . . . . . . . 7
POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
pornograa envolvendo criancas . . . . . . . . . . . . . . 15
protocolos sem criptograa . . . . . . . . . . . . . . . . . . . 25
proxy Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
formas de abuso . . . . . . . . . . . . . . . . . . . . . . . . . 16
R
redes privadas (RFC 1918) . . . . . . . . . . . . . . . . . . . 25
redes reservadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
ltragem de enderecos . . . . . . . . . . . . . . . . . . . 25
lista atual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
vazamento de enderecos . . . . . . . . . . . . . . . . . 26
refer encias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Registro .br . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
relay aberto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
roaming users . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
rel ogio
fuso hor ario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
hor ario de ver ao . . . . . . . . . . . . . . . . . . . . . . . . . 17
sincronizac ao . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
timezone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
restaurac ao de backups . . . . . . . . . . . . . . . . . . . . . . . 27
rexec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
RFC 1918 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25, 26
RFC 2142 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
RFC 2544 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
RFC 3068 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
rlogin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Roberta Bragg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
root . . . . . . . . . . . . . . . . . . . . veja contas privilegiadas
rsh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
S
Scott Barman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Scott Seebass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
senhas
caractersticas desej aveis . . . . . . . . . . . . . . . . . 13
compartilhadas . . . . . . . . . . . . . . . . . . . . . . . . . . 18
de administrador . . . . . . . . . . . . . . . . . . . . . . . . 13
fortes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
poltica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
service packs. . . . . . . . . veja correc oes de seguranca
servicos
desativac ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
divis ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
n ao utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
servidores
de tempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2123, 26
SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16, 23
Simon Cooper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Simson Garnkel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
SPAM
relay aberto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
SSH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
su . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
T
Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Trent R. Hein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
V
vulnerabilidades
correc oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
exposic ao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
W
W. Richard Stevens . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Web
proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
sites sobre seguranca . . . . . . . . . . . . . . . . . . . . 28
webmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
WHOIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
39