SecureSite - Trend Micro SMB
Propaganda
Trend Micro™ SecureSite Guia de Melhores Práticas Marketing Técnico de produtos SMB A Trend Micro Incorporated reserva-se o direito de fazer mudanças sem aviso neste documento e nos produtos nele descritos. Antes de instalar e usar o software, verifique o arquivo ‘Readme’ e a versão mais recente da documentação correspondente. Trend Micro, o logotipo Trend Micro t-bal e Worry-Free são denominações comerciais ou marcas registradas da Trend Micro Incorporated. Todos os outros nomes de produtos ou empresas podem ser denominações comerciais ou marcas registradas de seus respectivos titulares. Copyright © 2008. Trend Micro Incorporated. Marketing Técnico de Produtos SMB. Todos os direitos reservados. Trend Micro SecureSite 1.0 – Guia de Melhores Práticas oferece orientações a revendedores e clientes que estão desenvolvendo e gerenciando um site de comércio eletrônico pequeno ou médio. Informações detalhadas sobre o uso de recursos específicos do software estão disponíveis na seção de ajuda on-line e também nos documentos Trend Micro Getting Started Guide (Guia Rápido Trend Micro) e Trend Micro SecureSite 1.0 Administrator’s Guide (Trend Micro SecureSite 1.0 – Guia do Administrador). A Trend Micro busca melhorar sua documentação constantemente. Se você tem dúvidas, comentários ou sugestões sobre este ou qualquer outro documento da Trend Micro, por favor entre em contato conosco pelo e-mail [email protected]. Você também pode avaliar este documento no endereço abaixo: www.trendmicro.com/download/documentation/rating.asp 3 PERFIL DO DOCUMENTO: Produto: Trend Micro™ Worry-Free SecureSite 1.0 Título do Documento: Trend Micro™ Worry-Free SecureSite 1.0 – Guia de Melhores Práticas v1.0 Nome de Arquivo do Documento: Best Practices v1.0 Trend Micro SecureSite 1.0 Data de Lançamento do Documento: 29 de abril de 2008 Equipe: Marketing Técnico de Produtos SMB Autor: Randy Jeff Licsi, Engenheiro Sênior de Produto (TSS-PH) 4 Índice Prefácio...........................................................................................................................................................7 Introdução.................................................................................................................................................... 8 Capítulo 1: Melhores Práticas para Sites de Comércio Eletrônico...........................................9 Segurança dos Sistemas Operacionais......................................................................................................................9 Instalação.................................................................................................................................................................9 Pós-Instalação.........................................................................................................................................................11 Segurança do Servidor Web....................................................................................................................................... 20 Serviços de Informação na Internet (IIS 6.0)............................................................................................... 20 Apache 2.0 ............................................................................................................................................................21 Segurança dos Aplicativos Web.................................................................................................................................24 Segurança do Banco de Dados..................................................................................................................................26 SQL Server ...........................................................................................................................................................26 Capítulo 2: Manutenção da segurança de seu site de comércio eletrônico com Trend Micro SecureSite........................................... 31 Como o Trend Micro SecureSite funciona................................................................................................................31 Arquitetura.............................................................................................................................................................31 Principais Recursos e Benefícios...............................................................................................................................32 Manutenção da postura de segurança de seu site de comércio eletrônico com Trend Micro SecureSite.........34 Apêndice A – Amostra Executiva Geral.......................................................................................... 37 Apêndice B – Amostra de Plano de Remediação........................................................................... 4 5 Prefácio Bem-vindo ao Trend Micro™SecureSite 1.0 – Guia de Melhores Práticas. Este documento foi criado para ajudar revendedores e clientes no desenvolvimento de um conjunto de melhores práticas de segurança para sites de comércio eletrônico pequenos e médios, além do teste de vulnerabilidades por meio do Trend Micro SecureSite 1.0. O documento deve ser usado em conjunto com os guias a seguir: • Trend Micro SecureSite 1.0 Getting Started Guide (Trend Micro Worry Free Secure Site 1.0 – Guia Rápido) • Trend Micro SecureSite 1.0 Administrator’s Guide (Trend Micro Worry Free Secure Site 1.0 – Guia do Administrador) - Grupo de Marketing Técnico de Produtos SMB TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 7 Introdução O rápido crescimento da Internet abre muitas portas para novos negócios, já que se trata de uma maneira nova e fácil de oferecer produtos e serviços. Com a Internet ficou muito mais fácil navegar por vários itens e categorias de produtos, comparar preços em várias lojas e contar com a conveniência de receber os produtos em casa. Estas transações on-line exigem a troca eletrônica de dados confidenciais, como por exemplo, o envio de um número de cartão de crédito de um consumidor na Europa para uma empresa sediada nos Estados Unidos. O tratamento dado às informações confidenciais recebidas dos clientes pode definir o destino de uma empresa de comércio eletrônico. A segurança das informações não deve ser considerada um recurso adicional no site: deve ser encarada como uma parte vital do design e do planejamento. O conjunto de melhores práticas a seguir oferece todas as informações necessárias para planejar, desenvolver e manter de maneira eficiente os servidores e aplicativos de seu site de comércio eletrônico. Desta forma, você garante a segurança de seu negócio e o protege contra uma grande variedade de vulnerabilidades. 8 TREND MICRO™ worry-free securesite | GUIA de melhores práticas | Capítulo 1: Melhores Práticas para Sites de Comércio Eletrônico 1 Segurança dos Sistemas Operacionais O sistema operacional é o programa de base que gerencia todos os recursos de hardware e software de um computador. Por se tratar de um programa muito complexo, um sistema operacional é dividido em diversos subsistemas, e cada um deles é responsável por uma tarefa específica. Esta complexidade e os milhões de linhas de código transformam o sistema operacional em um alvo em potencial para ataques. É muito importante levar em conta a segurança de um sistema operacional antes de decidir por sua instalação. As soluções e procedimentos de segurança a seguir ajudam a minimizar os efeitos das vulnerabilidades de segurança em um sistema operacional Windows. Instalação 1. Etapas da Instalação – O administrador deve inserir algumas informações durante o processo de instalação do Windows. As etapas abaixo devem ser definidas antes da instalação. • Sempre que possível, instale o servidor quando não estiver conectado à Internet ou protegido por um firewall. Isso vai proteger o servidor do tráfego intenso até que esteja completamente instalado, atualizado e configurado. • Compatibilidade de Hardware e Software – Sistemas operacionais mais novos demandam mais recursos de hardware. Antes do lançamento de um sistema operacional, a Microsoft divulga uma lista de hardware compatível. É importante verificar os drivers de todos os periféricos, especialmente se você estiver usando hardware legado, já que esses drivers também podem causar problemas de vulnerabilidade. o O Catálogo do Windows Server, que pode ser acessado em http://www.windowsservercatalog.com, contém uma lista de recursos de hardware e software compatíveis com o sistema operacional Windows. Os fabricantes de hardware testam seus próprios produtos e enviam os resultados das provas. Os fabricantes de software, por outro lado, enviam seus programas para que sejam testados pela equipe competente e recebam o logotipo do Windows. • Espaço em Disco – Planeje com antecedência e reserve espaço em disco suficiente para o sistema operacional e os aplicativos. Considere o espaço necessário para bancos de dados e logs. • Partições de Disco – Atualmente o tamanho dos discos rígidos varia de 40GB a 750GB para unidades IDE/SATA e de 37 GB a 1TB para unidades SCSI/SAS. É uma prática comum deixar o sistema operacional em um disco ou partição separado, reservando outro disco ou partição para os aplicativos e bancos de dados. • Sistema de Arquivos – O sistema de arquivos deve ser configurado como NTFS para permitir as configurações de segurança. Existe uma idéia errada e bastante difundida de que é mais fácil recuperar um sistema que usa uma partição FAT. Isso não é verdade. Um sistema FAT é menos seguro e sua recuperação não é fácil. NTFS oferece mais segurança por meio de direitos de acesso a arquivos e diretórios, além de suportar criptografia de arquivos. • Componentes de Serviço – Antes da instalação, decida quais serviços serão necessários para o sistema operacional. Para instalações de servidor, as opções podem incluir Active Directory, DNS, WINS ou DHCP. Procure instalar apenas os serviços que você vai precisar. TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 9 2. Escolha de Senha – é importante pensar bem sobre a senha de administrador antes da instalação. As instruções a seguir podem ser úteis para escolher uma senha segura: •Uma senha deve ter pelo menos 8 caracteres. A Microsoft recomenda 14 caracteres ou mais. •Use uma combinação de caracteres diferentes. Para ter mais segurança, misture letras maiúsculas, minúsculas, números e pontuação. Lembre-se: quanto menos tipos de caracteres você usar em sua senha, mais longa ela deve ser. 1 • Pense em palavras longas ou frases curtas que você se lembre facilmente, mas que sejam difíceis de adivinhar. Você também pode transformar a frase em uma senha mais segura. Exemplo: a frase “Minha filha Sofia faz aniversário em 25 de agosto!” pode ser usada como mfSfaem25A!. • Você também pode substituir letras por caracteres especiais. A letra “s” pode ser substituída por “$” e a letra “e” pode se transformar em “&”. Você pode até escrever com erros de ortografia para dar mais complexidade. • Verificadores de senhas on-line podem determinar a força de sua senha. O endereço abaixo é de uma ferramenta deste tipo da Microsoft: https://www.microsoft.com/protect/yourself/password/checker.mspx Figura 1 – Verificador de Senha da Microsoft 3. Escolha Apenas os Componentes de Serviços Necessários – Não instale um determinado componente de serviço se não tiver necessidade imediata. Na última etapa do procedimento de instalação do Windows, o sistema vai perguntar quais componentes você deseja instalar. Desmarque todas as opções desnecessárias. Como alguns dos itens são marcados por padrão, verifique a lista cuidadosamente e desmarque o que não for necessário para sua instalação. Figura 2 – Componentes do Windows 10 TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 4. Permissões de Diretórios Ativos – Se o servidor instalado for promovido a controlador de domínio, o Guia de Instalação de Diretórios Ativos vai exibir uma caixa de diálogo de Permissões, como mostrado na Figura 3. Se não houver sistemas operacionais legados (Windows 9x/NT) que precisem de acesso ao servidor, a segunda opção deve ser selecionada. Isso abre mão da compatibilidade com versões anteriores, para garantir mais segurança. Figura 3 – Permissões de Diretórios Ativos Pós-Instalação Depois de terminar a instalação do sistema operacional, você ainda precisará fazer mais coisas. Algumas delas podem demandar trabalho rotineiro e devem fazer parte das tarefas regulares de administração do servidor. Abaixo listamos alguns procedimentos de pós-instalação que reforçam a segurança de seu sistema operacional. 1. Instale o Service Pack e atualizações mais recentes – um Service Pack da Microsoft é uma coleção de correções para erros e falhas de segurança. É altamente recomendável usar um CD de instalação com o último Service Pack já incorporado, assim você vai precisar apenas fazer o download das atualizações mais recentes. Existe uma maneira de incorporar Service Packs e atualizações em seu CD de instalação. Esse procedimento é chamado de “slipstreaming”, e junta as atualizações aos arquivos de instalação de uma versão mais antiga em um CD. Isso otimiza o processo de instalação do SO, já que você não vai precisar instalar mais nada ao final do processo. Além disso, o administrador contará com instalação mais atualizada possível do sistema operacional. Para saber mais sobre este procedimento, visite: http://en.wikipedia.org/wiki/Slipstream_(computing). 2. Ative as Atualizações Automáticas do Windows – Quando as Atualizações Automáticas estão ativadas, o Windows verifica periodicamente se existem atualizações prioritárias que podem ajudar a proteger seu computador contra as últimas ameaças. Podem ser atualizações de segurança, críticas ou Service Packs. De acordo com suas configurações, o Windows automaticamente faz o download e instala as atualizações prioritárias, ou então avisa quando elas estão disponíveis. TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 11 1 1 Figura 4 – Ativar as Atualizações Automáticas do Windows Note que quando a atualização exige que o sistema seja reiniciado, isso será feito automaticamente. Se o computador é um servidor em produção que só pode ficar indisponível em horários programados, esta opção pode ser inviável. Para impedir que o sistema seja reiniciado automaticamente, ative a opção correspondente na tela de Windows Update, usando uma Diretiva de Grupo. a. Clique em Iniciar | Executar e digite gpedit.msc b. Em Diretiva Computador Local | Modelos Administrativos | Componentes do Windows | Windows Update, selecione “Não há reinícios automáticos nas instalações agendadas em Atualizações Automáticas” c. Marque a opção como Ativado d. Reinicie Figura 5 - Não há reinícios automáticos nas instalações agendadas em Atualizações Automáticas 3. Gerenciamento de Contas – Na medida do possível, evite a criação de contas de teste. Contas compartilhadas também podem causar confusão, especialmente durante a análise de logs de auditoria. Em uma empresa sem muitos recursos no departamento de TI, é muito comum a criação de contas duplicadas. Normalmente são contas com senhas fracas, que podem ser facilmente quebradas por programas de força bruta. Por fim, adote a prática de desabilitar contas inativas para evitar que elas sejam usadas sem o seu consentimento. 12 TREND MICRO™ worry-free securesite | GUIA de melhores práticas | • Se isso for permitido pelas políticas da empresa, crie e utilize uma conta de administração geral que pode ser usada para verificar e-mails e logs, além de executar outras tarefas cotidianas de administração. A conta embutida de administrador pode ser usada para qualquer tarefa que exija privilégios de administrador. Então, os aplicativos selecionados poderão rodar como processos do administrador por meio da conta correspondente. Esta configuração pode impedir que processos de malware rodem com privilégios de administrador. • Mudar o nome da conta embutida de administrador cria uma camada adicional de defesa, já que em vez de apenas descobrir a senha, o intruso também precisará determinar o nome de usuário do administrador. Como alternativa, a conta de administrador pode perder seus direitos administrativos e se transformar em um usuário sem privilégios. Dessa forma, em conjunto com a auditoria, você pode determinar se um intruso está tentando acessar seus servidores ao monitorar esta conta. 4. Senha – Dê muita importância à proteção com senha de todos os servidores e estações de trabalho quando houver inatividade. Instrua seus usuários a criar o hábito de bloquear suas estações de trabalho quando precisarem se ausentar. 5. Instale um Produto Antivírus e Anti-spyware, e o configure para realizar atualizações automáticas. Escolha um produto que ofereça administração sem preocupações e que cubra uma grande variedade de ameaças, como por exemplo, o Worry-Free Business Security mostrado na figura 6. Figura 6 – Trend Micro Worry-Free Business Security 6. Instale um firewall pessoal ou habilite o Windows Firewall. 7. Desabilite Serviços Desnecessários – Alguns serviços do Windows podem não ser necessários para instalação do servidor. Os serviços a seguir podem ser desabilitados na inicialização do servidor. • DHCP Client • Fax Service • Internet Connection Sharing • Intersite Message • Remote Registry Service • RunAs Service • Simple TCP/IP Services • Telnet •Utility Manager TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 13 1 8. Verifique se existem portas desnecessárias abertas. Você pode executar netstat –ab para determinar todas as portas locais abertas e por quais processos elas estão sendo utilizadas. •Utilize o firewall pessoal que você instalou para restringir o acesso a portas abertas. 1 •Utilize o filtro de TCP/IP para permitir ou negar explicitamente os protocolos TCP/UDP e ICMP para a interface específica de rede. 9. Habilite a Auditoria – Auditorias de segurança monitoram diversos eventos relacionados com segurança. É necessário monitorar os eventos do sistema para detectar invasões e tentativas de comprometimento de dados. Os tipos de eventos mais comuns que devem passar por auditoria são: • Acesso a objetos, como arquivos e pastas • Gerenciamento de usuários e de grupos de contas • Entrada e saída de usuários no sistema • Erro em uma tentativa de entrada Além da auditoria em eventos relacionados com segurança, um log específico é gerado quando esta opção está habilitada. Assim, você pode ver um relatório dos eventos identificados. Você pode acessar o log de segurança no Visualizador de Eventos. É possível habilitar a auditoria abrindo o menu Configurações Locais de Segurança e navegando por Configurações de Segurança | Diretivas Locais | Diretivas de Auditoria no menu à esquerda. Figura 7 – Configurações de Auditoria A tabela abaixo lista diversos eventos que devem passar por auditoria, além das ameaças de segurança específicas que tal evento monitora. 14 TREND MICRO™ worry-free securesite | GUIA de melhores práticas | Tabela 1 - Itens para Auditoria Evento de Auditoria Ameaça em Potencial Falha ao entrar/sair Acesso ilegal Sucesso ao entrar/sair Entrada por meio de senha roubada Sucesso para uso privilegiado, gerenciamento de usuários e grupos, mudança de políticas de segurança, reinício/desligamento do sistema e outros eventos Abuso de privilégios Sucesso e erro para acesso de arquivos e objetos, acesso de arquivos vitais por usuários ou grupos suspeitos Acesso indevido a arquivos vitais Sucesso e erro para impressão de arquivos e objetos, gerenciamento de impressoras e acesso de impressoras por usuários ou grupos suspeitos Acesso indevido a impressoras Sucesso e erro de acesso a arquivos de programas (com extensões .exe e .dll), acompanhamento de processos, execução de programas suspeitos, análise do log de segurança para identificar tentativas de modificar arquivos de programas ou criar processos inesperados. Executar apenas quando estiver monitorando ativamente o log de sistema. Ataque de vírus. 1 10. Evite que o nome do último usuário a entrar seja exibido na caixa de diálogo do Windows – Isso gera mais uma camada de proteção, já que o invasor será obrigado a adivinhar tanto o nome de usuário quanto a senha. Para isso, siga os procedimentos abaixo: a. Clique em Iniciar, depois em Executar, digite secpol.msc e clique em OK. b. Expanda o menu Configurações de Segurança. c. Expanda o menu Diretivas Locais, e depois clique em Opções de Segurança. d. No painel à direita, clique duas vezes em Logon Interativo: Não exibir o último nome do usuário. e. Clique em Ativado. f. Clique em OK e reinicie o computador. Para o Windows 2000, verifique o Artigo KB Q310125 da Microsoft. 11. Desabilite os Compartilhamentos-Padrão – Um compartilhamento que termina com “$” é um compartilhamento administrativo e está escondido para visão pela rede. Este compartilhamento administrativopadrão, que aponta para a raiz de cada partição, é criado automaticamente e pode significar um risco de segurança em potencial. Para desativar o compartilhamento administrativo, você pode: • Desativar o serviço do Servidor. Ao fazer isso, você não poderá compartilhar nenhum arquivo ou pasta no servidor. • Insira um valor DWORD de 0 chamado “AutoShareServer” em HKLM\System\CurrentControlSet\Services\LANManServer\Parameters. Tenha em mente que isso pode causar sérios efeitos colaterais em alguns aplicativos de rede. Tenha cuidado e assegure-se de que ao desativar o compartilhamento administrativo você não vai prejudicar aplicativos de rede já instalados. TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 15 1 12. Desative a geração de dump de memória – Um arquivo memory.dmp é uma gravação do status da memória em funcionamento no sistema operacional Windows. Este arquivo dump é gerado automaticamente quando um erro STOP, BSOD ou de verificação ocorre em seu servidor. Como se trata de algo muito útil para solucionar problemas no servidor, este arquivo normalmente é ignorado em verificações de segurança. Porém, ele contém informações importantes do sistema operacional, como senhas. Se um hacker conseguir acesso a um arquivo dump em um de seus servidores, ele pode ser usado para obter informações que podem facilitar uma invasão. Para desabilitar a criação de um arquivo de dump no Windows, abra a pasta Sistema no Painel de Controle. Na guia Avançado, selecione Inicialização e Recuperação. No menu dropdown de Gravando Informações de Depuração, selecione (nenhum). Figura 8 – Desabilitando a geração de Dump de Memória 13. Criptografe seu Sistema de Arquivo usando EFS – As unidades, pastas e arquivos do Windows podem ser criptografados por meio da função EFS (Encrypting File System). Alguns diretórios, como a pasta Temp, podem ser criptografados para evitar que invasores vejam arquivos que não foram apagados pelos processos que os usaram. Abaixo listamos as melhores práticas para usar a criptografia no Windows: Certifique-se de que os arquivos que você deseja criptografar foram criados e continuam criptografados • Criptografe pastas antes de criar arquivos importantes dentro delas, para garantir segurança máxima. Dessa forma, os arquivos já são criados como criptografados e seus dados nunca são gravados no disco como abertos. • Criptografe a pasta Meus Documentos caso você tenha o costume de gravar seus arquivos neste local. Com isso, você garante que seus documentos pessoais serão criptografados por padrão. Para usuários de Roaming, isso só deve ser feito quando a pasta Meus Documentos for redirecionada para um local de rede. • Criptografe pastas em vez de arquivos, para que arquivos temporários criados por programas também permaneçam criptografados. Gerencie chaves privadas para garantir a segurança dos arquivos • O agente de recuperação escolhido deve exportar o certificado de recuperação de dados e a chave privada para o disco, assegurar que eles estejam em um local seguro e apagar a chave privada da recuperação de dados do sistema. Desta forma, a única pessoa capaz de recuperar dados do sistema será a mesma que tiver acesso físico à chave privada da recuperação de dados. 16 TREND MICRO™ worry-free securesite | GUIA de melhores práticas | • O número de agentes de recuperação escolhidos deve ser o menor possível. Isso reduz a exposição de chaves aos ataques de criptografia e oferece um nível maior de garantia de que os dados criptografados não serão quebrados inadequadamente. •Use os Serviços de Certificados Microsoft para gerenciar os certificados de EFS e Data Recovery Agent (DRA) e as chaves privadas. 1 Garanta segurança e confiabilidade constantes para os dados • Criptografe os dados importantes em computadores que fazem parte de um domínio. Isso evita o comprometimento de dados por meio de ataques de criptografia off-line. •Use IPSec para garantir que os dados permaneçam criptografados durante a transmissão pela rede. Além disso, o EFS pode ser usado em conjunto com Web Distributed Authoring and Versioning (WebDAV) para armazenamento dos dados criptografados na Internet. • Faça backups regulares de todo o servidor que armazena os dados criptografados. Isso garante que, em caso de recuperação de dados, os perfis que incluem chaves de criptografia também poderão ser restaurados. Criptografe arquivos com a Restauração do Sistema desativada • Desative a Restauração do Sistema antes de criptografar arquivos que são monitorados por este recurso. Depois que a criptografia for finalizada, reative a Restauração do Sistema. Isso garante que os arquivos criptografados não sejam restaurados de maneira aberta. • Se você vai criptografar tipos de arquivos monitorados pela Restauração do Sistema, copie estes arquivos para um local não verificado por este recurso. 14. Bloqueio do Registro – Por padrão, o Registro do Windows pode ser acessado pela rede. Um hacker pode usar isso como ponto de entrada para invadir a rede ou injetar malware por meio da modificação de certas permissões. Para restringir o acesso da rede ao registro, siga os passos a seguir: a. Execute o Editor do Registro (Regedt32.exe) e acesse a subchave abaixo: HKLM\SYSTEM\CurrentControlSet\Control b. No menu Edit, clique em Add Key. Digite os valores a seguir: Nome da Chave: SecurePipeServers Classe: REG_SZ c. Acesse a subchave abaixo: HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers d. No menu Edit, clique em Add Value. Digite os valores a seguir: Nome da Chave: winreg Classe: REG_SZ e. Acesse a subchave abaixo: HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg f. No menu Edit, clique em Add Value. Digite os valores a seguir: Nome do Valor: Description Tipo de Dado: REG_SZ String: Registry Server g. Acesse a subchave abaixo: HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg h. Selecione “winreg”. Clique em Security e depois em Permissions. Adicione os usuários ou grupos para os quais deseja permitir o acesso. i. Saia do Editor do Registro e reinicie o Windows. j. Caso você deseje mudar a lista de usuários que podem acessar o registro, repita as etapas 10-12. TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 17 1 15. Limpe o Arquivo de Paginação ao desligar – Alguns programas de terceiros podem armazenar temporariamente na memória algumas informações importantes (como senhas) sem criptografia. Devido à arquitetura da memória virtual do Windows, estas informações podem estar presentes no Arquivo de Paginação. A limpeza do Arquivo de Paginação não é uma opção adequada para substituir a segurança física de um computador, mas isso pode aumentar a segurança dos dados quando o Windows não estiver sendo executado. Para limpar o Arquivo de Paginação ao desligar: a. Inicie o Editor do Registro (Regedt32.exe). b. Mude o valor de ClearPageFileAtShutdown na chave de registro a seguir para 1 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management. Se este valor não existir, adicione o seguinte valor: Nome do Valor: ClearPageFileAtShutdown Tipo do Valor: REG_DWORD Valor: 1 c. Esta mudança não entrará em efeito até que você reinicie o computador. 16. Proteção da Pilha TCP/IP – Os ataques de negação de serviço (DoS) visam deixar um computador ou um serviço específico indisponível para os usuários da rede. A proteção contra este tipo de ataque pode ser problemática. As tabelas a seguir explicam os valores do registro relacionados com TCP/IP que você pode configurar para proteger a pilha TCP/IP em computadores conectados diretamente à Internet. Todos estes valores devem ser criados na chave de registro a seguir, exceto se houver instrução diferente: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. Tabela 2 – Chave do Registro - A Chave HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\SynAttackProtect Tipo do Valor REG_DWORD Variação Válida 0(padrão),1,2 Descrição Este valor do registro leva o Transmission Control Protocol (TCP) a ajustar a retransmissão de SYN-ACKS. Quando você configura este valor, o tempo de resposta da conexão se esgota mais rápido durante um ataque SYN (um tipo de ataque de negação de serviço). A lista abaixo mostras os parâmetros que você pode usar neste valor do registro: 0: (valor-padrão): Defina SynAttackProtect como 0 para a proteção típica contra ataques SYN. 1: Defina SynAttackProtect como 1 para ter mais proteção contra ataques SYN. Com este parâmetro, o TCP ajusta a retransmissão de SYN-ACKS. Com o valor definido para 1, o tempo de resposta da conexão se esgota mais rápido se aparentemente há um ataque SYN em andamento. O Windows usa os valores a seguir para determinar se o sistema está sendo atacado: • TcpMaxPortsExhausted • TCPMaxHalfOpen • TCPMaxHalfOpenRetried Nota: A chave de registro TcpMaxPortsExhausted é obsoleta no Windows XP SP2 e versões posteriores. 2: Defina SynAttackProtect como 2 para a maior proteção contra ataques SYN. Este valor cria atrasos adicionais às indicações de conexão, e o TCP exige tempos curtos de resposta quando existe um ataque SYN em andamento. Este parâmetro é a configuração recomendada. Nota: As opções de socket a seguir deixam de funcionar quando você define o valor de SynAttackProtect como 2: • Janelas escalonáveis • Parâmetros de TCP que são configurados em cada adaptador (inclusive RTT inicial e tamanho da janela) 18 TREND MICRO™ worry-free securesite | GUIA de melhores práticas | Tabela 3 – Chave do Registro - B Chave HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableDeadGWDetect Tipo do Valor REG_DWORD Variação Válida 0,1 (padrão) 1 A lista abaixo mostra os parâmetros que você pode usar neste valor do registro: Descrição 1: Quando você define EnableDeadGWDetect como 1, o TCP pode realizar a detecção de gateway inativo. Dessa forma, o TCP pode solicitar ao Internet Protocol (IP) a mudança para um gateway de backup caso certo número de conexões passe por dificuldades. Gateways de backup são definidos na seção Avançado da caixa de diálogo para configuração do TCP/IP no Painel de Controle de Rede. 0: Recomendamos que você defina EnableDeadGWDetect como 0. Caso contrário, um ataque poderia forçar o servidor a trocar de gateway de maneira não planejada. Tabela 5 – Chave do Registro - D Chave HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime Tipo do Valor REG_DWORD (milissegundos) Variação Válida 1-0xFFFFFFFF, 7,200,000(Padrão=2horas) Descrição Este valor controla a freqüência com que o TCP tenta verificar se uma conexão ociosa ainda está intacta, por meio do envio de pacotes para manter a conexão ativa. Se a comunicação com o computador remoto ainda é possível, ele reconhece o pacote. O envio destes pacotes está desativado por padrão. Você pode usar um programa para configurar este valor em uma conexão. O valor recomendado é 300.000 (5 minutos). Tabela 6 – Chave do Registro - E Chave HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\NoNameReleaseOnDemand Tipo do Valor REG_DWORD Variação Válida 0(Padrão),1 Descrição Este valor determina se o computador vai liberar ou não seu nome de NetBIOS ao receber uma solicitação neste sentido. Este valor foi inserido para permitir que o administrador proteja o computador contra ataques maliciosos que solicitam a liberação do nome. Recomendamos que você defina o valor de NoNameReleaseOnDemand para 1 (o valor-padrão). Nota: Você deve possuir o Windows 2000 Service Pack 2 (SP2) ou superior para usar o valor de NoNameReleaseOnDemand. Referências: http://www.microsoft.com/technet/security/prodtech/windows2000/win2khg/default.mspx http://labmice.techtarget.com/articles/postinstall.htm http://www.servepath.com/support/win2003_securitychecklist.htm http://labmice.techtarget.com/articles/securingwin2000.htm http://support.microsoft.com/default.aspx/KB/324270 TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 19 Segurança do Servidor Web Serviços de Informação na Internet (IIS 6.0) 1 1. Faça o logon com as últimas credenciais. Faça o logon em seu computador usando uma conta que não está no grupo de Administradores, e então use o comando Executar como para executar o IIS Manager 2. Reduza a superfície de ataque. Desabilite todos os serviços que você não precisa, inclusive serviços IIS como FTP, NNTP ou SMTP. Se um recurso ou serviço estiver desabilitado, ele não vai demandar proteção. 3. Não faça o download nem execute programas de fontes não confiáveis. Programas podem conter instruções sobre diversas maneiras de violar a segurança, incluindo negação de serviço e roubo e destruição de dados. 4. Mantenha seus programas antivírus sempre atualizados. Estes programas freqüentemente identificam arquivos infectados por meio de uma assinatura que seja um componente conhecido de um vírus já identificado anteriormente. Os programas mantêm estas assinaturas de vírus em um arquivo específico, que normalmente se encontra no disco rígido local. Como novos vírus são descobertos dia após dia, este arquivo também deve ser atualizado freqüentemente para que o antivírus identifique os vírus atuais com mais facilidade. 5. Mantenha sempre seus recursos de software atualizados. Atualizações de software oferecem soluções para problemas conhecidos de segurança. Verifique os Websites dos fornecedores de software periodicamente para saber se existem atualizações disponíveis para os programas usados por sua organização. 6. O novo modelo de processamento no IIS 6.0 inclui reciclagem de processos, o que significa que um administrador pode instalar facilmente a maioria das atualizações de IIS e dos novos processos de DLLs sem nenhuma interrupção de serviço. 7. Auto Update versão 1.0 oferece três opções aos clientes: aviso no momento em que uma atualização fica disponível; download da atualização e notificação de que este download foi efetuado; e instalação programada. Para mais informações, veja a seção “Windows Automatic Updates” (Atualizações Automáticas do Windows) na ajuda do Windows Server 2003. 8. Use NTFS. O sistema de arquivos NTFS é mais seguro do que os sistemas FAT ou FAT32. 9. Conceda permissões NTFS sólidas para seus recursos. 10. Tenha cuidado com os controladores de domínio. Se você usa um controlador de domínio como um servidor de aplicativos, tenha em mente que a segurança fica comprometida neste controlador e conseqüentemente em todo o domínio. 11. Restrinja as permissões de acesso e gravação para a conta IUSR_computername. Dessa forma, você limita o acesso de usuários anônimos aos recursos de seu computador. 12. Guarde arquivos executáveis em um diretório separado. Dessa forma, fica mais fácil dar permissões de acesso e auditoria aos administradores. 13. Crie um grupo para todas as contas de usuários anônimos. Você pode negar o acesso aos recursos com base neste grupo. 14. Negue permissões de execução a usuários anônimos para todos os arquivos executáveis dos diretórios e subdiretórios do Windows. 20 TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 15. Use restrições de endereço IP se administrar o IIS remotamente. 16. Restrinja as permissões o máximo que puder. Por exemplo, se seu Website é usado apenas para ver informações, dê permissão de Somente Leitura. Em um diretório ou Website com aplicativos, dê permissões de Somente Scripts, em vez de permissões de Scripts e Executáveis. 17. Não dê permissões de acesso Escrever e Script à fonte, nem permissões de Scripts e Executáveis. Use esta combinação com extremo cuidado. Ela pode permitir que um usuário faça o upload e utilize arquivos executáveis com alto poder de destruição em seu servidor. 18. Habilite a criptografia de dados em todos os scripts de administração remota baseados em WMI. 19. Certifique-se de que o VeriSign Intermediate Root CA está atualizado em seu servidor Web. Verifique a data de expiração e atualize o Intermediate Root CA se necessário. O novo VeriSign Intermediate Root CA possui as propriedades a seguir: Emitido para: www.verisign.com/CPS Incorp.por Ref. LIABILITY LTD.(c)97 VeriSign Emitido por: Class 3 Public Primary Certification Authority Válido de: 16/04/97 a 24/10/11 Apache 2.0 1. Mantenha Atualizado – O Apache HTTP Server conta com um bom retrospecto de segurança e com uma comunidade de desenvolvimento bastante preocupada com questões de segurança. Porém, é inevitável que alguns problemas (pequenos ou grandes) sejam descobertos no software após o seu lançamento. Por isso, é fundamental manter o programa sempre atualizado. Se você obteve sua versão do HTTP Server diretamente com a Apache, recomendamos veemente que você assine o boletim Apache HTTP Server Announcements List, para ficar sempre informado sobre novos lançamentos e atualizações de segurança. Serviços similares são oferecidos pela maioria dos distribuidores autorizados de software Apache. É óbvio que na maioria das vezes em que um servidor é comprometido, isso ocorre devido a problemas no código HTTP Server. Ou então devido a problemas no código add-on, scripts CGI ou no Sistema Operacional de base. Por isso, você deve sempre ficar atento a problemas e atualizações relativos a todos os recursos de software em seu sistema. 2. Permissões nos Diretórios de Raiz do Servidor – Nas operações mais típicas, o Apache é inicializado pelo usuário raiz, e depois é alternado para o usuário definido pelas diretivas. Como este é o caso para qualquer comando executado pela raiz, você deve assegurar a proteção contra modificações feitas por outros usuários. O usuário raiz deve ser o único capaz de modificar arquivos, e o mesmo deve valer para todos os diretórios e raízes de todos os diretórios. Por exemplo, se você decide colocar a Raiz do Servidor em /usr/ local/apache, então a sugestão é criar este diretório como raiz, usando comandos assim: mkdir /usr/local/apache cd /usr/local/apache mkdir bin conf logs chown 0 . bin conf logs chgrp 0 . bin conf logs chmod 755 . bin conf logs Assume-se que /, /usr, e /usr/local podem ser modificados apenas pelo usuário raiz. Ao instalar o executável de httpd, você deve garantir uma proteção similar: cp httpd /usr/local/apache/bin chown 0 /usr/local/apache/bin/httpd chgrp 0 /usr/local/apache/bin/httpd chmod 511 /usr/local/apache/bin/httpd TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 21 1 Você pode criar um subdiretório htdocs que pode ser modificado por outros usuários – desde que o raiz nunca execute nenhum arquivo em outro lugar e nem crie arquivos neste subdiretório. 1 Se você permite que outros usuários modifiquem arquivos executados ou modificados pelo raiz, você expõe seu sistema a problemas. Por exemplo, alguém poderia substituir o HTTPd binário para causar a execução de código arbitrário na inicialização seguinte. Se o diretório de logs pode ser modificado por outros usuários, alguém poderia substituir um arquivo de logo com um symlink por outro arquivo de sistema, e então o raiz poderia sobrescrever tal arquivo com dados arbitrários. Se os próprios arquivos de log podem ser modificados por outros usuários, alguém poderia sobrescrever o log usando dados falsos. 3. Server Side Includes - Server Side Includes (SSI) apresenta um administrador de servidor com vários riscos potenciais de segurança. O primeiro risco é a carga elevada no servidor. Todos os arquivos habilitados para SSI devem ser analisados pelo Apache, mesmo se não houver diretivas SSI inclusas. Trata-se de um aumento de carga pequeno, mas que pode ficar significativo em um ambiente compartilhado. Arquivos SSI também impõem os mesmos riscos associados com scripts CGI em geral. Ao usarem o elemento “exec cmd”, os arquivos habilitados para SSI podem executar qualquer script CGI ou programa com permissões do usuário ou grupo do Apache conforme configuração no httpd.conf. Existem maneiras de aumentar a segurança de arquivos SSI sem abrir mão dos benefícios que eles oferecem. Para isolar os danos que um arquivo SSI malicioso pode causar, um administrador de servidor pode habilitar suexec como descrito na seção Geral em CGI. Habilitar SSI para arquivos com extensão .html pode ser perigoso. Isso é especialmente verdadeiro em um ambiente de servidor compartilhado ou com tráfego intenso. Arquivos com SSI habilitado devem ter uma extensão separada, como a convencional .shtml, por exemplo. Isso ajuda a manter a carga do servidor no menor nível possível e facilita o gerenciamento dos riscos. Outra solução é desabilitar a execução de scripts e programas nas páginas SSI. Para fazer isso, substitua ‘Includes’ por ‘IncludesNOEXEC’ na diretiva Opções. Tenha em mente que os usuários ainda podem usar <--#include virtual=”...” --> para executar scripts CGI, caso estes scripts estejam em diretórios definidos por uma diretiva ScriptAlias. 4. CGI no Geral – Em primeiro lugar, você sempre precisa se lembrar de que deve confiar nos criadores dos scripts/programas CGI ou então em sua habilidade de identificar falhas em potencial no CGI, não importa se deliberadas ou acidentais. Scripts CGI podem executar comandos essencialmente arbitrários em seus sistemas com as permissões do usuário do servidor Web. Dessa forma, representam um perigo extremamente grande caso não sejam verificados com cuidado. Todos os scripts CGI serão executados com o mesmo usuário, por isso eles têm potencial para entrar em conflito (por acidente ou deliberadamente) com outros scripts. Ex: o Usuário A odeia o usuário B, por isso ele cria um script para apagar o banco de dados CGI do Usuário B. suEXEC é um programa que pode ser usado para permitir a execução de scripts por usuários diferentes. Ele é incluído na versão 1.2 do Apache e acionado por ganchos especiais no código do servidor. Outra maneira popular de fazer isso é com o CGIWrap. 5. Script CGI Sem Alias – Permitir que usuários executem scripts CGI em qualquer diretório deve ser considerado apenas se: • Você confia que seus usuários não criarão scripts (por acidente ou deliberadamente) que podem expor seu sistema a um ataque. • Você considera a segurança em seu site tão frágil em outras áreas que mais uma falha em potencial seria irrelevante. • Você não tem usuários, e ninguém nunca visita o seu servidor. 22 TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 6. Script CGI com Alias – Limitar o CGI a diretórios específicos oferece ao administrador o controle sobre o que entra nestes diretórios. Isso é sempre mais seguro do que script CGI com alias, mas apenas se os usuários com privilégios de modificação nos diretórios são confiáveis ou se o administrador estiver disposto a testar qualquer novo script/programa CGI em busca de falhas de segurança. A maioria dos sites escolhe esta opção em detrimento de outras fontes de conteúdo dinâmico. Opções de scripts embutidos que são executados como parte do próprio servidor, como mod_php, mod_perl, mod_tcl e mod_python, também são executados sob a identidade do servidor (veja a diretiva Usuário). Por isso, os scripts executados por estes mecanismos podem acessar qualquer coisa que o usuário do servidor acessa. Alguns mecanismos de scripts podem oferecer restrições, mas é mais seguro assumir que isso não acontece. 7. Proteção das Configurações do Sistema – Para deixar as coisas em ordem, é uma boa idéia impedir que os usuários configurem arquivos .htaccess com recursos de segurança que você definiu. Esta é uma maneira de fazer isso: No arquivo de configuração do servidor, copie as instruções abaixo. Isso vai impedir o uso de arquivos .htaccess em todos os diretórios, exceto aqueles especificamente habilitados. <Directory /> AllowOverride None </Directory> 8. Proteção de Arquivos de Servidor por Padrão – Um aspecto do Apache que, às vezes, é mal compreendido é o recurso de acesso por padrão. Assim, se você não tomar medidas contrárias a isso, caso o servidor encontre o caminho até o arquivo por meio de regras normais de mapeamento URL, ele pode passar este caminho aos clientes. Por exemplo, considere o exemplo a seguir, que permitiria que os clientes passassem por todo o sistema de arquivos: # cd /; ln -s / public_html Accessing http://localhost/~root/ Para solucionar isso, adicione o bloco a seguir às configurações de seu servidor: <Directory /> Order Deny,Allow Deny from all </Directory> Isso vai proibir o acesso por padrão às localidades do sistema de arquivo. Adicione os bloqueios de Diretório apropriados para permitir o acesso apenas às áreas que você definir. Por exemplo, <Directory /usr/users/*/public_html> Order Deny,Allow Allow from all </Directory> <Directory /usr/local/httpd> Order Deny,Allow Allow from all </Directory> Preste muita atenção nas diretivas de Localidade e Diretório; por exemplo, mesmo que <Directory /> negue o acesso, a diretiva <Location /> pode reverter esta negação. Além disso, tenha cautela ao ‘brincar’ com a diretiva UserDir; defini-la como “./”, por exemplo, teria o mesmo efeito para a raiz do que o primeiro exemplo acima. Se você está usando o Apache 1.3 ou superior, recomendamos veementemente que inclua a linha a seguir em seus arquivos de configuração de servidor: UserDir disabled root TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 23 1 9. Verifique Seus Logs – Para acompanhar o que está acontecendo de verdade com o seu servidor, você deve sempre verificar os Arquivos de Log. Eles só mostram o que já aconteceu, mas mesmo assim oferecem um entendimento precioso sobre quais ataques foram lançados contra o servidor. Assim, você pode verificar se o nível necessário de segurança está presente. Alguns exemplos: 1 grep -c “/jsp/source.jsp?/jsp/ /jsp/source.jsp??” access_log grep “client denied” error_log | tail -n 10 O primeiro exemplo vai listar o número de ataques que tentou explorar o Apache Tomcat Source.JSP O segundo exemplo - Malformed Request Information Disclosure Vulnerability (Vulnerabilidade de Divulgação de Informação por Solicitação Inadequada) – vai listar os dez últimos clientes negados, por exemplo: [Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com] client denied by server configuration: /usr/ local/apache/htdocs/.htpasswd Como você pode ver, os arquivos de log só reportam o que já aconteceu, então caso o cliente tenha conseguido acessar o arquivo .htpasswd, você veria alguma coisa similar a: foo.bar.com - - [12/Jul/2002:01:59:13 +0200] “GET /.htpasswd HTTP/1.1” em seu Log de Acesso. Isso quer dizer que você provavelmente instruiu seu arquivo de configuração de servidor a ignorar o código a seguir: <Files ~ “^\.ht”> Order allow,deny Deny from all </Files> Referências: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/596cdf5a-c852-4b79b55a-708e5283ced5.mspx?mfr=true http://httpd.apache.org/docs/2.0/misc/security_tips.html Segurança dos Aplicativos Web Organizações como a OWASP (Open Web Application Security Project) e WASC (Web Application Security Consortium) oferecem padrões de melhores práticas de segurança amplamente aceitos na World Wide Web. Formadas por um grupo internacional de especialistas, estas organizações produzem materiais de Fonte Aberta, para que pessoas e organizações fiquem sempre informadas sobre os riscos de segurança para usuários da Web. Listamos a seguir oito dos principais problemas que afetam a segurança dos Aplicativos Web. Várias técnicas são utilizadas pelos invasores que se aproveitam de cada uma dessas vulnerabilidades. Assim, há muito que discutir sobre cada tópico. Recomendamos uma visita a http://www.webappsec.org/ e http://www.owasp.org para saber mais sobre como estes problemas são explorados. Também incluímos abaixo um link com uma possível solução para estas vulnerabilidades. 1. Cross-Site Scripting - A maioria dos especialistas e pesquisadores de segurança concorda que o cross-site scripting (XSS) continua sendo a vulnerabilidade mais comum nos Web sites. O XSS pode causar danos muito grandes às empresas e consumidores. Novos vetores de ataque estão sendo utilizados e são responsáveis por grandes fraudes de phishing e worms, que conseguem superar estratégias de proteção comumente aceitas. O uso de tecnologia JavaScript de ponta para a criação de malware transformou a identificação e solução deste tipo de vulnerabilidade em algo mais vital do que nunca. http://www.owasp.org/index.php/Cross_Site_Scripting 24 TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 2. Vazamento de Informações – Um vazamento de informações ocorre quando um site revela por engano (ou é manipulado para revelar) informações sensíveis como comentários do programador, dados dos usuários, endereços de IP internos, código fonte, números de revisão, mensagens/códigos de erro, etc. Tudo isso pode ajudar um invasor. http://www.webappsec.org/projects/threat/classes/information_leakage.shtml 3. URL Previsível - Com o passar do tempo, várias páginas de um site podem ficar isoladas, órfãs e esquecidas. Estas páginas freqüentemente contêm logs de pagamento, backups de software, conteúdo ainda não divulgado, mensagens de debug ou código fonte. Normalmente, o único mecanismo de proteção ao conteúdo destas páginas é a previsibilidade da URL. Programas automáticos já conseguem identificar estes arquivos por meio de milhares de tentativas aleatórias. Além disso, por meio de um processo chamado “Google Hacking”, os hackers conseguem usar mecanismos de busca para descobrir informações importantes em links esquecidos de um site. http://www.webappsec.org/projects/whid/byclass_class_attack_method_value_predictable_resource_location.shtml 4. Injeção de SQL - Ataques de Injeção de SQL estão por trás de alguns dos maiores incidentes de roubo de identidade e dados de cartões de crédito. Hoje, os bancos de dados backend dos Web sites armazenam muitas informações confidenciais, e por isso são um alvo natural para os criminosos virtuais. Os dados vulneráveis podem incluir nomes, endereços, telefones, senhas, datas de nascimento, propriedade intelectual, segredos comerciais, chaves de criptografia e muito mais. Com alguns códigos de comando bem executados, bancos de dados inteiros podem parar nas mãos erradas. http://www.owasp.org/index.php/SQL_injection 5. Autenticação Insuficiente - Falhas de autenticação insuficiente são normalmente encontradas dentro da lógica de negócios de um aplicativo. Se esta falha for explorada com sucesso, o hacker pode ganhar acesso a seções protegidas de um site. Por exemplo, mesmo logado como um usuário normal, o criminoso pode personificar outro usuário no sistema. http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml 6. Autorização Insuficiente - Falhas de autorização insuficiente também são normalmente encontradas dentro da lógica de negócios de um aplicativo. Um hacker bem-sucedido ao explorar esta vulnerabilidade pode escalonar seus próprios privilégios e acessar áreas proibidas. Por exemplo, mesmo logado como um usuário normal, o criminoso pode ganhar acesso aos dados de outro usuário. http://www.webappsec.org/projects/threat/classes/insufficient_authorization.shtml 7. Indexação de Diretório - Um recurso muito popular em vários servidores Web, a indexação de diretórios lista o conteúdo de um diretório se nenhum nome de arquivo específico é selecionado e se não existe um arquivo index (exemplo: index.html). A lista de conteúdo de um diretório pode revelar informações que não deveriam ser divulgadas, como páginas ainda não lançadas, arquivos de log, arquivos temporários, arquivos de backup, etc. http://www.webappsec.org/projects/threat/classes/directory_indexing.shtml 8. Injeção de Xpath - A Injeção de XPath é uma técnica de ataque similar à Injeção de SQL, usada para explorar sites que constroem queries XPath a partir de informações inseridas pelos usuários. Quando um hacker consegue modificar uma query XPath, ele pode obter informações confidenciais a partir de um documento XML que de outra maneira estaria fora de seu alcance. http://www.owasp.org/index.php/XPath_Injection_Testing_AoC TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 25 1 Segurança do Banco de Dados 1 SQL Server Abaixo apresentamos um resumo das melhores práticas de segurança recomendadas pela Microsoft para o SQL 2005. Para mais informações, é possível fazer o download do documento completo em http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/SQL2005SecBestPract.doc. 1. Melhores práticas para redução da área de superfície • Instale apenas os componentes que você vai usar imediatamente. Componentes adicionais sempre podem ser instalados quando necessário. • Habilite apenas os recursos opcionais que você vai usar imediatamente. • Revise o uso de recursos opcionais antes de fazer uma atualização e desative o que for desnecessário antes ou depois desta atualização. • Crie uma política para definir as escolhas permitidas de conectividade de rede. Use uma Configuração de Área de Superfície no SQL Server para padronizar esta política. • Crie uma política para o uso de recursos adicionais. Use uma Configuração de Área de Superfície no SQL Server para padronizar a habilitação destes recursos. Documente individualmente qualquer exceção a esta política. • Desative qualquer serviço desnecessário marcando este serviço para inicialização manual ou como desativado. 2. Melhores práticas para contas de serviço SQL Server •Use uma conta de usuário ou uma conta de domínio específica para serviços do SQL Server, em vez de uma conta compartilhada. •Use uma conta separada para cada serviço. • Não atribua nenhum privilégio especial a uma conta de serviço do SQL Server; esses privilégios serão atribuídos a grupos de membros. • Gerencie os privilégios por meio do grupo de contas oferecido pelo SQL Server, em vez de usar contas de serviço de usuários individuais. • Sempre use o Gerenciador de Configuração do SQL Server para mudar contas de serviço. • Mude a senha das contas de serviço periodicamente. •Use CREDENCIAIS para executar as etapas do trabalho que demandam privilégios específicos, em vez de ajustar os privilégios de uma conta de serviço do SQL Server Agent • Se um usuário agente precisa executar um trabalho que demanda credenciais diferentes no Windows, atribua a ele uma conta proxy apenas com as permissões suficientes para a realização da tarefa. 3. Melhores práticas para o modo de autenticação • Use o modo de autenticação do Windows sempre que possível. •Use autenticação do tipo Mixed-Mode apenas para aplicativos legados e usuários que não são do Windows. •Use as frases-padrão de login DLL, em vez de procedimentos de sistema de compatibilidade. • Altere a senha da conta sa para um valor conhecido, caso você precise usá-la em algum momento. Sempre use uma senha segura para a conta sa, e altere esta senha periodicamente. • Não gerencie o SQL Server usando a conta sa; atribua o privilégio sysadmin apenas para usuários ou grupos conhecidos. • Dê um nome diferente para a conta sa para evitar ataques nominais a esta conta. 26 TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 4. Melhores práticas para conectividade de rede • Limite os protocolos de rede suportados. • Não habilite protocolos de rede que não são necessários. • Não exponha um servidor rodando o SQL Server à Internet pública. • Configure instâncias nomeadas do SQL Server para usar portas TCP/IP específicas, em vez de portas dinâmicas. • Se for necessário suportar logins SQL, instale um certificado SSL de uma autoridade confiável, em vez de usar os certificados próprios do SQL Server 2005. •Use “permitir apenas conexões criptografadas” apenas se for necessária criptografia completa em sessões críticas. • Conceda permissão de conexão apenas aos endpoints realmente necessários. Negue explicitamente conexão aos endpoints que não são necessários aos usuários ou grupos. 5. Melhores práticas para procedimentos armazenados do sistema • Desabilite xp_cmdshell, exceto se for absolutamente necessário. • Desabilite os componentes COM quando todos eles forem convertidos para SQLCLR. • Desabilite ambos os procedimentos de correio (Database Mail e SQL Mail) exceto se for necessário enviar e-mails a partir do SQL Server. Prefira o Database Mail assim que a conversão for possível. •Use uma Configuração de Área de Superfície no SQL Server para estabelecer uma política-padrão para o uso de procedimentos estendidos. • Documente toda e qualquer exceção à política-padrão. • Não remova os procedimentos armazenados do sistema simplesmente os soltando. • Não negue acesso aos procedimentos estendidos a todos os usuários/administradores. 6. Melhores práticas para política de senhas • Estabeleça uma rígida política de senhas para sua organização, incluindo períodos de validade e complexidade. • Se precisar usar SQL logins, certifique-se de que o SQL Server 2005 roda no sistema operacional Windows Server 2003, e use políticas de senha. • Equipe seus aplicativos com um mecanismo que muda as senhas de SQL login. •Use MUST_CHANGE para novos logins. 7. Melhores práticas para o administrador de privilégios •Use o administrador de privilégios apenas quando for necessário • Minimize o número de administradores. • Defina explicitamente os principais administradores. • Tenha múltiplos administradores distintos caso precise de mais de um. • Evite dependência do grupo de administradores incluído no Windows. 8. Melhores práticas para propriedade e confiança do banco de dados • Conte com diferentes proprietários para os bancos de dados, nem todos devem ser propriedade da sa. • Minimize o número de proprietários de cada banco de dados. • Tenha cuidado ao atribuir confiança. • Desative a configuração Cross-Database Ownership Chaining (Encadeamento de Propriedade de Bancos de Dados Cruzados) exceto se existem múltiplos bancos de dados em uma mesma unidade. • Promova a migração do uso para a confiança seletiva, em vez de usar a propriedade TRUSTWORTHY. TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 27 1 9. Melhores práticas para o uso de esquemas • Agrupe objetos similares no mesmo esquema • Administre a segurança do banco de dados de objetos usando propriedades e permissões baseadas em esquemas. 1 • Tenha proprietários distintos para os esquemas. • Nem todos os esquemas devem ser propriedade de dbo. • Minimize o número de proprietários de cada esquema. 10. Melhores práticas para autorização de objeto de banco de dados • Divida o acesso dentro dos módulos. • Administre as permissões por meio de funções no banco de dados ou grupos do Windows. •Use as permissões granulares para implementar o princípio do privilégio mínimo. • Não permita o acesso de convidados. •Utilize usuários sem logins em vez de funções de aplicativo. 11. Melhores práticas para a segurança do catálogo • O acesso ao catálogo já é seguro por padrão. Nenhuma ação adicional de segurança é necessária. • Selecione as permissões VIEW DEFINITION de acordo com o objeto, esquema, banco de dados ou nível de servidor para conceder permissão de visualização aos metadados do sistema sem oferecer permissões adicionais. • Verifique os aplicativos legados que podem depender do acesso aos metadados do sistema durante a migração para o SQL Server 2005. 12. Melhores práticas para execução de fontes remotas de dados • Reduza progressivamente todas as definições remotas do servidor. • Substitua servidores remotos por servidores interligados. • Desative queries ad hoc por meio de servidores interligados, exceto se forem absolutamente necessárias •Use delegação forçada se for necessário contar com autenticação pass-through em um servidor interligado. 13. Melhores práticas para o contexto de execução • Defina o contexto de execução para cada módulo, em vez de usar as configurações-padrão. •Use EXECUTE AS em vez de SETUSER. •Use WITH NO REVERT/COOKIE em vez de funções de aplicativo. • Considere o uso de assinatura de código de programação procedural caso o procedimento demande um único privilégio granular adicional. 14. Melhores práticas para a criptografia de dados • Criptografe todos os dados de alto valor e críticos. •Use chaves simétricas para criptografar os dados, e chaves assimétricas ou certificados para proteger as chaves simétricas. • Proteja as chaves com senhas e remova a criptografia da chave mestra para contar com a configuração mais segura. • Sempre faça backup da chave mestra do serviço, chaves mestras do banco de dados e dos certificados por meio de declarações de DDL específicas para chaves. • Sempre faça backup de seu banco de dados para proteger suas chaves simétricas e assimétricas. 28 TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 15. Melhores práticas para auditoria • As auditorias são específicas para cada cenário. Equilibre as necessidades de auditoria com a geração de dados adicionais. • Faça auditorias de logins com e sem sucesso caso você armazene dados críticos. 1 • Faça auditorias de DDL e eventos específicos do servidor usando rastreamento ou notificações de eventos. • A auditoria de DML deve ser feita por meio de rastreamento de eventos. •Use WMI para receber alertas sobre eventos de emergência. • Habilite a auditoria C2 ou conformidade com Common Criteria apenas se necessário. 16. Melhores práticas para atualização do SQL Server • Faça atualizações sempre que possível. • Habilite as atualizações automáticas sempre que houver possibilidade, mas teste as atualizações antes de aplicá-las aos sistemas em produção. TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 29 Capítulo 2: Manutenção da segurança de seu site de comércio eletrônico com Trend Micro SecureSite 2 Trend Micro™ SecureSite é um serviço empresarial hospedado, voltado para a identificação e gerenciamento de vulnerabilidades. O SecureSite identifica falhas de segurança em todas as camadas de um ambiente de rede, e oferece informações sobre vulnerabilidades, avaliação de riscos e possíveis soluções. O SecureSite usa a rede para verificar componentes específicos de acordo com endereços IP ou nomes de host, por isso é capaz de oferecer relatórios sobre as vulnerabilidades da rede e ainda opções de correção destas falhas de segurança usando a quantidade mínima de recursos. Se as vulnerabilidades do site não forem corrigidas, elas podem ser exploradas pelos hackers para comprometer os dispositivos de rede. Em um site de comércio eletrônico, isso pode comprometer significativamente sua reputação e credibilidade, uma vez que o cartão de crédito é a forma de pagamento mais utilizada nas transações on-line. Como o Trend Micro SecureSite funciona O SecureSite verifica Web sites, aplicativos, servidores de bancos de dados e sistemas operacionais em busca de vulnerabilidades. Quando possui privilégios administrativos, o SecureSite pode realizar inspeções mais profundas nos recursos do sistema para detectar programas não autorizados, validar atualizações e identificar worms. Esta versão do SecureSite suporta duas tarefas dos usuários: • Site Summary (Resumo do Site) – Verifica a Home Page de sua conta SecureSite para visualização das vulnerabilidades detectadas nos últimos quatro meses. Você também pode ver uma lista de todos os seus sites que estão configurados para passar pela inspeção do SecureSite. • Reports (Relatórios) – O SecureSite oferece dois tipos de relatórios: Executive Summary (Resumo Executivo) e Remediation Plan (Plano de Reparo). Os relatórios são gerados automaticamente em formato PDF quando uma verificação de vulnerabilidade é completada. Arquitetura O SecureSite trabalha em conjunto com os sites que verifica. Quando um revendedor ou usuário assina o serviço, o FQDN ou Endereço IP do site é inserido no banco de dados WFSS. Então, o site é verificado periodicamente. A arquitetura WFSS é explicada abaixo: 31 2 Figura 9. Arquitetura do Trend Micro SecureSite O Trend Micro SecureSite opera na Internet, verificando os principais dispositivos, sistemas e aplicativos do site. Isso inclui os recursos a seguir: • Sites Individuais • O Sistema Operacional: • O Servidor de Aplicativos • Aplicativos e Arquivos Sites com múltiplos servidores também são verificados (EX: Servidor B), o que oferece avaliação de uma ampla variedade de vulnerabilidades. Principais Recursos e Benefícios Trend Micro SecureSite oferece recursos e benefícios importantes para gerentes de Web site, revendedores e usuários finais que possuem sites comerciais: • Protege a reputação e aumenta a credibilidade de um site. • Avalia o site por meio de análises constantes de vulnerabilidade, para ajudar na prevenção de ataques como invasões, injeções de SQL, cross-site scripting ou atividades de bot. • Monitora vulnerabilidades em múltiplos aplicativos web, bancos de dados e sistemas operacionais, em busca de vulnerabilidades e falhas de segurança que podem ser exploradas pelos hackers. • Mostra o status de segurança do site com alertas on-line e por e-mail, incluindo relatórios sobre os principais riscos e vulnerabilidades, boletins e avaliações de políticas. • Permite que você resolva seus problemas rapidamente por meio de dicas de soluções disponíveis em uma lista de vulnerabilidades em constante crescimento. • Não é necessário instalar nenhum software. Trend Micro SecureSite é uma solução hospedada, mantida e atualizada pela Trend Micro. Ou seja, os sites estão protegidos pelas tecnologias mais modernas. • O SecureSite conta com um console Web on-line para oferecer uma visão geral das vulnerabilidades, além de uma lista de relatórios executivos e planos para a solução de problemas como explicado na tabela a seguir. 32 TREND MICRO™ worry-free securesite | GUIA de melhores práticas | Tabela 7. Principais Funções do Console Web do SecureSite 1.0 Função Descrição Interface On-line: Resumo do Site Gráficos On-line: Sites mais vulneráveis, ao longo do tempo Lista On-Line: Lista de sites verificados por nome, vulnerabilidades, risco atual e última verificação. Relatório: Resumo Executivo Relatório em PDF: Relatório detalhado de status dos sistemas verificados, incluindo vulnerabilidades por severidade ou por serviço. Plano de Solução Relatório em PDF: Relatório consolidado de vulnerabilidades, com plano otimizado para solução. O banco de dados interno do SecureSite mantém uma lista atualizada de todas as atualizações e correções, com indicação das vulnerabilidades específicas. O relatório determina a vulnerabilidade, oferece a solução, e estima o tempo que será gasto para solucionar o problema. 2 Além disso, o SecureSite verifica e oferece proteção contra uma ampla variedade de vulnerabilidades e ameaças Web, como mostrado na tabela abaixo: Tabela 8. Vulnerabilidades Detectadas pelo SecureSite Categoria Vulnerabilidade Descrição Mecanismos de Fraude/Phishing Cross-Site Scripting Permite fraudes de phishing, a vulnerabilidade mais comum dos Web sites Vazamento de Informações Revela informações críticas (comentários do programador, dados dos usuários, endereços IP, códigos fonte, etc.) aos criminosos URL Previsível Busca informações críticas em sites por meio da verificação de páginas esquecidas. Injeção de SQL Rouba informações de bancos de dados ao inserir códigos nos sites e serve de base para os grandes ataques contra cartões de crédito. Indexação / Transversal de Diretórios Lista as páginas web que não devem ser expostas ao público, por meio do uso de um recurso comum de servidor web. Injeção de XPath Expõe documentos XML com informações críticas aos criminosos. Autorização Insuficiente Permite que usuários não autorizados tenham acesso a áreas protegidas do site. Buffer Overflow Explora as vulnerabilidades do site para assumir controle completo de um servidor e executar atos maliciosos. Vazamento de Dados Uso Não Autorizado TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 33 Manutenção da postura de segurança de seu site de comércio eletrônico com Trend Micro SecureSite 2 Os procedimentos a seguir podem servir como guia para que um dono de Web site aproveite plenamente o Trend Micro SecureSite. 1. Consulte o Guia do Revisor e Guia Rápido relativos ao SecureSite para conhecer os procedimentos de registro e configurações iniciais. 2. O arquivo robots.txt ou “The Robots Exclusion Protocol” ajuda na prevenção contra spiders ou webcrawlers conhecidos em um servidor web. O arquivo fica no diretório base do host do site, onde é facilmente acessado por qualquer bot ou scanner. Este arquivo pode prejudicar a ação do Worry Free SecureSite contra spiders, pois pode limitar os diretórios verificados. É fundamental que o leitor entenda que qualquer mudança no arquivo robot.txt é capaz de afetar o comportamento de webspiders de terceiros com relação ao site, e por isso pode causar efeitos indesejados. Por exemplo, menos visibilidade na Internet ou efeitos negativos em outras funcionalidades de marketing. Uma das maneiras de configuração do arquivo robots.txt está explicada a seguir: User-agent: * Disallow: /cgi-bin Disallow: /search Disallow: /query.html Disallow: /mailform.html Esta configuração sugere que qualquer agente webspider é autorizado a acessar o site, mas não os diretórios e arquivos da lista na diretiva “Disallow”. Assim, eles se transformam em elementos de um arquivo robots.txt. Informações relevantes sobre o arquivo robots.txt podem ser encontradas nas URLs abaixo: http://www.whitehouse.gov/robots.txt http://www.robotstxt.org 3. O serviço SecureSite pode enviar relatórios executivos e de solução de problemas ao final de cada verificação. Isso depende da freqüência de verificações e do tipo de relatório que você especificou ao registrar o produto. 4. O assunto do e-mail de notificação do SecureSite vai mostrar um resumo das vulnerabilidades encontradas durante a verificação. Dessa forma, você saberá quando precisa tomar alguma atitude apenas pelo título do e-mail. As vulnerabilidades mais sérias demandam ações imediatas. Figure 10 – E-mail de notificação do WFSS Notification 34 TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 5. O Resumo Executivo (Executive Summary), mostrado no Apêndice A, oferece uma visão geral do status de seus recursos de rede. Esse resumo mostra uma descrição das vulnerabilidades de acordo com sua gravidade, além de uma lista por tipo de aplicativo e protocolo. A Tendência de Vulnerabilidades (Vulnerability Trend) mostra a progressão do número de vulnerabilidades em comparação com as verificações anteriores. Dessa forma, você pode determinar e correlacionar qualquer ato administrativo recente (como instalar um novo serviço de rede, por exemplo) com as novas vulnerabilidades encontradas. 2 Preste atenção à descrição das vulnerabilidades com base nas categorias. Isso ajuda na definição do plano para solução dos problemas, já que mostra a você qual aplicativo está mais vulnerável. 6. O Relatório de Solução (Remediation Report), mostrado no Apêndice B, lista o número de etapas e o tempo estimado para a solução das vulnerabilidades recém encontradas. Recomendamos a leitura completa do relatório, para conhecer as melhores maneiras de aplicar efetivamente as mudanças em seus servidores. Além disso, cada dispositivo recebe um índice de risco. Assim, você pode dar prioridade ao host que tem mais chances de ser comprometido. Cada vulnerabilidade encontrada em um host ainda é resumida e recebe pesos (fatores de risco), assim você saberá qual vulnerabilidade deve priorizar em cada host. Figura 11 – Relatório de Solução com Fatores de Risco 7. Após seguir os procedimentos do plano de solução, você poderá relaxar e esperar pela próxima avaliação. Se tudo correr bem, você terá um site muito mais preparado para lidar com as ameaças da Internet. 8. Após a finalização do Plano de Solução e a verificação seguinte, seu site receberá um selo com o logo do Trend Micro SecureSite, uma indicação de que seu site é certificado pelo produto. Figura 12 – Selo de Certificação do Trend Micro SecureSite TREND MICRO™ worry-free securesite | GUIA de melhores práticas | 35 Apêndice A – Amostra Executiva Geral RESUMO EXECUTIVO MEU SITE DE COMÉRCIO ELETRÔNICO Auditoria realizada em 17 de abril de 2008, PDT Relatório em 17 de abril de 2008, PDT 37 38 39 Apêndice B – Amostra de Plano de Remediação PLANO DE REMEDIAÇÃO MEU SITE DE COMÉRCIO ELETRÔNICO Auditoria realizada em 17 de abril de 2008, PDT Relatório em 17 de abril de 2008, PD 41 42 43 44 45
