Excesso de segurança do servidor Web?

Eu tenho feito uma pesquisa "extensa" sobre como proteger um servidor web linux. Além do que é considerado "básico" (remoção de serviços não utilizados, proteção de ssh, iptables etc.), é aconselhável incluir anti-rootkits (Tripwire) e um antivírus (ClamAV)? Estes são apenas um exagero para um servidor web? Sei que essa é uma pergunta muito vaga, mas tenho curiosidade sobre as opiniões dos outros.

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 da web - aplicativos da web com uploads de usuários (fotos, pdfs etc.) - sites típicos (formulários etc.)

Se você tiver outras dicas, não hesite em adicionar!

obrigado

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

O ClamAV é uma questão diferente. Eu consideraria configurar isso se seus visitantes compartilharem arquivos fazendo upload e download no seu site. PDFs podem conter explorações.

Em servidores públicos, o SSH não permite autenticação por senha, apenas autenticação por chave pública. Se o SSH só for possível a partir de uma LAN interna, você poderá relaxar isso.

Sempre que possível, eu colocaria o servidor em uma DMZ para que não possa originar conexões com outros computadores em suas LANs internas.

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 seu aplicativo da web, verifique se o seu aplicativo não tem FILEprivilégios, é de longe o mais perigoso do MySQL.

4) Firewall fora de todos os UDP e todos os TCP que você não precisa. Considere usar porta batendo para ssh. Não banir não é tão bom quanto receber zero tentativas.

Provavelmente, você pode instalar o AIDE em um servidor da Web com segurança - adicionar e remover clientes não altera muitos arquivos de configuração e é possível filtrar a conversa normal com bastante facilidade.

Mas algo que muitos guias de segurança de servidor da web não mencionam é que você deve ativar o noexec na sua partição / tmp no / etc / fstab. Se você está oferecendo hospedagem ao público, muitas pessoas instalam aplicativos da Web inseguros sem o seu conhecimento (e não têm o conhecimento para manter seus aplicativos atualizados), e basicamente estão perseguindo esses erros para sempre. Se você se certificar de que o único local em que um invasor pode salvar o software é o diretório inicial do cliente e o diretório / tmp, o invasor corre o risco de mostrar onde está invadindo se não puder usar o diretório / tmp. Eles não gostam de fazer isso.

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

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

1. mod_security é uma dor para você e para o servidor. Seus recursos estão famintos e suas regras precisam de manutenção séria e será uma tarefa sem fim. E não, ele não funciona de forma independente ou com o Nginx. Se você realmente precisar, configure um servidor proxy separado (Apache, mod_proxy, mod_security). Também funciona como DMZ, seus servidores reais podem ser completamente fechados para o mundo exterior e, se o proxy for violado, não haverá nada.

2. O ClamAV também é muito pesado se for executado como um daemon. É melhor executar o clamscan periodicamente durante horas não ativas a partir de Cron.

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

4. Acredito que pelo menos 90% dos rootkits etc. cheguem aos servidores via uploads de máquinas Windows de desenvolvedores. Não há realmente uma boa maneira de evitar isso, exceto talvez forçando os desenvolvedores a nunca usar o Windows. A maioria dos cavalos de Troia procura credenciais de FTP, portanto nunca use FTP.

O uso da proteção de formulário captcha no mecanismo CMS popular (Wordpress, Jomlaa, Drupal) é considerado uma prática de segurança? Se sim, você pode usar estes:

• Mollom
• Aksimet
• Defensio