Pot de miel

Voyant depuis quelques années, dans les logs de mon serveur ftp, des tentatives malicieuses pour y accéder (des centaines de tentatives de mots de passe, avec des utilisateurs différents), je me suis dit que j’allais faire plaisir à ces petits piratins, pour voir ce qu’ils allaient faire, et donc faire un pot de miel.

Parce que la dernière fois que j’ai vu un serveur ftp se faire pirater, ledit serveur s’est fait remplir de musique, et c’est à cette occasion que j’ai découvert Dzihan et Kamien, tout de même.

Lire la suite « Pot de miel »

J’ai tor

Si vous avez essayé d’accéder à ce serveur (qui répond en fait à 4 noms DNS différents) entre hier soir 18h50 et ce matin (lundi, hein) vers 10h vous vous êtes sans doutes aperçu que c’était le joyeux rien intersidéral.

Pour cause : OVH, l’hébergeur, voyant plusieurs connexions ssh à 2 ip différentes dans un intervalle de temps assez court, en a conclu que c’était un scan de ports depuis ma machine (ce qui, en soit, est vrai), donc qu’elle était compromise (ce qui, en soit, est certainement faux), et a donc décidé unilatéralement de la scotcher jusqu’à ce que le problème soit résolu.

Outre le fait que ce serveur soit un Linux, et donc potentiellement moins cassable qu’un Windows, c’est moi qui le gère, donc potentiellement ce serveur est moins cassable qu’un Linux de base. Ceci dit je ne suis pas à l’abri d’un piratin malveillant, mais je me demande sérieusement comment quelqu’un aurait pu entre sur ce serveur et y faire des bêtises que je n’aurais pas vues.

Écartons cette hypothèse, car la plus probable est que ce scan ne soit pas le fait d’un intrus mais d’un petit rigolo qui le fait depuis TOR. Car oui, j’avoue, j’ai mis un relais TOR sur ce serveur. Mieux : je l’ai configuré pour qu’il soit port de sortie.

En appelant la hot line d’ovh ce matin, ils me l’ont rendu accessible ; j’ai donc désactivé TOR et fait 2 3 vérifs de base avant de remettre ce serveur en ligne (note pour plus tard : si quelqu’un sort de TOR en ssh, c’est qu’il a quelque chose à cacher)

Il semblerait donc que j’ai eu TOR …

Comment BusyBox vous sauvera la vie

Quand ceci commence à apparaître dans les logs :

C’est que les choses commencent à sérieusement tourner mal.

En général, d’ailleurs, les choses sont déjà très mal engagées : les commandes de base (ls, init, reboot, … ) ne fonctionnent plus, à part celles inclues dans le shell. Plus moyen de se logger à la machine, bien sûr, et bien sûr encore vous n’avez pas d’accès physique à la machine pour investiguer plus en profondeur, voir redémarrer.

Il se passe que votre disque est partie en vrille, est dans la choupignoufs, fait la gueule, bref : ça pue. Vous n’avez accès qu’aux systèmes de fichier montés en ram (/dev, /sys, /proc, et peut-être d’autres)

La bonne nouvelle est qu’on ordi planté à ce point ne peut pas l’être beaucoup plus. La mauvaise est que vous ne pouvez rien faire de là où vous êtes si vous n’avez pas prévu de parachute.

Le parachute, le voici.

Lire la suite « Comment BusyBox vous sauvera la vie »

tmpfs, cas d’usage

Intro

tmpfs est un système de fichier en RAM dispo sur pas mal d’*nix-like (OpenBSD, FreeBSD, GNU/Linux, Solaris, pour ceux que j’ai touché) (vu que sous *BSD ça s’appelle md mais j’ai la flemme, je dirai tout le temps tmpfs, na 🙂 ).

Vous allez me demander à quoi ça sert… Sachez que la RAM est 1 million de fois plus rapide qu’un disque dur : les accès sur la première sont de l’ordre de la nanoseconde, et sur les seconds de l’ordre de la dizaine de millisecondes. Ok : les mécanismes de cache du disque dur font que les accès sont bien plus rapide mais ils sont loin d’égaler ceux de la RAM.

So what ? Sans aller jusqu’à un rapport 1000, les accès aux fichiers dans un tmpfs sont 10 à 50x plus rapide, et son purement électronique : pas de mécanique à faire tourner. Vous voyez les bénéfices ?

Lire la suite « tmpfs, cas d’usage »