Escolar Documentos
Profissional Documentos
Cultura Documentos
Politicas Seguranca
Politicas Seguranca
net
Polticas de Segurana
Neste documento h uma srie de referncias para polticas de segurana. Seguidamente, estas referncias
incluiro recomendaes para polticas especficas.
Introduo:
www.projetoderedes.kit.net
que sejam adequados aos requisitos propostos. Portanto, uma tentativa de utilizar um conjunto de
ferramentas de segurana na ausncia de pelo menos uma poltica de segurana implcita no faz sentido.
Uma poltica de uso apropriado (Appropriate - ou Acceptable - Use Policy - AUP) pode tambm ser parte
de uma poltica de segurana. Ela deveria expressar o que os usurios devem e no devem fazer em
relao aos diversos componentes do sistema, incluindo o tipo de trfego permitido nas redes. A AUP
deve ser to explcita quanto possvel para evitar ambiguidades ou maus entendimentos. Pr exemplo,
uma AUP pode lista newsgroups USENET proibidos.
www.projetoderedes.kit.net
4. Uma poltica de contabilidade que defina as responsabilidades dos usurios. Deve especificar a
capacidade de auditoria, e oferecer a conduta no caso de incidentes (pr exemplo, o que fazer e a
quem contactar se for detectada uma possvel intromisso.
5. Uma poltica de autenticao que estabelea confiana atravs de uma poltica de senhas efetiva,
e atravs da linha de conduta para autenticao de acessos remotos e o uso de dispositivos de
autenticao.
6. Um documento de disponibilidade que define as expectativas dos usurios para a disponibilidade
de recursos. Ele deve enderear aspectos como redundncia e recuperao, bem como especificar
horrios de operao e de manuteno. Ele tambm deve incluir informaes para contato para
relatar falhas de sistema e de rede.
7. Um sistema de tecnologia de informao e poltica de manuteno de rede que descreva como
tanto o pessoal de manuteno interno como externo devem manipular e acessar a tecnologia. Um
tpico importante a ser tratado aqui como a manuteno remota permitida e como tal acesso
controlado. Outra rea para considerar aqui a terceirizao e como ele gerenciada.
8. Uma poltica de relatrio de violaes que indique quais os tipos de violaes devem ser
relatados e a quem estes relatos devem ser feitos. Uma atmosfera de no ameaa e a possibilidade
de denncias annimas ir resultar uma grande probabilidade que uma violao seja relatada.
9. Suporte a informao que oferea aos usurios informaes para contato para cada tipo de
violao; linha de conduta sobre como gerenciar consultas externas sobre um incidente de
segurana, ou informao que seja considerada confidencial ou proprietria; referncias cruzadas
para procedimentos de segurana e informaes relacionadas, tais como as polticas da
companhia e leis e regulamentaes governamentais.
Pode haver requisitos regulatrios que afetem alguns aspectos de sua poltica de segurana (como a
monitorao). Os criadores da poltica de segurana devem considerar a busca de assistncia legal na
criao da mesma. No mnimo, a poltica deve ser revisada pr um conselho legal.
Uma vez que a poltica tenha sido estabelecida ela deve ser claramente comunicada aos usurios, pessoal
e gerentes. Deve-se criar um documento que os usurios assinem, dizendo que leram, entenderam e
concordaram com a poltica estabelecida. Esta uma parte importante do processo. Finalmente sua
poltica deve ser revisada regularmente para verificar se ela est suportando com sucesso suas
necessidades de segurana.
www.projetoderedes.kit.net
3. Arquitetura
3.1 Objetivos
3.1.1 Planos de Segurana Completamente Definidos
Todos os sites devem definir um amplo plano de segurana, que deve ser de mais alto nvel que as
polticas discutidas no captulo 2, e deve ser projetado como um framework de objetivos amplos nos quais
polticas especficas se enquadraro.
importante ter esse framework de tal maneira que polticas individuais possam ser consistentes dentro
de todo o contexto da arquitetura de segurana do site. Pr exemplo, ter uma poltica forte em relao ao
acesso pela Internet e ter baixas restries no uso do modem inconsistente dentro de uma filosofia de
fortes restries no que diz respeito ao acesso externo.
Um plano de segurana deve definir: a lista de servios de rede que sero providos; quais reas da
organizao provero os servios; quem ter acesso aos servios; como o acesso ser provido; quem
administrar esses servios; etc.
O plano tambm deve indicar como incidentes sero tratados. Captulo 5 prov uma discusso profunda
neste tpico, mas importante que cada site defina classes de incidentes e reaes correspondentes. Pr
exemplo, sites com firewalls devem setar um nmero de tentativas de ataque suportado antes de tomar
uma ao? Nveis de ao devem ser definidos para todos os ataques e respostas. Sites com firewalls
devem determinar se uma simples tentativa de conexo a um host constitui um incidente ou no. E em
relao procura sistemtica de sistemas?
Para sites conectados Internet, o nmero significativo de incidentes relatados em relao segurana
pode se fazer esquecer dos incidentes internos rede. Da mesma maneira, organizaes no conectadas
Internet devem ter planos fortes e bem definidos de poltica de segurana interna.
www.projetoderedes.kit.net
A primeira opo retirar todos os servios e ento habilit-los seletivamente, considerando-os caso a
caso. Isto pode ser feito no nvel de host ou rede, o mais apropriado. Este modelo, referenciando como
"bloquear tudo", geralmente mais seguro do que o outro, descrito no prximo pargrafo. Porm, a
configurao requer mais trabalho e compreenso dos servios. Permitir somente servios conhecidos
para uma melhor anlise de um particular servio/protocolo e o projeto de um mecanismo de segurana
cabem no nvel de segurana do site.
O outro modelo, referenciado como "permitir tudo", mais fcil de implementar, mas geralmente menos
seguro que o outro. Simplesmente ligar todos os servios (a nvel de host) e permitir a todos os protocolos
que trafeguem na rede (a nvel de roteador). Como os buracos de segurana ficam aparentes, eles so
restritos aos nveis de host e rede.
Cada um dos modelos pode ser aplicado a diferentes pores do site, dependendo dos requerimentos das
funcionalidades, do controle administrativo, da poltica de segurana, etc. Pr exemplo, a poltica pode
ser usar "permitir tudo" quando se trata de estaes de uso geral, mas "bloquear tudo" quando se trata de
servidores de informaes, como servidores de email. Da mesma forma, "permitir tudo" pode ser
empregado no trfego entre subredes internas, mas "bloquear tudo" pode ser adotado na comunicao
com a Internet.
Deve-se tomar cuidados quando se mistura as duas filosofias. Tomar cuidado somente com usurios
externos pode no ser a melhor filosofia, pois usurios internos rede podem no ser confiveis. E a
partir do momento que um usurio externo entra na rede (passando pr um firewall) ele tem acesso a
tudo, pois no h isolamento interno.
www.projetoderedes.kit.net
www.projetoderedes.kit.net
firewalls conectando estes conjuntos. Um grande cuidado deve-se tomar a fim de garantir o
funcionamento correto da firewall.
H um grande interesse em se usar intranets na conexo com diferentes partes da organizao (divises da
companhia). Enquanto este documento diferencia rede interna de rede externa (privada e pblica), sites
com intranets devem estar atentos que eles precisaro considerar 3 separaes e tomar aes apropriadas
quando projetando e oferecendo servios. Um servio provido a uma intranet no deve se tornar pblico,
nem completamente privado como um servio de uma sub-unidade da organizao. Entretanto, o servio
pode precisar de um suporte prprio, separadamente tanto dos servios e rede internos e externos.
Uma forma de servio externo que merece uma ateno especial o acesso annimo, ou guest. Ele pode
ser tanto pr FTP ou pr login guest (no autenticado). importante manter esses acessos isolados de
hosts e sistemas de arquivos que no devem ser vistos pr usurios externos. Outro cuidado especial diz
respeito ao acesso annimo com permisso de escrita. Um site deve ser legalmente responsvel pela
informao pr ele tornada pblica, portanto informaes colocadas pr annimos devem ser
monitoradas.
Agora iremos considerar alguns dos mais populares servios: servidor de nomes, servidor de senhas,
servidor de proxy/autenticao, correio eletrnico, WWW, transferncia de arquivos e NFS. Considerando
que so os servios mais freqentemente usados, so os principais alvos de ataques. E um ataque em um
destes servios pode produzir um desastre alm das propores do servio bsico.
3.3 Firewalls
Uma das medidas de segurana mais amplamente empregada e publicada em uso na Internet um
"firewall". Firewalls tem sido determinados a reputao de uma panacia geral para muitas, seno todas,
questes de segurana da Internet. Eles no so. Firewalls so apenas outra ferramenta em questo para
segurana de sistema. Eles fornecem um certo nvel de proteo e so, em geral, uma maneira de
implementar a poltica de segurana no nvel de rede. O nvel de segurana que um firewall fornece pode
variar tanto quanto o nvel de segurana em uma mquina particular. Existe o tradicional "trade-off" entre
segurana, facilidade de uso, custo, complexidade, etc.
Um firewall qualquer um dos vrios mecanismos usados para controlar e observar o acesso de e para
uma rede com a finalidade de proteg-la. Um firewall atua como um gateway atravs do qual todo o
trfego de e para a rede ou sistemas protegidos passa. Firewalls ajudam a colocar limitaes na
quantidade e tipo de comunicao que ocorre entre a rede protegida e a outra rede (pr exemplo, a
Internet, ou outra parte da rede de um site).
Um firewall geralmente uma maneira de construir uma parede entre uma parte de uma rede, uma rede
interna de uma empresa, pr exemplo, e outra parte, a Internet global, pr exemplo. A nica caracterstica
sobre esta parede que precisam existir maneiras para algum trfego com caractersticas particulares
passarem atravs de portas cuidadosamente monitoradas ("gateways"). A parte difcil estabelecer o
critrio pelo qual os pacotes so permitidos ou negados acesso pelas portas. Livros escritos sobre firewall
usam terminologia diferente para descrever as vrias formas de firewalls. Isto pode ser confuso para
administradores de sistemas que no so familiares com firewalls. O ponto a observar aqui que no
existe nenhuma terminologia fixa para a descrio de firewalls.
Firewalls no so sempre, ou mesmo tipicamente, uma nica mquina. Preferivelmente, firewalls so
freqentemente uma combinao de roteadores, segmentos de rede, e computadores host. Portanto, para o
propsito desta discusso, o termo "firewall" pode consistir em mais de um dispositivo fsico. Firewalls
so tipicamente construdos usando dois diferentes componentes, roteadores de filtragem e servidores
proxy.
Roteadores de filtragem so o componente mais fcil de conceituar em um firewall. Um roteador move
dados de um lado para outro entre duas (ou mais) redes diferentes. Um roteador "normal" pega um pacote
da rede A e encaminha-o para seu destino na rede B. Um roteador de filtragem faz a mesma coisa mas
7
www.projetoderedes.kit.net
decide no apenas como rotear o pacote mas se deveria rotear o pacote. Isto feito instalando uma srie
de filtros pelos quais o roteador decide o que fazer com qualquer pacote de dados.
Uma discusso referente a capacidades de uma marca particular de roteador, executando uma verso de
software especfica est fora do escopo deste documento. Porm, quando avaliando um roteador para ser
usado para filtragem de pacotes , o seguinte critrio pode ser importante quando da implementao de
uma poltica de filtragem: endereo IP origem e destino, nmeros de porta TCP origem e destino, estado
do bit "ACK" no pacote TCP, nmeros de porta UDP origem e destino, e direo do fluxo de pacotes (i.e.,
A->B ou B->A). Outra informao necessria para construir um esquema de filtragem seguro se o
roteador reordena instrues de filtro (projetada para otimizar filtros, isto algumas vezes pode mudar o
significado e causar acesso no pretendido), e se possvel aplicar filtros para pacotes que chegam e que
saem em cada interface (se o roteador filtra somente pacotes que saem ento o roteador externo aos seus
filtros e pode ser mais vulnervel para atacar). Alm do roteador ser vulnervel, esta distino entre
aplicar filtros em pacotes que chegam ou que saem especialmente relevante para roteadores com mais
de duas interfaces. Outras questes importantes so a capacidade de criar filtros baseado nas opes do
cabealho IP e o fragmento de estado do pacote. Construir um bom filtro pode ser muito difcil e requer
um bom entendimento do tipo de servios (protocolos) que sero filtrados.
Para melhor segurana, os filtros geralmente restringem acesso entre as duas redes conectadas a apenas
um host, o bastion host. S possvel ter acesso para a outra rede atravs deste bastion host. Como
somente este host, em lugar de algumas centenas de hosts, pode ser atacado, mais fcil manter um certo
nvel de segurana pois somente este host tem que ser muito cuidadosamente protegido. Para tornar
disponvel recursos para legitimar usurios atravs deste firewall, servios tem que ser passados adiante
pelo bastion host. Alguns servidores tem esta capacidade embutida (como servidores DNS ou servidores
SMTP), para outros servios (pr exemplo, Telnet, FTP, etc.), servidores proxy podem ser usados para
permitir acesso aos recursos atravs do firewall de modo seguro.
Um servidor proxy um modo para concentrar servios de aplicao atravs de uma nica mquina.
Tipicamente existe uma nica mquina (o bastion host) que atua como um servidor proxy para uma
variedade de protocolos (Telnet, SMTP, TFP, HTTP, etc.) mas podem existir computadores host
individuais para cada servio. Ao invs de conectar diretamente um servidor externo, o cliente conecta
para o servidor proxy que em troca inicia uma conexo para o servidor externo solicitado. Dependendo do
tipo de servidor proxy usado, possvel configurar clientes internos para realizar este redirecionamento
automaticamente, sem conhecimento para o usurio, outros podem requerer que o usurio conecte
diretamente para o servidor proxy e ento iniciar a conexo atravs de um formato especfico.
Existem significantes benefcios de segurana que podem ser obtidos pelo uso de servidores proxy.
possvel adicionar listas de controle de acesso para protocolos, exigir que usurios ou sistemas forneam
algum nvel de autenticao antes do acesso ser concedido. Servidores proxy mais espertos, algumas
vezes chamados Gateways da Camada de Aplicao, podem ser escritos de modo que entendam
protocolos especficos e podem ser configurados para bloquear somente subsees do protocolo. Pr
exemplo, um Gateway de Aplicao para FTP pode reconhecer a diferena entre o comando "put" e o
comando "get"; uma organizao pode desejar permitir aos usurios realizar "get" de arquivos da Internet,
mas no permitir "put" de arquivos internos no servidor remoto. Em contraste, um roteador de filtragem
poderia ou bloquear todo acesso ao FTP, ou no, mas no um subconjunto.
Servidores proxy tambm podem ser configurados para encriptar fluxos de dados baseado em uma
variedade de parmetros. Uma organizao pode usar esta caracterstica para permitir conexes
encriptadas entre duas localizaes cujos nicos pontos de acesso esto na Internet.
Firewalls so pensados como uma maneira de manter intrusos do lado de fora, mas eles so usados
geralmente como uma maneira de legitimar usurios em um site. Existem muitos exemplos onde um
usurio vlido poderia precisar acessar regularmente o site "home" durante viagens para apresentaes e
conferncias, etc. Acesso Internet geralmente disponvel mas pode ser atravs de uma mquina ou rede
no confivel. Um servidor proxy configurado corretamente pode permitir os usurios corretos no site
enquanto bloqueia acesso para outros usurios.
8
www.projetoderedes.kit.net
O maior esforo atual em tcnicas de firewall encontrar uma combinao de um par de roteadores de
filtragem com um ou mais servidores proxy na rede entre os dois roteadores. Esta configurao permite
ao roteador externo bloquear qualquer tentativa de usar a camada IP subjacente para quebrar a segurana
(IP spoofing, roteamento pela origem, fragmentos de pacotes), enquanto permite ao servidor proxy tratar
potenciais furos de segurana nos protocolo das camadas superiores. A finalidade do roteador interno
bloquear todo trfego exceto para o servidor proxy. Se esta configurao implementada rigorosamente,
pode ser obtido um alto nvel de segurana.
Muitos firewalls fornecem capacidade de log que pode ser adequado para fazer administrao mais
conveniente da segurana da rede. A funo de log pode ser centralizada e o sistema pode ser configurado
para enviar alertas para condies anormais. importante monitorar regularmente estes logs para
qualquer sinal de intruses ou tentativas de arrombamento. Desde que alguns intrusos tentaro encobrir
seus ataques pela edio dos logs, desejvel proteger esses logs. Uma variedade de mtodos est
disponvel, incluindo: escreva uma vez, leia muitos (WORM) drives; logs em papel; e logs centralizados
atravs do utilitrio "syslog". Outra tcnica usar um impressora serial falsa, mas ter uma porta serial
conectada para uma mquina isolada ou PC que mantm os logs.
Firewalls esto disponveis em uma ampla faixa de qualidade e intensidade. Pacotes comerciais iniciam
em aproximadamente $10,000US e alcanam mais de $250,000US. Firewalls desenvolvidos pelo prprio
site podem ser construdos para quantias menores de capital. Deve-se lembrar que a configurao correta
de um firewall (comercial ou "caseiro") requer uma significante habilidade e conhecimento do TCP/IP.
Ambos os tipos requerem manuteno regular, instalao de patches de softwares e atualizaes, e
monitorao regular. Quando realiza-se o oramento de um firewall, estes custos adicionais deveriam ser
considerados alm do custo dos elementos fsicos do firewall.
Como um aparte, construir uma soluo "caseira" para um firewall requer significante habilidade e
conhecimento do TCP/IP. Isto no deveria ser tentado trivialmente pois a sensao de segurana
percebida pior ao longo da execuo do que saber que no existe nenhuma segurana. Como com todas
as medidas de segurana, importante decidir na ameaa, o valor do recurso a ser protegido, e os custos
para implementar segurana.
Uma nota final sobre firewalls. Eles podem ser uma grande ajuda quando implementando segurana para
um site e protegem contra uma grande variedade de ataques. Mas importante ter em mente que eles so
apenas uma parte da soluo. Eles no podem proteger seu site contra todos os tipos de ataque.
O que e como funciona o principal dispositivo de segurana na Internet.
Segurana ainda o ponto mais discutido na Internet, mas, em grande parte dos casos, a discusso se
resume a problemas como violao de correspondncia e dificuldades para se enviar nmero de carto de
credito. medida que a maior parte das empresas conecta suas redes privadas grande rede, entretanto, a
questo fundamental passa a ser como impedir que usurios no autorizados ganhem acesso livre a dados
sensveis. O principal meio de proteger as redes privadas so os chamados firewalls.
Um firewall um sistema ou grupo de sistemas atravs do qual flui o trafego de dados entre duas redes
distintas de computadores, permitindo que se implemente uma poltica de segurana que determine o que
pode ou no passar de uma rede para outra. A aplicao mais comum de um firewall proteger uma rede
contra acesso dos inmeros usurios mal-intencionados (chamados crackers) que povoam a Internet.
Mais especificamente, o firewall um dispositivo de hardware dotado de duas placas de rede (uma ligada
a rede corporativa e a outra ligada Internet) rodando software especifico de analise e roteamento de
pacotes. Como todo pacote enviado de uma rede a outra passa obrigatoriamente pelo sistema, o firewall
tem a chance de analis-lo, determinar se ele representa algum risco e, se for o caso, descart-lo antes que
ele possa alcanar seu destino.
Os critrios utilizados para decidir se determinado pacote de dados oferece ou no risco fazem parte a
poltica de segurana praticada pela entidade proprietria do firewall. Existem firewalls que operam na
camada de rede analisando pacotes IP e outros que operam na camada de aplicao analisando os
dados dentro dos pacotes IP. Alguns firewalls so to restritos que deixam passar apenas mensagens de
correio, enquanto outros so bem permissivos. Como seria de se esperar, quanto mais diligente e rigoroso
for o firewall, mais difcil ser penetrar um ataque e mais facial ser investig-lo posteriormente.
9
www.projetoderedes.kit.net
www.projetoderedes.kit.net
os pacotes) e ecoa os dados que vm da conexo x para a conexo y e vice-versa. O que importante
que todo pacote, antes de ser ecoado de uma conexo para a outra, analisado pelo proxy server um
programa para detectar abusos de segurana no protocolo utilizado naquela porta especfica - , que decide
se o pacote deve passar ou ser descartado. O resultado o firewall de aplicao consege detectar riscos
que um firewall de rede no teria como perceber, alcanando um nvel de segurana superior.
Um exemplo clssico do tipo de informao que um proxy pode filtrar o comando DEBUG do SMTP,
usado para solicitar a um servidor de correio que fornea certas informaes de controle e considerado
arriscado pela maior parte dos administradores de rede. Como no normal que esse tipo de comando
seja emitido durante uma troca de mensagens de correio, um bom proxy SMTP descartar o pacote como
o comando proibido, mudar o estado do firewall para "ataque em curso" e enviara uma mensagem (que
pode at seguir para um pager ou telefone celular) para o administrador, prevenindo-o do ocorrido.
Outro exemplo so proxies FTP, que podem vedar completamente o acesso de usurios externos s
maquinas da empresa ao mesmo tempo que permite que funcionrios copiem arquivos da Internet para a
rede interne (comando GET), mas no o contrrio (comando PUT). Todos esses exemplos esto ligados
ao funcionamento dos protocolos especficos de cada aplicao e no poderiam ser implementados em
firewalls de rede, que no so capazes de examinar o contedo dos pacote IP.
Firwalls de aplicao so bem menos transparentes do que firewalls e rede. Para comear, toda e qualquer
aplicao exige a existncia de um proxy; se o usurio precisa de uma aplicao para a qual no existe um
proxy rodando no firewall, no h o que fazer: a aplicao simplesmente no funcionar. Em um mundo
onde h novas aplicaes sendo lanadas todos os dias, este tende a ser um problema considervel, e o
resultado que os fornecedores sempre tm uma nova verso (esta suporta SSL, a prxima suportar Real
udio, a seguinte suportar SQL) de firewall no forno.
Quando necessrio usar uma aplicao para a qual o fornecedor do firewall no tem (nem ter) um
proxy especfico, a soluo a utilizao de um proxy genrico. Criar um proxy genrico simples: tratase to-somente de informar ao firewall que quaisquer pacote trafegando entre as maquinas x (internas) e
as maquina y (externas)que usem a porta z so confiveis e podem passar. Apesar de tais pacotes serem
roteados sem uma anlise cuidadosa (similar ao que faria um firewall de rede), trata-se de um
procedimento razoavelmente seguro, porque a comunicao no monitorada duplamente restrita: no
apenas ocorre numa nica porta IP, como s envolvem maquinas de confiana afinal, se o fornecedor
no fosse de confiana no seria contratado.
Como no permite comunicao direta entre o cliente e o servidor, o firewall de aplicao
consideravelmente menos transparente que o firewall de rede. necessrio que o programa cliente saiba
que deve estabelecer uma conexo com o proxy e determinar aes como "conecte-se ao servidor Web da
Mantel e recupere a pgina tal para mim". Quando o cliente sabe isso; como a maioria dos browsers
Web, basta configur-lo corretamente. Quando os clientes so poucos sofisticados e exigem conexes
diretas com o servidor (como comum com FTP e Telnet, pr exemplo), utiliza-se um artifcio: o usurio
se loga no proxy e este; m vez de solicitar nome e senha (como seria de esperar), solicita o nome do
servidor com o qual se deseja a conexo; a partir da, tudo funciona normalmente.
O firewall de aplicao oferece algumas vantagens sobre o firewall de rede. A primeira e mais importante
permitir um acompanhamento muito mais prximo e efetivo das comunicaes entre duas redes,
inclusive com logs e relatrios de auditoria. O fato de o DNS ser tambm um proxy server permite que os
nomes das maquinas internas sejam preservados e que um mesmo nome possa identificar duas maquinas
diferentes da origem de quem consulta, se um usurio interno ou externo.
Alm disso, como toda a comunicao ricocheteada pelo firewall, o mundo s precisa saber de um
nico endereo IP (o da porta externa do firewall), e os verdadeiros endereos das maquinas internas
podem ser protegidos, trazendo vrios benefcios. Para comear, o simples desconhecimento dos
endereos reais refora a segurana. Melhor ainda que isso permite o uso de faixas reservadas de
endereos que, pr conveno, no podem ser utilizadas na Internet. Neste caso, virtualmente
impossvel para o cracker enviar pacotes diretamente s maquinas da rede interna. E o uso de endereos
protegidos tambm possibilita a atribuio de mais endereos do que os concedidos originalmente pelo
provedor de acesso.
11
www.projetoderedes.kit.net
Alm do firewall
Infelizmente, no h firewall que consiga bloquear um ataque efetuado pr fora do firewall. Apesar de
isso ser bvio, a Internet parece deter o monoplio no que se refere a difundir o terror; de modo que h
muita gente que s v perigo na grande rede, deixando de lado os outros pontos onde, com freqncia, o
dano pode ser maior ou o risco mais provvel. So comuns os casos empresas que instalam firewalls de
primeira ao mesmo modems permitindo acesso discado sem senha. Isso eqivale a colocar tranca de ao
na portas da frente e abandonar as janelas destrancadas.
Um firewall no impede o vazamento de dados. O correio eletrnico de fato a forma mais simples de se
enviar dados para fora da empresa, mas tambm a forma mais perigosa, j que o trafego de correio pode
ser controlado e auditado. Um espio consciencioso preferir uma fita, um disquete (razo pelos quais h
quem defenda o banimento dos drives de disquete) ou um simples fax. E no existe aplice de seguro
contra estupidez: se um funcionrio fornecer sua senha de acesso a usurios no autorizados ou
desconhecidos, no h firewall que resolva.
Firewalls podem ser muito eficientes para reconhecer e neutralizar ataques efetuados da utilizao
maliciosa de caractersticas especficas dos protocolos de comunicao utilizados na rede, mas pouco
podem fazer contra ataques baseados em dados. Do ponto de vista do firewall, mensagens de correio ou
arquivos copiados para algum servidor no constituem ataque. O resultado que possvel que crackers
se valha de caractersticas (ou, mais comumente, falhas) de programas especficos para executar aes
nefastas. O caso mais notrio deste tipo de utilizao mal-intencionada foi o vrus da Internet, que se valia
de uma falha do sendmail (programa de envio de correio do Unix) e derrubou 6 mil maquinas em 1988.
Outros exemplos particularmente graves so os vrus e programas executveis pelos browsers (como
applets java ou controles activeX); ambos os casos so tratados pelos firewalls como dados e, em geral,
trafegam de uma rede a outra sem problema algum.
A maneira correta de combater vrus a tradicional, atravs da utilizao de programas rodando em
estaes e servidores de arquivos identificar e limpar arquivos contaminados logo depois sua gravao em
disco. Tambm j existem antivrus para servidores de correio capazes de analisar arquivos anexados a
mensagens de correio, detectando e removendo vrus antes mesmo que os destinatrios sejam notificados
de sua chegada. A preveno contra o cdigo executvel distribudo atravs da Web deve ser feita nos
programas que recebem e executam. Browsers como o Netscape e Internet Explorer tm opes de
configurao que permitem que tipos de objetos podem ser recebidos e em que condies podem ser
executados.
Apesar de haver no mercado excelentes solues para proteger redes privadas contra ataque de invasores
inescrupulosos, o firewall no pode ser encarado como soluo isolada para a questo de segurana na
comunicao com a Internet. H empresas que gastam pequenas fortunas para montar firewall
inexpugnveis mas no se preocupam em criar polticas de segurana coerentes e consistentes. Para ser
eficaz, o firewall deve ser parte de uma poltica global de segurana uma que seja realista o bastante
para identificar e prevenir os riscos efetivos (maquinas que contm dados mais confidenciais, pr
exemplo, no precisam de firewall: elas no devem estar ligadas Internet), mas que, pr outro lado, no
seja paranica a ponto de impedir as pessoas de trabalhar.
www.projetoderedes.kit.net
Este captulo guia o leitor atravs de uma srie de tpicos os quais deveriam ser observados para tornar
um site seguro. Cada seo aborda um servio ou uma capacidade de segurana que pode ser necessria
para proteger a informao e os sistemas de um site. Os tpicos so apresentados em razovel alto-nvel
para a introduo de conceitos ao leitor.
Ao longo do captulo voc encontrar referncias significativas criptografia. Est fora do escopo deste
documento aprofundar-se em detalhes concernentes criptografia, mas o leitor interessado pode obter
mais informaes atravs de livros e artigos listados na seo de referncia deste documento.
4.1 Autenticao
Pr muitos anos, o mtodo prescrito para a autenticao de usurios tem passado pelo uso de senhas
padro reutilizveis. Originalmente, estas senhas eram usadas pr usurios em terminais para
autenticarem-se em um computador central. Na poca no existiam redes (interiormente ou
externamente), sendo mnimo o risco de revelao da senha de texto claro. Atualmente sistemas so
conectados atravs de redes locais, e estas redes locais so conectadas mais adiante e Internet. Usurios
esto se logando de toda parte o globo; suas senhas reutilizveis so freqentemente transmitidas atravs
destas mesmas redes em texto claro, no ponto para que qualquer um (que esteja na escuta) possa capturar.
E, sem dvida, o Centro de Coordenao CERT* e outras equipes de reao esto vendo um grande
nmero de incidentes envolvendo visualizadores de pacote os quais esto capturando as senhas de texto
claro.
Com o advento de tecnologias mais recentes, como senhas de uso nico (pr exemplo, S/Key), PGP, e
dispositivos de autenticao baseados em tokens, as pessoas esto usando strings tipo senhas como tokens
e identificadores numricos secretos. Se estes tokens e identificadores numricos secretos no forem
apropriadamente selecionados e protegidos, a autenticao ser facilmente subvertida.
4.1.2 Kerberos
Kerberos um sistema de segurana de rede distribudo que prov autenticao atravs de redes
inseguras. Caso sejam requisitados pela aplicao, integridade e criptografia tambm podem ser providos.
Kerberos foi desenvolvido originalmente no Instituto de Massachusetts de Tecnologia (MIT) nos anos
oitenta. H dois principais lanamentos do Kerberos, verso 4 e 5 que so, para propsitos prticos,
incompatveis.
13
www.projetoderedes.kit.net
www.projetoderedes.kit.net
(3) Restringindo acesso ao arquivo de senhas - em particular, um site deseja proteger a poro de senha
codificada do arquivo para que os pretendentes a intrusos no os tenham disponveis para a quebra. Uma
tcnica efetiva usar senhas de sombra onde o campo de senha do arquivo padro contm uma senha
boba ou falsa. O arquivo contendo as senhas legtimas protegido em outro lugar do sistema.
(4) Envelhecimento de senhas - Quando e como expirar senhas ainda um assunto de controvrsia entre a
comunidade de segurana. Geralmente aceito que uma senha no deve ser mantida uma vez que uma
conta no se encontra mais em uso, mas ardentemente debatido se um usurio deve ser forado a mudar
uma senha boa na que esta em uso ativo. Os argumentos para a troca de senhas relaciona-se preveno
do uso continuo de contas penetradas. Entretanto, a oposio reivindica que mudanas de senha
freqentes conduza usurios a escreverem suas senhas em reas visveis (como cola-las em um terminal)
ou selecionarem senhas muito simples as quais sejam fceis de adivinhar. Tambm deve ser declarado que
um intruso provavelmente usar uma senha capturada ou adivinhada mais cedo do que tarde. Neste caso o
envelhecimento da senha prov pequena ou nenhuma proteo.
Enquanto no h resposta definitiva a este dilema, uma poltica de senhas deve dirigir a questo
diretamente e prover diretrizes para com que freqncia um usurio deve mudar a senha. Certamente,
uma mudana anual em sua senha no difcil para a maioria dos usurios, normalmente, e voc deve
considerar esta requisio. recomendado que senhas sejam mudadas pelo menos sempre que uma conta
privilegiada seja compromissada, exista uma mudana pessoal crtica (especialmente se for um
administrador!) ou quando uma conta seja compromissada. Ainda, se a senha de uma conta privilegiada
compromissada, todas as senhas no sistema devem ser alteradas.
(5) Bloqueio de contas e senhas - Alguns sites acham til desabilitar contas depois de um nmero prdefinido de no sucedidas tentativas de autenticao. Se seu site decidir empregar este mecanismo,
recomendado que o mecanismo no avise a sim mesmo. Depois de
desabilitar, at mesmo se a senha correta for apresentada, a mensagem exibida deve permanecer como a
de uma tentativa no sucedida de login. A implementao deste mecanismo requerer que usurios
legtimos contatem seus administradores de sistema para pedir que sua conta seja reativada.
(6) Uma palavra sobre o finger daemon - O finger daemon exibe, como padro, informao considervel
do sistema e do usurio. Pr exemplo, ele pode exibir uma lista de todos os usurios que atualmente usam
um sistema ou todo o contedos do arquivo .plan de um usurio especfico. Esta informao pode ser
usada pr possveis intrusos para identificar usernames e adivinhar suas senhas. recomendado que sites
considerem modificar o finger para restringir a informao exibida.
4.2 Confiana
Haver recursos de informao que seu site desejar proteger da revelao entidades no autorizadas.
Sistemas operacionais possuem freqentemente mecanismos de proteo de arquivo embutidos que
permitem um administrador controlar quem no sistema pode acessar ou "enchergar" o contedo de um
determinado arquivo. Um modo mais forte de prover confiana atravs de criptografia. Criptografia
realizada misturando dados de forma que venha a ser muito difcil e consuma tempo demasiado para que
qualquer um que no um receptor ou proprietrio autorizado possa obter o texto claro. Os receptores e
autorizados e proprietrios da informao possuiro as chaves de decriptao correspondentes as quais
lhes permitem ordenar facilmente o texto para uma forma legvel (texto claro). Ns recomendamos que
sites usem criptografia para prover confiana e proteger informao valiosa.
O uso de criptografia controlado s vezes pr regulamentos governamentais e de sites, portanto ns
encorajamos que os administradores tornem-se informados de leis ou polticas que regulem seu uso antes
de emprega-la. Est fora do escopo deste documento discutir os vrios algoritmos e programas
disponveis para este propsito, mas ns acautelamos contra o uso casual do programa crypt do UNIX pr
ter sido achado facilmente quebrvel. Ns tambm encorajamos todos a levarem tempo para entender a
fora da criptografia em qualquer algoritmo/produto dado antes de us-lo. A maioria dos produtos
famosos bem-documentada na literatura, devendo ser esta uma tarefa bastante fcil.
15
www.projetoderedes.kit.net
4.3 Integridade
Como um administrador, voc desejar ter certeza que informaes (pr exemplo, arquivos de sistema
operacional, dados de companhia, etc.) no tenham sido alteradas de uma maneira no autorizada. Isto
significa que voc desejar prover alguma garantia sobre a integridade da informao em seus sistemas.
Um modo de prover isto realizar um checksum do arquivo inalterado, armazenar o checksum de maneira
offline e periodicamente (ou quando desejado) conferir para ter certeza que o checksum do arquivo online
no tenha sido alterado (que indicaria a alterao dos dados).
Alguns sistemas operacionais vm com programas de checksum, como o programa sum do UNIX.
Entretanto, estes podem no prover a proteo da que voc precisa de fato. Arquivos podem ser
modificados arquivos de tal forma que o resultado do programa sum do UNIX seja conservado! Assim,
ns sugerimos a utilizao de um forte programa de criptografia, como o programa de condenso de
mensagem MD5 [ref.], para produzir os checksums que voc usar para garantir a integridade.
H outras aplicaes onde a integridade precisar ser assegurada, como quando da transmisso de um
email entre duas entidades. Existem produtos disponveis os quais podem prover esta capacidade. Uma
vez que voc identificar esta capacidade como sendo necessria, voc pode identificar tecnologias que
provero isto.
4.4 Autorizao
Autorizao se refere ao processo de conceder privilgios para processos e, fundamentalmente, usurios.
Isto difere daquela autenticao que o processo de identificao de um usurio. Uma vez identificados
(seguramente), os privilgios, direitos, propriedade e aes permissveis do usurio so determinados
atravs da autorizao.
Listar explicitamente as atividades autorizadas de cada usurio (e processo de usurio) com respeito a
todos os recursos (objetos) impossvel em um sistema razovel. Em um sistema real certas tcnicas so
usadas para simplificar o processo de conceder e verificar autorizaes.
Uma abordagem, popularizada em sistemas de UNIX, associar a cada objeto trs classes de usurio:
proprietrio, grupo e mundo. O proprietrio o criador do objeto ou o usurio associado como
proprietrio pelo super usurio. As permisses de proprietrio (leitura, escrita e execuo) aplicam-se
somente para o proprietrio. Um grupo uma coleo de usurios que compartilham direitos de acesso
sobre um objeto. As permisses de grupo (leitura, escrita e execuo) aplicam-se a todos os usurios no
grupo (exceto o proprietrio). O mundo refere-se a todos outros com acesso ao sistema. As permisses de
mundo (leitura, escrita e execuo) aplicam-se a todos os usurios (menos o proprietrio e membros do
grupo).
Outra abordagem associar a um objeto uma lista que explicitamente contm a identidade de todos
usurios permitidos (ou grupos). Esta uma Lista de Controle de Acesso (ACL). A vantagem de ACLs
que elas so
facilmente mantidas (uma lista central pr objeto) e muito fcil verificar visualmente quem tem acesso
ao que. As desvantagens so os recursos extras exigidos armazenar tais listas, como tambm o vasto
nmero de listas requeridas para sistemas grandes.
4.5 Auditoria
Esta seo cobre os procedimentos para coletar os dados gerados pela atividade de rede, que podem ser
teis para analisar a segurana de uma rede e responder a incidentes de segurana.
16
www.projetoderedes.kit.net
17
www.projetoderedes.kit.net
4.6 Acesso
4.6.1 Acesso Fsico
Restrinja o acesso fsico aos hosts, permitindo acesso somente a aquelas pessoas que devem us-los.
Hosts incluem terminais confiveis (ou seja, terminais que permitem uso no autenticado tais como
consoles do sistema, terminais de operadores e terminais dedicados a tarefas especiais), e
microcomputadores e estaes de trabalho individuais, especialmente aqueles conectados a sua rede.
Certifique-se de que as reas de trabalho das pessoas se ajusta bem s restries de acesso; caso contrrio
elas encontraro maneiras de evitar sua segurana fsica (pr exemplo portas fechadas abrindo).
18
www.projetoderedes.kit.net
Mantenha cpias originais e backup de programas e dados seguras. Alm de mant-los em boas condies
para fins de backup, eles devem ser protegidos contra furtos. importante manter backups em uma
localizao separada dos originais, no somente em considerao a danos, mas tambm para proteger
contra furtos.
Hosts portteis so um risco particular. Certifique-se que eles no causaro problemas se um computador
porttil de seu pessoal for roubado. Considere o desenvolvimento de polticas para as espcies de dados
que deveriam ser permitidas residirem em discos de computadores portteis bem como a maneira pela
qual os dados deveriam ser protegidos (pr exemplo criptografia) quando estivessem em computadores
portteis.
Outras reas onde o acesso fsico deveria ser restringido so os gabinetes de fiao e elementos
importantes de rede como servidores de arquivos, hosts servidores de nomes e roteadores.
4.6.4 Modems
4.6.4.1 Linhas de Modem devem ser Gerenciadas
Ainda que elas forneam acesso conveniente a um local para todos seus usurios, elas podem tambm
fornecer um desvio efetivo dos firewalls do local. Pr esta razo essencial manter um controle
apropriado dos modems.
No permite aos usurios instalar uma linha de modem sem uma autorizao apropriada. Isto inclui as
instalaes temporrias (pr exemplo, pendurar um modem em um aparelho de fax ou uma linha
telefnica durante a noite.
19
www.projetoderedes.kit.net
Tenha um registro de todas as suas linhas de modem e mantenha-o atualizado. Conduza verificaes
regulares (idealmente automatizadas) dos modems no autorizados no "site".
www.projetoderedes.kit.net
Exiba um "banner" curto, mas no oferea um nome "convidativo" (pr exemplo "Universidade XYZ",
"Sistema de Registro de Estudantes"). Ao invs, fornea o nome de seu local, uma advertncia curta de
que as sesses podem ser monitoradas, e um "prompt" de cdigo de usurio e senha. Verifique possveis
questes legais relacionadas ao texto que voc pe no "banner".
Para aplicaes de alta segurana considere o uso de uma senha "cega" (isto , no d nenhuma resposta a
uma chamada que chega at que o usurio tenha digitado uma senha). Isto efetivamente simula um
modem morto.
www.projetoderedes.kit.net
22
www.projetoderedes.kit.net
* Protegendo evidncias e logs de atividades (que registros deveriam ser mantidos de antes, durante, e
depois do incidente)
* Conteno (como o dano pode ser limitado)
* Erradicao (como eliminar as causas do incidente)
* Recuperao (como restabelecer servio e sistemas)
* Seqncia (que ao deveriam ser tomadas depois do incidente)
5. conseqncias (quais as implicaes de incidentes passados).
6. resposta administrativa para incidentes.
O resto deste captulo detalhar os assuntos envolvidos em cada dos tpicos importantes listados acima, e
prov alguma direo sobre o que deveria ser includo em uma poltica do site para tratar incidentes.
www.projetoderedes.kit.net
mesmo tempo para responder a ele; prioridades so essenciais. Embora prioridades variem de instituio
para instituio, as seguintes sugestes de prioridades podem servir como ponto de partida para definir a
resposta de sua organizao:
Prioridade 1 --proteja vida humana e segurana das pessoas; vida humana sempre tem precedncia
sobre outras consideraes.
Prioridade 2 -- proteger dados importantes. Previna explorao sistemas, redes ou locais importantes.
Informe sistemas, redes ou locais importantes que tenham sido afetados sobre invases acontecidas.
(Esteja atento aos regulamentos de seu site ou do governo)
Prioridade 3--proteja outros dados incluindo dados proprietrios, cientficos, administrativos e outros,
pois perda de dados cara em termos de recursos. Previna exploraes de outros sistemas, redes ou
locais e informe os sistemas, redes ou locais afetados sobre invases bem sucedidas.
Prioridade 4--previna dano para sistemas (pr exemplo, perda ou alterao de arquivos de sistemas,
danos a unidades de disco, etc.). Danos em sistemas pode resultar em custo de recuperao alto.
Prioridade 5--minimize a interrupo dos recursos de computao(inclusive processos). melhor em
muitos casos desligar um sistema ou desconecta-lo de uma rede que arriscar dano para dados ou
sistemas. Os sites tero que avaliar a melhor opo entre desligar e desconectar, manter o sistema
funcionando. Pode haver acordos de servios em lugares que podem requerer a manuteno dos
sistemas no ar mesmo com a possibilidade de danos adicionais. Porm, o dano e escopo de um
incidente podem ser to extensos que aqueles acordos de servio podem ter que ser ignorados.
Uma implicao importante para definir prioridades que uma vez que a vida humana e consideraes de
segurana nacionais foram previstas, geralmente mais importante salvar dados que software e hardware.
Embora indesejvel ter qualquer dano ou perda durante um incidente, sistemas podem ser substitudos.
Porm, a perda ou comprometimento de dados (especialmente classificados ou proprietrios)
normalmente no de forma alguma um resultado aceitvel.
Outra preocupao importante o efeito em outros, alm dos sistemas e redes onde o incidente acontece.
Dentro dos limites impostos pr regulamentos governamentais sempre importante informar as partes
afetadas o mais cedo possvel. Devido s implicaes legais deste tpico, ele deveria ser includo nos
procedimentos planejados para evitar demoras adicionais e incertezas para os administradores.
Qualquer plano para responder a incidentes de segurana deveria ser guiado pr polticas locais e
regulamentos. Sites privados e do governo que lidem com material classificado tem regras especficas que
eles devem seguir.
As polticas escolhidas pr seu site sobre como reagir a incidentes ir moldar sua resposta Pr exemplo,
pode fazer pouco sentido criar mecanismos para monitorar e rastrear intrusos se o seu site no planeja
entrar em ao contra os intrusos caso eles sejam pegos. Outras organizaes podem ter polticas que
afetam seus planos. Companhias de telefone freqentemente liberam informaes sobre rastreamento de
telefones apenas para agncias responsveis pela execuo da lei.
Tratar incidentes pode ser tedioso e requerer qualquer nmero de tarefas rotineiras que poderiam ser
tratadas pelo pessoal de apoio. Para liberar o pessoal tcnico, til identificar pessoal de apoio que
ajudar com tarefas como: fotocopiar, passar fax, etc.
www.projetoderedes.kit.net
organizaes investigativas. Conhecendo estes contatos antes dos incidentes acontecerem ajudar a fazer
seu processo de tratamento de incidentes mais eficiente.
Para cada tipo de contato de comunicao, Pontos de Contato (POC) especficos deveriam ser definido.
Estes podem ser de natureza tcnica ou administrativa e podem incluir agncias legais ou investigativas
como tambm os provedores de servio e vendedores. Ao estabelecer estes contatos, importante decidir
quanta informao ser compartilhada com cada classe de contato. especialmente importante definir,
com antecedncia, que informao ser compartilhada com os usurios de um site, com o pblico
(inclusive a imprensa), e com outros sites.
Determinar estes assuntos especialmente importantes para a pessoa local responsvel pr tratar o
incidente, j que essa pessoa responsvel pela notificao dos outros. Uma lista de contatos em cada
uma destas categorias representam uma economia de tempo importante para esta pessoa durante um
incidente. Pode ser bastante difcil achar uma pessoa apropriada durante um incidente quando muitos
eventos urgentes esto acontecendo. fortemente recomendado que os nmeros de telefone pertinentes
(tambm endereos de correio eletrnicos e nmeros de fax) sejam includos na poltica de segurana do
site. Os nomes e informaes de contato de todos os indivduos que estaro envolvidos diretamente no
tratamento de um incidente devem ser colocados no topo desta lista.
5.2.1 Gerentes locais e Pessoal
Quando um incidente est ocorrendo, uma questo importante decidir quem est encarregado de
coordenar a atividade dos diversos jogadores. Um dos maiores enganos que pode ser cometido ter vrias
pessoas cada qual trabalhando independentemente, mas no trabalhando junto. Isto s aumenta a confuso
do evento e provavelmente conduzir a esforo desperdiado ou ineficaz.
O nico POC pode ou no ser a pessoa responsvel pr tratar o incidente. H dois papis distintos a serem
preenchidos quando se est decidindo quem ser POC e quem ser a pessoa encarregada do incidente. A
pessoa encarregada do incidente tomar decises sobre a interpretao da poltica aplicada ao evento. Em
contraste, o POC deve coordenar os esforos de todas as partes envolvidas no tratamento do evento.
O POC deve ser uma pessoa com percia tcnica para coordenar com sucesso os esforos dos gerentes de
sistemas e usurios envolvidos na monitorao e reao ao ataque. Cuidado deveria ser tomado ao
identificar quem ser esta pessoa. No deveria ser necessariamente a mesma pessoa que tem
responsabilidade administrativa pelos sistemas comprometidos uma vez que freqentemente tais
administradores tem conhecimento suficiente apenas para o uso dos computadores no dia-a-dia, faltandolhes conhecimento tcnico mais profundo.
Outra funo importante do POC manter contato com as autoridades legais competentes e outras
agncias externas para assegurar que o envolvimento multi-agncia. O nvel de envolvimento ser
determinado atravs de decises de administrao bem como pr restries legais.
Um nico POC tambm deveria ser a nica pessoa encarregada de coletar evidncias, desde que como
regra geral, quanto mais pessoas tocam uma pea potencial de evidncia, o maior a possibilidade de que
esta seja inadmissvel no tribunal. Para assegurar que as evidncias sero aceitveis para a comunidade
legal, a coleta de evidncias deve ser feita seguindo-se procedimentos predefinidos, de acordo com leis
locais e regulamentos legais.
Um das tarefas mais crticas para o POC a coordenao de todos os processos pertinentes.
Responsabilidades podem ser distribudas sobre o site inteiro, envolvendo mltiplos departamentos ou
grupos independentes. Isto ir requerer um esforo bem coordenado para alcanar sucesso global. A
situao fica ainda mais complexa se mltiplos sites esto envolvidos. Quando isto acontece, raramente
um nico POC num site poder coordenar o tratamento do incidente inteiro adequadamente. Ao invs
disso, deveriam ser envolvidos grupos apropriados de resposta a incidentes.
O processo de tratamento de incidentes deveria prover alguns mecanismos de ampliao. Para definir tal
mecanismo, os sites precisaro criar um esquema de classificao interno para incidentes. Associado a
cada nvel de incidente estaro o POC e procedimentos apropriados. Conforme um incidente aumenta,
pode haver uma mudana do POC que precisar ser comunicada a todos os outros envolvidos no
tratamento do incidente. Quando uma mudana no POC acontece, o POC antigo deve fazer um resumo
para o POC novo sobre toda a informao background.
25
www.projetoderedes.kit.net
Finalmente, usurios tm que saber informar incidentes suspeitos. Os sites devem estabelecer
procedimentos de informe que iro funcionar durante e fora de horas de trabalho normais. "Help desks"
freqentemente so usadas para receber estes relatrios durante horas de trabalho normais, enquanto
beepers e telefones podem ser usados fora de hora.
www.projetoderedes.kit.net
O equilbrio entre apoiar atividade investigativa e limitar obrigao enganador. Voc precisar
considerar as sugestes de seu conselho legal e o dano que o intruso est causando (se algum) ao tomar
sua deciso sobre o que fazer durante qualquer incidente em particular.
Seu conselho legal tambm deveria ser envolvido em qualquer deciso para contactar agncias
investigativas quando um incidente acontece em seu site. A deciso para coordenar esforos com agncias
investigativas de seu site ou organizao. Envolver seu conselho legal tambm nutrir a coordenao
multi-nvel entre seu site e a agncia investigativa envolvida, o que resulta em uma diviso eficiente de
trabalho. Outro resultado que provvel que voc obtenha direcionamento que o ajudar a evitar futuros
enganos legais.
Finalmente, sua conselho legal deveria avaliar o procedimentos escritos de seu site para responder a
incidentes. essencial obter uma aprovao de uma perspectiva legal antes que voc de fato leve a cabo
estes procedimentos.
vital, quando lidando com agncias investigativas, verificar que a pessoa que chama pedindo
informao uma representante legtima da agncia em questo. Infelizmente, muitas pessoas bem
intencionadas tm vazado detalhes sensveis sobre incidentes sem perceber, permitido pessoas sem
autorizao nos sistemas, etc., porque um visitante disfarou-se como representante de uma agncia
governamental. (Nota: esta palavra de precauo na verdade se aplica a todos os contatos externos.)
Uma considerao semelhante envolve usar meios seguros de comunicao. Porque muitos atacantes de
rede podem desviar correio eletrnico facilmente, evite usar correio eletrnico para comunicar-se com
outras agncias (como bem com outros lidando com o incidente em questo). Linhas telefnicas inseguras
(os telefones normalmente usados no mundo empresarial) tambm so alvos freqentes para escutas pr
intrusos de rede, logo tenha cuidado!
No h um conjunto estabelecido de regras para responder a um incidente quando o governo local
envolvido. Normalmente (nos E.U.A.), exceto atravs de ordem legal, nenhuma agncia pode o for-lo a
monitorar, desconectar da rede, evitar contato de telefone com os atacantes suspeitos, etc. Cada
organizao ter um conjunto de leis e regulamentos locais e nacionais aos quais devem ser aderidos
quando do tratamento de incidentes. recomendado que cada site esteja familiarizado com essas leis e
regulamentos, e identifique e conhea os contatos para agncias com jurisdio com antecedncia do
tratamento de um incidente.
www.projetoderedes.kit.net
www.projetoderedes.kit.net
Um dos assuntos mais importantes a considerar quando, quem, e quanto liberar ao pblico em geral pela
imprensa. H muitos assuntos para considerar quando decidindo este ponto em particular. Primeiro e
antes de mais nada, se um escritrio de relaes pblicas existe para o site importante usar este
escritrio como ligao para a imprensa. O escritrio de relaes pblicas treinado no tipo e formulao
de informao a serem liberadas, e ajudar a assegurar que a imagem do site protegida durante e depois
do incidente (se possvel). Um escritrio de relaes pblicas tem a vantagem de que voc pode se
comunicar francamente com eles, e prov um pra-choque entre a ateno de imprensa constante e a
necessidade do POC para manter controle sobre o incidente.
Se um escritrio de relaes pblicas no est disponvel, a informao, lanado imprensa deve ser
considerada cuidadosamente. Se a informao sensvel, pode ser vantajoso s prover mnima
informao para a imprensa. bastante possvel que qualquer informao provida imprensa ser vista
depressa pelo perpetrador do incidente. Tambm note que enganar a imprensa pode sair pela culatra
freqentemente e pode causar mais dano que liberar informaes delicadas.
Enquanto difcil de determinar com antecedncia que nvel de detalhe prover imprensa, algumas
diretrizes para serem lembradas so:
(1) mantenha o nvel de detalhes tcnicos baixo. Informao detalhada sobre o incidente pode prover
bastante informao para outros lanarem ataques semelhantes em outros sites, ou at mesmo
danificar habilidade do site para processar a parte culpada uma vez que o evento terminou.
(2) Mantenha a especulao fora de declaraes de imprensa. Especulao sobre quem est causando
o incidente ou os motivos, est muito sujeita a erros e pode causar uma viso inflamada do incidente.
(3) Trabalhe com profissionais da lei para assegurar que a evidncia protegida. Se prossecuo for
envolvida, assegurar que a evidncia coletada no divulgada imprensa.
(4) Tente no ser forado a uma entrevista de imprensa antes de voc estar preparado. A imprensa
popular famosa pela "entrevista das 2 das manh", onde a esperana pegar o entrevistado
desprevenido e obter informao no disponvel em outras circunstncias.
(5) No permita que a ateno de imprensa diminua o tratamento do evento. Sempre se lembre que o
fechamento com sucesso de um incidente de importncia fundamental.
www.projetoderedes.kit.net
(4) discrepncia de contabilidade (em um sistema de UNIX pode voc notar a diminuio de um
arquivo de contabilidade chamado /usr/admin/lastlog, algo que o deveria muito desconfiado de que
pode haver um intruso).
(5) mudanas em tamanho ou data de arquivo (um usurio deveria desconfiar se .arquivos EXE em
um computador MS-DOS tenha inexplicavelmente aumentado mais de 1800 bytes).
(6) Tentativas de escrever em system (um gerente de sistema nota que um usurio privilegiado em um
sistema de VMS est tentando alterar RIGHTSLIST.DAT).
(7) modificao de dados ou apagamento (arquivos comeam a desaparecer).
(8) negao de servio (gerente de sistema e todos os outros usurios so impedidos de entrar num
sistema de UNIX, agora em modo de usurio nico).
(9) desempenho de sistema inexplicavelmente, baixo
(10) anomalias (GOTCHA " exibido no monitor ou h freqentes e inexplicveis "beeps ").
(11) sondas suspeitas (h numerosas tentativas de login sem sucesso de outro nodo).
(12) Browsing suspeito (algum se torna um usurio root em um sistema UNIX e acessa arquivos
arquivo aps arquivo em contas de muitos usurio.)
(13) inabilidade de um usurio para se logar devido a modificaes em sua conta.
De forma alguma esta lista completa; ns listamos apenas um certo nmero de indicadores comuns.
melhor colaborar com outro pessoal tcnico e de segurana de computador para tomar uma deciso como
um grupo sobre se um incidente est acontecendo.
30
www.projetoderedes.kit.net
ou que tenha conhecimento ntimo ou acesso aos sistemas. Em todos os casos, a preparao antes do
incidente determinar se a recuperao possvel.
Se o sistema suporta logs centralizados (a maioria o faz), volte para os logs e procure anormalidades. Se
contabilidade de processo e tempo de conexo estiver habilitada, procure padres de uso do sistema.
Numa menor extenso, o uso do disco pode jogar luz no incidente. Contabilidade pode prover muita
informao til em uma anlise de um incidente e prossecuo subseqente. Sua habilidade para verificar
todos os aspectos de um incidente especfico depende fortemente do sucesso desta anlise.
www.projetoderedes.kit.net
A escolha do idioma usado quando notificar as pessoas sobre o incidente pode ter um efeito profundo no
modo que informao recebida. Quando voc usa termos emocionais ou inflamatrios, voc eleva o
potencial para dano e resultados negativos do incidente. importante permanecer tranqilo ambos as
comunicaes escrita e falada.
Outra considerao que nem todas as pessoas falam o mesmo idioma.
Devido a este fato, podem surgir enganos e demora, especialmente se um incidente multinacional. Em
outras preocupaes internacionais inclua a diferena nas implicaes legais de um incidente de
segurana e diferenas culturais. Porm, diferenas culturais no s existem entre pases. Elas igualmente
existem dentro de pases, entre diferente grupos sociais ou de usurios. Pr exemplo, administrador de um
sistema universitrio muito relaxado sobre tentativas para conectar o sistema pr telnet, mas provvel
que o administrador de um sistema militar considere a mesma ao como um possvel ataque.
Outro assunto associado com a escolha de idioma a notificao de pessoas no tcnicas ou de fora do
site. importante descrever o incidente com preciso sem gerar alarme imprprio ou confuso. Enquanto
mais difcil de descrever o incidente a uma conjunto de pessoas no-tcnicas, freqentemente mais
importante. Uma descrio no-tcnica pode ser requerida pela administrao de nveis superiores, a
imprensa, ou instituies responsveis pela execuo de lei. A importncia destas comunicaes no pode
ser menosprezada e pode fazer a diferena entre a soluo do incidente corretamente ou eleva-lo a algum
nvel mais alto de dano.
Se um grupo de resposta a incidentes envolvido, poderia ser necessrio preencher um modelo para a
troca de informao. Embora isto possa parecer ser um fardo adicional e possa somar uma certa demora,
isto, ajuda o grupo para agir neste mnimo conjunto de informao. O grupo de resposta poder responder
a aspectos do incidente do qual o administrador local desavisado. Se a informao dada para uma
pessoa de fora ento, esta pessoa deveria ter um mnimo de informao contando o seguinte:
1. timezone de logs,... em GMT ou hora local
2. informao sobre o sistema remoto, inclusive nomes de host, endereos IP e (talvez) IDs de
usurios
3. todas as entradas de log relevantes para o local distante
4. tipo de incidente (o que aconteceu, pr que se voc deveria se preocupar)
Se informaes locais (i.e., IDs de usurios locais) so includas nas entradas de logs, ser anteriormente
necessrio a **sanitize** as entradas para evitar assuntos de isolamento. Em geral, toda a informao que
poderia ajudar um local distante solucionando um incidente deveria ser distribudas, a menos que polticas
locais probem isto.
www.projetoderedes.kit.net
todas as conversaes externas (inclusive a pessoa com quem voc falou, a data e tempo, e o
contedo da conversao)
O modo mais direto para manter documentao mantendo um livro de log. Isto lhe permite ter uma
centralizada e cronolgica fonte de informao quando voc precisar disto, em vez do requerer, chame
pr folhas individuais de papel. Muitas destas informaes so evidncias potenciais em um tribunal de
lei. Assim, quando um procedimento legal uma possibilidade, a pessoa deveria seguir os procedimentos
preparados e evitar pr em perigo o procedimento legal pr manipulao imprpria de possvel evidncia.
Se apropriado, os passos seguintes podem ser levados.
1. regularmente (pr exemplo, diariamente) fazer cpias assinadas de seu logbook (como tambm mdias
que voc usa para registrar eventos de sistemas) para um administrador de documentos.
2. administrador deveria armazenar estas pginas copiadas em um seguro lugar (pr exemplo, uma caixa
forte).
3. quando voc submete informao para armazenamento, voc deve receba um recibo datado e assinado
pelo administrador do documento.
Fracasso para observar estes procedimentos pode resultar em invalidao de qualquer evidncia que voc
obtm em um tribunal de lei.
5.4.3 Reteno
O propsito de reteno limitar a extenso de um ataque. Uma parte essencial de reteno deciso do
que fazer (pr exemplo, determinando desligar um sistema, desconectar da rede, monitorar sistemas ou
atividades de rede, set traps, incapacitar funes como transferncia de arquivo remotoss, etc.).
s vezes esta deciso trivial; desligar o sistema se a informao secreta, importante, ou proprietria.
Tenha em mente que isso remove todo o acesso enquanto um incidente est em progresso, obviamente
notifique todos os usurios, inclusive os usurios que alegaram problemas, que os administradores esto
atentos ao problema; isto pode ter um efeito danoso uma investigao. Em alguns casos, prudente
remover todo o acesso ou funcionalidade o mais cedo possvel, ento restabelea operao normal em
fases limitadas. Em outros casos, vale a pena arriscar algum dano para o sistema, se manter o sistema
poderiam habilitar voc identificar o intruso.
Esta fase deveria se desenvolver levando a cabo procedimentos predeterminados.
Sua organizao ou site devem, pr exemplo, definir riscos aceitvel lidando com um incidente, e deveria
prescrever aes especficas e estratgias adequadas. Isto especialmente importante quando uma deciso
rpida necessria e no possvel contactar todas as partes envolvidas primeiro para discutir a deciso.
Na ausncia de procedimentos predefinidos, a pessoa no cargo do incidente no ter freqentemente o
poder para tomar decises de administrao difceis (como perder os resultados de uma experincia cara
desligando um sistema). Uma atividade final que deveria acontecer durante esta fase de tratamento do
incidente a notificao de autoridades apropriadas.
5.4.4 Erradicao
Uma vez que o incidente foi contido, tempo para erradicar a causa. Mas antes de erradicar a causa,
deveria ser tomado grande cuidado colecionar todas as informaes necessrias sobre os sistemas
comprometidos e a causa do incidente como elas sero provavelmente sero perdidas quando o sistema
for limpo.
Softwares podem estar disponveis para ajudar no processo de erradicao, como software de anti-vrus.
Se qualquer falso arquivos foram criados, devem ser apagados. No caso de infees de vrus, importante
limpar e reformatar qualquer mdia que contm arquivos infetados. Finalmente, assegura que todos os
backups esto limpos. Muitos sistemas infetados com vrus ficam periodicamente r-infetados
33
www.projetoderedes.kit.net
simplesmente porque as pessoas no erradicam o vrus do backup. Depois de erradicao, deveria ser
feito um novo backup.
Removendo todas as vulnerabilidades uma vez um incidente aconteceu difcil. A chave para remover
vulnerabilidades conhecimento e entendimento da brecha.
Pode ser necessrio voltar para as mdia de distribuio originais e r-customizar o sistema. Para facilitar
esta situao de pior caso, um registro do setup do sistema original e de cada mudana de customizao
deveria ser mantido. No caso de um ataque baseado na rede, importante instalar remendos para cada
vulnerabilidade de sistema operacional que foi explorado.
Como discutido na seo 5.4.2, um log de segurana pode ser muito valioso durante esta fase de remover
vulnerabilidade. Os logs que mostram como o incidente foi descoberto e foi contido pode ser usado para
ajudar depois a determinar qual a extenso do dano de um determinado incidente. O passos podem ser
usados no futuro para ter certeza que o problema no ir ocorrer. Idealmente, a pessoa deveria automatizar
e regularmente deveria aplicar o mesmo teste como foi usado para descobrir o incidente de segurana.
Se uma vulnerabilidade particular isolada como explorada, o prximo passo achar um mecanismo para
proteger seu sistema. A segurana que remete listas e boletins seria um lugar bom para procurar esta
informao, e voc pode obter conselhos dos grupos de resposta a incidentes.
5.4.5 Recuperao
Uma vez que a causa de um incidente foi erradicada, a fase de recuperao define a prxima fase de ao.
A meta de recuperao retornar o sistema ao normal. Em geral, expondo servios na ordem de demanda
e com um mnimo de inconvenincia aos usurio a melhor prtica. Entenda que os procedimentos de
recuperao formais para o sistema extremamente importante e deveria ser especfico para o site.
5.4.6 Prosseguimento
Uma vez que voc acredita que o sistema foi restabelecido a um " estado seguro ", ainda possvel que
buracos, e at mesmo armadilhas, podem estar espreitando o sistema. Uma das fases mais importantes de
respostas a incidentes tambm freqentemente omitida, a fase de seguimento. Na fase de seguimento, o
sistema deveria ser monitorado com vistas aspectos que podem ter sido perdidos durante a fase de
cleanup. Seria prudente utilizar, como um comeo, algumas das ferramentas de gerenciamento.
Lembre-se, estas ferramentas no substituem uma monitorao continuada do sistema e boas prticas de
administrao de sistemas.
O elemento mais importante da fase de seguimento executar uma anlise de ps morte. Exatamente o
que aconteceu, e quanto tempo? Como foi a performance do pessoal envolvido com o incidente? Que tipo
de informao foi necessria rapidamente para o pessoal, e como eles adquirir aquela informao o mais
cedo possvel? O que faria o pessoal diferentemente da prxima vez?
Aps um incidente, prudente escrever um relatrio que descreve a sucesso exata de eventos: o mtodo
de descoberta, procedimento de correo, procedimento de monitorao, e um resumo da lio aprendida.
Isto ajudar na compreenso clara do problema. Criando uma cronologia formal de eventos (inclusive
time stamps) tambm importante pr razes legais.
Um relatrio de seguimento valioso pr muitas razes. Prov uma referncias a serem usadas no caso de
outros incidentes semelhantes. Tambm importante para que, to depressa quanto possvel obtenha-se
uma estimativa da quantia monetria dos danos que o incidente causou. Esta estimativa deve incluir
custos associados com qualquer perda de software e arquivos(especialmente o valor de dados proprietrio
que podem ter sido descoberto), dano de hardware, e fora de trabalho usada para restabelecer arquivos
alterados, reconfigure sistemas afetados, e assim sucessivamente. Esta estimativa pode se tornar a base
para atividade de prossecuo subseqente. O relatrio tambm pode ajudar justifique o esforo de
segurana dos computadores de uma organizao para administrao.
34
www.projetoderedes.kit.net
5.6 Responsabilidades
5.6.1 No cruzando a Linha
Uma coisa proteger a sua prpria rede, mas outra assumir que deve proteger outras redes. Durante o
tratamento de um incidente, certas vulnerabilidade dos prprios sistemas e os sistemas de outros ficam
aparentes. bastante fcil e pode ser tentador rastrear os intrusos para localiz-los. Tenha em mente que
em certo momento possvel cruzar a linha e, com a melhor das intenes, comportar-se no melhor do
que o intruso.
A melhor regra a seguir no usar facilidades de sistemas remotos que no sejam pblicas. Isto
claramente exclui qualquer entrada em um sistema (usando um shell ou login remoto) que no seja
explicitamente permitido. Isto pode ser muito tentador depois que uma brecha de segurana descoberta;
um administrador de sistema pode ter os meios para, averiguar que danos podem ter sido feitos ao site
remoto. No faa! Ao invs, tente buscar o contato apropriado para o site afetado.
5.6.2 Poltica de boa vizinhana na Internet
Durante um incidente de segurana h duas escolhas que a pessoa pode fazer. Primeiro, um site pode
escolher observar o intruso na expectativa de pega0lo; ou, o site pode limpar o sistema depois do
incidente e manter o intruso fora dos sistemas. Esta uma deciso que deve ser tomada com muito
cuidado, pois poder haver conseqncias legais se voc optar pr deixar seu site aberto sabendo que um
intruso est usando-o como um ponto de lanamento para atacar outros sites. Sendo um "bom vizinho" na
Internet voc deveria tentar alertar outros sites que podem ter sidos impactados pelo intruso. Estes locais
afetados podem ser detectados aps uma reviso completa de seus arquivos de log.
35
www.projetoderedes.kit.net
Quando um incidente de segurana envolve um usurio, a poltica de segurana do site deveria descrever
que ao ser tomada. A transgresso deve ser levada a srio, mas muito importante estar seguro sobre o
papel do usurio. O usurio era ingnuo? Poderia haver um engano atribuindo a quebra de segurana ao
usurio? Aplicar alguma penalidade administrativa assume que o usurio intencionalmente causou o
incidente e isto pode no ser apropriado para um usurio que simplesmente cometeu um engano. Pode ser
apropriado prever sanes adequadas a cada situao em sua poltica (pr exemplo, educao ou
repreenso a um usurio) alm para medidas mais duras para atos intencionais de intruso e abuso do
sistema.
6. Atividades em andamento
Neste momento, seu site esperanosamente desenvolveu uma poltica completa de segurana bem como
os procedimentos para assistir na configurao e gerenciamento da sua tecnologia no suporte destas
polticas. Como seria bom se voc pudesse sentar e relaxar neste momento j que voc concluiu com o
trabalho de segurana. Infelizmente isto no possvel. Os seus sistemas e redes no so um ambiente
esttico, ento voc ter que rever suas polticas e procedimentos nos seus fundamentos. H um nmero
de passos que voc pode seguir para ajuda-lo a manter as mudanas sob controle de forma a poder tomar
as aes correspondentes. A seguir apresentado um conjunto inicial de passos ao qual voc pode
adicionar outros de forma a ajust-lo ao seu site.
(1) Assine as publicaes que so editadas pr vrios times de resposta a incidentes de segurana,
como os Centros de Coordenao CERT, e atualize os seus sistemas contra as ameaas que se aplicam
tecnologia do seu site.
(2) Mantenha-se atualizado sobre os patches produzidos plos vendedores do seu equipamento e
obtenha e instale os que se aplicam ao seu sistema.
(3) Mantenha sob vigilncia as configuraes do seu sistema para identificar qualquer mudana que
possa ter ocorrido e investigar anomalias.
(4) Revise todas as polticas de segurana e procedimentos anualmente (no mnimo).
(5) Leia os mailing lists relevantes e USENET newsgroups para manter-se atualizado das ltimas
informaes compartilhadas plos colegas de classe.
(6) Verifique regularmente pr polticas e procedimentos complacentes. Esta auditoria deve ser feita
preferencialmente pr algum que no tenha participado da definio ou implementao destas
polticas ou procedimentos.
36