Un journal peut-être pas mais je veux bien en discuter.
Le problème à résoudre?
À l'origine, ce qui m'intéressait était d'avoir des infos comme proftpd peut en fournir mais adapter aux transferts de fichiers par SSH. J'ai pensé greffer une verrue sur ssh mais finalement, j'ai opté pour une solution générique qui peut fonctionner avec d'autres programmes. Par exemple si tu écoutes une chanson avec VLC, tu auras une notification.
Comment sont récupérés les évenements? Il y a très longtemps, ça bouclait sur "lsof" pour lister les fichiers ouverts. Si un fichier était ouvert et fermé entre les 2 appels de boucle, l'information était perdue.
Aujourd'hui, c'est le kernel qui envoie les alertes à mon soft en user-space. Ce qui permet de gagner en réactivité. Les informations complémentaires sont extraites de /proc et du fichier lui-même. Les informations retournées par le kernel sont rudimentaires. Il faut se contruire les informations à la main. Ainsi, quand tu mets un dossier en surveillance, ce n'est pas fait récursivement. Donc tu dois aller lister les sous-dossiers pour les surveiller eux-aussi. Si un dossier est supprimé, tu as un event seulement pour ce dossier. La conséquence est que tu dois gérer ton arbre de dossiers et faire des parcours en profondeur quand un dossier est déplacé pour. De même quand tu as un événement sur un fichier, tu as seulement son nom. Si ce fichier est dupliqué à plusieurs endroits, comment savoir lequel a été ouvert et quel est son path complet? C'est ce que l'arbre permet de palier comme carence. Quant à /proc, ça me permet de savoir quel programme a ouvert le fichier et surtout, si le fichier est ouvert plusieurs fois par ce soft, de savoir qui a fermé qui (imaginez le même fichier transféré par SSH).
Comme le but de ce soft était de tourner sur un serveur, je voulais être avisé à distance lors d'évènement. La démarche de lire la base est manuel et les notifications locales insuffisantes (j'ai pas dbus sur mon serveur). J'ai donc mis en place la partie réseau en protégeant les communications en TLS. Pour protéger le soft lui-même d'attaque par la porte d'entrée réseau, j'ai splitté l'appli en 2 processus (fork) dans le processus réseau, je change d'identité pour baisser les privilèges et je le chroote. Ceci est dans l'hypothèse que l'appli avait besoin d'être lancée en root. La partie notification par mail est arrivée récemment. Ca me gavait de devoir lancer le client réseau développer alors que les mails conviennent bien à mon usage. En revanche, l'autre utilisateur de mon projet a codé une appli web autour de la base de données remplie par Repwatcher ainsi qu'un soft pour recevoir les notifications sur son smartphone. La partie "push" du réseau prend alors pas mal de sens. Grace au "last_known_offset", tu peux te coder une barre de progression et calculer la vitesse de transfert.
Que dire de plus? Les captures d'écran du terminal t'intéresse vraiment? :)
Autrement, ce qui m'intéresse dans le développement de ce programme est de m'amuser, mettre en pratique des compétences de sécu, toujours m'améliorer. Avoir des retours pour m'améliorer m'intéressent beaucoup.
Pour ce qui est des comparaisons, j'en ai pas vraiment à faire malheureusement. Quand j'ai démarré le développement, je n'avais pas trouvé de programmes qui remplissaient mon besoin et développer ce logiciel était aussi pour mon apprentissage de l'OCaml. Comme énoncé dans l'article, j'ai détesté ce langage à l'école et j'en riais en me disant que jamais je le mettrai dans mon CV.
[^] # Re: Auto-promo
Posté par dest . En réponse au journal Quelques projets intéressants en OCaml. Évalué à 5. Dernière modification le 01 mars 2013 à 12:23.
Un journal peut-être pas mais je veux bien en discuter.
Le problème à résoudre?
À l'origine, ce qui m'intéressait était d'avoir des infos comme proftpd peut en fournir mais adapter aux transferts de fichiers par SSH. J'ai pensé greffer une verrue sur ssh mais finalement, j'ai opté pour une solution générique qui peut fonctionner avec d'autres programmes. Par exemple si tu écoutes une chanson avec VLC, tu auras une notification.
Comment sont récupérés les évenements? Il y a très longtemps, ça bouclait sur "lsof" pour lister les fichiers ouverts. Si un fichier était ouvert et fermé entre les 2 appels de boucle, l'information était perdue.
Aujourd'hui, c'est le kernel qui envoie les alertes à mon soft en user-space. Ce qui permet de gagner en réactivité. Les informations complémentaires sont extraites de /proc et du fichier lui-même. Les informations retournées par le kernel sont rudimentaires. Il faut se contruire les informations à la main. Ainsi, quand tu mets un dossier en surveillance, ce n'est pas fait récursivement. Donc tu dois aller lister les sous-dossiers pour les surveiller eux-aussi. Si un dossier est supprimé, tu as un event seulement pour ce dossier. La conséquence est que tu dois gérer ton arbre de dossiers et faire des parcours en profondeur quand un dossier est déplacé pour. De même quand tu as un événement sur un fichier, tu as seulement son nom. Si ce fichier est dupliqué à plusieurs endroits, comment savoir lequel a été ouvert et quel est son path complet? C'est ce que l'arbre permet de palier comme carence. Quant à /proc, ça me permet de savoir quel programme a ouvert le fichier et surtout, si le fichier est ouvert plusieurs fois par ce soft, de savoir qui a fermé qui (imaginez le même fichier transféré par SSH).
Comme le but de ce soft était de tourner sur un serveur, je voulais être avisé à distance lors d'évènement. La démarche de lire la base est manuel et les notifications locales insuffisantes (j'ai pas dbus sur mon serveur). J'ai donc mis en place la partie réseau en protégeant les communications en TLS. Pour protéger le soft lui-même d'attaque par la porte d'entrée réseau, j'ai splitté l'appli en 2 processus (fork) dans le processus réseau, je change d'identité pour baisser les privilèges et je le chroote. Ceci est dans l'hypothèse que l'appli avait besoin d'être lancée en root. La partie notification par mail est arrivée récemment. Ca me gavait de devoir lancer le client réseau développer alors que les mails conviennent bien à mon usage. En revanche, l'autre utilisateur de mon projet a codé une appli web autour de la base de données remplie par Repwatcher ainsi qu'un soft pour recevoir les notifications sur son smartphone. La partie "push" du réseau prend alors pas mal de sens. Grace au "last_known_offset", tu peux te coder une barre de progression et calculer la vitesse de transfert.
Que dire de plus? Les captures d'écran du terminal t'intéresse vraiment? :)
Autrement, ce qui m'intéresse dans le développement de ce programme est de m'amuser, mettre en pratique des compétences de sécu, toujours m'améliorer. Avoir des retours pour m'améliorer m'intéressent beaucoup.
Pour ce qui est des comparaisons, j'en ai pas vraiment à faire malheureusement. Quand j'ai démarré le développement, je n'avais pas trouvé de programmes qui remplissaient mon besoin et développer ce logiciel était aussi pour mon apprentissage de l'OCaml. Comme énoncé dans l'article, j'ai détesté ce langage à l'école et j'en riais en me disant que jamais je le mettrai dans mon CV.