Les cybercriminels ciblent de plus en plus les serveurs Linux et l'infrastructure cloud (Linux étant le système d'exploitation le plus courant dans ces environnements) pour lancer leurs campagnes de ransomwares, de cryptojacking et autres activités illicites, relève ZDNet.
Plutôt que d'infecter un PC puis de naviguer vers une cible de plus grande valeur, les cybercriminels ont en effet réalisé que compromettre un seul serveur peut être très rentable, notamment dans les environnements virtualisés, permettant aux attaquants de chiffrer simultanément de vastes pans du réseau et de rendre la réponse aux incidents plus difficile.
Pour autant, les cyberattaques ciblant les environnements Linux sont encore relativement peu sophistiquées par rapport à celles ciblant les systèmes Windows. Cela signifie qu'avec une approche correcte de la surveillance et de la sécurisation des systèmes basés sur Linux, bon nombre de ces attaques peuvent être évitées.
« Le fait est que la plupart des adversaires ne sont pas très avancés », explique Brian Baskin, responsable de la recherche sur les menaces chez VMware. « Ils ne recherchent pas des exploits uniques, ils recherchent les vulnérabilités générales et les erreurs de configuration. Concentrez-vous sur celles-ci avant de commencer à vous concentrer sur les attaques zero-day et les nouvelles vulnérabilités ».
Commentaires (17)
#1
Un effet, je ne compte plus le nombre de tentatives de connexion ssh sur mon serveur avec mot de passe bidon genre admin.
#1.1
Le plus chiant, c’est que depuis 1-2 ans, les attaques bruteforce sur SSH sont un peu plus élaborées et les attaquants utilisent des botnets avec 1 IP différente par tentative… ça devient difficile à bloquer avec fail2ban par exemple.
#1.2
Fait juste une règle pour autoriser que ton IP en SSH (en changeant le port SSH par défaut), et tu deny tout le reste.
Après si tu veux y accéder de partout, c’est plus compliqué ^^
Perso, j’ai coupé SSH carrément, et je me connecte à la console KVM de l’hébergeur pour y accéder
#1.9
Effectivement, c’est au niveau pro avec un paquet d’utilisateurs éparpillés un peu partout. On va sous peu profiter d’un changement de matériel pour passer d’un système relativement permissif au niveau de la source de connexion à un système où seules des IP identifiables et enregistrées pourront se connecter, ça va gronder chez certains utilisateurs mais ils ont des alternatives (VPN ou portail web).
Merci, je ne connaissais pas, ça pourrait m’être utile dans le cadre perso.
#1.7
Si tu ne connais pas, jette un œil au port knocking. Faut pas voir ça comme un atout en sécurité (Security by obscurity), par contre ça permet de réduire la taille des logs…
#1.3
Tu peux interdire l’accès par mot de passe et ne laisser que par clé (en interdisant dans tous les cas le root) ou tu peux aussi mettre du 2FA sur le SSH, voir coupler les deux !
https://www.vultr.com/docs/how-to-use-twofactor-authentication-with-ubuntu-20-04/
Personnellement, SSH n’est pas accessible de l’extérieur. Je passe par Cockpit qui lui a le 2FA d’activé.
#1.4
On peut directement configurer Cockpit avec du 2FA ? De mémoire, ça ne me parle pas, mais ça m’intéresse :)
#1.5
Même méthode que pour SSH : https://community.nethserver.org/t/2fa-or-two-factor-authentication-with-cockpit/14172
#1.6
ah oui ok merci :)
#1.11
Effectivement cela fonctionne bien, je viens de tester, merci :)
#1.8
Essaie de filtrer en liste blanche sur des plages d’adresses IP source depuis lesquelles les administrateurs sont les plus susceptibles de se connecter, par exemple celles de FAI de pays dans lequel tu te situes.
Ça évitera la majorité des tentatives.
J’appuie, et je précise, qu’aujourd’hui, l’analyse de l’ensemble des adresses IPv4 est réalisable en quelques heures.
Sur la durée, l’ensemble des ports qui répondent peuvent être essayé, et la prise d’empreinte permet de détecter le protocole parlé, notamment pour SSH.
L’obfuscation du port ne sert donc pas à grand chose, mais limite simplement la surface d’attaque face aux vers qui tentent la force brute sur TCP/22… Ce n’est généralement pas d’eux que vient le problème.
#1.10
Le port knocking c’est pas changer le port SSH sur un autre port, non c’est une méthode qui permet d’autoriser une adresse IP a se connecter au port SSH en faisant des tentatives de connexion sur différents ports dans un ordre précis, c’est un peu un “Port de passe”, exemple: port 52510, puis port 29345, puis port 13334, puis port 7664, ensuite le firewall du serveur autorisa ton IP sur le port SSH.
Avec cette méthode tu peux avoir la totalité des ports de fermés aux yeux du monde.
#2
J’ai aussi dans les logs du syno de ma boite pleins de tentatives de connexions.
C’est un peu stressant, surtout que c’est toujours en pleine nuit.
#3
Changement du port SSH + ban de toute IP qui se connecte sur le 22.
#4
En plus de ce qui a été cité par @gg40 et @Edtech, je rajoute ses 3 lignes :
KexAlgorithms [email protected]
Ciphers [email protected],[email protected]
MACs [email protected],[email protected],hmac-sha2-512,hmac-sha2-256
J’observe que ceci ne réduit pas forcément les tentatives de connexions, mais elles avortent avant même d’avoir testé le mot de passe ou la clé.
#5
Ranafout. J’utilise Telnet.
#6
Merci pour ce tips, ça a l’air à explorer.
Par contre, pas de port 22 sur ssh et accès uniquement par clé par un hôte sur un réseau spécifique (autre que CIDR 24, ou une IP en particulier si accès externe).
Ça marche bien le tunneling ? Il paraît que ça ressemble à une sorte de VPN mais j’ai eu la flemme d’essayer..