Gerenciamento da Segurança - Março 2005

Mitos sobre Segurança

Publicado em: 14 de Março de 2005

Por Jesper M. Johansson e Steve Riley

Informações

Este é o primeiro artigo de uma série de duas partes baseada no novo livro de Jesper e Steve, "Protect Your Windows Network" (Proteja sua Rede Windows). O livro será lançado no final de maio pela Addison-Wesley. Para mais informações, veja a página: http://www.aw-bc.com/catalog/academic/product/0,1144,0321336437,00.html

Veja outras colunas sobre Gerenciamento de Segurança.

As mudanças e os guias sobre configuração de segurança existem a pelo menos 10 anos no mundo do Windows, mais tempo do que em qualquer outra área. Os guias originais do Windows NT 4.0 que eram publicados pela Agencia Nacional de Segurança dos Estados Unidos e pelo Instituto SANS eram basicamente apenas uma lista de mudanças, com um pouco de lógica por trás de cada configuração mas sem uma coesão com o todo. Os guias eram uma resposta para a demanda que hoje chamamos de "big blue 'secure-me-now' button" (grande botão azul de "deixe-me seguro agora"). O problema é que tal botão não existe. Se existisse, o seu fornecedor o teria incluído.

Existem muitas coisas em jogo em se tratando de orientações de segurança. Em primeiro lugar, é fácil entender porque as pessoas clamam tanto por segurança. Qualquer um pode ver o benefício de uma configuração que bloqueia um ataque. Em alguns ambientes, acionar esta configuração não é nem uma opção. Um sistema deve ser configurado de acordo com algumas configurações de segurança ou guia de endurecimento que seja compatível com a política de segurança. Em outros ambientes a orientação para configuração de segurança é bastante encorajada. Antes de começar a mexer com a segurança, no entanto, acreditamos que seja importante compreender alguns dos problemas fundamentais envolvendo esta questão. Chamamos alguns destes problemas de mitos.

Para evitar soar como se odiássemos os guias de segurança (não odiamos), queremos mostrar que os autores participaram da criação, co-criação, ou edição da maioria dos guias disponíveis para o Windows nos últimos 10 anos. Os guias que foram feitos corretamente são valiosos, mas para fazê-los assim é preciso compreender o que eles não são capazes de fazer. É por isso que os mitos são importantes.

Aviso

Esta seção é de certa forma (na verdade bastante) cínica. Não leve tudo ao pé da letra e dê risada de alguns exemplos que daremos. Não perca de vista, no entanto, o intuito principal: trata-se de mitos. Se você for cuidadoso e evitar cair na armadilha de acreditar nestes mitos, poderá concentrar seus esforços nas coisas que realmente importam ao invés de ser iludido como muitas outras pessoas que olham para uma só arvore ao invés de cuidar da floresta.

Mito N°. 1: Guias de Segurança Tornam o seu Sistema Seguro

Um momento, porque este é um mito? Este não é o propósito principal de um guia de segurança? Sim. Esta é a idéia principal. No entanto, o termo "seguro" conota um estado final que na verdade nunca iremos alcançar. A segurança é um processo, a ser avaliado constantemente. Nada pode ser feito para colocá-lo em um "estado de segurança". Infelizmente, muitas pessoas (com certeza, nenhum de vocês, leitores) parecem acreditar que ao aplicar algum guia de enrijecimento no sistema garantirá a sua segurança. Isto é uma mentira por diversas razões.

Em primeiro lugar, considere qualquer um dos worms recentes, o Sasser, o Slammer,o Blaster, o Nimda, o Code Red, o ILOVEYOU, o Friends, etc., a lista é infinita. Todos eles exploram vulnerabilidades que não foram corrigidas, portanto, nenhum deles teria sido bloqueado porque nenhum sistema de segurança. Enquanto a maioria dos guias diz a você que os patches (correções e atualizações) devem ser aplicados, já vimos diversos sistemas cujos donos acreditam que os patches não são tão importantes já que os guias foram aplicados. Se você não tem certeza sobre quais patches instalar, a melhor resposta é "todos eles." O ideal seria, na verdade, que você tivesse um processo de gerenciamento de patches. Poucas configurações podem prevenir que sua rede seja atacada através de vulnerabilidades que não foram corrigidas.

Em segundo lugar, as configurações raramente bloqueiam ataques reais. Poucas coisas são mais difíceis de serem feitas, mas, em geral, as redes não são atacadas através de configurações que podem ser desligadas. Existem algumas exceções. Por exemplo, um guia de segurança pode desligar o armazenamento de LM Hashes para dificultar a descoberta de senhas. No entanto, como já discutimos anteriormente no artigo http://www.microsoft.com/technet/community/columns/secmgmt/sm1004.mspx), a quebra de senhas é, falando francamente, desnecessária. Um guia pode dificultar a enumeração anônima, mas os invasores quase sempre têm acesso à mesma conta que pode ser usada ao invés de conexões anônimas.

Isto ocorre principalmente porque os guias de segurança tendem a serem simplistas, enquanto os ataques são geralmente complexos. Os guias de segurança fornecem um ótimo ponto de partida, mas para melhorar sua segurança de verdade é preciso fazer muito mais do que isso. Geralmente, você teria que recorrer a medidas complexas para bloquear ataques complexos, e medidas complexas não vêm em pacotes na forma de um modelo de segurança.

Um guia de segurança não torna o seu sistema mais seguro. Na melhor das hipóteses ele fornece um pouco mais de segurança sobre outras coisas que já haviam sido feitas, ou que serão feitas, no sistema, como será visto nos outros capítulos. Na pior das hipóteses ele comprometerá a sua segurança. Por exemplo, um guia pode muito bem comprometer a porção disponibilidade no trio Confiabilidade - Integridade - Disponibilidade ao desestabilizar o sistema.

Início da página

Mito N°. 2: Se Nos Escondermos, os Bandidos Não Nos Encontrarão

Se eu ganhasse um centavo cada vez que alguém tenta esconder seu sistema... Esconder o sistema raramente ajuda. Alguns exemplos são comuns: algumas pessoas defendem que a transmissão SSID em redes sem fio seja desligada. Você não só terá uma rede que não compatível com o padrão, como os seus clientes também irão preferir uma rede de baixa qualidade com o mesmo nome ao invés de uma legítima. Além disso, e de qualquer forma, leva apenas alguns minutos para encontrar a rede, usando as ferramentas adequadas. Um outro exemplo é a mudança dos banners no seu web site para que os bandidos não saibam que o IIS está sendo executado. Em primeiro lugar, é relativamente simples descobrir o que o web site está executando. Em segundo lugar, a maioria dos bandidos não é inteligente o bastante para fazer isso, então eles simplesmente tentam todos os meios, incluindo os do IIS. Uma outra forma é re-nomear a conta do Administrador. Após algumas chamadas do API é possível encontrar o nome verdadeiro. O nosso exemplo favorito é os administradores que usam a Política de Grupo para re-nomear a conta do Administrador. Eles então têm uma conta chamada "Zelador3;" com um comentário "Conta incorporada para a administração do computador/domínio." Isto não enganará ninguém.

Em geral, re-nomear ou esconder as coisas tende a quebrar as aplicações mais do que bloquear os ataques. Os invasores competentes sabem que os administradores mudam os nomes das coisas, e procuram primeiro pelo nome verdadeiro. As aplicações que foram escritas de maneira muito simplificada assumem que o diretório dos Arquivos do Programa, por exemplo, está em um local determinado, e que a conta do Administrador tem um nome determinado dependendo da região, e assim por diante. Estas aplicações serão quebradas. É discutível até que já estivessem quebradas, mas o resultado é que elas não funcionam mais.

Início da página

Mito N°. 3: Quanto Mais Mexer Melhor

Os guias de segurança trazem diversas configurações, e conseqüentemente, existe muita opção de escolha. O Windows Server 2003 traz 140 configurações de segurança na interface da Política de Grupo, sem falar das listas de controle de acesso (access control lists - ACL), da configuração do serviço, das políticas do Sistema de Arquivos Encriptados (Encrypting File System - EFS), das políticas IPsec, e assim por diante. A "melhor" configuração para cada para todo o tipo de ambiente é no mínimo nebulosa. Portanto, diversas que pessoas agem como se, quanto mais mudanças ocorrerem, mais seguras estarão.

Gostaríamos de lembrar uma manchete do final do verão (no hemisfério norte) de 2003. Ela dizia "Dell Vendará Sistemas Que São Seguros Por Padrão." A Dell acabava de anunciar que começaria a vender os sistemas do Windows 2000 configurados com o benchmark CIS Level 1 diretamente da fábrica. O artigo continuava apontando que este guia aplicava "mais de 50 alterações de segurança… melhorando significativamente a segurança padrão do Windows 2000."

Acontece que havia alguns problemas com aquela declaração. Em primeiro lugar, o benchmark fazia apenas 33 alterações, e não "mais de 50." Em segundo lugar, apenas três delas tinham um impacto real na segurança. E finalmente, apesar da Dell ter possivelmente feito algumas configurações de segurança no sistema, ele estava sendo vendido sem o último pacote de serviço, o que nos parece ser um requisito básico de segurança. Não nos entenda mal, é encorajador ver fornecedores que olham para trás, vêem os antigos sistemas operacionais, e avaliam que eles podem tornar-se mais seguros do que seria considerado prudente muitos anos antes, quando foram lançados. Mas foi apresentado como uma forma de ter um sistema "seguro", quando obviamente isto não existe. Além disso, o fornecedor não incluiu diversos requisitos básicos para um sistema protegido.

Muitas das configurações que as pessoas fazem causam pouquíssimo impacto na segurança. Considere, por exemplo, a configuração "Acesso restrito ao disco apenas para usuário registrado localmente". Isto garante que usuários remotos não terão acesso a nenhum disco através da rede; se, e apenas se, um usuário estiver registrado num sistema que hospeda um disquete, caso o contrário, a configuração não tem efeito algum; E um compartilhamento for criado para o disquete (não é feito por padrão); E o ACL no compartilhamento especificar que o usuário remoto pode chegar a ele; E o sistema tiver um drive de disco E tem um disquete dentro dele. A maioria dos sistemas vendidos hoje nem mesmo possuem um disquete, isso sem mencionar como são improváveis os demais requisitos para que ocorram juntos. Estaríamos inclinados a dizer que esta configuração não causa impacto algum na segurança.

Também somos fãs das configurações "NetworkHideSharePasswords" e do "NetworkNoDialIn" que diversos guias defenderam por muitos anos. A primeira foi criada para garantir que quando uma senha compartilhada é estabelecida ela é obscurecida no diálogo da interface do usuário; no Windows 95. A configuração não tem funcionado desde então (O Windows NT, Windows 2000, Windows XP, e Windows Server 2003 nunca suportaram senhas compartilhadas). É claro, mesmo no Windows 95 a configuração teria sido muito mais eficiente se tivesse sido soletrada corretamente (network\hidesharepasswords). A outra configuração, também soletrada incorretamente, controlava as permissões discadas do modem, também no Windows 95. Apesar destas configurações nunca terem funcionado em nenhum sistema operacional baseado no Windows NT, ainda existem "auditores de segurança" que circulam por aí explicando aos gerentes que a equipe de segurança não está fazendo um bom trabalho já que estas configurações não foram feitas no Windows 2000 ou mesmo no Windows XP. Freqüentemente, os guias que vemos são tirados diretamente de documentos obsoletos e tecnicamente imprecisos para outros sistemas operacionais, também obsoletos. Depois eles são transformados em requisitos por pessoas que não entendem nada de segurança nem dos sistemas operacionais que estão tentando proteger.

Na verdade, projetar segurança para um modelo de ameaça parece ser um luxo quando é muito mais fácil cobrar por um serviço de consultoria caríssimo e papaguear algo que alguém, que também não entendia nada do produto, dizia ser o correto. Aqui vão algumas regras básicas.

Se você é uma daquelas pessoas que são avaliadas de acordo com um número de configurações que fizeram, vá em frente e faça várias destas mudanças sem sentido. Sei lá, invente algumas também (parece que todo mundo faz isso). Estas são algumas configurações que podem ser usadas sem quebrar nada:

Certifique-se de estabelecer nelas as ACL apropriadas também. Desta forma você pode mostrar que você está realmente fazendo muito mais do que os outros. Se você criar também um gráfico mostrando para o seu gerente de segurança o impacto positivo que está causando no retorno do investimento (ROI - return of investment), sua promoção para o departamento de Despesa de Gerenciamento Inútil (Useless Management Overhead - UMO) estará garantida!

Enquanto isso, nós estaremos concentrados em melhorar a segurança de fato, através da criação de medidas de segurança para um modelo de ataque.

Início da página

Mito N°. 4: É Necessário Mexer Aqui e Ali

Algumas pessoas afirmam que não é possível ter um sistema seguro (leia-se "protegido") sem fazer uma porção de mudanças. Isto é uma simplificação da questão. As alterações bloqueiam coisas que você não consegue bloquear em outro local. Por exemplo, se você possui dois sistemas em uma rede atrás de um firewall ou um sistema corporativo que possui políticas IPsec que permitem apenas que ele faça solicitações e receba informações de alguns poucos servidores bem gerenciados, estes sistemas provavelmente estarão seguros sem qualquer alteração adicional.

Mesmo em sistemas altamente expostos, a maioria das alterações não é necessária. Na competição Open Hack IV da eWeek em 2002 (na página http://msdn.microsoft.com/library/en-us/dnnetsec/html/openhack.asp), construímos o que era provavelmente a rede mais protegida do mundo. Fizemos, ao todo, apenas quatro alterações registradas, algumas mudanças em ACL, e estabelecemos uma política de senha. O resto da proteção para estes sistemas foi baseado na segmentação de rede apropriada, num conhecimento sólido das ameaças, no desligamento de serviços desnecessários, no enrijecimento de aplicativos da web (veja o Writing Secure Code, 2ª. Edição, por Howard e LeBlanc [Redmond, WA: Microsoft Press, 2003]), na proteção adequada de servidores web e do computador executando o SQL Server. É claro, este era um sistema especializado com uma funcionalidade muito limitada, mas ainda assim demonstra que menos significa mais.

A compreensão apropriada das ameaças e a mitigação realista destas ameaças através de uma arquitetura de rede sólida são muito mais importantes do que maioria dos ajustes que acionamos em nome da segurança.

A segunda parte deste artigo será publicada após 13 de abril. Como sempre, esta coluna é feita para você. Queremos saber se existe algo que gostaria de discutir, ou se existe uma maneira melhor de ajudarmos você a proteger os seus sistemas. Clique em "Comentários" e envie-nos uma mensagem.

Início da página