Overkill de segurança do servidor Web?

Question

Eu tenho feito uma pesquisa "extensa" sobre como proteger um servidor web linux. Em cima do que é considerado o "básico" (remoção de serviços não utilizados, hardening ssh, iptables, etc) é aconselhável incluir anti-rootkits (Tripwire) e um anti-vírus (ClamAV)? Estes são apenas um exagero para um servidor web? Eu sei que esta é uma pergunta muito vaga, mas estou curioso sobre outras opiniões.

Meu ambiente futuro: - ubuntu 10.04 - fail2ban - nginx 0.8.x - php 5.3.x (suhosin, apc, memcached) - mongodb 1.6.x

Possíveis aplicações: - serviços web - aplicativos da web com uploads de usuários (fotos, pdfs, etc.) - sites típicos (formulários, etc.)

Se você tiver outras dicas, sinta-se à vontade para adicionar!

Obrigado

    

Answer 1

Para um servidor voltado para o público, eu diria que instalar algo como o tripwire não é um exagero.

O ClamAV é um assunto diferente. Eu consideraria configurar isso se seus visitantes forem compartilhando arquivos enviando e baixando do seu site. Os PDFs podem conter explorações.

Em servidores voltados para o público, eu tenho SSH não permitir autenticação de senha, somente autenticação de chave pública. Se o SSH só é possível a partir de uma LAN interna, então você pode relaxar isso.

Sempre que possível coloco o servidor em um DMZ para que ele não possa originar conexões com outros computadores em suas LANs internas.

    

Answer 2

Não, você não foi longe o suficiente.

1) Você precisa de um firewall de aplicativo da web como mod_security e verifique se está configurado para bloquear ataques, não apenas registrá-los.

2) Bloqueie o php com phpsecinfo .

3) Bloqueie a conta MySQL do aplicativo da web, certifique-se de que seu aplicativo não tenha FILE privileges, é de longe o mais perigoso no MySQL.

4) Firewall fora de todo o UDP, e todo o TCP que você não precisa. Considere usar porta batendo para o ssh. Deixar de banir não é tão bom quanto conseguir zero tentativas.

    

Answer 3

Provavelmente você pode instalar com segurança AIDE em um servidor web - adicionar e remover clientes não altera muitos arquivos de configuração, e você provavelmente poderia filtrar o chatter normal facilmente.

Mas algo que muitos guias de segurança de servidores web não mencionam é que você deve ativar o noexec em sua partição / tmp em / etc / fstab. Se você está oferecendo hospedagem para o público, muitas pessoas instalarão aplicativos inseguros sem o seu conhecimento (e não terão o conhecimento necessário para manter seus aplicativos atualizados), e você está basicamente buscando esses bugs para sempre. Se você se certificar de que o único local onde um atacante pode salvar o software é o diretório home do cliente e o diretório / tmp, o invasor corre o risco de mostrar onde ele está invadindo se não puder usar o diretório / tmp. Eles não gostam de fazer isso.

Isso resolveu a grande maioria dos problemas de segurança em nosso servidor de hospedagem na web.

    

Answer 4

"Bem-vindo a bordo! A bordo do nosso novo avião você pode desfrutar de restaurante, cinema, academia, sauna e piscina. Agora aperte seus cintos de segurança, nosso capitão vai tentar levar toda essa merda no ar."

1. mod_security é um problema para você e para o servidor. É fome de recursos e suas regras precisam de manutenção séria e vai ser uma tarefa sem fim. E não, não funciona de forma autônoma ou com o Nginx. Se você sentir que realmente precisa, configure um servidor proxy separado (Apache, mod_proxy, mod_security). Ele também funciona como DMZ, seus servidores reais podem ser completamente fechados para o mundo externo e, se o proxy for violado, não há nada de qualquer maneira.

2. O ClamAV também é muito pesado, se executado como um daemon. É melhor executar o clamscan periodicamente durante as horas inativas do Cron.

3. O Tripwire é um exagero, IMHO. Mas algo capaz de caçar rootkits seria útil, existem muitos scripts (rkhunter, chkrootkit).

4. Acredito que pelo menos 90% dos rootkits, etc., chegam aos servidores via uploads de máquinas Windows devs. Não há uma maneira muito boa de evitar isso, exceto talvez forçar os desenvolvedores a nunca usarem o Windows. A maioria dos trojans procura por credenciais de FTP, portanto, nunca use o FTP.

Answer 5

Está usando a proteção de formulário captcha no popular mecanismo de CMS (Wordpress, Jomlaa, Drupal) considerado como práticas de segurança? Se sim, então você pode usar estes:

• Mollom
• Aksimet
• Defensio