Discussion :

[titux]

Hello,

Entre cet été et fin janvier j'ai eu pas mal de soucis niveau sécu. Je fonctionne toujours avec 2 partition : / et /home.
Bêtement à chaque résintallation je réutilisais mes disques et partitions de données douteux, avec Wireshark j'ai noté que de multiples threads akonadi démarrés transmettaient en crypté sur le net alors que je n'avais rien configuré. En déconnectant le cable eth, quand je stoppais akonadi un truc prenait le relais avec rpc bind, à verifier toutes les heures si la connexion réseau était rétablie, et à certains moment quelque chose déclenchait une copie de ma partition de données dans un sous dossier de /var jusqu'au remplissage de la partition /, du coup machine bloquée, aucune commande possible et impossible de charger Kde par manque d'espace disque.

Fin janvier, j'ai fait une install à partir d'un dvd debian du commerce et sans réinsérer les volumes douteux, ça parait du coup mieux même si je n'en suis pas totalement certain. En tous cas rkhunter, chkrootkit, fprot, clamav, mis à jour juste avant examen ne trouvent rien. Le démarrage d'akonadi est inhibé dans son fichier akonadiserverrc et rpc bind est désintallé.

Maintenant j'aimerais pouvoir accéder à mon disque 2To ext4 où j'ai toutes mes données mais il est très probablement vérolé je ne sais où.
Je cherche donc un moyen de le monter, isoler et dégager le virus. Cependant je ne suis pas un crack en fonctionnement de Debian. Juste quelques notions du fonctionnement.
J'ai commencé par réfléchir un peu à l'endroit qui peut être vérolé : les fichiers cachés dans la partition /home ? les descripteurs qui seront exécutés au montage ext4 ?
En utilisant un OS type RiscOS s'il gère le ext4, pourrait-il bugger sur le déclenchement du virus qui j'imagine est codé pour linux et pas RiscOS excepté en cas de code portable (java, python...) ?

pour info, l'autre jour en cherchant à effacer une clé usb douteuse avec un liveCD de Tail 1.6 et le SSD débranché, mon pc a booté sur la clé pas encore effacée, je suis tombé sur un écran que je n'ai jamais eu en 15 ans d'info :
en mode texte visiblement, chaque "case" de l'écran avait une couleur de fond différente avec un caractère aléatoire d'une autre couleur, je n'ai pas pensé à faire de photo
je tenterais la manip avec d'autres clés douteuses voir...

Si quelqu'un a une piste de solution, formatage du 2To exclue, je suis preneur.
Merci

[BufferBob]

salut,

j'ai noté que de multiples threads akonadi démarrés transmettaient en crypté sur le net

c'est comme ça qu'akonadi fonctionne :
"Akonadi est un logiciel de gestion d'informations personnelles - rendez-vous, carnet d'adresses, numéros de téléphones, etc. (...) Akonadi communique avec des serveurs afin d'envoyer et recevoir des données en lieu et place des applications, au moyen d'une API spécialisée."
...ou alors c'est un gros méchant virus de la mort qui tue la vie

En déconnectant le cable eth, quand je stoppais akonadi un truc prenait le relais avec rpc bind, à verifier toutes les heures si la connexion réseau était rétablie

et si c'était le système d'exploitation ? ou l'une des applications légitime ?
...ou alors c'est un gros méchant virus de la mort qui tue la vie

à certains moment quelque chose déclenchait une copie de ma partition de données dans un sous dossier de /var jusqu'au remplissage de la partition /, du coup machine bloquée, aucune commande possible et impossible de charger Kde par manque d'espace disque.

c'est emmerdant comme symptôme en effet, quand ça arrive tu boot sur un live-cd, tu mount ta partition / et tu vas inspecter ce qui remplit le /var/, à coups de find et/ou de du par exemple, mais manifestement tu ne l'as pas fait, du coup comment tu sais que quelque chose copiait ta partition de données ?

si il y a vraiment un virus ou un rootkit, c'est en fait très simple, soit il est de type "userland" et l'inspection à coups de ps et/ou le scan via des HIDS comme AIDE ou Tripwire vont vite le mettre en évidence, soit il a un pied en root et/ou dans le noyau et là tu peux considérer ton système comme foutu, une simple réinstallation suffit alors à le faire disparaitre (par pitié ne viens pas parler de malwares persistants en RAM ou indécrottables dans le firmware du disque dur...) la seule chose à laquelle il faut évidemment faire attention si tu récupères ton /home, ce sont les scripts utilisateurs qui se lancent à l'ouverture/fermeture d'une session, les .bash_profile, .bashrc et autres .kde/Autostart, ici encore un coup de find sur les fichiers les plus récemment modifiés pourra s'avérer utile

[titux]

Salut BufferBob et merci

Je veux bien que ce soit le fonctionnement normal d'akonadi et rpc bind et que n'étant pas très calé, dans le contexte, avoir pris ça pour un truc louche.

Pour le coup du dossier /var rempli c'est bien arrivé une 10aine de fois au total entre aout et décembre sur plusieurs de mes machines après la compromission de mon serveur maison en aout.
Je ne me souviens plus du moyen utilisé la dernière fois (soit un liveCD soit une install sur un autre DD) mais j'ai clairement reconnu le contenu de mon dossier /home dans un sous-dossier /var/.../ossec

Merci pour ton aide, me reste à examiner tout ça avec un liveCD et l'un des HIDS que tu mentionnes

[BufferBob]

Je ne me souviens plus du moyen utilisé la dernière fois (soit un liveCD soit une install sur un autre DD) mais j'ai clairement reconnu le contenu de mon dossier /home dans un sous-dossier /var/.../ossec

OSSEC c'est censé être un IDS, et normalement c'est toi qui l'as installé explicitement (dpkg -l | grep ossec), si c'est le cas c'est peut-être un problème de configuration ou alors tu auras pris pour un dump de ton /home quelque chose qui ne prenait pas tant de place que ça et le remplissage était ailleurs

dans tous les cas il n'y a pas de mystère, savoir utiliser les commandes Linux permet d'avoir un contrôle très fin sur le système et de vérifier quasiment tout ce qu'on souhaite, qu'il s'agisse de faire un petit script de monitoring pour voir quel processus bouffe toute la mémoire au bout de X semaines, trouver quel répertoire prend le plus de place sur la partition, vérifier qu'un processus vu par ps est bien ce qu'il prétend être et n'a pas modifié son argv[0] ou trouver des backdoors éventuelles, tout est faisable "assez simplement" et fait partie des taches courantes de l'admin

[titux]

J'ai bien installé OSSEC volontairement et envisagé l'erreur de config d'OSSEC, j'avais posé la question sur leur liste en posant le lien du tuto suivi, pour eux c'était exclu.

Je me souviens d'une fois où ce remplissage est arrivé, à 17h32 j'annonce sur irc partir faire mes courses, en rentrant un peu plus d'1h après, debian bloquée, et au reboot kde ne charge pas.
c'est là que j'ai examiné le truc, le 1er fichier copié l'avait été à 17h36 ou 38. J'ai fait une iso avec dd de chacune des 2 partitions que j'ai stocké, je vais re-vérifier, mais pour moi c'était bien une copie de mon /home, j'avais tracé avec du -h et étais tombé dessus.

C'est certain que je dois m'améliorer encore côté admin

[BufferBob]

donc si on résume, le comportement d'akonadi te faisait penser qu'il y avait une infection, mais finalement ça n'est possiblement pas ça ou dans le meilleur/pire des cas (selon comment on perçoit la chose ^^') ça reste à prouver de manière formelle par de l'analyse et de la traque efficace

depuis tu as fais une réinstallation du système, et donc ta question se résume finalement à comment monter ta partition "de manière safe"
monter une partition c'est safe en soi, après ça dépend de toi on va dire, soit t'es un peu plus détendu vis à vis de tes craintes précédentes et tu fais confiance à ta partition, tu la remonte en l'état, soit tu fais pas confiance et auquel cas c'est pas d'une armée de programmes comme fprot ou rkhunter dont t'as besoin mais de connaissances Linux et sécurité, monter la partition ailleurs (dans /mnt/toto par exemple) et aller investiguer autant que possible les fichiers, et au minimum s'assurer de l'intégrité de tes données/documents, les backuper en laissant derrière les fichiers du homedir générés par le système, et réinjecter dans une installation fraiche

il y a là dedans une question d'attitude, c'est comme sur la route, on évite de freiner d'un coup sec en tournant le volant, on essaye de conserver la maîtrise de ce qu'on fait et de réagir avec sang-froid

dans le cas d'une infection c'est pareil, lorsque tu te rends compte que tu es infecté rien ne te dit avec certitude (sauf à le prouver justement) que ça vient juste d'arriver, peut-être que la vérole est là depuis des lustres et fait sortir tes données depuis plusieurs mois, donc ça ne sert à rien de paniquer, ni de se laisser aller aux fantasmes, si on a un soupçon il faut faire le maximum pour en avoir le coeur net

par exemple concernant ton problème de remplissage de disque, si ça m'arrivait je pense que :

• je garderais précieusement la partition bloquée/remplie pour l'examiner, quitte à prendre un autre disque et faire une réinstallation en attendant
• si je ne l'ai pas fait, je commencerai par vérifier la taille de ma partition remplie, elle doit être suffisamment grande, plusieurs Go si elle inclut /usr par exemple, et si ma machine a tendance à générer beaucoup de logs, je m'assurerai que les politiques de logrotate effectuent des rotations suffisament souvent pour éviter d'engorger la partition, ce genre de choses
• au delà, je me ferais probablement une sonde perso, qui m'envoie par mail (par exemple, mais on peut envisager de logguer dans un fichier qu'on récupèrera sur incident, pour peu qu'il ne se remplisse pas trop vite et contribue au problème ) toutes les minutes le remplissage de la partition (df), les processus qui s'exécutent (ps, /proc), et les fichiers ouverts par chacun d'eux (lsof, fuse), si le problème survient je suis prêt et j'ai de quoi traquer un peu plus efficacement son origine
• et si ça ne suffit pas rebelote, la prochaine fois j'affinerai encore ma sonde pour cibler de manière plus précise, jusqu'à identification formelle