Anda di halaman 1dari 35

Pr ticas de Seguranca para Administradores de Redes Internet a

NIC BR Security Ofce nbso@nic.br Vers o 1.0.1 a 17 de julho de 2002


Resumo ` Este documento e destinado a administradores de redes ligadas a Internet, incluindo provedores de acesso e de conte do. O seu prop sito e ser um guia com informacoes para congurar, administrar e operar estas u o redes de forma mais segura.

Sum rio a
1 Introducao 1.1 1.2 2 Organizacao do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Como Obter este Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 3 4 4 6 7 7 7 9 11 12 12 13 13 14 14

Polticas 2.1 2.2 Polticas de Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Polticas de Uso Aceit vel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a

Instalacao e Conguracao Segura de Sistemas 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 Preparacao da Instalacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estrat gias de Particionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Documentacao da Instalacao e Conguracao . . . . . . . . . . . . . . . . . . . . . . . . . . . Senhas de Administrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instalacao Mnima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Desativacao de Servicos N o Utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a Instalacao de Correcoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prevencao de Abuso de Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.1 3.8.2 Controle de Relay em Servidores SMTP . . . . . . . . . . . . . . . . . . . . . . . . . Controle de Acesso a Proxies Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Administracao e Operacao Segura de Redes e Sistemas 4.1 Ajuste do Rel gio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.1.1 4.1.2 4.2 Sincronizacao de Rel gios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o Timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15 15 15 15 15 15 16 16 17 17 17 18 19 19 19 20 20 21 21 22 23 24 25 25 26 27 27 31 31 31 33

Equipes de Administradores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 4.2.3 Comunicacao Eciente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controle de Alteracoes na Conguracao . . . . . . . . . . . . . . . . . . . . . . . . . Uso de Contas Privilegiadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3

Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 4.3.2 4.3.3 Geracao de Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Armazenamento de Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoramento de Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4 4.5

DNS Reverso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Informacoes de Contato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 4.5.2 4.5.3 Enderecos Eletr nicos Padr o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o a Contato no DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contatos no WHOIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.6 4.7 4.8 4.9

Eliminacao de Protocolos sem Criptograa . . . . . . . . . . . . . . . . . . . . . . . . . . . Cuidados com Redes Reservadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Polticas de Backup e Restauracao de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . Como Manter-se Informado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.10 Precaucoes contra Engenharia Social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Uso Ecaz de Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11.1 A Escolha de um Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11.2 Localizacao dos Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11.3 Crit rios de Filtragem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 4.11.4 Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Refer ncias Adicionais e A.1 URLs de Interesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 Livros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Indice Remissivo 2

Introducao

Este documento procura reunir um conjunto de boas pr ticas em conguracao, administracao e operacao a ` segura de redes conectadas a Internet. A implantacao destas pr ticas minimiza as chances de ocorrerem pro a blemas de seguranca e facilita a administracao das redes e recursos de forma segura. E importante frisar que este conjunto representa o mnimo indispens vel dentro de um grande universo de boas pr ticas de seguranca, a a o que equivale a dizer que a sua adocao e um bom comeco mas n o necessariamente e suciente em todas as a situacoes. As recomendacoes apresentadas s o eminentemente pr ticas e, tanto quanto possvel, independentes de a a plataforma de software e hardware. A maioria dos princpios aqui expostos e gen rica; a sua efetiva aplicacao e requer que um administrador determine como estes princpios podem ser implementados nas plataformas que ele utiliza. ` Este documento e dirigido ao pessoal t cnico de redes conectadas a Internet, especialmente aos adminise tradores de redes, sistemas e/ou seguranca, que s o os respons veis pelo planejamento, implementacao ou a a operacao de redes e sistemas. Tamb m podem se beneciar da sua leitura gerentes com conhecimento t cnico e e de redes.

1.1

Organizacao do Documento

O restante deste documento est organizado da seguinte maneira. A secao 2 apresenta polticas importantes a para respaldar e viabilizar os procedimentos t cnicos descritos nas secoes subseq entes. A secao 3 mostra como e u congurar sistemas e redes de forma mais segura. Na secao 4 s o discutidos m todos para se ter seguranca na a e administracao e operacao de redes e sistemas. O ap ndice A traz sugest es de material de consulta para quem e o queira obter conhecimentos mais aprofundados sobre algum dos temas abordados nas secoes de 2 a 4.

1.2

Como Obter este Documento

Este documento pode ser obtido em http://www.nic.br/docs/seg-adm-redes.html. Como ele e periodicamente atualizado, certique-se de ter sempre a vers o mais recente. a Caso voc tenha alguma sugest o para este documento ou encontre algum erro nele, entre em contato e a atrav s do endereco doc@nic.br. e

2
2.1

Polticas
Polticas de Seguranca

Uma poltica de seguranca e um instrumento importante para proteger a sua organizacao contra ameacas a ` seguranca da informacao que a ela pertence ou que est sob sua responsabilidade. Uma ameaca a seguranca a ` e compreendida neste contexto como a quebra de uma ou mais de suas tr s propriedades fundamentais (cone dencialidade, integridade e disponibilidade). A poltica de seguranca n o dene procedimentos especcos de manipulacao e protecao da informacao, a ` mas atribui direitos e responsabilidades as pessoas (usu rios, administradores de redes e sistemas, funcion rios, a a gerentes, etc.) que lidam com essa informacao. Desta forma, elas sabem quais as expectativas que podem ter e quais s o as suas atribuicoes em relacao a seguranca dos recursos computacionais com os quais trabalham. a ` ` Al m disso, a poltica de seguranca tamb m estipula as penalidades as quais est o sujeitos aqueles que a dese e a cumprem. Antes que a poltica de seguranca seja escrita, e necess rio denir a informacao a ser protegida. Usualmente, a isso e feito atrav s de uma an lise de riscos, que identica: e a recursos protegidos pela poltica; ameacas as quais estes recursos est o sujeitos; ` a vulnerabilidades que podem viabilizar a concretizacao destas ameacas, analisando-as individualmente. Uma poltica de seguranca deve cobrir os seguintes aspectos: aspectos preliminares: abrang ncia e escopo de atuacao da poltica; e denicoes fundamentais; normas e regulamentos aos quais a poltica est subordinada; a quem tem autoridade para sancionar, implementar e scalizar o cumprimento da poltica; meios de distribuicao da poltica; como e com que freq encia a poltica e revisada. u poltica de senhas: requisitos para formacao de senhas; perodo de validade das senhas; normas para protecao de senhas; reuso de senhas; senhas default. direitos e responsabilidades dos usu rios, tais como: a utilizacao de contas de acesso; utilizacao de softwares e informacoes, incluindo quest es de instalacao, licenciamento e copyright; o 4

protecao e uso de informacoes (sensveis ou n o), como senhas, dados de conguracao de sistemas a e dados condenciais da organizacao; uso aceit vel de recursos como email, news e p ginas Web; a a ` direito a privacidade, e condicoes nas quais esse direito pode ser violado pelo provedor dos recursos (a organizacao); uso de antivrus. direitos e responsabilidades do provedor dos recursos, como: backups; diretrizes para conguracao e instalacao de sistemas e equipamentos de rede; autoridade para conceder e revogar autorizacoes 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. acoes previstas em caso de violacao da poltica: diretrizes para tratamento e resposta de incidentes de seguranca; penalidades cabveis. Cabe ressaltar que a lista de t picos acima n o e exaustiva nem tampouco se aplica a todos os casos. o a Cada organizacao possui um ambiente distinto e os seus pr prios requisitos de seguranca, e deve, portanto, o desenvolver uma poltica de seguranca que se molde a essas peculiaridades. Alguns fatores importantes para o sucesso de uma poltica de seguranca s o: a apoio por parte da administracao superior; a poltica deve ser ampla, cobrindo todos os aspectos que envolvem a seguranca dos recursos computaci onais e da informacao sob responsabilidade da organizacao; a poltica deve ser periodicamente atualizada de forma a reetir as mudancas na organizacao; deve haver um indivduo ou grupo respons vel por vericar se a poltica est sendo respeitada; a a todos os usu rios da organizacao devem tomar conhecimento da poltica e manifestar a sua concord ncia a a em submeter-se a ela antes de obter acesso aos recursos computacionais; a poltica deve estar disponvel em um local de f cil acesso aos usu rios, tal como a intranet da organiza a a cao. Dentre os itens acima, o apoio por parte da administracao superior e essencial. Se a poltica de seguranca n o for encampada pela administracao, ela rapidamente ser deixada de lado pelos demais seto a a ` res da organizacao. Al m disso, e importante que os seus membros d em o exemplo no que diz respeito a e e observ ncia da poltica de seguranca. a Os seguintes fatores inuem negativamente na aceitacao de uma poltica de seguranca e podem lev -la ao a fracasso: a poltica n o deve ser demasiadamente detalhada ou restritiva; a 5

o excesso de detalhes na poltica pode causar confus o ou diculdades na sua implementacao; a n o devem ser abertas excecoes para indivduos ou grupos; a a poltica n o deve estar atrelada a softwares e/ou hardwares especcos. a

2.2

Polticas de Uso Aceit vel a

A poltica de uso aceit vel (AUPAcceptable Use Policy) e o documento que dene como os recursos a computacionais da organizacao podem ser utilizados. Ela deve ser p blica e estar disponvel a todos os que u utilizam a infra-estrutura computacional da organizacao, sendo recomend vel que a autorizacao para uso dos a recursos seja condicionada a uma concord ncia expressa com os seus termos. a A AUP e geralmente parte integrante da poltica de seguranca global. Para muitas organizacoes, ela ser a composta pelos itens da poltica que afetam diretamente os usu rios de recursos computacionais, principalmente a os que denem seus direitos e responsabilidades. Por outro lado, organizacoes que oferecem acesso a usu rios externos (tais como provedores de acesso a ` Internet) devem denir uma poltica de uso aceit vel para esses usu rios que seja independente da AUP a qual a a est o sujeitos os seus usu rios internos. E importante que os usu rios externos tomem conhecimento dessa a a a poltica e saibam que o uso dos recursos est condicionado ao seu cumprimento. a

Instalacao e Conguracao Segura de Sistemas

Uma vez estabelecidas as polticas de seguranca apropriadas para a sua rede (conforme exposto na secao 2), a etapa seguinte deve ser a conguracao segura dos sistemas que estar o nessa rede. a Caso n o exista uma documentacao atualizada que detalhe a conguracao de alguns ou todos os sistemas a em uso na sua rede, e aconselh vel que estes sistemas sejam reinstalados observando-se as recomendacoes aqui a expostas, ou, pelo menos, que a sua conguracao seja revisada e a documentacao correspondente atualizada. ` IMPORTANTE: um sistema s dever ser conectado a Internet ap s os passos descritos nas secoes 3.1 a 3.8 o a o terem sido seguidos. A pressa em disponibilizar um sistema na Internet pode levar ao seu comprometimento.

3.1

Preparacao da Instalacao

A instalacao de um sistema deve ser feita com ele isolado do mundo externo. Para tanto, os seguintes princpios devem ser seguidos: planeje a instalacao, denindo itens como: o prop sito do sistema a ser instalado; o os servicos que este sistema disponibilizar ; a a conguracao de hardware da m quina; a como o disco ser particionado, etc. a providencie de antem o todos os manuais e mdias de instalacao que ser o utilizados; a a instale o sistema a partir de dispositivos de armazenamento locais (CD, ta ou disco), desconectado da rede; caso voc precise ligar o sistema em rede (para fazer download de atualizacoes, por exemplo), coloque-o e em uma rede isolada, acessvel apenas pela sua rede interna. Caso seja possvel, evite concentrar todos os servicos de rede em uma unica m quina, dividindo-os entre a v rios sistemas. Isto e desej vel pois aumenta a disponibilidade dos servicos na sua rede e reduz a extens o de a a a um eventual comprometimento a partir de um deles.

3.2

Estrat gias de Particionamento e

Conforme mencionado na secao 3.1, um dos aspectos que devem ser includos no planejamento da ins talacao e como ser feito o particionamento do(s) disco(s) do sistema. Embora isso dependa basicamente da a utilizacao pretendida para o sistema, existem alguns fatores que devem ser levados em consideracao no mo mento de decidir como o disco deve ser particionado. Um princpio b sico e dividir o disco em v rias particoes em vez de usar uma unica particao ocupando o a a disco inteiro. Isto e recomend vel por diversas raz es: a o

Um usu rio ou um programa mal-comportado pode lotar uma particao na qual tenha permiss o de escrita a a ( reas tempor rias e de armazenamento de logs s o suscetveis a este problema). Se os programas do a a a sistema estiverem em outra particao eles provavelmente n o ser o afetados, evitando que o sistema trave. a a Caso uma particao seja corrompida por alguma raz o, as outras particoes provavelmente n o ser o afe a a a tadas. Em alguns sistemas (notadamente sistemas UNIX), e possvel denir algumas caractersticas individuais para cada particao. Por exemplo, algumas particoes podem ser usadas em modo read-only, o que e util para particoes que contenham bin rios que s o modicados com pouca freq encia. a a u Em alguns casos a exist ncia de v rias particoes permite m ltiplas operacoes de disco em paralelo e/ou o e a u uso de otimizacoes individuais para cada particao, o que pode aumentar signicativamente o desempenho do sistema. O uso de v rias particoes geralmente facilita o procedimento de backup do sistema, pois simplica a funcoes como: copiar particoes inteiras de uma s vez; o excluir particoes individuais do procedimento; fazer backups a intervalos diferentes para cada particao. As particoes especcas que devem ser criadas variam de sistema para sistema, n o existindo uma regra que a possa ser sempre seguida. Entretanto, recomenda-se avaliar a conveni ncia da criacao de particoes separadas e para as areas onde s o armazenados itens como: a programas do sistema operacional; dados dos usu rios; a logs; arquivos tempor rios; a las de envio e recepcao de emails (servidores SMTP); las de impress o (servidores de impress o); a a reposit rios de arquivos (servidores FTP); o p ginas Web (servidores HTTP). a Note que a lista acima n o e exaustiva, podendo existir outras areas do sistema que merecam uma particao a separada. Da mesma forma, existem itens dentre os acima que n o se aplicam a determinados casos. Consulte a a documentacao do seu sistema operacional para ver se ela cont m recomendacoes a respeito do particionamento e adequado dos discos. As particoes 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 documentacao, o que pode auxiliar na determinacao do tamanho de algumas particoes. Qualquer que seja a estrutura de particionamento escolhida, e recomend vel que voc tenha pelo menos a e um esboco dela por escrito antes de comecar a instalacao. Isto agiliza o processo de instalacao e reduz a probabilidade de que se faca uma determinada escolha sem que as suas conseq encias sejam adequadamente u previstas. 8

3.3

Documentacao da Instalacao e Conguracao

Uma medida importante para permitir uma r pida avaliacao da situacao de um sistema e a documentacao a de sua instalacao e conguracao. A id ia e ter uma esp cie de logbook (ou di rio de bordo), que detalhe os e e a componentes instalados no sistema e todas as modicacoes na sua conguracao global. Esse logbook pode ser particularmente util para determinar qual vers o de determinado pacote est instalada a a no sistema ou para reconstituir uma dada instalacao. Muitas vezes um administrador precisa consultar diversas fontes e realizar v rias tentativas antes de instalar e/ou congurar corretamente um determinado pacote de a software. A exist ncia de um documento que relate quais os passos exatos que tiveram que ser seguidos para que e a instalacao/conguracao fosse bem sucedida permite que esse mesmo pacote possa ser instalado com correcao a e rapidez em outro sistema ou ocasi o. Conforme ser visto na secao 4.2, a import ncia deste documento cresce a a na medida em que a responsabilidade pela administracao dos sistemas seja compartilhada por diversas pessoas. O formato e o grau de sosticacao do logbook dependem de diversos fatores, e cada administrador deve determinar qual a melhor maneira de manter essas informacoes. 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 informacoes su cientes para que, a partir dele, seja possvel reconstituir a exata conguracao que o sistema possua antes da falha, sem que seja necess rio recorrer a backups.1 a E essencial que alteracoes na conguracao do sistema e de seus componentes estejam documentadas neste logbook. A entrada referente a estas alteracoes deve conter, no mnimo, os seguintes itens: data da modicacao; respons vel pela modicacao; a justicativa para a modicacao; descricao da modicacao. Deve ser possvel, ainda, reconstituir a situacao antes da mudanca na conguracao a partir dessa entrada. A gura 1 mostra um exemplo com algumas entradas do logbook de um servidor FTP. A primeira entrada registra a instalacao 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 s a instalacao; o quais os usu rios criados (com seus respectivos UIDs e GIDs). a
1A

exist ncia do logbook n o diminui a import ncia dos backups, que ser o tratados na secao 4.8. e a a a

Logbook para vangogh.example.org (IP 192.0.2.24) ================================================ 26/Fev/2002 Responsvel: Joe a

Instalaco de vangogh.example.org, servidor FTP de example.org. Instalado o a sistema operacional GoodBSD verso 6.5. A instalaco foi feita usando a opco a a a custom do menu de instalaco. O disco foi particionado da seguinte maneira: a Filesystem /dev/wd0a /dev/wd0d /dev/wd0e Size 100M 3.0G 500M Mount point / /var /tmp | | | | Filesystem /dev/wd0f /dev/wd0g /dev/wd0h Size 2.0G 400M 4.0G Mount point /usr /home /home/ftp As portas

Uma lista dos pacotes instalados est em /usr/local/sysadm/pkg.inst. a abertas aps a instalaco so (netstat -a): o a a Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address tcp 0 0 *.ftp *.* tcp 0 0 *.ssh *.* udp 0 0 vangogh.example.org.ntp *.* udp 0 0 localhost.ntp *.* udp 0 0 *.ntp *.* udp 0 0 *.syslog *.*

(state) LISTEN LISTEN

Criados os usurios joe (UID=501), alice (UID=502), bob (UID=503) e caio a (UID=504). Cada usurio pertence ao seu prprio grupo (GID=UID) e joe, alice e a o bob pertencem tambm ao grupo wheel. e -----------------------------------------------------------------------01/Mar/2002 Responsvel: Alice a Instalado o foo-1.2.3, uma ferramenta para anlise de logs de FTP. Os fontes a esto em /usr/local/src/foo-1.2.3. Os comandos necessrios para a instalaco foram: a a a $ ./configure $ make # make install Para usar o programa, foi necessrio criar o usurio foo (UID=300,GID=100/users) a a e o diretrio /usr/local/share/foo (owner=foo, group=users), com permisses 0755. o o -----------------------------------------------------------------------03/Mar/2002 Responsvel: Bob a Criado o grupo foobar (GID=300), para os usurios do pacote foo. O diretrio a o /usr/local/share/foo teve seu grupo alterado de users para foobar e as permisses de 0755 para 0750. Modificaco necessria para que apenas usurios o a a a pertencentes ao grupo foobar tenham acesso aos programas do pacote foo. Os usurios alice, bob e caio foram adicionados ao grupo foobar. a -----------------------------------------------------------------------03/Mar/2002 Responsvel: Alice a Modificado o /etc/rc.local para carregar o daemon bard (usado pelo pacote foo) no boot. Um diff da modificaco est em /usr/local/sysadm/rc.local-bard.diff. a a

Figura 1: Exemplos de entradas no logbook 10

Ap s a instalacao inicial do sistema operacional, no dia 01/03 foi instalado um pacote chamado foo, vers o o a 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 (criacao de um usu rio e um diret rio, com suas respectivas a o informacoes). A terceira entrada registra algumas alteracoes que tiveram que ser feitas na conguracao do sistema pa ra que o pacote foo pudesse ser usado corretamente. Por sua vez, a ultima entrada do exemplo apresenta uma modicacao na inicializacao do sistema para carregar um daemon (software servidor) usado pelo paco te. Observe que ambas as entradas permitem que a situacao anterior do sistema (ou seja, a situacao antes das modicacoes descritas) seja restaurada, caso isso se revele necess rio ou desej vel. a a IMPORTANTE: o logbook de um sistema e um documento sensvel, pois cont m informacoes que podem e 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 organizacao.

3.4

Senhas de Administrador

Durante a instalacao de um sistema, em determinado momento ser solicitado que voc informe uma senha a e de administrador (root ou Administrator). Na maioria dos casos, e o pr prio programa de instalacao que o solicita a escolha da senha. Em outros casos, a senha de administrador deve ser denida ap s o primeiro boot o do sistema. Procure estabelecer esta senha t o cedo quanto possvel durante a instalacao do sistema. De prefer ncia, a e tenha uma senha j em mente quando comecar a instalacao. a Uma senha adequada e aquela f cil de ser lembrada e difcil de ser adivinhada. Ela deve respeitar, no a mnimo, os seguintes crit rios: e ter um comprimento mnimo de 8 caracteres; ser formada por letras, n meros e caracteres especiais; u n o ser derivada de seus dados pessoais, tais como nomes de membros da famlia (incluindo animais de a estimacao), n meros de telefone, placas de carros, n meros de documentos e datas; u u n o dever ser adivinhada por quem conheca suas prefer ncias pessoais (time para o qual torce, escritor, a e ator ou cantor favorito, nomes de livros, lmes ou m sicas, etc.); u n o estar presente em dicion rios (de portugu s ou de outros idiomas). a a e Uma sugest o para formar senhas que se encaixem nos requisitos acima e usar as primeiras ou ultimas letras a das palavras de uma frase, adicionando n meros e smbolos e trocando min sculas e mai sculas para dicultar u u u ataques baseados em forca bruta. Por exemplo, a partir das iniciais de the book is on the table obt m-se, e inicialmente, tbiott. A partir da, e possvel trocar a letra o por um 0 (zero) e o pen ltimo t por um u smbolo +, colocar algumas letras em mai sculo e acrescentar outras letras, chegando a tBi0+TbL, uma u 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.

11

3.5

Instalacao Mnima

Um sistema mais seguro comeca pela instalacao do mnimo possvel de pacotes e componentes, especial mente os que implementam servicos de rede. Este mnimo depende fundamentalmente do prop sito do sistema o em quest o e do ambiente de rede no qual ele est inserido. Por exemplo, em princpio um sistema dedicado a a a servir p ginas Web n o precisa de um software servidor SMTP, assim como uma estacao de trabalho n o a a a precisa de um servidor HTTP. A justicativa para esta recomendacao e bastante simples. E comum que servicos n o utilizados n o se a a jam monitorados por falhas de seguranca, o que aumenta a possibilidade de n o ser aplicada uma correcao a necess ria. A reducao no n mero de pacotes instalados diminui a chance de que o sistema possua uma vulnea u rabilidade que possa vir a ser explorada por um atacante. Muitas vezes, administradores preferem instalar componentes cujo prop sito ou funcionalidade desconheo 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 ncias que avisa quando determinado componente precisa de e outro para funcionar. Em outras palavras, freq entemente e possvel deixar de instalar v rios componentes sem u a comprometer a funcionalidade do sistema. Consulte a documentacao do seu sistema ou o suporte t cnico do e seu fornecedor para saber se isto se aplica ao seu caso. Alguns programas de instalacao permitem que o administrador escolha entre uma instalacao tpica e uma personalizada (para experts). Quando possvel, opte pela personalizada, evitando instalar componentes cuja ` funcionalidade seja desconhecida ou que voc n o esteja certo quanto a sua necessidade. e a Em outros sistemas a instalacao se d em duas etapas, a instalacao do sistema base (sobre a qual o admi a nistrador tem mnimo ou nenhum controle) e a instalacao de pacotes ou componentes adicionais. Neste caso, instale o sistema base e selecione cuidadosamente quais os componentes extras que ser o adicionados ao sistea ma. Neste tipo de sistema, a desativacao de servicos n o utilizados (secao 3.6) e muito importante e deve ser a realizada com especial atencao.

3.6

Desativacao de Servicos N o Utilizados a

O passo seguinte a uma instalacao mnima e a desativacao de servicos (locais e, principalmente, de rede) que n o ser o imediatamente utilizados no sistema. A l gica por tr s desta recomendacao e a mesma por tr s a a o a a da instalacao mnima de pacotes: reduzir a exposicao do sistema a vulnerabilidades. Embora possa parecer que exista redund ncia entre este passo e o anterior, na pr tica surgem situacoes a a 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 m disso, muitos programas de instalacao de e sistemas operacionais optam por maximizar a funcionalidade disponibilizada aos usu rios, e a conguracao a padr o do sistema traz ativados todos os servicos que foram instalados. Caso uma dessas situacoes ocorra, as a funcionalidades que n o ser o utilizadas dever o ser desativadas ou mesmo removidas do sistema. a a a Por exemplo, suponha que um pacote de servicos de impress o contenha tanto um cliente quanto um servi a dor de impress o remota. Se o sistema necessitar apenas do software cliente, o administrador deve desabilitar a a parte referente ao software servidor neste sistema. Caso n o seja possvel desativar servicos individualmente, uma alternativa e usar um ltro de pacotes para a bloquear as portas TCP/UDP usadas por esses servicos, impedindo que eles sejam acessados atrav s da rede. e Isto ser discutido em maiores detalhes na secao 4.11. a 12

IMPORTANTE: a desativacao de servicos e/ou a remocao de arquivos efetuadas nesta fase dever o ser a documentadas no logbook do sistema.

3.7

Instalacao de Correcoes

Depois de um sistema ter sido corretamente instalado e congurado, e necess rio vericar se n o existem a a correcoes (patches, xes, service packs) para vulnerabilidades conhecidas nos componentes instalados. A mai oria dos fornecedores de software libera correcoes para problemas de seguranca que sejam descobertos em um sistema, sem que se tenha de esperar pela sua pr xima vers o. Na maioria das vezes, estas correcoes est o o a a disponveis atrav s da Internet. Consulte seu fornecedor para saber como manter-se informado a respeito de e correcoes para o seu sistema e de que forma elas podem ser obtidas. ` Nem sempre todas as correcoes disponveis precisam ser instaladas. Restrinja-se aquelas que corrigem problemas em componentes que estejam efetivamente instalados no seu sistema. Em caso de d vida, recorra ao u suporte t cnico do seu fornecedor. A instalacao indiscriminada de atualizacoes pode enfraquecer a seguranca e do sistema ao inv s de fortalec -la. e e Registre no logbook a instalacao de correcoes. Mantenha em sua rede um reposit rio das atualizacoes que o j foram utilizadas, para facilitar a instalacao das mesmas em outros sistemas. a
IMPORTANTE: muitas vezes algumas conguracoes do sistema s o alteradas durante o processo de instala a cao de correcoes. Sendo assim, e recomend vel que voc reveja a conguracao do seu sistema ap s instalar a e o uma correcao para certicar-se de que a instalacao n o tenha revertido eventuais modicacoes que voc tenha a e feito (especialmente aquelas destinadas a desativar servicos). IMPORTANTE: a instalacao de correcoes deve ser realizada n o s como parte da instalacao inicial do a o sistema, mas tamb m durante o seu tempo de vida, a intervalos peri dicos ou sempre que surgirem vulnerabie o lidades que o afetem. A secao 4.9 traz algumas recomendacoes sobre como manter-se informado a respeito de novas vulnerabilidades que afetem os seus sistemas.

3.8 Prevencao de Abuso de Recursos


Existem alguns servicos que, se mal congurados, podem permitir que usu rios externos abusem dos re a cursos da sua rede, ainda que isso n o implique na ocorr ncia de uma invas o. Dois destes servicos s o o email a e a a e os proxies de Web. A conguracao incorreta destes servicos pode causar v rios efeitos indesej veis. Um deles e que recursos a a computacionais da organizacaoa comecar pelo link Internet, mas incluindo CPU, discos e mem ria dos o servidoress o consumidos por terceiros sem que eles paguem por esse uso. Em muitos casos, esses recursos a s o exauridos de forma que usu rios legtimos n o possam utilizar o servico. a a a Al m disso, servidores mal congurados s o muitas vezes usados para disseminar conte do ilegal, tal como e a u pornograa envolvendo criancas. Se um conte do deste tipo for encontrado em sistemas sob sua responsabili u dade, existe a possibilidade de que voc e/ou sua organizacao venham a ser legalmente implicados no caso. e

13

3.8.1

Controle de Relay em Servidores SMTP

Na sua conguracao padr o, muitos servidores SMTP v m com o relay aberto, permitindo que eles sejam a e usados para enviar mensagens de e para qualquer rede ou domnio, independente dos enderecos envolvidos serem da sua rede ou n o. Estes servidores s o amplamente explorados para envio de SPAM. a a Al m das conseq encias j mencionadas, diversas redes bloqueiam a recepcao de mensagens a partir de e u a servidores que tenham sido ou estejam sendo usados para envio de SPAM, fazendo com que usu rios do servidor a com relay aberto n o possam enviar mensagens a usu rios dessas redes. H que se considerar tamb m que o a a a e uso de servidores SMTP de terceiros torna mais difcil a localizacao e identicacao dos spammers, diminuindo as chances de que eles sejam punidos por estes abusos. Para resolver este problema de relay aberto voc precisa congurar os seus servidores SMTP corretamente. e A conguracao adequada deve permitir apenas: envio de mensagens com endereco de origem local e endereco de destino local ou externo; recepcao de mensagens com endereco de origem local ou externo e endereco de destino local. Informacoes sobre como corrigir este problema para diferentes servidores SMTP est o disponveis em a 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 rios deste tipo, a consulte a documentacao do seu servidor SMTP ou o seu fornecedor para saber como fechar o relay sem prejudicar a utilizacao 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 m podem ser abusados se n o forem tomadas as devidas precaucoes. e a Um proxy mal congurado pode ser usado por usu rios externos como um trampolim para acessar recura sos de forma an nima. Esta anonimidade pode ser usada para cometer crimes, tais como envio de mensagens o caluniosas, difamat rias ou ameacadoras e divulgacao de pornograa envolvendo criancas. o A conguracao correta para um proxy Web e aquela que libera o acesso somente aos enderecos IP de ` usu rios autorizados (pertencentes a sua rede). Consulte a documentacao do seu software ou o suporte t cnico a e do seu fornecedor para obter maiores informacoes sobre como congurar o controle de acesso no seu proxy.

14

4
4.1

Administracao e Operacao Segura de Redes e Sistemas


Ajuste do Rel gio o
Sincronizacao de Rel gios o

4.1.1

Os rel gios de todos os sistemas da sua rede (incluindo as estacoes de trabalho) dever o estar sincronizados, o a ou seja, dever o ter exatamente o mesmo hor rio. Para que isso aconteca, voc deve usar um protocolo de a a e sincronizacao de rel gios, tal como o NTP (Network Time Protocol). Este protocolo e o mais recomendado, o pois existem implementacoes dele para os mais variados sistemas operacionais, como pode ser visto em http: //www.ntp.org/. Para obter maior precis o no ajuste e para minimizar o tr fego desnecess rio na rede, sugere-se que a a a a sincronizacao via NTP seja implementada observando-se as seguintes recomendacoes: 1. Procure manter em sua rede um servidor NTP local. Esse servidor e quem ir realizar a sincronizacao a com um servidor externo. As demais m quinas da sua rede, por sua vez, ter o seus rel gios sincronizados a a o com o rel gio do servidor local. o 2. Muitos backbones disponibilizam um servidor NTP a seus clientes. Consulte o suporte t cnico do seu e backbone para vericar se ele oferece este servico e como voc pode fazer para utiliz -lo. e a

4.1.2

Timezone

Caso voc trabalhe com servidores UNIX, ajuste o rel gio de hardware destes sistemas para a hora padr o e o a de Greenwich (GMT) e congure adequadamente o seu fuso hor rio (timezone) para que a hora local seja a exibida corretamente. O uso do timezone certo tamb m possibilita o ajuste automatizado do rel gio por conta do hor rio de ver o. e o a a Para que isso seja possvel, voc dever criar ou obter um arquivo de informacoes de timezone com as datas e a corretas de incio e m do hor rio de ver o. Para maiores informacoes, consulte a documentacao do comando a a zic.

4.2

Equipes de Administradores

Em muitas redes, a administracao de sistemas e uma responsabilidade dividida entre v rias pessoas. Nesses a casos, e necess rio estabelecer algumas regras para garantir a eci ncia do trabalho em equipe. a e

4.2.1

Comunicacao 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 o por email que sejam internas a sua organizacao. Esa tas listas podem ser usadas para, entre outros prop sitos, comunicar alteracoes na conguracao dos sistemas, o noticar os demais administradores a respeito de ocorr ncias relevantes e servir como mecanismo de acompae nhamento da divis o de tarefas. a 15

A grande vantagem de usar listas de discuss o e que elas possibilitam a comunicacao entre os adminisa tradores mesmo que alguns trabalhem em diferentes turnos ou locais. O hist rico das listas pode servir para o documentar decis es tomadas e para atualizar um administrador que tenha passado algum tempo afastado de o suas atividades.

4.2.2

Controle de Alteracoes na Conguracao

A partir do momento em que v rias pessoas cam encarregadas da administracao de um sistema, torna-se a necess rio dispor de meios que possibilitem a identicacao de quem foi o respons vel por cada alteracao na sua a a conguracao. Isso permite resolver problemas de forma mais eciente, pois a pessoa que realizou determinada modicacao e a mais indicada para ajudar na resolucao de eventuais complicacoes dela decorrentes. a Conforme mostrado na secao 3.3, o logbook pode auxiliar nessa tarefa. Para isso, e necess rio que em cada entrada no logbook conste o nome da pessoa respons vel pelas modicacoes ali descritas. a Uma forma mais automatizada de fazer isso e atrav s do uso de ferramentas de controle de vers o como e a o RCS (http://www.cs.purdue.edu/homes/trinkle/RCS/) e o CVS (http://www.cvshome.org). Essas ferramentas tamb m permitem manter um hist rico de arquivos de conguracao, de forma a possibilitar a e o recuperacao de antigas vers es desses arquivos. Recomenda-se que, sempre que possvel, este tipo de ferra o menta seja usado em sistemas que possuam m ltiplos administradores. u

4.2.3 Uso de Contas Privilegiadas Um problema que surge em sistemas com m ltiplos administradores e a diculdade de se manter um registro u do uso de contas privilegiadas, tais como root e Administrator. Sempre que possvel, estas contas n o devem ser usadas diretamente. Um administrador deve entrar no a sistema usando sua conta pessoal e a partir dela realizar suas tarefas, usando os privil gios mais elevados e apenas quando estritamente necess rio. Em sistemas UNIX, isso e realizado atrav s do comando su. O su traz a e 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 sistema conceda a determinados usu rios a possibilidade de executar comandos predenidos como se eles fossem a root (ou outro usu rio), registrando nos logs do sistema a utilizacao desses comandos. O uso do sudo reduz a a necessidade de compartilhamento da senha de root, uma vez que os usu rios entram com sua pr pria senha a o para utilizar os comandos disponveis atrav s dele. Isso pode ser usado, por exemplo, quando existem contas e de operador que s o usadas para a realizacao de backups ou para invocar o procedimento de desligamento do a sistema. O sudo e extremamente congur vel, possibilitando, entre outros recursos, a denicao de grupos de usu a a rios, de comandos e de hosts e o uso de restricoes por host ou grupo de hosts (permitindo que o mesmo arquivo de conguracao seja usado em sistemas diferentes). IMPORTANTE: o uso de uma conta administrativa unica com senha compartilhada, que n o permita a determinar qual dos administradores acessou o sistema, deve ser evitado ao m ximo. a

16

4.3

Logs

Logs s o muito importantes para a administracao segura de sistemas, pois registram informacoes sobre o a seu funcionamento e sobre eventos por eles detectados. Muitas vezes, os logs s o o unico recurso que um a administrador possui para descobrir as causas de um problema ou comportamento an malo. o

4.3.1

Geracao de Logs

Para que os logs de um sistema sejam uteis para um administrador, eles devem estar com o hor rio sina cronizado via NTP, ser t o detalhados quanto possvel, sem no entanto gerar dados em excesso. Informacoes a especialmente uteis s o aquelas relacionadas a eventos de rede, tais como conex es externas e registros de a o utilizacao de servicos (arquivos transferidos via FTP, acessos a p ginas Web, tentativas de login sem sucesso, a avisos de disco cheio, etc.). Para registrar estas informacoes, e necess rio congurar o sistema da maneira apropriada. A forma de fazer a isto geralmente varia para cada componente especco; consulte a documentacao para descobrir como habilitar o logging de informacoes no seu sistema e em softwares especcos como rewalls e servidores HTTP.

4.3.2

Armazenamento de Logs

Armazenamento on-line Os logs s o tradicionalmente armazenados em disco, no pr prio sistema onde s o gerados. Essa e a opcao a o a 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 o do sistema a (uma ocorr ncia bastante comum). Em alguns sistemas, isso pode ser contornado atrav s da instalacao de um e e 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 rio redundante de logs. Via de regra, o loghost n o disponibiliza o a 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 lise dos logs e a correlacao 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 negacao de servico contra um determinado sistema, gerando eventos em excesso at que o disco onde s o armazenados e a os logs que cheio e o sistema trave em conseq encia disto. Conforme discutido na secao 3.2, o uso de uma u particao separada para armazenar os logs pode minimizar o impacto deste problema. Outro ponto que merece atencao e a rotacao autom tica de logs. Quando este recurso e utilizado, deve-se a garantir que os logs sejam movidos para o armazenamento off-line antes que eles sejam removidos do sistema pela rotacao, evitando assim a perda de registros. Alguns sistemas trazem a rotacao autom tica habilitada na a sua conguracao padr o; ao instalar um destes sistemas, verique se esta conguracao e compatvel com os a seus procedimentos de backup e armazenamento off-line de logs. Armazenamento off-line 17

Evidentemente, os logs n o podem ser mantidos on-line por tempo indeterminado, pois acabam por consua mir muito espaco em disco. A melhor estrat gia para resolver esta quest o e transferir periodicamente os logs e a do disco para dispositivos de armazenamento off-line, tais como ta, CD-R ou CD-RW. E recomend vel gerar um checksum criptogr co (tal como MD5 ou SHA-1) dos logs que s o armazenados a a a off-line. Esse checksum deve ser mantido separado dos logs, para que possa ser usado para vericar a integridade destes caso eles venham a ser necess rios. a Os logs armazenados off-line devem ser mantidos por um certo perodo de tempo, pois podem vir a ser ne cess rios para ajudar na investigacao de incidentes de seguranca descobertos posteriormente. O Comit Gestor a e da Internet no Brasil recomenda que logs de conex es de usu rios de provedores de acesso estejam disponveis o a por pelo menos 3 anos (vide http://www.cg.org.br/acoes/desenvolvimento.htm). E aconselh vel que a 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 o tratados na secao 4.8). a 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 encia para permitir que eventuais problemas sejam u rapidamente identicados. Existem algumas pr ticas recomend veis no que diz respeito ao monitoramento de logs: a a ` incorpore o h bito de inspecionar os logs a sua rotina de trabalho; a faca isso pelo menos uma vez por dia, mas tenha em mente que sistemas muito importantes ou que geram muita informacao podem precisar ter seus logs analisados com maior freq encia; u procure investigar as causas de qualquer registro que lhe pareca incorreto ou an malo, por mais insigni o cante que ele aparente ser; procure identicar o padr o de comportamento normal dos seus sistemas, para poder encontrar eventuais a anomalias com maior rapidez. Quando estiver analisando logs, voc deve certicar-se do timezone usado para registrar o hor rio dos e a eventos. Por exemplo, alguns softwares (como o Microsoft IIS, dependendo da conguracao adotada) registram eventos com a hora de Greenwich (GMT), e n o com a hora local. O desconhecimento do timezone em que a est o os logs pode facilmente invalidar uma an lise e lev -lo a conclus es equivocadas. a a a o ` A medida em que voc venha a adquirir pr tica com a an lise dos seus logs, voc poder escrever scripts e a a e a ou pequenos programas para auxili -lo nesta tarefa, automatizando assim parte do processo. Estes scripts s o a a uteis, por exemplo, para pr -processar os logs em busca de determinados conte dos e para elaborar um resumo e u que pode ser enviado por email para o administrador do sistema. Uma outra opcao s o ferramentas que permitem monitorar logs em tempo real, tais como o swatch (http: a //www.oit.ucsb.edu/eta/swatch). O swatch requer que voc especique um conjunto de padr es a serem e o monitorados e as acoes a serem tomadas quando um destes padr es e registrado nos logs. As acoes podem ser o de diversos tipos, como exibir a informacao registrada, noticar um determinado usu rio por email e invocar um a programa do sistema. A capacidade de execucao de comandos arbitr rios do swatch torna-o muito atraente, pois a 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. 18

4.4

DNS Reverso

O uso mais freq ente do DNS e a traducao de nomes em enderecos IP. Entretanto, ele tamb m permite u e descobrir o nome associado a um determinado endereco IP. Isso e chamado DNS reverso, e possibilita a identicacao do domnio de origem de um endereco IP. Um DNS reverso mal congurado ou inexistente pode causar alguns transtornos. O primeiro deles e que muitos sites negam o acesso a usu rios com enderecos sem DNS reverso ou com o reverso incorreto.3 Em a segundo lugar, erros na conguracao do DNS dep em contra a compet ncia t cnica da equipe de administracao o e e de redes respons vel pelo domnio, e isso pode vir a causar diculdades quando for necess rio interagir com a a equipes de outras redes. E recomend vel que voc mantenha atualizado o DNS reverso dos enderecos sob sua responsabilidade. Em a e ` alguns casos a administracao do DNS reverso dos seus blocos pode ser delegada a sua rede, enquanto em outros o seu provedor de backbone e quem e respons vel pelo DNS reverso dos seus enderecos. Entre em contato com a o seu provedor de backbone para obter informacoes sobre como atualizar o seu DNS reverso.

4.5

Informacoes de Contato

Existem na Internet alguns enderecos eletr nicos (emails) que s o usados para entrar em contato com o a ` administradores quando se deseja comunicar determinadas ocorr ncias relacionadas a seguranca de suas redes e extremamente importante que estas informacoes sejam v lidas e estejam sempre atualizadas, e sistemas. E a pois assim garante-se que estas comunicacoes ser o recebidas pela pessoa certa no menor espaco de tempo a possvel, o que pode muitas vezes impedir um incidente de seguranca ou limitar as conseq encias. Esta secao u mostra quais s o essas informacoes e como voc deve proceder para atualiz -las. a e a

4.5.1 Enderecos Eletr nicos Padr o o a A RFC 21424 dene uma s rie de emails padr o que devem existir em todas as redes e que podem ser e a usados para contatar os seus respons veis. Dentre os enderecos padr o, existem dois que est o relacionados a a a 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 o chegar at os respons veis por lidar com essas ocorr n a e a e cias. N o e necess rio criar usu rios com estes nomes, basta que sejam congurados aliases redirecionando as a a a mensagens enviadas a estes enderecos para os usu rios apropriados. a Cabe observar que muitas vezes estes enderecos n o s o usados da maneira mais apropriada, com abuse a a recebendo reclamacoes de incidentes de seguranca e security relatos de abusos, ou ambos os enderecos sendo usados na mesma noticacao. Sendo assim, e importante que sua rede possua ambos os enderecos e que eles sejam constantemente monitorados pela sua equipe de seguranca.
3 O caso mais comum de incorrecao e quando existe um nome para resolver um dado IP mas este mesmo nome n o est registrado a a em nenhum DNS direto, ou ent o resolve para outro endereco IP. Um exemplo disso seria o endereco IP 192.0.2.34 resolver para a 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.

19

4.5.2

Contato no DNS

Cada domnio registrado em um servidor DNS possui uma s rie de par metros de conguracao no registro e a de SOA (Start of Authority). Um destes par metros e o email do respons vel pelo domnio, que muitas vezes a a tamb m e usado para comunicar problemas de seguranca envolvendo esse domnio. e 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 rio e joe.example.org representa o endereco joe@example. a 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 minimo (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 o se esqueca que o formato a e usu rio.domnio, e n o usu rio@domnio. a a a

4.5.3

Contatos no WHOIS

Cada domnio ou bloco de enderecos IP registrado possui uma lista de informacoes de contato que remetem ` as pessoas respons veis por estes domnios ou blocos. Geralmente existem tr s tipos de contatos: a e contato t cnico: respons vel t cnico pela administracao e operacao do domnio ou bloco; e a e contato administrativo: quem tem autoridade sobre o domnio ou bloco; contato de cobranca: quem recebe correspond ncias de cobranca das despesas de registro e manutencao e do domnio ou bloco. Os enderecos de email destes contatos devem estar sempre atualizados e ser v lidos. No caso do contato t cnico, a e isso signica dizer que mensagens enviadas para este endereco devem ser recebidas por um administrador de redes respons vel pelo bloco ou domnio, e n o por pessoal administrativo ou jurdico da organizacao. Este a a contato e usado com muita freq encia para noticacao de incidentes de seguranca e outros problemas com a u infra-estrutura de rede envolvendo o domnio ou bloco. Estas informacoes de contato s o mantidas em uma base de dados chamada WHOIS. Esta base de dados e a normalmente gerenciada por entidades que registram domnios (informacoes sobre domnios) e por provedores de backbone (informacoes sobre enderecos IP). No Brasil, estas informacoes s o administradas e disponibili a zadas pelo Registro .br (http://registro.br). O procedimento de atualizacao 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 informacoes detalhadas sobre como efetuar essa atualizacao. Para domnios registrados no Brasil, informacoes sobre como atualizar os contatos est o disponveis em http://registro.br/faq/faq2.html. a 20

4.6

Eliminacao de Protocolos sem Criptograa

Uma medida de seguranca muito importante na operacao de redes e a substituicao de protocolos onde n o haja autenticacao atrav s de senhas, ou onde senhas trafeguem em claro, por outros que corrijam estas a e deci ncias. A lista de protocolos cuja utilizacao deve ser evitada na medida do possvel inclui: e Telnet; FTP; POP3; IMAP; rlogin; rsh; rexec. A maioria dos protocolos citados pode ser substituda pelo SSH.5 Essa substituicao, al m de fazer com e que o tr fego entre cliente e servidor passe a ser criptografado, traz ainda outras vantagens, como protecao da a sess o contra ataques tipo man-in-the-middle e seq estro de conex es TCP. a u o Em relacao ao POP3, existem diversas possibilidades de substituicao: 1. Usar uma das variantes do protocolo (APOP, KPOP, RPOP) que tornam a autenticacao de usu rios mais a segura, pois eliminam o tr fego de senhas em claro. As desvantagens desta opcao s o que nem todos a a os clientes de email suportam estas variantes e o conte do dos emails (que pode conter informacoes u sensveis) n o e criptografado. a 2. Usar POP3 atrav s de um t nel SSH ou SSL. A primeira opcao e interessante quando o servidor POP3 e u e o servidor SSH residem na mesma m quina. Para a segunda, podem ser usadas ferramentas como a o stunnel (http://stunnel.mirt.net). Alguns clientes de email j suportam SSL diretamente, n o a a sendo necess rio o uso de t neis. a u 3. Usar uma solucao de Webmail sobre HTTPS (HTTP+SSL). Esta solucao tamb m e v lida para o IMAP. e a

4.7

Cuidados com Redes Reservadas

Existem alguns blocos de enderecos IP que s o reservados pelo IANA (Internet Assigned Numbers Au a thority) para prop sitos especcos. N o existe um documento unico que registre todos estes blocos; alguns o a est o documentados em RFCs, enquanto que outros s o considerados reservados por raz es de compatibilidaa a o de hist rica. A lista atual de redes reservadas conhecidas e mostrada na tabela 1, juntamente com um breve o coment rio sobre a nalidade cada rede. a Enderecos pertencentes a estes blocos n o devem ser propagados atrav s da Internet, devendo ser ltrados a e no permetro da sua rede, tanto para entrada quanto para sada.
5 Implementacoes

de SSH para diversos sistemas operacionais est o disponveis em http://www.openssh.com. a

21

Rede 0.0.0.0/8 127.0.0.0/8 192.0.2.0/24 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 169.254.0.0/16 192.88.99.0/24 224.0.0.0/4 240.0.0.0/5

Coment rio a usada por sistemas antigos para broadcast loopback TEST-NET; usada para exemplos em documentacao usada em redes privadas (RFC 1918) usada em redes privadas (RFC 1918) usada em redes privadas (RFC 1918) usada para autoconguracao (est relacionada ao protocolo DHCP) a usada com IPv6 (vide RFC 3068) classe D classe E Tabela 1: Lista de redes reservadas pelo IANA

Caso voc possua redes privadas com IPs reservados, certique-se de que os enderecos utilizados sejam os e 6 (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16). especicados na RFC 1918 Enderecos reservados n o devem estar associados a nomes em servidores DNS p blicos. Se voc utiliz -los a u e a em redes privadas e quiser usar nomes para as m quinas, congure um servidor DNS privado ou utilize tabelas a de hosts (/etc/hosts ou C:\WINDOWS\HOSTS). Caso voc detecte um ataque proveniente de uma das redes da tabela 1 e estes enderecos estiverem sendo e ltrados no permetro, os pacotes correspondentes s podem ter partido de dentro da sua pr pria rede. A causa o o mais freq ente para isso e a exist ncia de erros de conguracao que fazem com que os enderecos reservados u e 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 Restauracao de Sistemas

A import ncia dos backups na administracao de sistemas nunca pode ser minimizada. Sem eles, muitos a dados s o simplesmente irrecuper veis caso sejam perdidos devido a uma falha acidental ou a uma invas o. a a a Os backups devem fazer parte da rotina de operacao dos seus sistemas e seguir uma poltica determinada. O melhor e faz -los da forma mais automatizada possvel, de modo a reduzir o seu impacto sobre o trabalho e dos administradores e operadores de sistemas. A lista de itens cujo backup deve ser feito com freq encia inclui: u dados; arquivos de conguracao; logs. Um ponto que merece especial cuidado e o backup de bin rios (execut veis e bibliotecas), que geralmente a a deve ser evitado. Uma excecao a essa regra e uma c pia completa do sistema logo ap s a sua instalacao, o o antes que ele seja colocado em rede. Backups que incluem bin rios n o s o aconselh veis porque abrem a a a a a
6 Y. Rekhter et.al., Address Allocation for Private Internets, RFC 1918, February 1996. Disponvel em ftp://ftp.isi.edu/ in-notes/rfc1918.txt.

22

possibilidade de que eventuais Cavalos de Tr ia ou execut veis corrompidos sejam reinstalados na restauracao o a do sistema. Alguns cuidados devem ser tomados em relacao ao local onde s o guardados os backups: a o acesso ao local deve ser restrito, para evitar que pessoas n o autorizadas roubem ou destruam backups; a o local deve ser protegido contra agentes nocivos naturais (poeira, calor, umidade); se possvel, e aconselh vel que o local seja tamb m a prova de fogo. a e ` Os backups devem ser vericados logo ap s a sua geracao e, posteriormente, a intervalos regulares. Isto o possibilita a descoberta de defeitos em dispositivos e meios de armazenamento e pode evitar que dados sejam perdidos por problemas com backups que n o podem ser restaurados. a Algumas organizacoes providenciam meios para armazenar backups fora das suas instalacoes, como em cofres de bancos, por exemplo. Essa e uma boa maneira de garantir a disponibilidade dos backups em caso de problemas nas instalacoes. Entretanto, isso pode comprometer a condencialidade e integridade desses back ups. Uma possvel solucao e criptografar o backup e gerar um checksum (MD5 ou SHA-1, por exemplo) dele antes que seja entregue a pessoas de fora da organizacao. Uma vericacao do checksum antes da restauracao pode servir como prova de que o backup n o foi alterado desde que foi feito. a Quando for necess rio restaurar um sistema, isto deve ser feito com a m quina isolada da rede. Caso o a a sistema em quest o tenha sido comprometido, revise a sua conguracao ap s a restauracao para certicar-se de a o que n o tenha cado nenhuma porta de entrada previamente instalada pelo invasor. a

4.9

Como Manter-se Informado

Administradores envolvidos com a seguranca de redes e sistemas necessitam buscar informacoes de forma ` a se manterem atualizados em relacao a novas vulnerabilidades e correcoes de seguranca. Devido a sua natureza din mica, o principal meio de obtencao de tais informacoes e a pr pria Internet, atrav s de listas de discuss o a o e a por email e sites especializados. Os tipos mais indicados de listas de discuss o para um administrador incluem: a lista de an ncios de seguranca de fornecedores de software e hardware cujos produtos s o usados na sua u a rede; listas de administradores e/ou usu rios desses produtos; a lista de alertas de seguranca do CERT/CC.7 Destas, as listas de an ncios de seguranca de fornecedores e a lista de alertas do CERT/CC s o fortemente u a recomendadas a qualquer administrador. As listas destinadas a administradores e usu rios de produtos, por a sua vez, podem ajud -lo a conhecer melhor as ferramentas disponveis no seu ambiente computacional, muitas a vezes levando-o a descobrir formas mais ecientes de trabalhar com elas.8 Existem outras listas que s o indicadas para administradores que possuam alguma experi ncia e bons coa e nhecimentos de programacao. Essas listas costumam ter um alto tr fego e o conte do das suas discuss es a u o
7 Veja 8A

http://www.cert.org/contact_cert/certmaillist.html. secao 4.10 mostra alguns cuidados que devem ser tomados por quem utiliza listas de discuss o por email. a

23

e bastante t cnico, muitas vezes envolvendo o uso de conceitos avancados. A principal (e tamb m a mais e e conhecida) destas listas e a Bugtraq.9 A Web tamb m oferece boas fontes de informacoes atualizadas na area de seguranca, tais como: e http://www.cert.org/advisories/; http://www.cert.org/current/current_activity.html; http://online.securityfocus.com/; http://www.incidents.org/. IMPORTANTE: e recomend vel que voc tome cuidado com a proced ncia de informacoes relacionadas a e e com seguranca, procurando se restringir a fontes con veis. Existem diversos relatos de informacoes proposi a talmente erradas terem sido divulgadas com o objetivo de abrir brechas na seguranca da rede daqueles que as tenham seguido.

4.10

Precaucoes contra Engenharia Social

e Engenharia social e a t cnica (ou arte) de aproveitar-se da boa f de pessoas para obter informacoes que e possibilitem ou facilitem o acesso aos recursos computacionais de uma organizacao por parte de usu rios n o a a autorizados. Dentre as informacoes procuradas destacam-se as seguintes: senhas de acesso; topologia da rede; enderecos IP em uso; nomes de hosts em uso; listas de usu rios; a tipos e vers es de sistemas operacionais usados; o tipos e vers es de servicos de rede usados; o dados sigilosos sobre produtos e processos da organizacao. Existem diversas formas de se efetuar um ataque de engenharia social, mas todas elas t m em comum a e caracterstica de usarem basicamente psicologia e perspic cia para atingir os seus prop sitos. Atualmente, as a o mais populares s o: a usar telefone ou email para se fazer passar por uma pessoa (geralmente algu m da equipe de suporte e t cnico ou um superior da pessoa atacada) que precisa de determinadas informacoes para resolver um e suposto problema; aproveitar informacoes divulgadas em um f rum p blico da Internet (lista de discuss o por email, news o u a group, IRC) por um administrador ou usu rio que busca ajuda para resolver algum problema na rede; a
9 Veja

http://online.securityfocus.com/.

24

enviar programas maliciosos ou instrucoes especialmente preparadas para um administrador ou usu rio, a com o objetivo de abrir brechas na seguranca da rede ou coletar o m ximo de informacoes possvel sobre a ela (esta t cnica e particularmente ecaz quando a pessoa pede auxlio em algum f rum de discuss o e o a pela Internet); navegar por websites ou reposit rios FTP em busca de informacoes uteismuitas vezes e possvel eno contrar descricoes detalhadas da infra-estrutura computacional e/ou documentos que, por descuido ou esquecimento, n o foram removidos do servidor. a A principal maneira de se prevenir contra estes ataques e orientando os usu rios e administradores de redes a e sistemas sobre como agir nestas situacoes. A poltica de seguranca da organizacao (secao 2.1) desempenha um papel importante neste sentido, pois e nela que s o denidas as normas para protecao da informacao na a organizacao. Recomenda-se fortemente que os administradores tenham cuidado ao buscar ajuda em listas de discuss o e a outros f runs na Internet. Estes recursos podem ser valiosos na resolucao de problemas, mas tamb m podem o e ser usados por terceiros para coleta de informacoes. Procure reduzir a exposicao da sua rede em f runs p blicospor exemplo, use enderecos IP, nomes de o u hosts e usu rios hipot ticos, e tente n o revelar mais sobre a topologia da rede do que o estritamente necess rio a e a a para resolver um dado problema. Tome cuidado com orientacoes passadas por pessoas desconhecidas, e evite executar programas de origem obscura ou n o con veleles podem ser uma armadilha. a a

4.11

Uso Ecaz de Firewalls

Antes de apresentar t cnicas para aumentar a ec cia de rewalls, e importante denir o que um rewall e a e e o que ele n o e. Um rewall bem congurado e um instrumento importante para implantar a poltica a de seguranca da sua rede. Ele pode reduzir a informacao disponvel externamente sobre a sua rede, ou, em alguns casos, at mesmo barrar ataques a vulnerabilidades ainda n o divulgadas publicamente (e para as quais e a correcoes n o est o disponveis). a a Por outro lado, rewalls n o s o infalveis. A simples instalacao de um rewall n o garante que sua a a a rede esteja segura contra invasores. Um rewall n o pode ser a sua unica linha de defesa; ele e mais um a dentre os diversos mecanismos e procedimentos que aumentam a seguranca de uma rede. Outra limitacao 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 secao apresenta apenas alguns aspectos importantes da utilizacao de rewalls. Maiores informacoes podem ser obtidas em http://www.interhack.net/pubs/fwfaq/ e nas refer ncias do ap ndice A. e e

4.11.1 A Escolha de um Firewall Existem diversas solucoes de rewall disponveis no mercado. A escolha de uma delas est atrelada a fatores a como custo, recursos desejados e exibilidade, mas um ponto essencial e a familiaridade com a plataforma operacional do rewall. A maioria dos rewalls est disponvel para um conjunto reduzido de plataformas a 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 ncia. Por exemplo, se voc utiliza basicamente servidores UNIX, e e e 25

aconselh vel que voc escolha um rewall que rode sobre a sua variante favorita de UNIX, e n o um produto a e a que requeira Windows NT. Existem, basicamente, duas raz es para esta recomendacao. A primeira delas e que voc deve estar fao e miliarizado o suciente com o sistema onde o rewall ser executado para congur -lo de forma segura. A a a exist ncia de um rewall instalado em um sistema inseguro pode ser at mais perigosa do que a aus ncia do e e e rewall na rede. A segunda raz o e que os produtos tendem a seguir a losoa da plataforma onde rodam; por a exemplo, a maioria dos rewalls para Windows e congurada atrav s de menus e janelas, ao passo que muitos e rewalls para UNIX s o congurados por meio de arquivos texto. a Administradores experientes em UNIX t m a disposicao diversas ferramentas de software livre que podem e ` 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 o modestos. a Ferramenta
ipchains iptables ipfw pf iplter TIS Firewall Toolkit Squid

Plataforma Linux Linux FreeBSD OpenBSD v rios UNIX a v rios UNIX a v rios UNIX a

Caracterstica ltro de pacotes (stateless) ltro de pacotes (stateful) ltro de pacotes (stateful) ltro de pacotes (stateful) ltro de pacotes (stateful) proxy para v rios protocolos a proxy Web/FTP

Tabela 2: Ferramentas de software livre para a construcao de rewalls

4.11.2

Localizacao dos Firewalls

A localizacao 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 fego deve passar pelo rewall. Um rewall s pode atuar sobre o tr fego que passa por ele. a o a A ec cia de um rewall pode ser severamente comprometida se existirem rotas alternativas para dentro a da rede (modens, por exemplo). Caso n o seja possvel eliminar todas esses caminhos, eles devem ser a documentados e fortemente vigiados atrav s de outros mecanismos de seguranca. e 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 prio roteador, se ele tiver esta capacidade e voc se sentir o e confort vel utilizando-o para esta tarefa. O ltro de pacotes de borda e importante para tarefas como a bloqueio global de alguns tipos de tr fego (vide secao 4.11.3) e bloqueio r pido de servicos durante a a a implantacao de correcoes ap s a descoberta de uma nova vulnerabilidade. o Coloque os servidores externos em uma DMZ. E recomend vel que voc coloque os seus servidores a e acessveis externamente (Web, FTP, correio eletr nico, etc.) em um segmento de rede separado e com o acesso altamente restrito, conhecido como DMZ (DeMilitarized Zone, ou zona desmilitarizada). A prin cipal import ncia disso e proteger a rede interna contra ataques provenientes dos servidores externos a uma precaucao contra a eventualidade de que um destes servidores seja comprometido. Por exemplo, suponha que um atacante invada o servidor Web e instale um sniffer na rede. Se este servidor Web estiver na rede interna, a probabilidade dele conseguir capturar dados importantes (tais como senhas ou informacoes condenciais) e muito maior do que se ele estiver em uma rede isolada. 26

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 administracao nanceira. Nestes casos, recomenda-se o uso de rewalls internos para isolar estas sub-redes umas das outras, com o prop sito de aumentar a protecao dos sistemas internos e conter o a propagacao de ataques bem-sucedidos.

4.11.3

Crit rios de Filtragem e

Existem basicamente dois crit rios de ltragem que podem ser empregados em rewalls. O primeiro e o e de default deny, ou seja, todo o tr fego que n o for explicitamente permitido e bloqueado. O segundo, default a a allow, e o contr rio, ou seja, todo o tr fego que n o for explicitamente proibido e liberado. a a a A conguracao dos rewalls deve seguir a poltica de seguranca da rede. Se a poltica permitir, e reco mend vel adotar uma postura de default deny. Esta abordagem e, geralmente, mais segura, pois requer uma a intervencao explcita do administrador para liberar o tr fego desejado, o que minimiza o impacto de eventuais a erros de conguracao na seguranca da rede. Al m disso, ela tende a simplicar a conguracao dos rewalls. e No permetro da rede, pelo menos as seguintes categorias de tr fego devem ser ltradas: a tr fego de entrada (ingress ltering): pacotes com endereco de origem pertencente a uma rede reservada a (secao 4.7) ou a um dos blocos de enderecos da sua rede interna; tr fego de sada (egress ltering): pacotes com endereco de origem pertencente a uma rede reservada ou a que n o faca parte de um dos blocos de enderecos da rede interna. a O tr fego para a DMZ deve ser altamente controlado. As unicas conex es permitidas para os sistemas a o dentro da DMZ devem ser as relativas aos servicos p blicos (acessveis externamente). Conex es partindo u o da DMZ para a rede interna devem ser, na sua maioria, tratadas como conex es oriundas da rede externa, o aplicando-se a poltica de ltragem correspondente.
IMPORTANTE: a DMZ e a rede interna n o podem estar no mesmo segmento de rede (ligadas ao mesmo a 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 implantacao de rewalls em uma rede. A opcao por uma delas obedece a uma s rie de fatores, incluindo a estrutura l gica da rede a ser protegida, custo, funcionalidades e o pretendidas e requisitos tecnol gicos dos rewalls. o Esta secao apresenta duas destas arquiteturas. A intencao n o e cobrir todas as possibilidades de uso de a rewalls, mas fornecer exemplos de arquiteturas que funcionam e que podem eventualmente ser adotados (na sua forma original ou ap s passarem por adaptacoes) em situacoes reais. o A gura 3 mostra um exemplo simples de uso de rewall. Neste exemplo, o rewall possui tr s interfaces de e 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 o for explicitamente permitido (default deny). Al m disso, o rewall usado e do tipo stateful, a e que gera dinamicamente regras que permitam a entrada de respostas das conex es iniciadas na rede interna; o portanto, n o e preciso incluir na conguracao do rewall regras de entrada para estas respostas. a O tr fego liberado no exemplo da gura 3 e o seguinte: a 27

Internet

WWW

DMZ FW DNS

SMTP

Rede Interna

Figura 3: Um exemplo simples de rewall interface externa: sada: tudo com excecao de pacotes com enderecos de origem pertencentes a redes reservadas; pacotes com enderecos de origem n o pertencentes aos blocos da rede interna. a ` entrada: apenas os pacotes que obedecem as seguintes combinacoes 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: sada: portas 25/TCP (SMTP), 53/UDP e 53/TCP (DNS) e 113 (IDENT); entrada: al m das mesmas regras de entrada da interface externa, tamb m e permitido o tr fego para e e a 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 situacao mais complexa do que a anterior. Neste segundo exemplo, al m dos servidores externos na DMZ, h tamb m servidores na intranet e no setor nanceiro da e a e ` organizacao. Devido a import ncia das informacoes mantidas neste setor, a sua rede conta com a protecao a ` adicional de um rewall interno, cujo objetivo principal e evitar que usu rios com acesso a rede interna da a organizacao (mas n o a rede do setor nanceiro) possam comprometer a integridade e/ou o sigilo dessas a ` informacoes. 28

Internet
WWW

DMZ FW DNS

Setor Financeiro SMTP WWW FW Intranet DNS

SMTP

Rede Interna

Figura 4: Um exemplo mais complexo de rewall

29

A conguracao do rewall externo neste segundo exemplo e quase id ntica ao primeiro. Entretanto, no e presente caso sup e-se que o servidor SMTP visvel externamente (o da DMZ) repassa as mensagens recebidas o para o servidor SMTP da intranet. Para que isso seja possvel, e necess rio mudar a regra de ltragem para a a interface interna, liberando o tr fego do servidor SMTP da DMZ para a porta 25/TCP do servidor SMTP da a intranet. A conguracao 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 rios da organizacao possam consultar seus contrachea ques; outros tipos de acesso n o s o permitidos. O tr fego liberado por este rewall e o seguinte: a a a interface externa (rede interna): 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).

30

A
A.1

Refer ncias Adicionais e


URLs de Interesse

CERT Security Improvement Modules: Security Knowledge in Practice. http://www.cert.org/ security-improvement/skip.html. Apresenta, de forma gr ca, os passos que est o envolvidos na obtencao de uma rede mais a a segura. Cont m uma grande quantidade de material que aborda de forma mais aprofundada e v rios dos assuntos discutidos neste documento. a Security Links. http://www.nic.br/links.html. Uma compilacao de URLs sobre diversos aspectos de administracao e seguranca de redes e sistemas, incluindo diversos apresentados neste documento, e que e atualizada periodicamente.

A.2

Livros

Nelson Murilo de O. Runo. Seguranca Nacional. Novatec, 2001. Uma boa refer ncia sobre seguranca computacional em portugu s, com enfoque em aspectos e e pr ticos. a 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 tico, e numerosos exemplos a (usando tcpdump) ajudam a compreender o funcionamento dos protocolos na pr tica. a 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 ncia e obrigat ria em seguranca de sistemas UNIX. o 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 informacoes pr ticas sobre a como constru-los. Evi Nemeth, Garth Snyder, Scott Seebass e Trent R. Hein. UNIX System Administration Handbook, 3rd Edition. Prentice Hall, 2001. O cl ssico sobre administracao de sistemas UNIX, recentemente atualizado. Traz explicacoes a 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. 31

Um bom livro sobre seguranca de Windows NT, incluindo instalacao, conguracao, 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 ticos. Os a 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 m v rios e a exemplos extrados de polticas reais, que podem ser usados como guia para a formulacao de novas polticas. S rie OReilly sobre administracao de servicos de rede e sistemas operacionais especcos. http:// e www.oreilly.com. A editora OReilly e conhecida pela qualidade t cnica dos seus livros, que geralmente abore dam um assunto especco com bastante profundidade e com um enfoque bem pr tico. Exis a tem guias para servidores como Apache (Web), BIND (DNS) e Sendmail (SMTP), al m de e diversos ttulos sobre uso e administracao de sistemas operacionais (incluindo UNIX, Linux e Windows).

32

Indice Remissivo
A abuso de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 conseq encias. . . . . . . . . . . . . . . . . . . . . . . . . . .13 u implicacoes legais . . . . . . . . . . . . . . . . . . . . . . . 13 administradores equipe . . . . . . . veja equipes de administradores Administrator . . . . . . . . . . . veja contas privilegiadas an lise de riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 a AUP . . . . . . . . . . . . . . . veja poltica de uso aceit vel a B backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2223 armazenamento . . . . . . . . . . . . . . . . . . . . . . . . . 23 bin rios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 a checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 itens importantes . . . . . . . . . . . . . . . . . . . . . . . . 22 logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 off-site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 particoes individuais . . . . . . . . . . . . . . . . . . . . . . 8 polticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 restauracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 vericacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 C Charles B. Rutstein . . . . . . . . . . . . . . . . . . . . . . . . . . 31 conguracao controle de alteracoes . . . . . . . . . . . . . . . . . . . . 16 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 20 documentacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 proxy Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 revis o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 a servidores SMTP . . . . . . . . . . . . . . . . . . . . 14, 19 conta Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . 16 conta root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 contas privilegiadas . . . . . . . . . . . . . . . . . . . . . . . . . . 16 contatos . . . . . . . . . . . . . veja informacoes de contato correcoes de seguranca precaucoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 correcoes de seguranca . . . . . . . . . . . . . . . . . . . . . . . 13 periodicidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 reposit rio local . . . . . . . . . . . . . . . . . . . . . . . . . 13 o D D. Brent Chapman . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 di rio de bordo . . . . . . . . . . . . . . . . . . . . veja logbook a DNS contato no SOA . . . . . . . . . . . . . . . . . . . . . . . . . 20 exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 problemas de conguracao . . . . . . . . . . . . . . . 19 reverso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 atualizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 servidor privado . . . . . . . . . . . . . . . . . . . . . . . . . 22 E Elizabeth D. Zwicky . . . . . . . . . . . . . . . . . . . . . . . . . 31 enderecos reservados . . . . . . . veja redes reservadas endereco reverso . . . . . . . . . . . . . . . . . . . . . . veja DNS enderecos eletr nicos padr o . veja informacoes de o a contato engenharia social . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 formas de ataque . . . . . . . . . . . . . . . . . . . . . . . . 24 prevencao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 equipes de administradores . . . . . . . . . . . . . . . . . . . 15 comunicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 contas privilegiadas . . . . . . . . . . . . . . . . . . . . . . 16 listas de discuss o . . . . . . . . . . . . . . . . . . . . . . . 15 a vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Evi Nemeth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 F ferramentas CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 rewalls de software livre . . . . . . . . . . . . . . . . 26 OpenSSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 RCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 stunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 sudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 swatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 rewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2530 crit rios de escolha . . . . . . . . . . . . . . . . . . . . . . 25 e crit rios de ltragem . . . . . . . . . . . . . . . . . . . . . 27 e default allow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 default deny . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26, 27 ingress ltering . . . . . . . . . . . . . . . . . . . . . . . . . 27 exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2730 ferramentas de software livre . . . . . . . . . . . . . 26 ltragem de permetro . . . . . . . . . . . . . . . . . . . 26 ingress ltering . . . . . . . . . . . . . . . . . . . . . . . . . 27 internos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26, 28 limitacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 localizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 33

servicos n o utilizados . . . . . . . . . . . . . . . . . . . 12 a zona desmilitarizada . . . . . . . . . . . . . . . . . . . . . 26 xes . . . . . . . . . . . . . . . . . veja correcoes de seguranca FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 fuso hor rio . . . . . . . . . . . . . . . . . . . . . . . veja timezone a G Garth Snyder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Gene Spafford . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 H hor rio de ver o . . . . . . . . . . . . . . . . . . . veja timezone a a I IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 informacoes de contato aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 WHOIS atualizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 informacoes de contato . . . . . . . . . . . . . . . . . . . . . . . 19 endereco abuse . . . . . . . . . . . . . . . . . . . . . . . . . 19 endereco security . . . . . . . . . . . . . . . . . . . . . . 19 monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . 19 RFC 2142 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 SOA do DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 WHOIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 tipos de contato . . . . . . . . . . . . . . . . . . . . . . . 20 instalacao de correcoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 de pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 desativacao de servicos . . . . . . . . . . . . . . . . . . 12 documentacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 mnima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 personalizada . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 preparacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 IPs reservados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 L listas de discuss o a alertas de seguranca . . . . . . . . . . . . . . . . . . . . . 23 Bugtraq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 cuidados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24, 25 internas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 para manter-se informado . . . . . . . . . . . . . . . . 23 logbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911 cuidados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 34

formato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 informacoes essenciais . . . . . . . . . . . . . . . . . . . . 9 uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12, 13, 16 logs armazenamento off-line . . . . . . . . . . . . . . . . . . 17 armazenamento on-line . . . . . . . . . . . . . . . . . . 17 riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 geracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16, 17 import ncia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 a integridade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 loghosts centralizados . . . . . . . . . . . . . . . . . . . . 17 monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . 18 eventos anormais . . . . . . . . . . . . . . . . . . . . . . 18 timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 perodo de armazenamento . . . . . . . . . . . . . . . 18 rel gio sincronizado . . . . . . . . . . . . . . . . . . . . . 17 o rotacao autom tica . . . . . . . . . . . . . . . . . . . . . . 17 a N Nelson Murilo de O. Runo . . . . . . . . . . . . . . . . . . 31 NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 ajuste mais preciso . . . . . . . . . . . . . . . . . . . . . . 15 reducao de tr fego . . . . . . . . . . . . . . . . . . . . . . . 15 a servidor local . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 P particionamento de disco . . . . . . . . . . . . . . . . . . . . . . 7 vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 patches . . . . . . . . . . . . . . veja correcoes de seguranca poltica an lise de riscos . . . . . . . . . . . . . . . . . . . . . . . . . . 4 a backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 de seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 de senhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 de uso aceit vel . . . . . . . . . . . . . . . . . . . . . . . . . . 6 a polticas fatores de sucesso . . . . . . . . . . . . . . . . . . . . . . . . 5 inu ncias negativas . . . . . . . . . . . . . . . . . . . . . . 5 e POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 pornograa envolvendo criancas . . . . . . . . . . . . . . 13 protocolos sem criptograa . . . . . . . . . . . . . . . . . . . 21 proxy Web formas de abuso . . . . . . . . . . . . . . . . . . . . . . . . . 14 proxy Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 R redes privadas (RFC 1918) . . . . . . . . . . . . . . . . . . . 21

redes reservadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 ltragem de enderecos . . . . . . . . . . . . . . . . . . . 21 lista atual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 vazamento de enderecos . . . . . . . . . . . . . . . . . 22 refer ncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 e Registro .br . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 relay aberto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 roaming users . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 rel gio o fuso hor rio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 a hor rio de ver o . . . . . . . . . . . . . . . . . . . . . . . . . 15 a a sincronizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 restauracao de backups . . . . . . . . . . . . . . . . . . . . . . . 23 rexec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 RFC 1918 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 RFC 2142 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 rlogin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Roberta Bragg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 root . . . . . . . . . . . . . . . . . . . . veja contas privilegiadas rsh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 S Scott Barman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Scott Seebass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 senhas caractersticas desej veis . . . . . . . . . . . . . . . . . 11 a compartilhadas . . . . . . . . . . . . . . . . . . . . . . . . . . 16 de administrador . . . . . . . . . . . . . . . . . . . . . . . . 11 fortes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 poltica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 service packs . . . . . . . . . veja correcoes de seguranca servicos desativacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 divis o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 a n o utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 a servidores de tempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 20, 22 SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14, 19 Simon Cooper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Simson Garnkel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 SPAM relay aberto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 su . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

T Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Trent R. Hein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 V vulnerabilidades correcoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 exposicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 W W. Richard Stevens . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Web proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 sites sobre seguranca . . . . . . . . . . . . . . . . . . . . 24 webmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 WHOIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

35