Respostas:
Antes de tudo, esteja ciente de que qualquer capacidade de script no Apache (php, cgi, ruby, ...) é o equivalente potencial de uma conta shell com privilégios do usuário executando o script.
Se o servidor for compartilhado com vários usuários, convém pensar em usar suexec (- ou ITK MPM - sugerido por David Schmitt ) para que nem todo script seja executado como o mesmo usuário apache.
Virtualize ou faça chroot apache, para que qualquer compromisso seja pelo menos um pouco contido em uma camada adicional de segurança. Esteja ciente de que quando você executa o apache, a manutenção pode se tornar mais difícil, pois você acaba transferindo as bibliotecas para a prisão etc. a partir de portas e execute portaudit a partir dela, sem precisar se preocupar com nenhuma dependência de biblioteca e mover arquivos manualmente, o 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 o VServer para virtualização. - Sugerido por David Schmitt )
(obviamente) Acompanhe as atualizações e os patches, não apenas no Apache, mas também no PHP, ruby, perl, etc ... não confie apenas no seu sistema operacional para fornecer todas as atualizações. Algumas distribuições são extremamente lentas com seus patches. Limite o tempo de exposição a vulnerabilidades de 0 dia, tanto quanto possível. Coloque o feed milw0rm no seu leitor de RSS, assine as listas de discussão do insecure.org , etc ... Não apenas irá ajudá-lo a aprender sobre vulnerabilidades antes que o seu sistema operacional libere um patch, você também aprenderá sobre vulnerabilidades em determinados php aplicativos cms, por exemplo, que nem sequer podem ser gerenciados ou corrigidos pelo seu sistema operacional.
Use algo como tripwire / aide, audit ou mtree (no BSD) para acompanhar as alterações no seu sistema de arquivos. Este é realmente importante. Receba as alterações por e-mail regularmente, revise-as manualmente, todos os dias. Se algum arquivo mudar que não deve mudar, investigue o porquê. Se algum javascript malicioso for inserido de alguma forma nas suas páginas por qualquer método, você o capturará dessa maneira. Isso não apenas salva seu servidor, mas também seus usuários, pois suas próprias páginas da Web podem ser abusadas para infectar seus visitantes. (Essa é uma tática muito comum: os atacantes nem sempre se preocupam com o servidor, eles só querem infectar o maior número possível de visitantes até serem descobertos. Esses atacantes também nem se importam em esconder suas trilhas normalmente. Obter um compromisso como esse o mais rápido possível é muito importante.)
Usando coisas como suhosin para proteger php ajuda. Mas também aprenda a entender, ajuste sua configuração aos parâmetros esperados do seu aplicativo.
O uso de um patch de kernel como o PaX pode ajudar a proteger você de muitas vulnerabilidades de estouro de buffer. Mesmo se o seu software estiver vulnerável. (Isso não o torna invulnerável, é apenas mais uma camada menor.)
Não fique confiante demais ao usar alguma ferramenta de segurança. Entenda as ferramentas que você usa e use o bom senso. Leia, aprenda, acompanhe o máximo que puder.
Considere usar o controle de acesso obrigatório (por exemplo: SELinux ). Ele permite que você especifique, para cada aplicativo, o que é permitido fazer, com grandes detalhes. Quais arquivos estão autorizados a acessar. O que o kernel chama é permitido fazer, etc. Este é um processo muito envolvido e requer muita compreensão. Algumas distribuições fornecem políticas pré-fabricadas do SELinux para seus pacotes (por exemplo: Gentoo ). Essa sugestão é uma espécie de contradição com 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, configure regras padrão muito restritivas (Opções Nenhuma, Negar a todos, etc ...) e substitua conforme necessário para VirtualHosts específicos.
Negar acesso a todos os arquivos de ponto (que também abrange imediatamente arquivos .htaccess)
Sempre use https em qualquer lugar onde haja algum tipo de autenticação de senha.
O firewall deve ser uma política de negar por padrão. Crie algumas regras específicas no seu firewall para registrar tráfego específico.
Configure scripts de análise de log para verificar anomalias nos logs. (o prelúdio do IDS pode fazer isso, mas, honestamente, recomendo que você crie seus próprios scripts ao longo do tempo, pois isso ajudará você a entender melhor suas próprias ferramentas e regras.)
Faça com que o servidor envie relatórios diários sobre os últimos usuários conectados, conexões ativas, largura de banda usada, etc ...
Faça uma verificação cron para binários suid, arquivos graváveis no mundo e coisas assim, e envie-os por e-mail.
Para qualquer um dos itens configurados que são enviados por e-mail, você deve criar uma lista de exceções ao longo do tempo. (pastas para ignorar as alterações do sistema de arquivos, 777 arquivos para permitir, binários suid para permitir). É importante que você seja notificado apenas de coisas que não deveriam acontecer. Se você receber um e-mail todos os dias com coisas triviais, começará a ignorá-las, e elas se tornarão inúteis.
Tenha uma boa estratégia de backup redundante em camadas sólida. E não pense apenas que fazer uma imagem ou cópia de tudo funciona. Por exemplo, se o MySQL estiver no meio da gravação de uma tabela durante o backup, os arquivos binários do MySQL poderão estar corrompidos quando você restaurar o backup. Então você precisará de um cron que o mysqldump faça em seus bancos de dados sobre imagens regulares ou tarballs noturnos 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, lê todos eles, pesquisa todas as sugestões e usa o bom senso e a experiência para se decidir. No final, experiência e bom senso são as únicas coisas que o salvarão. Nem listas, nem ferramentas. Leia, mas não copie apenas sem entender.
Eu recomendo a lista de verificação de segurança do Linux , da SAN. Eu uso isso, além de outros procedimentos internos. A lista de verificação pode estar um pouco desatualizada, mas muitos dos principais pontos são verdadeiros.
Sempre haverá inúmeras permissões para verificar, inúmeras listas de verificação, sem nunca terminar a descoberta de novos bugs / vulnerabilidades. Segurança Eu acho que não é algo que você liga ou desliga, é algo que você faz constantemente.
Dada a "falha inevitável" do software, o SELinux ajuda a colocar algumas preocupações (mais uma vez, nenhuma bala de prata por segurança). Supondo que um aplicativo de espaço de usuário seja comprometido, a política correta do SELinux impedirá que ele atue nos privilégios usuais (por exemplo, se o SELinux foi desabilitado ou permissivo). É claro que isso exigirá que você monitore seus logs de auditoria, analise a política instalada e modifique-a sempre que necessário para permitir que os aplicativos funcionem.
Não dizer que a política padrão não ajudaria, mas eu pessoalmente gosto de saber o que ela permite.