Quando tenho que administrar um servidor Linux existente, qual é a melhor maneira de verificar se é seguro?

9

Existem muitos tutoriais sobre como configurar um novo servidor protegido.

Mas e se eu tiver que administrar um servidor que alguém configurou há algum tempo e ainda não sei muito sobre sua configuração?

Existe alguma ferramenta que verifica automaticamente os "suspeitos usuais" ou alguma lista de verificação que eu possa fazer para garantir que não haja falhas óbvias de segurança? Existem serviços da web que verificam remotamente as vulnerabilidades?

    
por Daniel Rikowski 11.08.2009 / 09:37

12 respostas

13

Faça o download do Nessus e faça uma verificação de rede. Ele informará sobre vulnerabilidades exploráveis remotamente.

Além disso, instale Ossec ; embora não seja seu objetivo principal, ele encontrará alguns problemas de configuração comuns (contas configuradas incorretamente, por exemplo). E sua função principal - detecção de intrusão baseada em host - ajudará a descobrir se alguém está tentando explorar vulnerabilidades.

    
por 11.08.2009 / 09:55
5

Gostaria de começar com as listas de verificação do Centro de Segurança da Internet "de referência". Estas são listas de verificação baseadas em consenso compiladas por profissionais de segurança para uma variedade de plataformas e pacotes de software. Algumas ferramentas mencionadas pelas listas de verificação, ou de outra forma geralmente recomendadas, que ajudarão na sua busca por questões de segurança:

(o tcpdump é instalado em muitos sistemas Linux por padrão, ou pode ser facilmente instalado a partir de um repositório de pacotes, e possui uma página man completa)

Se isso for para a empresa em que você trabalha, certifique-se de que a análise de segurança seja autorizada pelo gerenciamento e de que as verificações não causem nenhuma falha ou falha na aplicação. Sim, um simples escaneamento de portas pode causar problemas - as portas podem usar impressoras HP LaserJet mais antigas e elas soltam montes de papel.

    
por 11.08.2009 / 09:44
4

Como uma primeira verificação muito rápida:

Executar

netstat -ltnp

como root. Isso mostrará todos os serviços ouvidos na rede:

Isso pode mostrar coisas que você deseja encerrar imediatamente. Então você pode continuar com as soluções nas outras respostas.

Para serviços que precisam ser executados, mas não podem ser acessados de fora (como um servidor de banco de dados local), considere alterar a configuração para que ela apenas escute em localhost / 127.0.0.1. Dessa forma, só pode ser acessado por usuários locais.

    
por 11.08.2009 / 13:49
4

Gostaria de verificar o Bastille-Linux no link , é um conjunto de scripts que você pode executar e verificará o configurações do sistema, permissões de arquivos, configuração do usuário, etc. Eu usei uma vez ou duas vezes em minhas próprias caixas, e se encontrar problemas em instalações padrão (principalmente r_x em utilitários rsh / rsync). Ele é exibido como html / java + curses / texto simples.

    
por 11.08.2009 / 14:48
3

Que distro?

Geral:

  • Revise iptables e / ou firewall configurações
  • Revise as configurações do SSHD
  • Rever todos os acessos externos configurações de serviço
  • Verifique se você está executando o mais recente software disponível
  • Verificar vulnerabilidades do kernel (uname -a e depois google)
  • Revise a permissão do usuário e o grupo permissões em arquivos editáveis
por 11.08.2009 / 09:49
3

Outra boa primeira verificação é executar nmap hostname de outro host na rede. Isso dá uma visão de fora do que o netstat mostrou no host.

    
por 11.08.2009 / 14:17
3

Se você estiver preocupado, recomendo seguir os tutoriais mencionados e reconstruir o servidor. Especialmente se você acha que o outro administrador pode ter deixado algo ruim. Como o novo administrador, você deve saber como implantar qualquer serviço que esteja sendo executado novamente.

Apenas certifique-se de fazer tudo de volta primeiro, você pode criar uma imagem de todas as partições para ter certeza de que está tudo certo.

Se o seu chefe não te deixar, então todas as outras recomendações soam boas para mim :-)

    
por 11.08.2009 / 14:36
2

Além de algumas das respostas muito boas aqui, confira o link . Eles têm alguns documentos muito bons se você estiver disposto a ler um pouco para entender melhor a "defesa em profundidade".

Algumas das premissas básicas são:

  • mantenha seus servidores corrigidos
  • executam apenas os serviços que precisam estar em execução
  • limita o acesso do usuário ao servidor
por 11.08.2009 / 15:06
1

Tente também chkrootkit , ele vem no repositório padrão da maioria das distribuições e é de qualquer maneira muito fácil de instalar. Ele verificará seu sistema em busca de muitas vulnerabilidades, rootkits e worms conhecidos.

    
por 11.08.2009 / 16:00
1

Uma coisa que você pode fazer para ter uma idéia do sistema é diff a pasta / etc em uma nova instalação (com as mesmas atualizações aplicadas). Isso lhe dirá o que mudou para que você possa concentre suas preocupações de segurança lá.

    
por 11.08.2009 / 17:26
1

Para expandir o que o mas disse, aqui está um comando find simples para listar todos os arquivos setuid e setgid no sistema para revisão.

find / -type f \( -perm -4000 -o -perm -2000 \) -print

É claro que, como outros já disseram, isso é tudo assumindo que a máquina não tem um rootkit nela ...

    
por 11.08.2009 / 21:10
1

O Chrootkit / rkhunter é o fruto de longa data. Se você tiver um rootkit instalado, tudo o que foi relatado ficará comprometido e, portanto, não será de muita ajuda. Portanto, baixe-o de uma fonte conhecida e não use os que já estão na caixa. Outro bom truque é instalar um kernel que você sabe que é bom (seja de pacotes ou role seus próprios). Verifique se há backdoors (lsof -i e 0 uid contas não raiz). Inspecionar regras de firewall geralmente pode dizer muito sobre os hábitos dos administradores anteriores. Coloque um wireshark / snort nele, tente detectar algo incomum. Olhe para onde os logs estão indo. Verifique todos os tipos de arquivos .profile / .bashrc para quaisquer comandos incomuns. Procure em .ssh / known_hosts por quaisquer hosts desonestos.

    
por 12.08.2009 / 02:53