Como posso testar a segurança do meu servidor?

7

Como posso testar a segurança do meu servidor?

Por favor, eu sei que é uma questão muito geral. Mas eu queria saber se existe um software de teste ou serviço da web verificando todas as portas do seu servidor, ou possivelmente falhas de segurança?

Eu normalmente verifico as permissões do Unix e é isso, mas há algo que eu possa fazer?

ps. Os usuários não podem fazer upload de arquivos com meus aplicativos da web, então não tenho esse problema.

    
por aneuryzm 29.12.2010 / 13:47

9 respostas

5

Com base nas suas tags, veja alguns conselhos básicos:

SO (Linux)

  • Aplicar atualizações / patches de segurança, incluindo o Kernel
  • Ferramenta Checksum para detectar alterações de arquivos / permissões, como ajuda, fcheck, tripwire, etc.
  • Ative apenas os serviços de rede que você está realmente usando (verifique com netstat -tulpen )
  • Definição de usuário sã: quem tem acesso root?
  • SSH: desabilitar logins raiz diretos
  • Hard- ou software firewall

PHP

  • Use PHP endurecido (Suhosin)
  • Google na web para práticas recomendadas de segurança em PHP

MySQL

  • Eiter deixa rodar com sockets Unix ou via TCP mas somente em localhost / sua LAN
  • Definir uma senha de root
  • Definir usuários restritos para cada aplicativo diferente

Isso é apenas o básico puro escrito em 2 minutos. Há muito mais.

    
por 29.12.2010 / 14:55
4

Faça o download do Backtrack e execute o AutoPwn do FastTrack no seu servidor. É uma abordagem completamente automatizada, mas é uma ótima maneira de baixo esforço de encontrar o fruto mais fácil.

Se você tem componentes da web, o SkipFish é outra ótima ferramenta de teste automatizada.

    
por 29.12.2010 / 15:25
3

Existem muitos testes que você pode realizar e muitas ferramentas disponíveis para teste. Para começar, talvez você queira executar o Nikto .

Embora você acredite que os usuários não podem fazer upload de arquivos, uma falha de segurança nos aplicativos ou serviços pode muito bem ser o contrário, como muitos aprenderam da maneira mais difícil. Sempre trabalhe com a suposição de que seu sistema está quebrado e vulnerável e procure maneiras de consertá-lo antes que alguém encontre os buracos para você.

    
por 30.12.2010 / 00:13
1

Se você tiver acesso ao sistema, poderá descobrir quais portas podem ser abertas usando netstat . Pode listar todas as portas de escuta. Firewalls e outras medidas de segurança podem atenuar o risco.

Corresponda esta lista a uma verificação remota. Investigue as portas que a varredura remota mostra que não estão listadas pelo netstat. Não deve haver nenhum que não seja considerado pelas regras DNAT em um firewall.

Desative todos os serviços que você não precisa. Costumava ser comum arquivar uma variedade de serviços desnecessários em execução. Muitos eram triviais, como chargen, hora, dia e outros. Alguns foram significativos, como Telnet, FTP, HTTP.

Para serviços necessários apenas internamente, configure-os para ouvir em 127.0.0.1 e / ou :: 1 (IPv6), se possível.

    
por 29.12.2010 / 17:41
1

O AutoPwn do BackTrack FastTrack é bom para servidores muito antigos com pacotes muito antigos instalados. Se você tem um moderno linux / windows atualizado, ele não encontrará nada. (Eu gosto de voltar atrás, mas essa ferramenta séria que exige amplo conhecimento de segurança e testes de caneta)

Eu recomendaria instalar e varrer seu servidor com o Nessus, ele é bastante poderoso (mesmo que a versão gratuita não tenha as últimas assinaturas de vulnerabilidades) e possa não apenas procurar portas abertas e software vulnerável remoto, mas também fazer login no servidor com credenciais raiz e realizar auditoria local.

É apenas uma ferramenta, não é suficiente para tornar o seu servidor "seguro", mas junto com, por exemplo, as dicas do weeheavy que você pode se aproximar.

Eu também adicionaria o Monitoring. Instale o OSSEC ou seu análogo (tripwire, etc), você quer ser notificado se alguma coisa estranha acontecer no servidor em tempo real via email / sms / etc.

    
por 29.12.2010 / 23:15
0

Existem alguns serviços para isso, geralmente comercializados como verificação de conformidade com o PCI-DSS. Quero dizer, essa não é a melhor solução para todas as varreduras de segurança, mas a conformidade com o PCI-DSS requer um alto nível de segurança.

É provavelmente um ponto de partida sensato. Esteja avisado. Não é barato.

edite: Eu usei HackerGuardian no passado, e é muito bom. Preços chegam após o primeiro exame gratuito por US $ 249 / ano

    
por 29.12.2010 / 13:57
0

Bem, você pode começar com o nmap e verificar quais portas / serviços estão abertos.

Se você quer aprender, dê uma olhada no link e link e dia a dia aprenda como se proteger dos outros, mas lembre-se que será um longo caminho.

Os relatórios de software podem ajudá-lo, mas eles vão mantê-lo seguro apenas das crianças do script, um bom hacker encontrará um buraco e somente outro ser humano poderá encontrar e consertar (prevenir) o problema.

Este software custa dinheiro e o suficiente para pagar um profissional para ter o relatório e a solução ao mesmo tempo.

Então, se o seu servidor web é realmente importante, peça ajuda, pois o dinheiro é bem gasto (novamente nos sites acima).

    
por 29.12.2010 / 15:40
0

Examine cada vetor de ataque.

Física: Este é bastante simples. O servidor está em um rack? está trancado? quem tem a chave? Quão segura é a chave? O servidor é uma sala? O quarto está trancado? Portas USB estão acessíveis ou ativadas? etc.

Se é um switch você está usando segurança de porta? etc.

Rede: Menos simples, mas o mais comum. Teste suas portas examinando todas as portas abertas no servidor com nmap ou wireshark ou algo assim. Determine quão restrito você deseja que esses serviços de rede sejam, dependendo de como você quer que eles funcionem e como eles são vulneráveis.

Por exemplo; um serviço http, restringir quem tem acesso, mas sub-rede? por host? pelo usuário? Verifique as vulnerabilidades comuns; está indexando ativado, etc.

Humano / social: Isso é algo que não é facilmente corrigido por meio de TI, normalmente de RH. Mas aqui estão algumas coisas que você pode fazer. Política de senha; A velha escola do pensamento é mudar as senhas regularmente, mas isso parece forçar os usuários finais a escolherem senhas fracas. Gerar senhas para usuários tende a fazê-las anotá-las. Você precisará encontrar uma política que melhor se adapte a você, mas você pode querer educar os usuários finais sobre como criar uma senha strong, mas faça a senha mudar uma vez por ano ou nunca. Também instrua os usuários finais sobre como gerenciar senhas e mantê-las em segredo.

    
por 30.12.2010 / 00:00
-2

google de novo?

Os aplicativos listados no link acima fornecem verificações de tipo de impressão digital para ataques de modo único bem definidos - isso não substitui uma avaliação de segurança adequada, mas a execução do nessus / nikto é um começo e a eliminação de problemas que podem parecer inexploráveis pode evitar vários ataques vetorizados. (Também elimina os frutos mais baixos para que você possa ter mais certeza de que qualquer um que você se envolva para testar a segurança corretamente tem que ganhar sua taxa).

I usually check unix permissions and that's it

err, sim - há muito mais que você deveria fazer. Essa declaração significa que você tem um modelo de segurança de permissões? É válido? E quanto a outro acesso ao servidor (console, ssh, ftp ...). Se você ainda não possui uma política de segurança detalhada, não há muito sentido em pedir a alguém que teste o sistema se ele estiver seguro. A política deve abranger itens como implantação de software, identificação e implementação de patches de fornecedores, backups, verificação de rootkits.

    
por 29.12.2010 / 14:07