Como sei se meu servidor Linux foi invadido?

34

Quais são os sinais indicadores de que um servidor Linux foi invadido? Existe alguma ferramenta que possa gerar e enviar por e-mail um relatório de auditoria em uma base programada?

    
por cowgod 01.05.2009 / 22:59

10 respostas

31
  1. Mantenha uma cópia original de arquivos críticos do sistema (como ls, ps, netstat, md5sum) em algum lugar, com um md5sum deles e compare-os com as versões ao vivo regularmente. Os rootkits invariavelmente modificarão esses arquivos. Use essas cópias se suspeitar que os originais foram comprometidos.
  2. O aide ou tripwire informará sobre quaisquer arquivos que tenham sido modificados, desde que seus bancos de dados não tenham sido adulterados.
  3. Configure o syslog para enviar seus arquivos de log para um servidor de log remoto onde eles não possam ser adulterados por um intruso. Assista esses arquivos de log remotos para atividades suspeitas
  4. leia seus registros regularmente - use logwatch ou logcheck para sintetizar as informações críticas.
  5. Conheça seus servidores . Saiba quais tipos de atividades e registros são normais.
por 01.05.2009 / 23:11
11

O Tripwire é uma ferramenta comumente usada - ele avisa quando os arquivos do sistema foram alterados, embora, obviamente, você precise instalá-lo antecipadamente. Caso contrário, itens como novas contas de usuário que você não conhece, processos estranhos e arquivos que você não reconhece, ou o aumento do uso da largura de banda sem motivo aparente são os sinais usuais.

Outros sistemas de monitoramento, como o Zabbix , podem ser configurados para alertá-lo quando arquivos como / etc / passwd são alterados.

    
por 01.05.2009 / 23:01
11

Você não faz isso.

Eu sei, eu sei - mas é a verdade triste e paranóica, realmente;) Há muitas dicas, é claro, mas se o sistema fosse direcionado especificamente - poderia ser impossível dizer. É bom entender que nada é completamente seguro. Mas precisamos trabalhar por mais segurança, então vou apontar todas as outras respostas;)

Se o seu sistema foi comprometido, nenhuma das ferramentas do seu sistema pode ser confiável para revelar a verdade.

    
por 01.05.2009 / 23:13
10

Algumas coisas que me alertaram no passado:

  • Carga alta em um sistema que deve estar ocioso
  • Segfaults estranhos, por exemplo. de utilitários padrão como ls (isso pode acontecer com kits de raiz quebrados)
  • Diretórios ocultos em / ou /var/ (a maioria dos kiddies de script é muito estúpida ou preguiçosa para encobrir seus rastros)
  • netstat mostra portas abertas que não deveriam estar lá
  • Daemons na lista de processos que você normalmente usa diferentes tipos de sabores (por exemplo, bind , mas você sempre usa djbdns )

Além disso, descobri que há um sinal confiável de que uma caixa está comprometida: se você tem um mau pressentimento sobre a diligência (com atualizações, etc.) do administrador de quem você herdou um sistema, fique atento isso!

    
por 03.05.2009 / 03:49
8

Há um método de verificação de servidores invadidos por meio de kill -

Essencialmente, quando você executa "kill -0 $ PID" você está enviando um sinal nop para processar o identificador $ PID. Se o processo estiver em execução, o comando kill sairá normalmente. (FWIW, desde que você está passando um sinal de nop kill, nada vai acontecer com o processo). Se um processo não estiver em execução, o comando kill falhará (status de saída menor que zero).

Quando seu servidor é invadido / um rootkit é instalado, uma das primeiras coisas que ele faz é dizer ao kernel para esconder os processos afetados das tabelas de processo, etc. No entanto, ele pode fazer todo tipo de coisa legal no espaço do kernel. ao redor com os processos. E isso significa que

a) Esta verificação não é uma verificação extensa, já que os rootkits bem codificados / inteligentes garantirão que o kernel responda com uma resposta "o processo não existe", tornando esta verificação redundante. b) De qualquer forma, quando um servidor hackeado tem um processo "ruim" em execução, o PID geralmente não é mostrado em / proc.

Então , se você está aqui até agora, o método é matar -0 todo processo disponível no sistema (qualquer coisa de 1 - > / proc / sys / kernel / pid_max) e veja se há processos em execução mas não relatados em / proc.

Se alguns processos surgirem como em execução, mas não forem relatados em / proc, você provavelmente terá um problema de qualquer maneira.

Aqui está um script bash que implementa tudo isso - link . Salve isso em algum arquivo e execute-o, se você encontrar um processo que não seja reportado no proc, você deve ter alguma vantagem para começar a procurar.

HTH.

    
por 17.06.2011 / 22:39
7

Dou as respostas dadas aqui e adiciono uma das minhas.

find /etc /var -mtime -2

Isso lhe dará uma indicação rápida se algum dos arquivos do servidor principal foi alterado nos últimos 2 dias.

Isto é de um artigo sobre detecção de hackers Como detectar se o seu servidor foi invadido.

    
por 29.03.2012 / 17:58
5

De Como posso detectar intrusões indesejadas nos meus servidores?

  • Use um IDS

    SNORT® is an open source network intrusion prevention and detection system utilizing a rule-driven language, which combines the benefits of signature, protocol and anomaly based inspection methods. With millions of downloads to date, Snort is the most widely deployed intrusion detection and prevention technology worldwide and has become the de facto standard for the industry.

    O Snort lê o tráfego de rede e pode procurar por coisas como "teste da unidade por caneta", em que alguém apenas executa uma varredura de metasploit inteira em seus servidores. É bom saber esse tipo de coisa, na minha opinião.

  • Use os registros ...

    Dependendo do seu uso, você pode configurá-lo para que você saiba sempre que um usuário fizer login ou efetuar login a partir de um IP ímpar ou sempre que o usuário fizer login ou sempre que alguém tentar fazer login. Na verdade, eu tenho o servidor me enviando um e-mail a cada mensagem de log maior que Debug. Sim, até mesmo aviso. Eu filto alguns deles, é claro, mas toda manhã, quando eu recebo 10 e-mails sobre coisas, isso me faz querer consertar, então isso pára de acontecer.

  • Monitore sua configuração - na verdade, mantenho todo o meu / etc no subversion para que eu possa acompanhar as revisões.

  • Execute verificações. Ferramentas como Lynis e Rootkit Hunter pode fornecer alertas para possíveis falhas de segurança em seus aplicativos. Existem programas que mantêm um hash ou hash tree de todos os seus bins e podem alertá-lo sobre alterações.

  • Monitore seu servidor - Assim como você mencionou o espaço em disco - os gráficos podem lhe dar uma dica se algo for incomum. Eu uso Cactos para ficar de olho em CPU, tráfego de rede, espaço em disco, temperaturas, etc. Se algo parece estranho é ímpar e você deve descobrir porque é estranho.

por 01.05.2009 / 23:40
2

Gostaria apenas de acrescentar isto:

Verifique seu histórico de bash, se estiver vazio e você não tiver desativado ou esvaziado, há uma boa possibilidade de alguém ter comprometido seu servidor.

Verifique por último. Ou você verá I.P's desconhecidos ou parecerá muito vazio.

Em seguida, como a resposta aceita afirmou, os arquivos do sistema geralmente são alterados, verifique a data de modificação. No entanto, eles costumam adulterar a data modificada.

Eles geralmente instalam outra versão do ssh em execução em uma porta aleatória. Isso é muitas vezes escondido em alguns lugares muito estranhos. Note que normalmente será renomeado para algo diferente de ssh. Portanto, verifique o netstat (pode não funcionar como eles geralmente o substituem) e use o iptables para bloquear qualquer porta desconhecida.

Em qualquer caso, esta é uma situação em que é melhor prevenir do que remediar. Se você foi comprometido, é melhor apenas formatar e começar de novo. É quase impossível confirmar que você limpou com sucesso o hack.

Anote o seguinte para impedir que o servidor seja comprometido.

  1. Alterar porta ssh
  2. Impedir que o root faça login
  3. permite apenas determinados usuários
  4. Impedir login de senha
  5. Use chaves ssh, chaves protegidas por senha preferíveis
  6. Sempre que possível, lista negra de todos os ip e coloque na lista de permissões os ips necessários.
  7. Instalar e configurar o fail2ban
  8. Use o tripwire para detectar intrusões
  9. Monitore o número de usuários logados com o Nagios ou zabbix. Mesmo se você for notificado toda vez que fizer login, pelo menos saberá quando outra pessoa estiver jogando.
  10. Se possível, mantenha seu servidor em uma VPN e apenas permita ssh via vpn ip. Proteja sua vpn.

Vale a pena observar que, uma vez em um servidor, eles verificarão o histórico bash e procurarão por outros servidores que você conectou via ssh a partir desse servidor. Eles tentarão se conectar a esses servidores. Então, se você for forçado a usar brutalidade devido a uma senha ruim, é muito possível que eles consigam se conectar ao outro servidor e comprometê-los também.

É um mundo feio lá fora, eu reitero que é melhor prevenir do que remediar.

    
por 20.12.2013 / 10:12
1

Depois de pesquisar um pouco, há isso também, ele faz o que eu listei acima, entre outras coisas: link e link

    
por 17.06.2011 / 22:57
0

Você deve verificar o GuardRail. Ele pode escanear seu servidor diariamente e dizer o que mudou de uma maneira visual agradável. Ele não requer um agente e pode se conectar ao SSH, para que você não precise arruinar sua máquina e recursos com um agente.

O melhor de tudo é que é grátis até 5 servidores.

Confira aqui:

link

    
por 17.10.2013 / 21:23