Problemas comuns de segurança que você enfrenta como provedor de hospedagem Linux (web)

Problemas comuns de segurança que você enfrenta como provedor de hospedagem Linux (web)

Pergunta aos usuários que possuem hospedagem própria (sejam servidores físicos ou revendedores):

Há algum problema de segurança comum com o qual você precisa lidar em seus servidores? Alguma sugestão sobre coisas problemáticas que devem ser desativadas? Algum erro estúpido de segurança específico para hospedagem na web que devo evitar? Alguma vulnerabilidade recente que esteja afetando os webhosts?

Responder1

A prática de dar acesso de usuário a qualquer pessoa com uma conta PayPal ou cartão de crédito é em si uma loucura. Tenho trabalhado na indústria de hospedagem durante a maior parte dos últimos seis anos e ainda acho isso uma loucura.

Esta é uma lista do que faço para a maioria dos servidores (compartilhados ou não) sem nenhuma ordem lógica específica:

  • Quase nunca uso o kernel fornecido pela distribuição. Eu mantenho nossa própria árvore de kernel que acompanha a linha principal do Linux ... até onde o grsecurity permite. Não é apenas uma medida de segurança, é também uma medida de otimização. Você não encontrará coisas como suporte paralelo/usb/áudio em nossos kernels (já que os servidores web não precisam deles). Os kernels são construídos para utilizar apenas o material de que precisamos na placa.
  • 9/10 coisas ruins são permitidas por scripts de usuários com erros. Muitos clientes conhecem PHP o suficiente para ser perigoso. mod_security é um dos meus melhores amigos, eu pago por assinaturas de conjuntos de regras rígidos e os mantenho atualizados quase semanalmente.
  • A auditoria é fundamental, também recomendo usar OSSEC ou algo semelhante.
  • Todos os meus servidores estão conectados a uma LAN de manutenção, que posso acessar independentemente da rede pública. Quando/se as coisas derem errado e você encontrar seu servidor tão ocupado enviando pacotes indesejados por toda a Internet, você apreciará ter outra maneira de entrar. Também tenho KVMs IP instalados em todos os servidores ou IPMI, dependendo do hardware.
  • Ultimamente, tenho usado o Xen como camada de gerenciamento para servidores compartilhados. Eu crio um único convidado que possui 99% da memória do sistema. Isso me permite fazer coisas como reparos/instantâneos/etc do sistema de arquivos de maneira bastante indolor. Pode realmente ajudar na recuperação se algo der errado (e é útil para ocultar a LAN do servidor compartilhado).
  • Eu mantenho um firewall baseado em iptables muito rígido que é especialmente rigoroso quando se trata de saída.
  • Tenho muito cuidado com quem pode acessar o compilador do sistema e as ferramentas de vinculação.
  • Eu atualizo o software do sistema religiosamente.
  • Faço verificações periódicas para garantir que as pessoas não estejam executando involuntariamente versões antigas e vulneráveis ​​de aplicativos populares, como Wordpress, PHPBB, etc.
  • Ofereço instalação gratuita de coisas que os clientes “encontram na Internet”. Isso realmente me ajuda a auditar o que está sendo hospedado, ao mesmo tempo que oferece valor adicional aos clientes. Também ajuda a garantir que os itens sejam instalados de forma segura e correta.
  • Sempre, sempre, sempre fortaleça o PHP, certifique-se de usar suexec para PHP também. Nada é pior do que encontrar um bot em /tmp de propriedade de 'ninguém' :)

Finalmente, por último mas não menos importante:

  • Na verdade, eu li os arquivos de log do sistema.Muitos hosts vêm correndo para ver o que deu errado somente depois que um problema é percebido. Mesmo ao usar ferramentas como o OSSEC, é importante ser proativo.

Responder2

Parece que outras pessoas estão entrando em muitos detalhes, mas a maior fonte de atividade maliciosa deve serFTP.

Bloqueie-o para determinados IPs e desative-o para contas que não precisam dele. Até mesmo desabilite o serviço, a menos que seja solicitado.

Tive que lidar com dezenas de hacks depois que códigos maliciosos foram carregados em sites, enviando spam para o mundo ou redirecionando visitantes com injeções de iframe. Raramente eles obtêm acesso root ou shell; em vez disso, apenas causam uma tonelada de trabalho manual de limpeza de servidores na lista negra e pesquisa manual de código.

A principal fonte do hack não é o servidor em si, mas os PCs infectados dos usuários finais que detectam senhas de FTP e as enviam de volta à nave-mãe, para serem usadas posteriormente em uma máquina diferente para fazer upload do código.

Responder3

Trabalhei para uma empresa de hospedagem na web por um tempo e é um pesadelo manter todos os usuários seguros. Especialmente em um ambiente compartilhado. Servidores privados são muito mais fáceis de controlar, pois os problemas de segurança são isolados apenas desse sistema.

Algumas coisas para ter em mente em uma hospedagem compartilhada:

  • Um bug em um site pode afetar todos os outros. Portanto, tente limitar o que cada usuário pode fazer e seja restritivo nas permissões. Inclui ulimit, limites de php, etc.
  • Monitore o sistema e sites individuais. Uma ferramenta como o OSSEC pode ser muito útil para lidar com todas as informações.
  • O kernel do Linux não tem um bom histórico em relação a explorações locais. Portanto, certifique-se de que ele esteja sempre atualizado e use extensões de segurança do kernel (grsecurity, SELinux, etc).

Para os servidores privados, você deixa a segurança nas mãos dos usuários, mas certifique-se de instalar ferramentas adequadas de QOS, NIDS e anti-DOS em sua rede.

informação relacionada