SecureSite - Trend Micro SMB

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