Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 10/02/2015, à 07:04

Kreuzi

XOR.DDoS

Bonjour,


http://www.lemondeinformatique.fr/actua … 60175.html

Encore un malware sous Linux! ça devient inquiétant.

Hors ligne

#2 Le 10/02/2015, à 08:40

bruno

Re : XOR.DDoS

Bonjour,

Absolument rien d'inquiétant.
Pour s'installer le logiciel malveillant doit d'abord obtenir un accès root sur un serveur SSH en tentant une attaque par force brute. Donc, sauf à avoir un serveur configuré en autorisant un accès root direct par mot de passe et avec un mot de passe faible, le risque est nul.
Ce type d'article n'a d'autre but que de faire de la publicité pour la société qui en est à l'origine.

Hors ligne

#3 Le 10/02/2015, à 08:54

jplemoine

Re : XOR.DDoS

Je suis d'accord avec le commentaire de l'article :

article a écrit :

"la connexion à distance devrait être désactivée pour démarrer des comptes"
Qu’est ce que cela signifie concrètement?


Membre de l'ALDIL (Association Lyonnaise pour le Développement de l'Informatique Libre)
- En pro, après 20 ans de développement, administrateur Linux / Unix depuis Avril 2019.
- En privé, sous Ubuntu-Xubuntu depuis 2009.

En ligne

#4 Le 10/02/2015, à 09:13

bruno

Re : XOR.DDoS

Cela ne veut strictement rien dire…
Voir la pub l'article de la boîte en question :

If possible, configure your SSH server to use encryption keys instead of passwords. We also recommend you disable remote logins for the root account. The XOR.DDoS malware requires root permissions, ….

En français :
Configurez, si possible, votre serveur SSH pour utiliser des clés plutôt que des mots de passe. Nous recommandons également de désactiver les connexions à distance pour le compte root. Le logiciel malveillant XOR.DDoS nécessite des privilèges root, …

Hors ligne

#5 Le 10/02/2015, à 09:21

jplemoine

Re : XOR.DDoS

bruno, là, je comprends aussi bien en anglais qu'en français (ta traduction est, je pense, fidèle).
Personnellement, j'utilise un double-accès avec un OTP. Le compe root est désactivé.
Il y a fail2ban qui, normalement, bloque les attaques "brut-force".
Est-ce bon ou pas ?


Membre de l'ALDIL (Association Lyonnaise pour le Développement de l'Informatique Libre)
- En pro, après 20 ans de développement, administrateur Linux / Unix depuis Avril 2019.
- En privé, sous Ubuntu-Xubuntu depuis 2009.

En ligne

#6 Le 10/02/2015, à 09:21

Compte anonymisé

Re : XOR.DDoS

Bonjour.

Les attaques Brutes Forces ne remontent pas à hier mais existent depuis très très longtemps, que ce soit sur Linux, Windows. Il y a bien longtemps que Fail2ban corrige ce type d'attaque. Par ailleurs, une authentification par clé SSH résoud également le problème.

C'est article est un torchon pour néophyte ou tout simplement un site qui aime le buzz.

Libc6.

#7 Le 10/02/2015, à 10:55

pires57

Re : XOR.DDoS

Un tissu d'âneries,  pour pas changer...


Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn

Hors ligne

#8 Le 10/02/2015, à 11:09

Kreuzi

Re : XOR.DDoS

« Comme une commande distante ne créé par de terminal session, les systèmes de connexion TTY ne retiennent pas non plus ces événements, pas plus que les dernières commandes de logs ».


Cela veut dire que dans le journal d'UFW rien n'apparait de particulier, donc fail2ban ne sert à rien dans ce cas.

Hors ligne

#9 Le 10/02/2015, à 11:15

pires57

Re : XOR.DDoS

Cela veut surtout  dire que l'idiot qui a écrit l'article n'y connais rien du tout! Toutes les connexion ssh sont listés dans le fichier de log qui vas bien et je ne voit pas ce qu UFW viens faire ici, il n'est pas activé par défaut.
Fail2ban analyse les logs et ban en fonction, pour toute attaque de type bruteforce il est efficace a partir du moment ou il a des logs sous la dent

Dernière modification par pires57 (Le 10/02/2015, à 11:18)


Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn

Hors ligne

#10 Le 10/02/2015, à 11:46

bruno

Re : XOR.DDoS

@Kreuzi, l'article est pour le moins confus…
Certes les commandes envoyées ne sont pas inscrites dans les fichiers journaux, mais ces commandes peuvent aboutir si et seulement si la connexion au compte root a été établie. Avant cela toutes les tentatives de connexion de l'attaque par force brute auront été inscrites dans les journaux et le cas échéant les IP bannies par fail2ban ou directement par une règle ipables.

Dernière modification par bruno (Le 10/02/2015, à 11:48)

Hors ligne

#11 Le 10/02/2015, à 11:46

Kreuzi

Re : XOR.DDoS

Journal d'UFW ou pas ce n'est pas le problème, si rien ne se voit dans les logs à quoi sert fail2ban dans ce cas ? Quelle protection efficace utiliser ?

Hors ligne

#12 Le 10/02/2015, à 12:13

Compte anonymisé

Re : XOR.DDoS

Quelle protection efficace utiliser ?

Authentification par clé pour SSH smile Et comme le dit bruno, ce sont les commandes qui ne sont plus enregistrées quand la machine est infectée, en revanche, une tentative d'authentification (avant que la machine soit infectée et c'est obligatoire pour essayer de la compromettre) est indubitablement inscrite dans les fichiers journaux du système, Fail2ban est très efficace dans ce cas.
Libc6

Dernière modification par Compte anonymisé (Le 10/02/2015, à 12:20)

#13 Le 10/02/2015, à 13:08

pires57

Re : XOR.DDoS

TOUT est listé dans les logs!! Fail2ban analyse les logs donc trouvera les tentatives de bruteforce.


Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn

Hors ligne

#14 Le 10/02/2015, à 22:07

tiramiseb

Re : XOR.DDoS

Salut,

Journal d'UFW ou pas ce n'est pas le problème, si rien ne se voit dans les logs à quoi sert fail2ban dans ce cas ?

Non, les (tentatives de) connexions sont toujours enregistrées, comme le dis pires57.
Ce qui n'est pas enregistré, ce sont les commandes exécutées à distance. Donc une fois qu'un pirate a eu accès au serveur, on ne se rendra pas compte qu'il a mis son malware en place.

Pour ma part, je fais une authentification directe en root, avec clé ssh, mot de passe désactivé. Et c'est parfaitement sécurisé. Pas besoin de passer par un utilisateur intermédiaire (ce qui limite d'ailleurs les fonctionnalités).

Hors ligne

#15 Le 11/02/2015, à 09:12

Kreuzi

Re : XOR.DDoS

Merci pour les réponses.

Hors ligne

#16 Le 17/06/2015, à 11:09

coquelourde

Re : XOR.DDoS

Bonjour,

J'ai été infecté par XOR.ddos et je n'ai rien pu faire. J'imagine donc que c'est un rootkit.

Ce virus est extrêmement évolué.

Voici toute mon histoire:
tout a commencé hier soir alors que je regardais un documentaire: "l'Algérie vu du ciel". A un moment, l'écran gèle. Mon serveur de laboratoire est branché sur un switch avec le décodeur TV orange. J'éteins le décodeur et je m'aperçois que mon CPL n'arrête pas de clignoter. Hors, aucun service réseau n'était lancé sur mon serveur. Je comprends qu'un 1, orange vient de pénalisé ma ligne et donc y a un gros problème.

Le lendemain, sur mon serveur: je fais un truc du style "tcpdump" et je vois que pleins de connexion sont ouvertes. Je comprends qu'il y a un virus. 

J'ai trouvé un fichiers intrus dans dans /etc/init.d
le virus créait des fichiers avec des noms aléatoires comme dfjdfkfs
J'avais déjà vu cela.... sur windows !!

en utilisant "fatrace" (apt-get install fatrace) on s'apercoit que le virus crée des fichiers à la volée avec des noms au hasard toutes les secondes et les efface.

Ensuite en utilisant "netstat -ptu" on voit qu'il établit un contact avec l'exterieur. Il utilise un faux nom de processus comme "etc", "netstat", "id"
Il envoie beaucoup de données mais ne recoit rien.

J'ai installé clamAV, qui m'a trouvé les fichiers du style dxkjxcjc dans /usr/bin (en plus de /etc/init.d). clamAv avait également trouvé un fichier lib infecté par XOR.DDoS: libudev.so  dans /lib. Là aussi j'ai effacé.
Biensûr j'ai tout effacé mais cela ne servaità rien puisqu'ils revenaient après un reboot. J'ai désinstallé tous mes derniers packages mais cela n'a rien changé. 

Il m'a aussi trouvé un virus sur mon fichier de boot .efi. Néanmoins, le nom du virus sur mon .efi était Win32 exe protect. je me demandais si ce n'était pas un faux positif.


En fait, il était encore possible qu'un script dans /etc/init.d ait été remplacé par quelques choses d'autres mais je n'avais plus de patience. c'était encore peut être un autre fichier qui aurait pu être modifié comme dbus.



Leçon de vie:
Je n'installerai plus de machins de répos non officielles sur mon serveur baremetal.

Dernière modification par coquelourde (Le 17/06/2015, à 11:28)

Hors ligne

#17 Le 17/06/2015, à 11:14

Ubuntu1988

Re : XOR.DDoS

Kreuzi a écrit :

Encore un malware sous Linux! ça devient inquiétant.

Trop ! C'est où qu'on signe pour se faire rembourser ? mad
Comme d'habitude, faut espérer que les personnes concernées savent ce qu'ils font et c'est pas gagné ... hmm


J'ai perdu ! :(

Hors ligne

#18 Le 17/06/2015, à 11:50

bruno

Re : XOR.DDoS

coquelourde a écrit :


Leçon de vie:
Je n'installerai plus de machins de répos non officielles sur mon serveur baremetal.

Seconde leçon :

Toute machine compromise doit être déconnectée du réseau et entièrement réinstallée.

Hors ligne

#19 Le 18/06/2015, à 11:51

pires57

Re : XOR.DDoS

Toute machine compromise doit être déconnectée du réseau et entièrement réinstallée.

Tu réinstalles a chaques fois que tu as une merde?
Pour ma part j'ai des backups de mes systèmes, j'ai donc simplement à faire un retour arrière mais uniquement dans le cas ou l'infection est trop avancé, c'est à dire pas systèmatiquement.


Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn

Hors ligne

#20 Le 18/06/2015, à 12:06

bruno

Re : XOR.DDoS

Lorsqu'une machine a été compromise, on ne peut pas savoir jusqu'à quel point elle l'a été. Donc oui c'est réinstallation systématique sur un serveur et éventuellement copie de la partition système pour une analyse post-mortem.
Personnellement je fais pas de sauvegarde du système, uniquement des données et de la configuration (/etc) et de l'état des paquets. Je considère qu'il est souvent plus rapide de réinstaller et de restaurer la configuration que de restaurer une sauvegarde de plusieurs Go. Et puis il faut être absolument sûr que la sauvegarde  correspond bien à un état où le système était sain à 100%.

Hors ligne

#21 Le 18/06/2015, à 12:21

tiramiseb

Re : XOR.DDoS

Je suis d'accord avec bruno smile

Hors ligne

#22 Le 18/06/2015, à 12:36

jplemoine

Re : XOR.DDoS

D'accord aussi.


Membre de l'ALDIL (Association Lyonnaise pour le Développement de l'Informatique Libre)
- En pro, après 20 ans de développement, administrateur Linux / Unix depuis Avril 2019.
- En privé, sous Ubuntu-Xubuntu depuis 2009.

En ligne

#23 Le 19/06/2015, à 09:32

pires57

Re : XOR.DDoS

Justement, le plus fun c'est de s'amuser dessus (faut bien trouvé de quoi occuper ses soirées big_smile)


Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn

Hors ligne