Recentemente (mas também é uma pergunta recorrente), vimos três tópicos interessantes sobre hackers e segurança:

Como faço para lidar com um servidor comprometido? .
Localizando como um servidor invadido foi invadido
Pergunta sobre permissões de arquivo

O último não está diretamente relacionado, mas destaca como é fácil atrapalhar a administração de um servidor web.

Como existem várias coisas que podem ser feitas, antes que algo ruim aconteça, gostaria de receber suas sugestões em termos de boas práticas para limitar os efeitos colaterais de um ataque e como reagir no caso triste acontecerá.

Não se trata apenas de proteger o servidor e o código, mas também de auditoria, registro e contramedidas.

Você tem alguma lista de boas práticas ou prefere confiar em software ou em especialistas que analisam continuamente seus servidores da Web (ou nada)?

Se sim, você pode compartilhar sua lista e suas idéias / opiniões?

ATUALIZAR

Recebi vários comentários bons e interessantes.

Eu gostaria de ter uma lista simples, para que possa ser útil para os administradores de segurança de TI, mas também para os mestres de fatos da web .

Mesmo que todo mundo desse respostas boas e corretas, no momento eu prefiro a de Robert , pois é a mais simples, clara e concisa, e a de sysadmin1138, como a mais completa e precisa.

Mas ninguém considera a perspectiva e a percepção do usuário, acho que é a primeira a ser considerada.

O que o usuário pensará quando visitará meu site invadido, e muito mais se você possui dados confidenciais sobre eles. Não é apenas uma questão de onde armazenar dados, mas como acalmar usuários irritados.

E quanto a dados, mídias, autoridades e concorrentes?

Existem duas grandes áreas para focar:

1. Tornando difícil entrar.
2. Criação de políticas e procedimentos para lidar com calma e eficiência no caso de alguém entrar no ponto 1 anterior.

Tornando difícil entrar

Este é um tópico muito complexo, e grande parte dele se concentra em garantir que você tenha informações suficientes para descobrir se o WTF aconteceu após o fato. O marcador abstrato aponta para simplicidade:

• Manter registros (consulte também, Gerenciamento de eventos de informações de segurança)
  • Qualquer tentativa de autorização, bem-sucedida e com falha, de preferência com as informações de origem intactas.
  • Logs de acesso ao firewall (pode ser necessário incluir firewalls por servidor, se estiver em uso).
  • Logs de acesso ao servidor da Web
  • Logs de autenticação do servidor de banco de dados
  • Logs de uso específicos do aplicativo
  • Se possível, o SIEM pode emitir alertas sobre padrões suspeitos.
• Impor controles de acesso adequados
  • Certifique-se de que os direitos sejam definidos corretamente em todos os lugares e evite "direitos preguiçosos" ("oh, apenas deixe todo mundo ler") sempre que possível.
  • Auditorias periódicas das ACLs para garantir que os procedimentos estejam realmente sendo seguidos e as etapas temporárias de solução de problemas ("deixe todo mundo ler, veja se funciona então") foram removidas corretamente após a conclusão da solução de problemas.
  • Todas as regras de passagem do firewall precisam ser justificadas e auditadas periodicamente.
  • Os controles de acesso ao servidor da Web também precisam ser auditados, tanto para as ACLs do servidor quanto do sistema de arquivos.
• Impor gerenciamento de mudanças
  • Quaisquer alterações no ambiente de segurança precisam ser rastreadas e revisadas centralmente por mais de uma pessoa.
  • Patches devem ser incluídos nesse processo.
  • A criação de um modelo comum de sistema operacional simplificará o ambiente e facilitará o rastreamento e a aplicação das alterações.
• Desativar contas de convidado.
• Verifique se todas as senhas não estão definidas como padrões.
  • Aplicativos prontos para uso podem configurar usuários com senhas predefinidas. Mude-os.
  • Muitos dispositivos de TI são fornecidos com pares de usuário / senha muito conhecidos. Altere-os, mesmo se você fizer login apenas uma vez por ano.
• Pratique menos privilégios. Dê aos usuários o acesso que eles realmente precisam.
  • Para usuários Admin, uma configuração de duas contas é sábia. Uma conta comum usada para email e outras tarefas do escritório, e uma segunda para trabalho privativo elevado. As VMs facilitam a convivência.
  • NÃO incentive o uso regular de contas de administrador / raiz genéricas, é difícil rastrear quem estava fazendo o que quando.

Criar políticas e procedimentos para lidar com calma e eficiência com o evento de alguém entrar

Uma política de eventos de segurança é essencial para todas as organizações. Isso reduz bastante a fase de resposta "correr por aí com a cabeça decepada", pois as pessoas tendem a ficar irracionais quando confrontadas com eventos como esses. Intrusões são assuntos grandes e assustadores. A vergonha de sofrer uma intrusão pode fazer com que os administradores de sistemas, de outra maneira, comecem a reagir de maneira incorreta.

Todos os níveis da organização precisam estar cientes das políticas. Quanto maior o incidente, maior a probabilidade de a alta gerência se envolver de alguma maneira, e a definição de procedimentos para lidar com as coisas ajudará muito a evitar a "ajuda" do alto. Também fornece um nível de cobertura para os técnicos diretamente envolvidos na resposta a incidentes, na forma de procedimentos para a gerência intermediária interagir com o restante da organização.

Idealmente, sua política de Recuperação de Desastres já definiu por quanto tempo certos serviços podem ficar indisponíveis antes que a política de DR entre em ação. Isso ajudará na resposta a incidentes, pois esses tipos de eventos são desastres. Se o evento for de um tipo em que a janela de recuperação NÃO será atendida (exemplo: um site de recuperação de desastres de backup ativo recebe um feed em tempo real dos dados alterados, e os invasores excluíram um monte de dados que foram replicados no site de recuperação de desastres antes de serem restaurados Portanto, os procedimentos de recuperação a frio precisarão ser utilizados) e a alta gerência precisará se envolver nas negociações de avaliação de riscos.

Alguns componentes de qualquer plano de resposta a incidentes:

• Identifique os sistemas comprometidos e os dados expostos.
• Determine desde o início se as evidências legais precisam ou não ser mantidas para uma eventual ação judicial.
  • Se for necessário reter evidências , não toque em nada sobre esse sistema, a menos que seja absolutamente necessário . Não efetue login. Não peneire os arquivos de log. Faz. Não. Toque.
  • Para que as evidências sejam mantidas, os sistemas comprometidos precisam ficar online, mas desconectados até que um especialista em computação forense certificado possa dissecar o sistema de maneira compatível com as regras de manipulação de evidências.
    • Desligar um sistema comprometido pode manchar os dados.
    • Se o seu sistema de armazenamento permitir isso (dispositivo SAN discreto), capture as LUNs afetadas antes da desconexão e sinalize-as como somente leitura.
  • As regras de manuseio de evidências são complexas e fáceis de estragar. Não faça isso a menos que tenha recebido treinamento sobre eles. A maioria dos administradores de sistema em geral NÃO tem esse tipo de treinamento.
  • Se houver evidências, trate a perda de serviço como um desastre de perda de hardware e inicie os procedimentos de recuperação com novo hardware.
• Regras pré-definidas para que tipos de desastres requerem que tipos de aviso. As leis e os regulamentos variam de acordo com a localidade.
  • As regras referentes à 'exposição' e 'compromisso comprovado' variam.
  • As regras de notificação exigirão que o departamento de comunicações se envolva.
  • Se o aviso exigido for grande o suficiente, será necessário envolver a gerência de nível superior.
• Usando dados de DR, determine quanto tempo "o WTF acabou de acontecer" pode ser gasto antes de colocar o serviço novamente em operação e se tornar uma prioridade mais alta.
  • Os tempos de recuperação do serviço podem exigir o trabalho de descobrir o que passou a ser subordinado. Nesse caso, tire uma imagem da unidade do dispositivo afetado para dissecção após a restauração dos serviços (não é uma cópia de prova, é para os técnicos fazerem engenharia reversa).
  • Planeje suas tarefas de recuperação de serviço para incluir uma reconstrução completa do sistema afetado, não apenas limpando a bagunça.
  • Em alguns casos, os tempos de recuperação de serviço são apertados o suficiente para que as imagens de disco precisem ser capturadas imediatamente após a identificação de um comprometimento e as evidências legais não devem ser mantidas. Depois que o serviço é reconstruído, o trabalho de descobrir o que aconteceu pode começar.
• Examine os arquivos de log para obter informações relacionadas a como o invasor entrou e o que eles podem ter feito uma vez.
• Examine os arquivos alterados para obter informações relacionadas a como eles entraram e o que fizeram quando entraram.
• Examine os logs do firewall para obter informações sobre de onde eles vieram, para onde eles podem ter enviado dados e quanto deles podem ter sido enviados.

Ter políticas e procedimentos em vigor antes de um compromisso, e bem conhecido pelas pessoas que os implementarão no caso de um compromisso, é algo que só precisa ser feito. Ele fornece a todos uma estrutura de resposta em um momento em que as pessoas não pensam direito. A alta administração pode trovejar e explodir sobre ações judiciais e acusações criminais, mas, na verdade, reunir um caso é um processo caro e saber que de antemão pode ajudar a atenuar a fúria.

Também observo que esses tipos de eventos precisam ser incluídos no plano geral de resposta a desastres. Um compromisso provavelmente desencadeará a política de resposta 'hardware perdido' e também provavelmente a resposta 'perda de dados'. O conhecimento dos tempos de recuperação do serviço ajuda a definir as expectativas de quanto tempo a equipe de resposta de segurança pode ter para analisar o sistema comprometido real (se não manter as evidências legais) antes de ser necessário na recuperação do serviço.

Como procedimentos adequados de assistência técnica podem ajudar

Precisamos considerar como os clientes são tratados aqui (isso se aplica a clientes internos e externos que entram em contato com o suporte técnico).

Primeiro de tudo, a comunicação é importante ; os usuários ficarão irritados com a interrupção dos negócios e também poderão se preocupar com a extensão / consequências de quaisquer violações de informações que possam ter ocorrido como parte de uma invasão. Manter essas pessoas informadas ajudará a gerenciar sua raiva e preocupação, tanto do ponto de vista de que o compartilhamento de conhecimento é bom, quanto do ponto de vista talvez um pouco menos óbvio de que uma coisa que eles precisam ouvir é que você está no controle da situação. situação.

O suporte técnico e o gerenciamento de TI precisam agir como um "guarda-chuva" neste momento, protegendo as pessoas que estão fazendo o trabalho para determinar a extensão da invasão e restaurar serviços de inúmeras consultas que atrapalham esse trabalho.

1. Tente publicar atualizações realistas para os clientes e trabalhe com eles para determinar a urgência de colocar um serviço online novamente. Estar ciente das necessidades dos clientes é importante, mas ao mesmo tempo não permita que eles ditem um cronograma impraticável para você.
2. Verifique se sua equipe de suporte técnico sabe quais informações podem ou não ser divulgadas e que elas não devem incentivar rumores e especulações (e absolutamente não devem discutir nada que possa prejudicar qualquer ação legal que sua organização possa adotar ou enfrentar).
3. Uma coisa positiva que o serviço de assistência deve fazer é registrar todas as chamadas referentes à invasão - isso pode ajudar a medir a interrupção causada pela própria invasão e pelos processos que se seguiram para lidar com ela. Colocar um tempo e um custo financeiro na intrusão e na mitigação pode ser muito útil para refinar estratégias futuras e, obviamente, pode ser útil em qualquer ação legal. O registro de incidentes versus problemas da ITIL pode ajudar aqui - tanto a própria intrusão quanto a atenuação podem ser registradas como problemas separados, e cada chamador rastreado como um incidente de um ou ambos os problemas.

Como os padrões de implantação podem ajudar

A implantação em um modelo definido (ou pelo menos uma lista de verificação) também ajuda, juntamente com a prática de controle / gerenciamento de alterações sobre quaisquer personalizações / atualizações no seu modelo de implantação. Você pode ter vários modelos para contabilizar servidores executando trabalhos diferentes (por exemplo, um modelo de servidor de correio, um modelo de servidor web, etc.).

Um modelo deve funcionar para sistemas operacionais e aplicativos e incluir não apenas a segurança, mas todas as configurações usadas, e deve ser idealmente script (por exemplo, um modelo), em vez de ser aplicado manualmente (por exemplo, uma lista de verificação) para eliminar o máximo de erros humanos.

Isso ajuda de várias maneiras:

• Permite restaurar / reconstruir mais rapidamente caso ocorra uma invasão (observe que você não deve implantar a partir deste modelo 'como está' porque sabe que ele é vulnerável, mas permite retornar à sua "última configuração válida) ", que precisa ser reforçado antes da implantação ao vivo ... e não se esqueça de atualizar seu modelo de implantação quando tiver certeza de que está bloqueado corretamente)
• Fornece uma "linha de base" para comparar um servidor invadido
• Reduz erros desnecessários que podem levar a uma invasão em primeiro lugar
• Ajuda no gerenciamento de alterações e patches porque, quando se torna aparente que você precisa de um patch / upgrade ou alteração de procedimento para segurança (ou por qualquer outro motivo), fica mais fácil ver quais sistemas precisam da mudança, facilita a gravação de testes para ver se a alteração foi aplicada corretamente, etc).
• Se tudo é o mais consistente possível e sensato, isso ajuda a tornar os eventos incomuns e suspeitos um pouco mais distantes.

Para a maioria de nossos servidores, contamos com firewalls de host e de rede, software antivírus / spyware, IDS de rede e IDS de host durante a maior parte de nossa prevenção. Isso, juntamente com todas as diretrizes gerais, como privs mínimos, programas não essenciais desinstalados, atualizações etc. A partir daí, usamos produtos como Nagios, Cacti e uma solução SIEM para vários revestimentos básicos e notificações de quando os eventos ocorrem. Nosso HIDS (OSSEC) também faz muitos registros do tipo SIEM, o que é bom. Basicamente, tentamos fazer as coisas do bloco o máximo possível, mas depois registramos centralmente para que, se algo acontecer, possamos analisar e correlacionar.

O que você realmente deseja pode se dividir em três áreas básicas:

1. Configuração padrão do sistema
2. Monitoramento de Sistema / Aplicativo
3. Resposta a Incidentes

Se você tiver alguma equipe de informações (garantia | segurança) disponível, definitivamente converse com eles. Embora a resposta a incidentes seja frequentemente a única competência do referido escritório, o restante deve ser um esforço conjunto de desenvolvimento entre todas as partes afetadas.

Correndo o risco de auto-cafetão, esta resposta a uma pergunta relacionada deve indexar muitos recursos úteis para você: Dicas para proteger um servidor LAMP.

Idealmente, você deve ter o menor número de sistemas operacionais suportados e criar cada um usando uma imagem de base. Você deve desviar-se da base apenas o necessário para fornecer quaisquer serviços que o servidor forneça. Os desvios devem ser documentados ou podem ser necessários se você precisar atender ao PCI / HIPAA / etc. ou outras conformidades. O uso de sistemas de gerenciamento de implantação e configuração pode ajudar muito nesse sentido. Os detalhes dependerão muito do seu sistema operacional, sapateiro / fantoche / Altiris / DeployStudio / SCCM, etc.

Você definitivamente deve executar algum tipo de revisão regular de log. Dada a opção, um SIEM pode ser muito útil, mas eles também têm a desvantagem de serem caros, tanto no preço de compra quanto nos custos de construção. Confira esta pergunta no site do IT Security SE para alguns comentários sobre a análise de log: Como você lida com a análise de log? Se isso ainda for muito pesado, até mesmo ferramentas comuns, como o LogWatch, podem fornecer um bom contexto para o que está acontecendo. A peça importante, no entanto, é apenas reservar um tempo para examinar os logs. Isso o ajudará a se familiarizar com o que constitui um comportamento normal, para que você possa reconhecer anormalmente.

Além da revisão do log, o monitoramento do estado do servidor também é importante. Saber quando ocorrem mudanças, planejadas ou não, é crucial. A utilização de uma ferramenta de monitoramento local como o Tripwire pode alertar o administrador sobre alterações. Infelizmente, assim como os SIEMs e IDSes, tem o lado negativo de ser caro para ajustar e / ou comprar. Além disso, sem uma boa sintonia, seus limites de alerta serão tão altos que qualquer boa mensagem será perdida no ruído e se tornará inútil.

Uma política adequada de Gerenciamento de informações e eventos de segurança (SIEM) em vigor ajudará bastante a tornar sua vida mais segura.

Eu não sou especialista em segurança, por isso, principalmente, adoro eles; mas começar pelo Principal of Least Privilege quase sempre facilita significativamente o trabalho. A aplicação desse tipo de solução funciona bem para muitos aspectos da segurança: permissões de arquivo, usuários em tempo de execução, regras de firewall etc. O KISS também não é prejudicial.

A maior parte da solução mencionada aqui é aplicável no nível do host e da rede, mas geralmente esquecemos aplicativos da Web inseguros. As aplicações Web são as falhas de segurança mais comuns. Por meio de aplicativos da Web, um invasor pode obter acesso ao seu banco de dados ou host. Nenhum firewall, IDS, firewall pode protegê-lo contra esses. O OWASP mantém uma lista das 10 principais vulnerabilidades mais críticas e oferece correções para elas.

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide