Bonjour,
Le système d’exploitation Linux Debian n’est plus à l’abri des logiciels malveillants :
Mais hélas Linux victime de Ransomware
Ransomware : une variante linux de KillDisk ne vous rendra jamais vos fichiers…
Source : http://www.solutions-numeriques.com/une-variante-linux-du-ransomware-killdisk-ne-vous-rendra-jamais-vos-fichiers/
Comment éviter ce type d’attaques ?
D’avance merci.
linux n’est pas une garantie absolue de sécurité, si la machine en question est configurée “windows like friendly” avec les droits root mal configurés ou les droits sudoers n’importe comment et des mots de passes à la con alors il ne faudra pas s’étonner d’avoir des ennuis.
Comment éviter ce type d’attaques ?
Utiliser ce qui est entre ses 2 oreilles, ne pas cliquer sur tous les liens aussi attractive que soit la promesse de rencontre…ne pas installer un logiciel de source inconnue sous prétexte d’avoir deux euros de réduction,etc
je plussoie.
surtout!!! 
Ne pas installer Linux ! 
Bon, ok, … je sors => [ ]
Bonne nuit …
Je passais par là, simple curiosité… je ne comptais pas répondre…
mais là :
LOL
Sinon, hors blague…
-> pas de compte root activé (ne jamais se connecter en SSH en root, ni sur le poste fixe sauf cas de maintenance exceptionnel)
-> pas d’installation de tout et n’importe nawak “à la windowsienne” j’installe, je test, je jette… et je continue à consommer…
-> si nécessaire : iptables, rkhunter…
Mais surtout, la 1ere des failles de sécurité, c’est l’utilisateur lui-même…
Bonne soirée 
C’est sûr que c’est facile pour les mises à jour du coup ;-).
Si ça vient des dépôts officiels, quel est le problème ?
Oui on ne se connecte pas en root, mais sous un compte ayant des droits sudo pour les màj
interdire les connexions en root empêche (entre autres : des brut force, un utilisateur qui, vouant bien faire, lance une commande néfaste…)
Perso c’est ce que j fais… je ne suis jamais en root sur mon serveur…
Aucun c’est l’exception qui confirme la règle
/!\ à condirtion que ce soit les dépots stables à la rigueur unstables mais pas de Sid…
Pour moi tes arguments sont plutôt en faveur du compte root :
root auquel on ne peut pas se connecter directement par SSH, et avec soit un mot de passe en béton, soit pas de mot de passe et une connexion par clé.sudo ça arrive tout le temps (si mal configuré), alors que l’utilisateur n’a rien à faire avec ton mot de passe root, donc il n’y a aucune chance de bavure.Pour moi (et c’est un avis personnel), rien ne vaut un compte root inaccessible directement en SSH. Les mauvaises configurations de sudo sont à l’origine de trop nombreuses mauvaises habitudes pour les utilisateurs.
Unstable = SID.
+1 
je voulais dire testing
Il n y a pas qu’une seule méthode mais plusieurs, avec nombres de particularités.
Sudo ça s’utilise avec parcimonie. le fait de faire + de 1 compte Sudo doit pousser l’admin à se poser la bonne question : Pourquoi est-ce que je veux faire du Sudo ? Si c’est pour faire 40 comptes Sudo (avec les droits en root, soyons d’accord 
) mieux vaut accepter l’évidence : le serveur est un bateau qui part à la dérive.
Avant que je n’interdise le root login en SSH j’avais un paquet de tentative d’intrusion de bots qui tentait de forcer l’accès avec le nom d’utilisateur le plus répandu dans les unix : root.
Autoriser par clé de chiffrement est une option qui ne mange pas de pains et qui devrait être utilisé par tous le monde. Cela prémunit du premier point que j’ai évoqué plus haut. Néanmoins, il m’est arrivé de devoir accéder à mon serveur à distance sans être sur une machine qui possédait les bonnes paires de clés 
L’un n’empêche pas l’autre…
Chacun ses méthodes, du moment qu’elles sont efficaces
bonne nuit