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
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.
fonte
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.
fonte
"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."
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.
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.
Tripwire é um exagero, IMHO. Mas algo capaz de buscar rootkits seria útil, existem muitos scripts (rkhunter, chkrootkit).
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.
fonte
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:
fonte