Como sei se meu servidor Linux foi invadido?

Quais são os sinais indicadores de que um servidor Linux foi invadido? Existem ferramentas que podem gerar e enviar por email um relatório de auditoria de maneira programada?

1. Mantenha uma cópia original dos arquivos críticos do sistema (como ls, ps, netstat, md5sum) em algum lugar, com um md5sum, e compare-os regularmente com as versões ao vivo. Rootkits invariavelmente modificam esses arquivos. Use essas cópias se suspeitar que os originais foram comprometidos.
2. um assessor ou tripwire informará todos os arquivos que foram modificados - supondo que seus bancos de dados não tenham sido violados.
3. Configure o syslog para enviar seus arquivos de log para um servidor de log remoto, onde eles não podem ser violados por um invasor. Assista a esses arquivos de log remotos em busca de atividades suspeitas
4. ler seus registros regularmente - uso logwatch ou logcheck para sintetizar a informação crítica.
5. Conheça seus servidores . Saiba que tipos de atividades e logs são normais.

Você não

Eu sei, eu sei - mas é a verdade paranóica e triste, na verdade;) Existem muitas dicas, é claro, mas se o sistema foi direcionado especificamente - pode ser impossível dizer. É bom entender que nada é completamente seguro. Mas precisamos trabalhar para ter mais segurança; portanto, apontarei para todas as outras respostas;)

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

O Tripwire é uma ferramenta comumente usada - notifica quando os arquivos do sistema foram alterados, embora obviamente você precise instalá-lo com antecedência. Caso contrário, itens como novas contas de usuário desconhecidas, processos e arquivos estranhos que você não reconhece ou 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.

Algumas coisas que me deram dicas 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 raiz quebrados)
• Diretórios ocultos /ou /var/(a maioria das crianças de script é burra ou preguiçosa demais para cobrir suas trilhas)
• netstat mostra portas abertas que não deveriam estar lá
• Daemons na lista de processos dos quais você normalmente usa tipos diferentes (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ê tiver um mau pressentimento sobre a diligência (com atualizações, etc.) do administrador de quem você herdou um sistema, fique de olho nele!

Existe um método de verificar servidores invadidos por meio de kill:

Essencialmente, quando você executa "kill -0 $ PID", está enviando um sinal nop para processar o identificador $ PID. Se o processo estiver em execução, o comando kill sairá normalmente. (FWIW, como você está transmitindo um sinal de nop kill, nada acontecerá com o processo). Se um processo não estiver em execução, o comando kill falhará (o 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 ocultar os processos afetados das tabelas de processos etc. processos. E então isso significa que

a) Esta verificação não é uma verificação extensa, pois os rootkits bem codificados / inteligentes garantirão que o kernel responda com uma resposta "processo não existe", tornando a verificação redundante. b) De qualquer maneira, quando um servidor invadido tem um processo "ruim" em execução, seu PID geralmente não é exibido em / proc.

Portanto , se você está aqui até agora, o método é matar -0 todos os processos disponíveis no sistema (qualquer coisa entre 1 -> / proc / sys / kernel / pid_max) e ver se há processos em execução, mas não relatados em / proc.

Se alguns processos aparecerem em execução, mas não foram relatados em / proc, você provavelmente tem um problema da maneira que vê.

Aqui está um script bash que implementa tudo isso - https://gist.github.com/1032229 . Salve isso em algum arquivo e execute-o, se você encontrar um processo que não é relatado no proc, você deve ter algumas pistas para começar a pesquisar.

HTH.

Seguirei as respostas dadas aqui e adicionarei uma das minhas.

find /etc /var -mtime -2

Isso fornecerá 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 seu servidor foi invadido.

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

• Use um IDS

  O SNORT® é um sistema de prevenção e detecção de intrusões de rede de código aberto que utiliza uma linguagem orientada por regras, que combina os benefícios dos métodos de inspeção baseados em assinaturas, protocolos e anomalias. Com milhões de downloads até o momento, o Snort é a tecnologia de detecção e prevenção de intrusões mais amplamente implantada no mundo e se tornou o padrão de fato para o setor.

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

• Use os logs ...

  Dependendo do seu uso, você pode configurá-lo para que você saiba sempre que um usuário efetuar logon ou logon de um IP ímpar, ou sempre que o root efetuar logon ou sempre que alguém tentar efetuar login. Na verdade, tenho o servidor por e-mail todas as mensagens de log maiores que Debug. Sim, mesmo aviso. Eu filtro alguns deles, é claro, mas todas as manhãs quando recebo 10 e-mails sobre coisas, me faz querer corrigi-lo para que isso pare de acontecer.

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

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

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

Eu gostaria de adicionar a isso:

Verifique seu histórico do bash, se ele estiver vazio e você não o tiver desmarcado ou esvaziado, existe uma boa possibilidade de alguém comprometer seu servidor.

Verifique por último. Você verá IPs desconhecidos ou parecerá muito vazio.

Então, como a resposta aceita afirmou, os arquivos do sistema geralmente são alterados, verifique a data da modificação. No entanto, muitas vezes eles violam a data de modificação.

Eles costumam instalar outra versão do ssh em execução em uma porta aleatória. Isso geralmente está oculto em alguns lugares realmente estranhos. Observe que normalmente será renomeado para algo diferente de ssh. Portanto, verifique o netstat (pode não funcionar, pois geralmente o substitui) e use o iptables para bloquear qualquer porta desconhecida.

De qualquer forma, é uma situação em que prevenir é melhor que remediar. Se você foi comprometido, é melhor formatar e começar novamente. É quase impossível confirmar que você limpou com sucesso o hack.

Observe o seguinte para evitar que seu servidor seja comprometido.

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

Vale a pena notar que, uma vez que eles estejam em um servidor, eles verificarão seu histórico do bash e procurarão outros servidores aos quais você se conectou via ssh nesse servidor. Eles tentarão se conectar a esses servidores. Portanto, se você for brutalmente forçado devido a uma senha ruim, é muito possível que eles consigam se conectar ao outro servidor e comprometê-los também.

É um mundo feio, reitero que prevenir é melhor que remediar.

Depois de pesquisar um pouco, também é o que eu listei acima, entre outras coisas: http://www.chkrootkit.org/ e http://www.rootkit.nl/projects/rootkit_hunter.html

Você deve verificar o GuardRail. Ele pode verificar seu servidor diariamente e informar o que mudou de uma maneira visual agradável. Ele não requer um agente e pode conectar-se através de SSH, para que você não precise juntar a máquina e os recursos com um agente.

O melhor de tudo é que é gratuito para até 5 servidores.

Confira aqui:

https://www.scriptrock.com/