J’aime bien avoir des remontées de logs par mail de mes machines. Ca fait très camp militaire le passage en revue des machines le matin. Les informations que je souhaite avoir sont les suivantes :
Mises à jour du système de base ?
Mises à jour des ports ?
Vulnérabilités connues sur mon système ?
Digest des logs (via logwatch)
Pour ce faire, il faut déjà installer plusieurs paquets :
# cd /usr/ports/ports-mgmt/portupgrade
# make clean install clean
# portinstall portaudit
# portinstall logwatch
Commençons par mettre à jour le système de base. On va utiliser la commande freebsd-update vu que l’on est sur du i386. Pour télécharger les mises à jour :
Pour lancer la mise à jour on utilisera la commande install à la place du fetch.
Pour les mises à jour de ports, il nous faut déjà un arbre des ports à jour. Ajoutez la ligne suivante à la crontab :
0 3 * * * root /usr/sbin/portsnap -I cron update
Explications : cette commande portsnap va aller chercher une archive contenant la version à jour de l’arbre des ports (option “cron”). Ensuite juste le fichier /usr/ports/INDEX va être mis à jour (-I en combinaison avec update). Je ne souhaite pas mettre à jour violament l’arbre des ports au cas ou je sois en train de lancer une compilation dans celui ci alors qu’il est mis à jour de manière automatisée par le job de la crontab.
Ensuite pour vérifier que les ports sont à jour :
Cette commande s’appuie sur le fichier INDEX pour savoir si un port installé est obsolète ou pas. Pour mettre le port à jour :
# portupgrade <nom_du_port>
Ou pour une mise à jour de tous les ports du système :
En parlant des ports, on peut aussi vérifier qu’aucun port installé n’est vulnérable à une attaque connue :
Cette commande télécharge la dernière version de la base de vulnérabilités et regarde si les ports installés sont exposés.
Enfin, pour afficher un rapport de logs :
# logwatch.pl --detail 10 --print
Enfin on peut créer le script suivant :
#!/usr/local/bin/bash
umask 0077
LOGFILE="/var/log/$HOSTNAME-daily-report.log"
touch $LOGFILE
RET=$?
if [ $RET -ne 0 ]; then
exit 100;
fi
echo "###################### Security Issues ###################" > $LOGFILE
/usr/local/sbin/portaudit -Fad 2>>$LOGFILE 1>&2
echo "" >> $LOGFILE
echo "###################### Updating Status ###################" >> $LOGFILE
echo "-- Base system --" >> $LOGFILE
/usr/sbin/freebsd-update fetch 2>>$LOGFILE 1>&2
echo "" >> $LOGFILE
echo "-- Ports --" >> $LOGFILE
/usr/local/sbin/portversion -l '<' 2>>$LOGFILE 1>&2
/usr/local/sbin/logwatch.pl --detail 10 --print 2>>$LOGFILE 1>&2
/usr/bin/mail -s "[STATCRON] $HOSTNAME reporting !" admin@admin.fr < $LOGFILE
/bin/rm $LOGFILE
exit 0Téléchargeable ici.
Pour une fois un post qui ne contiendras aucun des mots suivants : OpenBSD, FreeBSD, Linux etc … J’ai décidé de parler d’un petit manga bien sympa acheté sur un coup de tête au Bazar du Bizarre d’Orléans. Sans être LE manga de la décade c’est assez léger, rigolo et original. L’histoire repose sur l’opposition entre une “executive woman” et un gros geek responsable d’un studio de création de jeux vidéos au bord de la faillite. Le dessin est correct et les personnages secondaires sont assez attachants. A priori, il ne devrait y avoir que deux tomes. Le second doit paraitre dans quelques semaines.
Aujourd’hui j’ai du installer un serveur subversion. J’utilise l’accès svn+ssh seulement et un serveur LDAP. Le problème s’est posé pour gérer les invités : des gens qui collaborent aux projets gérés par subversion mais pour qui il n’est pas forcément souhaitable de créer un compte LDAP. Enfin, je veux qu’a la première connexion l’utilisateur soit obligé de changer son mot de passe.
J’ai géré le problème de la manière suivante :
1 – Pour chaque invité je crée un utilisateur qui a comme groupe primaire “svn_queue” et qui appartient à un ou plusieurs groupes liés aux projets sous subversion. Le groupe svn_queue contient les utilisateurs en attente de changement de mot de passe. Ces utilisateurs ont un shell particulier :
svn# less /usr/local/bin/wrapper_passwd.sh
#!/bin/sh
/usr/bin/passwd
ret_pw=$?
if [ $ret_pw -eq 0 ]
then
/usr/local/bin/sudo /usr/sbin/pw usermod $USER -g svn_enable -s /bin/sh
exit 0
else
exit 1
fiCréation de l’utilisateur :
pw useradd -n svntest -g svn_queue -d /nonexistent -s /usr/local/bin/wrapper_passwd.sh
2 – Ce script à ajouter dans le /etc/shells force l’utilisateur à changer de mot de passe à la première connexion. Pourquoi ne pas le forcer avec de l’accounting ? En fait j’ai aussi besoin qu’a la connection SSH initiale, le GID primaire de l’utilisateur change pour le passer dans le group svn_enable. Ce groupe est utilisé par mon serveur SSH pour forcer l’execution de svnserve à la connexion des membres du groupe.
svn# tail -n 2 /usr/local/etc/ssh/sshd_config
Match group svn_enable
ForceCommand /usr/local/bin/svnserve -t -r /usr/local/repositories
Ca, c’est une question que je me suis posé un paquet de fois. La réponse est venue lorsque j’ai essayé de réformer les droits sur les répértoires utilisateurs. J’avais un objectif pas trop ambitieux : les autres utilisateurs devaient être incapables de zieuter le contenu de votre répértoire utilisateur.
Victoire de courte durée car le umask était bien trop restrictif. La raison est que chaque utilisateur est crée dans un groupe primaire “toto”. Donc pour assurer la confidentialité (à supposer que l’on puisse assurer une quelconque forme de confidentialité à des homes exportées en NFSv3 …) des données, il faut les passer en 0700. Jusque la tout va bien. Pour que le changement perdure, je place un umask à 0077 pour mes utilisateurs Unix / Linux et je fixe les droits par défaut des partages samba pour les windowsiens. La encore, impeccable.
Le problème est survenu lorsqu’un utilisateur (encore eux !) a essayé de mettre à jour sa page perso. Le nouveau fichier HTML qu’il a crée était en 0700, or le propriétaire du répértoire de pages personnels n’est pas apache mais l’utilisateur lui même. Apache n’avait pas les droits pour lire la page. Du coup, sanction 403 forbidden dans les dents.
La c’est dommage car si pour l’utilisateur titi, on avait un groupe primaire titi avec juste titi dedans alors on aurait pu avoir des droits en 0750 avec un umask à 0027. Voila la raison d’être du groupe utilisateur crée uniquement pour l’utilisateur.
Pour les petits curieux, j’ai trouvé l’explication ici sur une documentation Redat. Cette documentation évoque la gestion des utilisateurs sur un système Redhat et surtout le schéma UPG (User Private Group) qui consiste à associer à chaque utilisateur un group privé.