Como devo reagir em um login mal-intencionado?

Question

Assegurei o SSH no meu servidor (autenticação de chave, sem rootlogin, protocolo 2, etc), mas estou um pouco paranóico.

Não consigo usar algum filtro de IP, pois quero manter a flexibilidade de onde posso fazer o login.

Estou pensando em enviar um email para mim quando alguém fizer login no meu sistema usando o SSH.

No entanto, isso me faz pensar:

Digamos que eu tenha implementado o código acima e receba um e-mail informando que alguém acabou de efetuar login usando o SSH. E eu tenho certeza que não sou eu :) nem é outro administrador.

Qual seria a resposta apropriada?

• Diminui o servidor em pânico?
• Monitorar o que o usuário mal-intencionado está fazendo no servidor?
• Kick out the user?
• Mate com fogo?
• Algo mais?

PS

Servidor é o Centos 5.7

EDITAR

O servidor é usado como um servidor web (Apache / Postgres / PHP) e servidor de e-mail (Zimbra).

Então eu acho que os dados são e-mails e bancos de dados.

    

Answer 1

Dê uma olhada em um sistema IDS, pessoalmente eu uso o link da OSSEC.

Ele enviará um e-mail quando uma regra for acionada. Por padrão, ela é um pouco spam, mas pode ser configurada. Por exemplo, você receberá um email quando:

1. Login de usuário pela primeira vez via SSH
2. Primeira vez que um usuário executa o sudo
3. Failed sudo / su conversões
4. Quando a soma de verificação de um arquivo em / etc / (ou qualquer diretório configurado) é alterada.

E muito mais, procura rootkits e pode ser configurado para responder automaticamente às ameaças.

Em termos de como você deve reagir, isso é mais uma questão de lógica de negócios. Pergunte a si mesmo

• Quão crítico é esse sistema? Pode ser desligado por um tempo indeterminado sem problemas?
• Você tem backups? (E você pode confiar que esses backups também não serão quebrados?)

Se você puder tirar a caixa, retire-a. faça um backup completo do disco , você precisa informar como eles entraram, usar algo como o kit Sleuth. Você deve montar o disco para fazer testes, não confiar nas ferramentas do sistema que foram comprometidas, você não pode confiar que os binários são realmente o que você pensa que eles são. Além disso, se você for capaz de determinar que um usuário ganhou acesso root, tudo nessa caixa se foi, você não pode confiar nos logs, timestamps, binários, nada. É aqui que algo como o rsyslog pode ajudar.

Se você tivesse dados de clientes que foram comprometidos, é necessário seguir o plano de negócios para saber como isso deve ser feito.

    

Answer 2

Eu acho que você está sendo excessivamente paranóico. Você restringiu o login raiz à autenticação de chave. Você forçou o protocolo para a versão 2. Suponho que você também tenha restringido quais usuários podem fazer login via ssh (através do arquivo sshd_config) ...

Além dessas técnicas, você deve se certificar de que pode limitar o que um usuário conectado pode fazer. Restringir sua capacidade de escalar para o nível raiz. Limite o acesso aos comandos via sudo ou não. Você tem o SELinux ativado? Você tem a contabilidade do processo ativada? Você poderia instalar DenyHosts como meio de rastrear tentativas ssh ...

Você tem alguma capacidade de fechar o acesso SSH e confiar em uma VPN para acesso externo ao sistema?

    

Answer 3

Usar os scripts de bloqueio de IP é, na verdade, uma boa ideia, especialmente se o script de bloqueio apenas bloquear endereços IP dos quais você teve logins com falha anteriormente. A maior vantagem que vi imediatamente foi que limpou o meu arquivo syslog. Eu obteria N logins com falha dentro de Y segundos, depois boom, ip bloqueado, talvez uma ou duas tentativas, mas a entrada de log era uma linha, então eles parariam. Após um número X de dias, a entrada seria purgada. A principal coisa que eu tinha que lembrar era que, se eu não conseguisse logar algumas vezes, era para esperar antes que eu atingisse o login mágico.

Outra coisa a considerar é quando eles estiverem no seu sistema, suponha que eles tenham acesso totalmente privilegiado, para que eles podem usar seu sistema? Eles podem iniciar um serviço na caixa para receber novas conexões do lado de fora ou há algum hardware de firewall entre o sistema e a Internet? O sistema pode ser usado como uma plataforma de lançamento para ataques a outros sistemas, ou o seu firewall bloqueia todo o acesso de saída por padrão (um proxy de squid em outro host é útil para essas situações)? Também é fácil saltar para outros sistemas quando eles estão na sua rede?

    

Answer 4

Eu derrubaria o servidor imediatamente (já que o invasor conseguiu fazer o login, ele possivelmente é dono da sua chave privada e, nesse caso, você não tem meios de impedir que ele faça o login novamente). Então eu criaria outro VPS e copiaria lá apenas os dados que eu preciso, enquanto verificava que não copiava nenhum backdoor que ele instalasse (de preferência copiar de algum backup feito antes do ataque, para novos dados usar diff para verificar cada mudança desde o último backup para ver se essa mudança é a atividade do intruso). É difícil confiar no sistema hackeado.

Além disso, eu verificaria como ele conseguiu se logar - possivelmente ele possui sistema (s) que mantêm suas chaves privadas e, portanto, será capaz de obter suas novas chaves também, ou ele conseguiu de alguma forma alterar sua configuração sshd - novamente, a vulnerabilidade pode existir em um novo sistema também.

Além disso, se você é paranóico, você pode gostar da autenticação de pacote único para o seu SSH.