Você diz isso:
The past month, my personal web server has received thousands of these notices.
Não entre em pânico! Basta desativar a conta root no sistema.
Bem-vindo à Internet moderna! Não leve nenhum desses avisos pessoalmente e não tome nenhum deles como um sinal de um ataque direcionado contra o seu servidor web. Pelo contrário, esta é uma parte normal de qualquer servidor web existente on-line de alguma forma: os exércitos de botnets estão constantemente verificando os servidores da Web quanto a pontos fracos e, em seguida, exploram essas deficiências por vários motivos / hacks.
Se você estiver preocupado, a melhor, mais simples e fácil coisa que você pode fazer para remediar essa situação é desabilitar o usuário root no servidor e, em seguida, atribuir sudo direitos a outro usuário no sistema. Simplesmente fazendo isso, você elimina o problema sem precisar instalar nenhum software adicional.
Sim, alguns recomendam a instalação de software como Fail2ban no seu servidor e, embora eu não ache que seja uma ferramenta ruim um arsenal de defesa on-line, ele pode fornecer uma falsa sensação de segurança se você não tiver feito algo tão básico quanto desabilitar a conta de usuário root no sistema.
A maneira mais simples de fazer isso em seu sistema é primeiro atribuir sudo direitos a qualquer outro usuário no sistema diferente de root . E uma vez feito isso, faça o login como aquele usuário via SSH e execute este comando:
sudo passwd -l root
Isso bloqueará com eficiência a conta do usuário root . Então deixe esses bots tentarem logar via root a partir de agora até sempre ... Com root desabilitado, os esforços são inúteis.
Dito isso ... Talvez você devesse se preocupar.
Mas então você diz isso; ênfase é minha:
These attacks started by attempting
root, but have since progressed to attempting user accounts where I am not certain how they even guessed the correct usernames (albeit wrong passwords).
Não se preocupe se contas nomeadas aleatoriamente estão sendo "invadidas", mesmo que alguns nomes de usuários correspondam aos usuários do sistema.
Então você diz que eles estão tentando "contas de usuários", mas quais usuários? Eles correspondem a usuários válidos no sistema? Se eles não corresponderem a usuários válidos no sistema, não se preocupe ... Mesmo que, de vez em quando, você veja uma tentativa de fazer login como tomcat ou testuser . Esses bots estão percorrendo as dezenas / centenas / milhares de nomes de usuários que têm em sua biblioteca para ver em qual conta eles poderiam entrar ... E eu não perderia o sono com isso.
Mas se as tentativas de "hackear" forem contra contas específicas / conhecidas puramente ? Então você deve se preocupar.
Mas, dito isto, se de alguma forma os ataques são direcionados apenas para os usuários que existem em seu sistema, então você pode assumir que os hackers de alguma forma obtiveram uma cópia do seu arquivo/etc/passwd . Primeiro, apesar do nome do histórico de passwd , esse arquivo não contém senhas de usuário, mas sim informações básicas do usuário. E se os invasores tiverem esse arquivo /etc/passwd , você terá um problema MUITO maior .
Se contas específicas / conhecidas estiverem sendo "invadidas", seu aplicativo da web possivelmente é invadido.
Normalmente, em servidores web, o principal ponto de compromisso é não via SSH ou algo parecido, mas através do próprio aplicativo / servidor web. Significa que o seu site é baseado em um sistema CMS conhecido como o WordPress ou o Joomla! os hackers conseguiram entrar no seu sistema por meio desse aplicativo da web, que entrou no sistema em um nível mais profundo, o que equivale a ter acesso SSH, mas não acesso SSH profundo.
Ou seja, os servidores da Web executados em software como o Apache são gerenciados por um usuário não-root, como www-data ou algo parecido. Um compromisso do seu aplicativo da web significaria que um hacker tem o mesmo nível de acesso que o Apache, mas não algo muito profundo em um nível de "gravação" ... Mas ainda é um nível assustador de acesso em um nível de "leitura".
Portanto, é totalmente concebível que um aplicativo da Web em seu servidor tenha sido invadido, uma carga útil tenha sido descartada em seu servidor em um nível de usuário Apache e, de alguma forma, eles obtiveram o arquivo /etc/passwd por meio desse acesso comprometido. E agora eles estão tentando entrar por meio de nomes de usuários nesse arquivo /etc/passwd .
O que fazer se seu aplicativo da web tiver sido invadido.
Então você deveria estar com medo? Se esse cenário for o caso, sim. Mas Fail2ban não irá salvá-lo agora. Desativar root ainda pode salvar você em certa medida. Mas se o seu aplicativo da Web estiver comprometido, ele deve ser limpo. As tentativas de SSH são apenas “gravy” em cima de um servidor que já está infectado com alguma coisa.
Como proceder para limpar seu aplicativo da web? Não há uma resposta simples, mas se você estiver usando o WordPress, por exemplo, considere a possibilidade de reinstalar o WordPress e reinstalar as personalizações do site por meio de backups.
E sim ... Coisas assim é por que backups e gerenciamento de recuperação de código são um grande negócio. Mas ninguém aqui pode explicar como você deve abordar isso neste momento. É completamente outra questão e, com base no uso do cPanel, talvez seja necessária ajuda adicional de um técnico externo. Mas tenho que mencionar isso.