ti-enxame.com

Endurecimento Linux - Servidores da Web

Quais são sua lista de verificação/rotina ao configurar um servidor Web Linux?

O que você recomenda alcançar a segurança máxima?

Existe alguma maneira preferida de realizar manutenção repetida?

31
pestaa
  • Primeiro de tudo, esteja ciente de que qualquer habilidade de script no Apache (PHP, CGI, Ruby, ...) é o potencial equivalente a uma conta shell com privilégios do usuário que está executando o script.

  • Se o servidor for compartilhado com vários usuários, você pode querer pensar em usar suexec (- ou itk mpm - sugerido por David Schmitt) Então nem todos os script são executados como o mesmo usuário do Apache.

  • Virtualize ou chroot Apache, de modo que qualquer compromisso seja pelo menos um pouco contido em uma camada adicional de segurança. Esteja ciente de que quando você chroot apache, a manutenção pode se tornar mais difícil, como você acaba movendo bibliotecas para a prisão etc. Se você estiver no FreeBSD, você pode usar uma cadeia, o que é muito mais fácil de manter, já que você pode apenas instalar o Apache A partir de portas, e execute o Portaudit de dentro, sem ter que se preocupar com quaisquer dependências de biblioteca e movimentar arquivos manualmente, que sempre se torna uma bagunça feia. Com as cadeias BSD, você pode simplesmente continuar usando o sistema de gerenciamento de pacotes (portas). (No GNU/Linux, você também pode usar vserver para virtualização. - sugerido por David Schmitt )

  • (Obviamente) acompanhar as atualizações e patches, não apenas para o Apache, mas também PHP, Ruby, Perl, etc ... Não confie apenas no seu sistema operacional para oferecer todas as atualizações. Algumas distro são extremamente lentas com seus patches. Limite a hora da exposição a vulnerabilidades de 0 dias o máximo possível. Stick The milw0rm Feed no seu leitor de RSS, inscreva-se nas listas de discussão insecure.org , etc ... Não só ajudará você a aprender sobre vulnerabilidades antes que seu sistema operacional fique por perto Para liberar um patch, você também aprenderá sobre vulnerabilidades em certos aplicativos PHP CMS, por exemplo, que podem nem ser gerenciados ou corrigidos pelo seu sistema operacional.

  • Use algo como Tripwire/Aide, Auditoria ou Mtree (no BSD) para acompanhe as alterações no sistema de arquivos. Este é realmente importante. Tenha quaisquer alterações enviadas para você regularmente, revisá-las manualmente, todos os dias. Se alguma alteração de arquivo não deve mudar, investigue o porquê. Se algum javascript malicioso de alguma forma for inserido em suas páginas através de qualquer método, você vai pegá-lo dessa maneira. Isso não só salva seu servidor, mas também seus usuários, pois suas próprias páginas da Web podem ser abusadas para infectar seus visitantes. (Esta é uma tática muito comum, os atacantes muitas vezes nem se importam com o seu servidor, eles só querem infectar tantos visitantes quanto possível até descobrir. Esses atacantes também nem se incomodam em esconder suas faixas normalmente. Pegando um compromisso como este o mais rápido possível é muito importante.)

  • Usando coisas como Suhosin para proteger o PHP ajuda. Mas também aprenda a entendê-lo, ajuste a configuração nos parâmetros esperados do seu aplicativo.

  • Usando um patch de kernel como pax pode ajudar a protegê-lo de muitas vulnerabilidades de transbordamento de buffer. Mesmo que seu software seja vulnerável. (Isso não faz você invulnerável, é ainda outro, menor, camada.)

  • Não fique super confiante ao usar alguma ferramenta de segurança. Entenda as ferramentas que você usa e use o senso comum. Leia, aprenda, acompanhe o máximo que puder.

  • Considere o uso de controle de acesso obrigatório (por exemplo: SELinux ). Ele permite que você especifique, para cada aplicativo, o que é permitido fazer, em grande detalhe. Quais arquivos é permitido acessar. O que o kernel chama é permitido fazer, etc. Este é um processo muito envolvido e requer muita compreensão. Alguma distro fornece políticas pré-feitas do Selinux para seus pacotes (por exemplo: Gentoo ). Essa sugestão é uma espécie de contradição para a abaixo, mas ainda válida, no entanto.

  • Mantenha as coisas simples. Uma estratégia de segurança complexa pode funcionar contra você.

  • No Apache, crie regras padrão muito restritivas (Opções Nenhum, negar de tudo, etc ...) e substituir conforme necessário para virtualhosts específicos.

  • Negar acesso a todos os pontos (que também cobre imediatamente arquivos .htaccess)

  • Sempre use HTTPS em qualquer lugar que haja qualquer tipo de autenticação de senha.

  • O firewall deve ser uma política negada por padrão. Crie algumas regras específicas em seu firewall para registrar o tráfego específico.

  • Configurar scripts de análise de log para digitalizar seus logs para anomalias. (The IDs do prelúdio Suíte pode fazer isso, mas honestamente, eu recomendo que você construa seus próprios scripts ao longo do tempo, pois ajudará você a entender suas próprias ferramentas e regras melhor.)

  • Peça ao servidor enviá-lo aos relatórios diários sobre usuários logados, conexões ativas, largura de banda usada, etc ...

  • Tenha uma varredura de cron para binários suados, arquivos graváveis ​​mundiais e coisas assim, e tê-los enviados para você.

  • Para qualquer uma das coisas que você configurou que é enviada para você, você deve construir uma lista de exceções ao longo do tempo. (Pastas para ignorar as alterações do sistema de arquivos, 777 arquivos para permitir, os binários suados para permitir). É importante que você seja apenas notificado de coisas que não devem acontecer. Se você receber um e-mail todos os dias com coisas triviais, você começará a ignorá-los, e eles ficarão sem sentido.

  • Tenha uma boa estratégia de backup redundante em camadas sólidas. E não apenas assuma que fazer uma imagem ou cópia de tudo funciona. Por exemplo, se o MySQL estiver no meio da escrita para uma tabela durante o seu backup, seus arquivos binários mysql podem ser corrompidos quando você restaurar seu backup. Então você precisará de um cron que o mysqldump dos seus bancos de dados no topo de imagens regulares ou tarballs noturnas ou controle de versão ou qualquer outra coisa que você tenha configurado. Pense na sua estratégia de backup. Eu realmente penso sobre isso.

  • Não confie em listas como esta para segurança :) Sério! Você encontrará muitos deles em toda a Internet, vá lê-los todos, pesquise todas as sugestões e use o senso comum e a experiência para compensar sua própria mente. No final, experiência e bom senso são as únicas coisas que vão te salvar. Não listas nem ferramentas. Ler, mas não apenas copie sem entender.

27
jns

Eu recomendo o Livro de segurança do Linux , de San. Eu uso isso, além de outros procedimentos internos. A lista de verificação pode ser um pouco datada, mas muitos dos principais pontos são verdadeiros.

5
user1797
  • Eu configurei um firewall, e só poke buracos para adicionar cada serviço individualmente
  • Para qualquer serviço, leio os documentos da Ajuda do aplicativo para o (s) arquivo (s) de configuração e certifique-se de que pelo menos a cada configuração.
  • Eu me inscrevo nas listas de discussão de segurança
  • Eu corro rkhunter e lynis todas as noites em um trabalho cron
  • Eu tenho todos os erros ao longo de um certo limiar para mim
  • Eu tenho todas as mudanças relacionadas ao registro (reiniciando o serviço de registro, etc) enviado para mim
  • Eu mantenho etc no subversão
5
Tom Ritter

edite seu ~/.ssh/config

permit_root_login no

isto faz

ssh [email protected]

não responde, mas

ssh [email protected]
user$ su

funcionará se você quiser fazer login como root.

4
devin

Sempre haverá inúmeras permissões para verificar, inúmeras listas de verificação, nunca terminando a descoberta de novos bugs/vulnerabilidades. Segurança Eu não acho que é algo que você liga ou desliga, é algo que você faz constantemente.

Dado o "fracasso inevitável" de software, o Selinux ajuda a colocar algumas preocupações (novamente nenhuma bala de prata para segurança). Assumindo que um aplicativo do UserSeace é comprometido a política correta do SELinux impedirá que ela atue em seu habitual (ou seja, se selinux fosse desativada ou permissiva) privilégios. Isso, naturalmente, exigirá que você monitore seus logs de auditoria e analise a política instalada e modifique-o quando necessário para permitir que os aplicativos funcionem.

Não dizendo que a política padrão não ajudaria, mas eu pessoalmente gosto de saber o que permite.

1
rev