Como posso determinar se minha caixa do Linux foi infiltrada?

10

Li recentemente um artigo sobre como analisar tentativas de login mal-intencionadas de SSH. Isso me fez pensar: o nome de usuário SSH, as combinações de senha na minha caixa Debian são incomuns? Eu tinha sido alvo de um ataque de dicionário de força bruta? Vamos dar uma olhada em /var/log/auth.log.0 :

Sep 23 07:42:04 SLUG sshd[8303]: Invalid user tyjuan from 210.168.200.190
Sep 23 07:42:09 SLUG sshd[8305]: Invalid user tykeedra from 210.168.200.190
Sep 23 07:42:14 SLUG sshd[8307]: Invalid user tykeem from 210.168.200.190
Sep 23 07:42:19 SLUG sshd[8309]: Invalid user tykeshia from 210.168.200.190
Sep 23 07:42:25 SLUG sshd[8311]: Invalid user tyla from 210.168.200.190
Sep 23 07:42:30 SLUG sshd[8313]: Invalid user tylan from 210.168.200.190
Sep 23 07:42:35 SLUG sshd[8315]: Invalid user tylar from 210.168.200.190
Sep 23 07:42:40 SLUG sshd[8317]: Invalid user tyler from 210.168.200.190
Sep 23 07:42:45 SLUG sshd[8319]: Invalid user tylerfrank from 210.168.200.190
Sep 23 07:42:50 SLUG sshd[8321]: Invalid user tyliah from 210.168.200.190
Sep 23 07:42:55 SLUG sshd[8323]: Invalid user tylor from 210.168.200.190

Então, isso não parece bom. Agora que sei que fui alvo de um ataque e que algumas das minhas combinações de nome de usuário e senha são fracas, gostaria de saber como posso ...

  • ... determina se minha caixa do Linux foi infiltrada?
  • ... desfaz qualquer dano deixado pelos criminosos?
  • ... impedir que isso aconteça no futuro?

UPDATE

Algum conselho sobre desfazer qualquer dano deixado pelos criminosos?

    
por Jake McGraw 24.09.2008 / 22:22

20 respostas

15

Muitas pessoas parecem sugerir DenyHosts, mas eu tenho visto muito sucesso com Fail2Ban nos meus sistemas. Ele observa um número (configurável) de falhas e, em seguida, executa uma ação - em meus servidores, essa ação é usar o iptables para descartar todo o tráfego do host. Após 10 falhas de login, elas são banidas e isso é o fim.

Eu uso isso em combinação com o Logcheck, para que eu sempre saiba o que está acontecendo nos meus servidores.

Se você tiver alguma evidência de que alguém invadiu seus sistemas (os registros que você postou não são provas disso), sua única solução é fazer backup de todos os dados que você precisa manter, limpar a máquina, reinstalar e restaurar a partir de backups. Caso contrário, não há como ter certeza.

    
por 24.09.2008 / 23:52
10

As tentativas de login válidas também são registradas, portanto, se você vir uma tentativa de força bruta seguida por um sucesso, isso é uma boa indicação de que algo ruim aconteceu.

Eu uso o DenyHosts para monitorar meus logs em busca de tráfego SSH suspeito, e eu o configurei para proteger automaticamente os hosts em um determinado ponto .

Observe que há várias outras maneiras de monitorar sua máquina para verificar se ela está comprometida, incluindo padrões de carga, atividade de login, verificação periódica de tráfego, monitoramento de processos em execução e portas abertas e garantia da integridade de arquivos com uma ferramenta como tripwire.

Se você for fazer um só, monitorar a carga do sistema é uma maneira muito eficaz de detectar comprometimentos, porque a maioria das máquinas comprometidas é usada para fazer coisas como enviar grandes quantidades de spam ou receber muito tráfego. Talvez não seja útil se você é um alvo de alto valor e as pessoas podem estar tentando especificamente invadir você por outras razões além de transformar seu host em um zumbi, mas valioso, no entanto. Mais carga de monitoramento é necessária para criar perfis e descobrir quando você precisa investir em mais hardware ou software melhor.

Você também deve fazer uma análise de log abrangente, olhando para auth.log e outros para coisas que são inesperadas. A análise de arquivos de log é um mercado competitivo e o problema ainda não foi resolvido, mas existem ferramentas gratuitas como o logwatch, que podem ser configuradas para enviar resumos diariamente.

Segurança através de camadas!

    
por 24.09.2008 / 22:26
4

Esqueça o Tripwire, é bem caro. Use AIDE em vez disso. É grátis, fácil de configurar (embora demore um pouco para decidir quais diretórios temporários devem ser excluídos e configurados).

você o executa, ele cria um banco de dados de todos os arquivos. Execute-o novamente e ele informará quais arquivos foram alterados.

Uma outra coisa a fazer é instalar o CSF, que tem um bloqueador de tipo denyhost, já que as pessoas falham repetidamente para efetuar login, ele as adicionará às regras do seu firewall. Você também pode exigir logins SSH para ter uma chave pública também, as crianças de script podem tentar tantos logins quanto quiserem.

    
por 24.09.2008 / 23:47
4
"* ... determine if my Linux box has been infiltrated?"
  • procure sinais de processos estranhos. Eu normalmente uso as ferramentas que vêm com chkrootkit ( link )
  • Faça um portscan com o nmap a partir de um diferente máquina. Se sua caixa foi comprometida, as chances são de que o atacante instalou um backdoor

"* ... desfaz qualquer dano deixado pelos perpetradores?"

esqueça, se houve um ataque, o melhor conselho é reinstalá-lo desde o início (certifique-se de fazer qualquer plug-in na nova instalação). É muito fácil não notar um backdoor ou um processo furtivo, é melhor você reinstalar.

"* ... impede que isso aconteça no futuro?"

  • atualizações de segurança

  • firewall restrito

  • senhas strongs

  • desativar serviços desnecessários

por 25.09.2008 / 02:46
3

Veja ferramentas como logcheck , portsentry e tripwire . é muito comum para tentativas aleatórias de dicionário SSH, então eu não estaria muito preocupado com isso. você pode querer mudar a porta para ofuscação aleatória, mas você ainda verá tentativas aleatórias de vez em quando, é a vida com uma máquina na internet.

    
por 24.09.2008 / 22:27
3

Uma coisa que eu uso em meus servidores para ajudar a evitar esses ataques é DenyHosts . O DenyHosts impedirá que um usuário mal-intencionado tente fazer o login. Desde a instalação, meus arquivos de log tiveram muito menos entradas de tentativas de login.

    
por 24.09.2008 / 22:29
3

É uma boa prática usar pares de chaves Pública / Privada como autenticação extra; Dessa forma, um usuário não pode efetuar login no SSH sem uma chave correta; o que seria bastante impossível adivinhar para um forcedor bruto. Um bom artigo sobre isso pode ser encontrado aqui .

Isso sozinho com uma senha seria bastante sólido para autenticação SSH; Mas existem mais vulnerabilidades! Cuidado com todos os aplicativos que usam uma porta aberta; Se eles contiverem um bug, os exploradores podem ultrapassar o seu sistema. Um bom exemplo foi um bot de spam instalado em nosso servidor devido a um bug no software webstats que estávamos usando no momento.

    
por 25.09.2008 / 00:00
2

O Fail2ban é um analisador em tempo real de log de acesso. Ele pode ser configurado para bloquear qualquer IP com várias tentativas falhas de login. Isso evita ataques de dicionário sem ter que mover a porta ssh. O chkrootkit e o rootkithunter são bons utilitários para verificar invasões. Se a invasão tiver sido bem-sucedida, a prática recomendada é copiar dados (e apenas dados, não executáveis), limpar e reinstalar porque é realmente difícil ter 100% de certeza de que o sistema está limpo.

    
por 25.09.2008 / 00:02
2

Não há nada aqui para sugerir que sua caixa foi comprometida. Mesmo que suas senhas sejam muito fracas, é extremamente improvável que um ataque de dicionário que apenas lance uma tentativa de login em cada nome de usuário tenha sucesso.

Mas, se você souber que suas senhas são fracas, então as fortaleça! Eu pessoalmente gosto do pwgen (que é empacotado pelo Debian). Em cada execução, ele gera um grande número de candidatos a senhas strongs, mas relativamente pronunciáveis, que (pelo menos para mim) são fáceis de lembrar, como yodieCh1, Tai2daci ou Chohcah9.

No entanto, se houver outras provas para mostrar que o seu sistema foi comprometido ... Nuke-lo de órbita. É a única maneira de ter certeza.

Dados não executáveis são provavelmente recuperáveis, mas qualquer coisa com conteúdo executável (isso inclui potencialmente documentos do MS Office e alguns arquivos de configuração) tem que ser executada a menos que você esteja disposto e seja capaz de examiná-los manualmente para garantir que ele não foi hostilizado ou aceitou a possibilidade de que poderia ser hostil e danificar o sistema ou fornecer um meio para um futuro comprometimento se você o mantiver por perto.

    
por 25.09.2008 / 05:41
2

Uma pequena proteção adicional que eu gosto é a de limitar as conexões ssh de entrada para retardar ataques de dicionário ou similares. Não espere que isso proteja você sozinho, mas use isso além das sugestões nas outras respostas, incluindo a desativação da autenticação de senha.

Usando o iptables:

$ iptables        -A INPUT      -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT
$ iptables        -A INPUT      -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 3 -j ACCEPT
$ iptables        -A INPUT      -p tcp --dport 22 -j DROP
    
por 26.09.2008 / 15:01
2

Há alguns conselhos ruins sobre esse tópico, como:

  • usando uma porta não padrão para ssh (errado!)
  • usando alguma ferramenta de segurança de terceiros (adicionando uma dependência / complexidade desnecessária)
  • configurando seu firewall para bloquear ou colocar na lista branca (dor de cabeça de manutenção)

Basta ajustar seu /etc/ssh/sshd_config para melhorar a segurança:

  • PermitRootLogin no
  • Configure AllowUsers apenas para os usuários do sistema que possuem contas ssh
  • Considere usar somente chaves físicas com 'PasswordAuthentication no'

Se você é caixa foi infiltrada. Reconstrua a caixa.

    
por 29.09.2008 / 16:30
1

Acontecerá o tempo todo com o ssh ativado. Mova-o para uma porta alta.

Existe um programa chamado "Tripwire" que é excelente para detecção de intrusão, mas muito difícil de instalar. Se nada mais, você deve ler seus documentos para entender os problemas.

    
por 24.09.2008 / 22:25
1

Você precisa instalar a detecção de invasões antes de conectar a máquina à Internet.

E é uma boa ideia para as conexões SSH da lista de permissões de IP apenas para ter certeza de que o mundo inteiro não pode nem experimentar coisas como essa.

    
por 24.09.2008 / 22:26
1

How can I determine if my Linux box has been infiltrated?

Inicialize a mídia somente leitura (livecd) e compare os arquivos com o backup ou a mídia original.

Basta procurar um comportamento estranho. É claro que isso é mais fácil se você tomar um tempo antes de um hack para ter uma boa noção do que é "normal".

Os erros que você postou não indicam um comprometimento. Só que alguém está tentando.

How can I undo any of the damage left by the perpetrators?

Reinstale e restaure a partir de um backup antes que o sistema seja comprometido.

Veja:

How can I prevent this from happening in the future?

Veja:

por 24.09.2009 / 22:10
0

Você pode assistir a caixa para ver o que está entrando e saindo e procurar por algo suspeito. Veja esta postagem: link

    
por 24.09.2008 / 22:27
0

Psad juntamente com Shorewall é uma boa maneira de elogiar suas regras do iptables.

Eu também uso o Fail2ban para rastrear meus ssh logins

    
por 29.09.2008 / 07:25
0

use rkhunter ou chkrootkit ou ambos; escaneie sua caixa de fora para ver quais portas estão abertas

de qualquer forma, se tudo que você tem é um usuário inválido, não precisa se preocupar:)

    
por 24.09.2009 / 20:58
0

Algo muito diferente: tente usar o Google no endereço IP! Um hacker que se chama STARTURK da Turquia pode ter tentado hackear seu site.

Embora pareça um ataque de força bruta no seu sistema, pode ser que esse hacker tenha feito uma tentativa e agora esteja fora de algum outro site.

    
por 24.09.2009 / 21:27
0

Como muitos notaram, o Tripwire / AIDE é a melhor maneira de procurar por mudanças no sistema. Infelizmente, a vaca está fora do celeiro porque ela tem que ser configurada em um sistema bem conhecido.

Uma coisa que pode ajudá-lo, pelo menos, a começar é usar o banco de dados RPM para verificar o md5sums dos seus arquivos. A essência básica é esta:

rpm -qa | xargs rpm -V

Isso não é perfeito por vários motivos. Primeiro, seu banco de dados RPM local poderia, teoricamente, ter sido alterado. Em segundo lugar, a maioria das distros usa o prelinking, e o RPM não está ciente do prelink. Os MD5s podem parecer ter sido alterados a partir desse processo, o que é legítimo.

O melhor conselho é este: se você não tiver certeza se foi comprometido, é hora de fazer uma reconstrução.

    
por 24.09.2009 / 22:26
0

Para evitar futuros problemas de segurança, você pode dar uma olhada no OSSEC , usá-lo para fazer verificações de integridade de arquivos e monitorar logs em nossos servidores, é muito completo e fácil de configurar. Pode enviar notificações por e-mail, você pode verificar alertas via linha de comando ou uma interface web ...

link

retirado do site:

"O OSSEC é um Sistema de Detecção de Intrusos baseado em Host de Código Aberto. Ele realiza análise de log, verificação de integridade de arquivos, monitoramento de políticas, detecção de rootkits, alertas em tempo real e resposta ativa."

  • análise de log Ele pode verificar o arquivo de logs em seus servidores e avisa você através de regras (existem muitos pré-definidos e você pode adicionar seus próprios)

  • integridade do arquivo tripwire / aide como functionnality, assim você verá se algum arquivo foi modificado em seu servidor

  • monitoramento de políticas: verifique algumas regras de segurança "Práticas recomendadas"

  • detecção de rootkits: rkhunter, chkrootkit como functionnality

  • alerta em tempo real e resposta ativa: Você pode configurar o ossec para reagir automaticamente aos alertas (eu não uso isso, mas você pode usá-lo para bloquear o acesso ssh a hosts fazendo muitas tentativas falhas de conexão)

Produto realmente bom e é muito ativo

Para endurecer sua caixa, você também pode usar lynis ou bastille

por 25.09.2009 / 11:40