Eu tenho um VPS do Debian de 32 bits do link e realmente não fiz nenhum tipo de configuração avançada para protegê-lo (porta 22; senha habilitada).
Parece que, de alguma forma, há uma varredura do ssh no meu IP, estou sendo sinalizada, pois isso é contra os TOS. Eu tenho SSHing apenas do meu Comcast ISP que eu executo o Linux.
Isso é algo comum quando se compra um novo vps? Existem algumas dicas de configuração de segurança padrão? Estou bastante confuso sobre como minha máquina foi acusada dessa varredura ssh.
Pessoalmente, parece que você foi comprometido. Eu reinstalaria o sistema operacional e, em seguida, reconfiguraria o SSH com:
Muitos comprometimentos do sistema são o resultado de serem verificados e uma senha fraca sendo forçada a brutalidade. Infelizmente, isso se tornou parte da vida cotidiana da Internet e você precisa proteger seu servidor contra esses ataques. Aqui está um bom guia para começar:
Este olhou como um comentário sobre a resposta de freedom_is_chaos, mas cresceu muito ...
@Meder: Outros serviços, como o próprio SSHd, mantêm logs - não apenas o Apache. Embora qualquer exploit bem codificado (ou um exploit criado por um gerador de exploit off-the-shelf de boa qualidade) provavelmente irá encobrir seus rastros assim que ele entrar.
Uma senha mal escolhida para root ou uma conta que tenha privilégios suficientes via sudo é o vetor de ataque mais provável aqui, pois a exploração está fazendo muitas conexões SSH (para tentar se espalhar para outros servidores da mesma forma infectado seu). Você precisa parar a VM imediatamente . Quanto mais tempo estiver, mais será um problema, causando potencialmente mais infecções.
Se você tiver dados sobre a VM que deseja manter, desligue-a imediatamente - não mexa antes em fazer backups porque, a menos que as coisas tenham mudado desde a última vez que usei os serviços da Linode, você pode criar uma nova VM não explorada. e conecte a unidade antiga a ela para retirar os dados. Tenha cuidado para não confiar nesses dados, especialmente binários executáveis e scripts - verifique o que você usa caso tenha sido modificado para facilitar futuras explorações (você não quer copiar acidentalmente para a nova VM uma porta de trás que foi instalado no antigo).
Dê também uma leitura à página ligada pelo tasaro. Parece um bom resumo de como tentar proteger uma VM simples. Se você não puder (por algum motivo, não) usar a autenticação baseada em chave, use pelo menos senhas strongs - não se preocupe se elas são memoráveis, pois você pode armazená-las em algo como keepass em vez de precisar se lembrar deles (apenas certifique-se de manter seu keepass daatase em um cofre). Enquanto um exploit remoto poderia facilmente chegar a algo como "elephant4" por meio de um dicionário baseado em força bruta, é improvável que aconteça algo como "eGz3nk7aVdN7OIChoPy7". Também certifique-se de usar senhas diferentes para serviços diferentes - assim, se alguém conseguir escapar de alguma forma, você apenas compromete um serviço e não muitos outros.
A explicação mais provável é que o seu servidor foi comprometido.
O que vem depois?
Depois de obter uma nova imagem, não se esqueça de desativar o login raiz via SSH. Dessa forma, você é forçado a fazer login por meio de uma conta de usuário e, em seguida, elevar para a raiz usando su . Não dê privilégios de sudo às contas de usuários regulares que não precisem dele.
Também é uma boa idéia usar AllowUsers em sua configuração SSH para restringir o acesso SSH àqueles que precisam dele. Se possível, garanta que esses usuários tenham senhas strongs de alguma forma.
Por que reinstalar do zero?
Se você continuar a usar o mesmo sistema, nunca poderá ter certeza de ter removido a última porta de trás instalada pelo invasor. Se o invasor explorasse um bug de escalonamento de privilégios para ganhar root , ele / ela poderia até mesmo substituir o sistema e / ou binários de inicialização.