DDoS : les botnets Linux montent en puissance
Les botnets Linux ont très amplement pris part aux dernières attaques par déni de service distribué menées à travers la planète.
Pour le second trimestre 2016, l'éditeur de solutions de sécurité Kaspersky Lab a constaté - et détecté - qu'avec les attaques par déni de service distribué utilisant des réseaux de zombies, la proportion de DDoS impliquant des botnets Linux a grimpé à 70,2 %. Une progression significative par rapport aux trimestres précédents.
Au premier trimestre, la proportion était en effet de 44,5 % pour les botnets Linux et de 54,8 % au quatrième trimestre 2015. C'est la première fois qu'il existe un écart d'une si grande ampleur entre les botnets Linux et Windows pour les DDoS.
Les bots Linux semblent particulièrement appropriés pour mener des attaques dites SYN-DDoS qui exploitent des particularités dans l'implémentation du protocole TCP et consistent à envoyer une série de requêtes SYN vers une cible.
" Les serveurs Linux contiennent souvent des vulnérabilités communes mais pas de protection d'une solution de sécurité fiable ", commente (non innocemment) Oleg Kupreev de Kaspersky Lab. " Les attaques menées par des bots Linux sont simples mais efficaces. Elles peuvent durer des semaines, alors que le propriétaire du serveur n'a pas conscience d'être à l'origine d'une attaque. "
L'attaque DDoS la plus longue enregistrée au deuxième trimestre 2016 a duré 291 heures, soit près de 12,1 jours. Un trafic paralysant pour le moins insistant pour l'entreprise qui en a été victime.
-
![DDoS : le code source du botnet IoT Mirai libéré]()
Le code source du puissant botnet Mirai spécialisé dans les attaques par déni de service distribué s'appuyant sur des objets connectés a été mis à disposition en ligne. -
![XOR DDoS : un puissant botnet Linux]()
Ce n'est pas un botnet Windows mais Linux. XOR DDoS mène des attaques par déni de service distribué avec un trafic de données pouvant dépasser 150 Gbps.
Vos commentaires Page 1 / 2
Voilà qui devrait mettre fin à tous les speechs sur tel OS qui serait plus sécurisé qu'un autre, blablabla
Tous les OS ont des failles, et certains sont plus attaqués que d'autre parce que plus répandus (Windows, Android). dot.
Là le problème se situe plus au niveau de l'interface chaise-clavier, que ce soit du Windows Server ou du GNU/Linux, si pour le premier tu colles un RDP accessible de l'extérieur (ie, sur le Grand Ternet), ou pour le second du SSH en mode login/mot de passe, un jour ça se fera péter, c'est évident. Sans compter les autres services que tu fais tourner et qui peuvent potentiellement te donner un shell sur la machine (*SQL mal configuré, applicatifs pas à jour, etc etc etc), ou le matériel fermé livré avec ses failles genre NAS, routeurs, etc.
Ce genre de news ne m'étonne même pas quand on voit comment tout le monde s'en tamponne le coquillard de la sécurité informatique. Je le disais déjà il y a quelques années quand tout le monde disait qu'un botnet linux n'avait aucun intérêt… Entre du poste utilisateur derrière du *DSL tout pourri et du serveur avec un lien gigabit, le choix est vite fait. Et quand je vois le nombre de boîtes de "presta Web" qui installent, grosso modo, une Debian bare-metal, ne sécurisent pas l'accès SSH, collent un Wordpress qu'ils ne mettront jamais à jour, et qui ne feront jamais un apt update && apt upgrade, en gros en mode "fire and forget", ça ne me surprend même pas.
Kaspersky peut essayer de nous refourguer ses "solutions", mais que ce soit Linux, BSD, ou Windows Server, si tu te le fais pwn, et que tu as besoin d'une de leurs "solutions", c'est que le problème est bien en amont. Leur solution ne soignera que le symptôme (la vérole), pas la cause (l'incompétence de l'adminsys).
Ensuite je comprends surtout de l'article que les serveurs visés n'ont pas été entretenus correctement. Donc rien à voir avec GNU/Linux ou un autre OS...
Tout cela m'interroge donc sur le pourquoi d'un article si alarmiste. Est-ce que c'est parce que c'est toujours plus facile de taper sur le libre que sur microsoft ? Est-ce que c'est une manipulation qui tend à associer l'OS libre à un manque de sécurité (ce qui serait un comble quand on sait que GNU/Linux se passe d'antivirus depuis toujours) ? Est-ce qu'il fallait juste pondre un article bidon avant le weekend pour faire du chiffre ?
Non franchement, à la fin de l'article, je n'ai rien appris de neuf, et j'ai vraiment cette sensation étrange d'avoir perdu mon temps...
Grâce à ton retour je rajoute à ce que j'ai dit que les utilisateurs Linux, du fait du choix d'un OS moins simple à aborder et à configurer, sont davantage des spécialistes de la chose, et donc sont moins sujets aux attaques de ce genre
Des choses qui vont sans dire; mais qui vont mieux en le disant !
''Akamai avait aussi évoqué de son côté un intérêt des cybercriminels pour des systèmes Linux mal configurés ou non maintenus.''
http://www.generation-nt.com/ddos-botnet-linux-kaspersky-xor-actualite-1921447.html
Tu me voles les mots de la bouche !
Traduction : "Hé, les mecs, .... utilisez donc du Windows sur vos serveurs, car alors .... nous pourrons vous VENDRE des solutions de sécurisation !!!
Et les Pink Floyd chantaient :
Money, it's a gas
Grab that cash with both hands and make a stash
New car, caviar, four star daydream
Think I'll buy me a football team........
La triste rançon du succès en quelque sorte pour l’OS Open Source.
Comme le souligne frèztagada, le métier de Kasp Lab est de vendre ses solutions de sécurisation.....donc il est évident que l'analyse de Kaspersky n'est pas forcement très crédible.....
Tiens, pour une fois que je suis d'accord avec toi… à un détail près: idéalement, un routeur (ou un switch, ou un serveur), on va se connecter dessus en SSH, et là, il vaut mieux mettre en place une authentification par clefs asymétriques (RSA 4096 bits minimum) et désactiver l'authentification par login/mot de passe - idem pour tout serveur et même pour son desktop/laptop si un serveur ssh tourne dessus (systemctl status sshd ou service ssh status pour le vérifier, si non nécessaire, systemctl disable sshd ou update-rc.d -f sshd remove && service sshd stop pour désactiver tout ça au boot).
Après, reste le problème des interfaces Web de management accessibles depuis l'extérieur (idéalement là aussi on doit pouvoir le configurer pour qu'il écoute, par exemple, sur un vlan privé utilisant des IPs RFC1918 (non routables sur internet) accessible uniquement via un VPN avec authentification par certificats à minima (ou mieux: certificats+RADIUS+LDAP - ne jamais faire tourner le RADIUS sur la même machine que le LDAP! ))
Autre solution plus simple à mettre en place mais dépendant des choix du constructeur du matériel, faire écouter l'interface Web de management sur localhost uniquement, et utiliser un tunnel SSH, par ex (évidemment ça dépend du port côté routeur (ou commutateur, il y a plein de switches "à poil" sur Internet… )):
ssh -L 8080:127.0.0.1:8080 admin@mon.routeur.tld, et ensuite accéder à l'interface web de management depuis son poste de travail via http(s)://localhost:8080
Ça marche aussi très bien pour tous les services disposant d'une interface de gestion Web, par ex ElasticSearch, Couchbase, Riak, etc, et ça évite de l'exposer "à l'extérieur" (ie sur le Grand Ternet)
EDIT: et quand je pense que certains de nos gouvernants/députés/sénateurs veulent limiter le chiffrement… y'a vraiment des baffes qui se perdent.