YOU BOON TOO !

Visionner la consommation de mémoire en temps réel : 

watch -n 1 free -m

Libérer de la mémoire :

Tout d’abord il va nous falloir installer git (si ce n’est pas déjà fait), comme suit :

sudo apt-get update sudo apt-get install git

Ensuite nous allons télécharger le client let's encrypt qui va permettre la génération du certificat. Pour cela nous allons cloner le dépot git comme suit :

sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt

On utilise ci-dessus le répertoire "/opt" car celui ci sert généralement pour l'installation de logiciels tiers.

Maintenant attaquons nous à la génération du(des) certificat(s) :

cd /opt/letsencrypt ./letsencrypt-auto --apache -d mondomaine.com

Cela va donc exécuter le script côté let's encrypt pour générer le certificat que nous souhaitons obtenir pour le domaine "mondomaine.com". Si nous souhaitons obtenir différents certificats (notamment pour un sous domaine), il suffit de faire comme suit :

./letsencrypt-auto --apache -d mondomaine.com -d www.mondomaine.com

Une fois le(les) certificat(s) généré(s), celui(ceux)-ci se retrouve(nt) dans le répertoire "/etc/letsencrypt/live". Le script de let's encrypt génère automatiquement le vhost https (port 443 par défaut) dans le répertoire d'apache.

Lors de l’exécution de la commande il vous est demandé de renseigner une adresse email. Si vous ne souhaitez pas faire cela, il suffit de saisir la commande avec le paramètre "--register-unsafely-without-email".

Le certificat aura une durée de validité de 3 mois (cela pouvant changer dans un futur proche, lorsque let's encrypt ne sera plus en version bêta) et pourra être facilement renouveler.

Dans la configuration d’OpenVPN il est conseillé de mettre les deux lignes qui permettent d’avoir des logs comme suit :

La première ligne permet de spécifier le fichier de log utilisé pour suivre le statut de connexion des utilisateurs du vpn puis le second permet de tracer l'intégralité des échanges avec open vpn.

Logrotate fonctionne également sur des fichiers de configuration et nous pouvons spécifier un fichier par service, ce que je trouve vraiment pratique. Ces fichiers se trouvent dans le répertoire "/etc/logrotate.d".

Ayant configuré plusieurs fois logrotate pour OpenVPN mais n'ayant pas réussi du premier coup à trouver la configuration la plus adaptée, voici celle qui m'a permis d'arriver à un résultat plutôt convaincant :

/var/log/openvpn/openvpn.log { weekly rotate 52 missingok notifempty delaycompress compress copytruncate postrotate /etc/init.d/openvpn restart endscript }

Différents cas peuvent vous donner envie de révoquer un certificat ssl comme par exemple le vol de clé. La manipulation n’est pas très compliquée vous allez voir. Il suffit de vous rendre dans le répertoire d’open vpn en y accédent comme suit :

cd /etc/openvpn/easy-rsa/

Nous allons ensuite initiliaser les variables d'environnement comme suit :

. ./vars

Puis nous allons révoquer le certificat cible (dans notre exemple "certname" qu'il vous faudra remplacer par le nom du certificat à révoquer) comme suit :

./revoke-full certname

Cette dernière va générer un fichier nommé "crl.pem" dans le répertoire "keys/".  Également vous devriez voir s’afficher un message du genre “error 23 at 0 depth lookup:certificate revoked“, cela n’est nullement une erreur mais un message généré par le script qui indique que le certificat est bien révoqué (suite à un test très probablement).

Nous allons copier ce fichier à la racine du répertoire "/etc/openvpn/ via la commande suivante :

cp /etc/openvpn/easy-rsa/keys/crl.pem /etc/openvpn/crl.pem cp /etc/openvpn/easy-rsa/keys/crl.pem /etc/openvpn/jail/crl.pem

Nous rajoutons la lecture de ce fichier dans la configuration d'OpenVPN en modifiant le fichier normalement nommé " openvpn.conf" en y ajoutant la ligne "crl-verify crl.pem".

Et enfin nous allons relancer open vpn afin que la prise en compte des révoquations soient fonctionnelle. Si vous souhaitez maintenant supprimer la révocation, il suffit de se rendre dans le fichier /etc/openvpn/easy-rsa/keys.index.txt, de remplacer le (ou les) R qui se trouve dans le (ou les) certificat révoqué par un V. De supprimer la 3ème colonne qui constitue un timestamp (date de la révocation) puis de déclencher la commande suivante :

source ./vars openssl ca -gencrl -out "crl.pem" -config "$KEY_CONFIG"'

Et enfin de recopier, comme précédemment, le fichier crl.pem aux deux endroits cités plus haut.

Pour ceux qui ne connaissent pas Google Authenticator, en voici la définition sur wikipédia :

Google Authenticator est un logiciel open-source basé sur l’authentification en deux étapes, développé par Google. Le logiciel fournit un nombre de 6 chiffres que l'utilisateur doit donner lors de son authentification, en plus de son pseudo et de son mot de passe. Développé à l'origine pour les services Google (comme Gmail), le logiciel permet de s'authentifier sur des services tiers tels que LastPass ou Dropbox.

Pour faire simple, c'est un moyen de sécurité supplémentaire qui vient s'ajouter après l'authentification classique par mot de passe.

Le mécanisme est très simple. Une fois authentifié sur le service désiré, un code composé de chiffre vous est demandé. Ce code doit donc être généré par le biais d'un logiciel et a une durée de validité très courte. Afin d'en savoir plus je vous recommande chaudement de consulter l'article du centre d'aide mis à disposition par google sur le sujet.

Fini le monologue, entrons dans le vif du sujet à savoir la mise en place de ce système d'authentification en complément de notre connexion SSH habituelle.

1ère étape : l'installation de google authenticator.

Sur ubuntu pas de manipulation magique, on installe comme d'habitude via apt :

sudo apt-get install libpam-google-authenticator

Le fait d'installer google authenticator ne modifie en rien le système de connexion déjà en place, il faudra donc configurer soit même la connexion ssh pour que celle-ci utilise le mécanisme.

2ème étape : l'activation de google authenticator sur un compte.

Afin d'activer google authenticator sur un compte, il est nécessaire de générer un fichier communément appelé "secret key", et ce pour chaque utilisateur ayant un accès ssh. Sans ce fichier l'utilisateur ne pourra tout simplement pas se connecter à son accès ssh (bien qu'il existe un moyen simple d'outrepasser cela que nous évoquerons en fin de billet).

Voici donc la commande à saisir, une fois connecté sur le compte utilisateur (surtout pas root !!!!) :

google-authenticator

Une fois la commande saisie vous devriez être amener à répondre à un certains nombres de questions pour la configuration du mécanisme. Rien de bien "technique" et à vous de choisir ce que vous souhaitez, je ne vous conseillerai donc pas sur ce sujet. Soyez attentif, c'est tout :).

Une fois l'étape des questions terminée, vous retrouverez les différents éléments de configuration en ouvrant le fichier ".google_authenticator" qui se situe à la racine de la home de chaque utilisateur.

Il sera nécessaire d'ouvrir ce fichier avant déconnexion pour différentes raisons : tout d'abord celui-ci contient la clé secrète permettant de faire la liaison entre votre machine et le service google authenticator (première ligne du fichier) et de plus celui-ci contient 5 codes à usage unique dans le cas d'un échec de génération de clé via l'application. Je vous recommande chaudement de noter ses clés sur un bout de papier ou tout autre support de votre choix. Passons à l'étape suivante.

3ème étape : activation de google authenticator.

Nous allons, maintenant que google authenticator est configuré sur notre compte, activer le mécanisme pour fonctionner avec nos futures connexions SSH.

Pour cela rien de bien compliqué car il suffit d'ouvrir en édition le fichier "/etc/pam.d/sshd" et d'y ajouter (en fin de fichier par exemple) le bout de code suivant :

auth required pam_google_authenticator.so

Une fois la modification enregistrée nous allons toucher à la configuration du sshd en ouvrant en édition le fichier "/etc/ssh/sshd_config" dans lequel nous mettrons "yes" devant le paramètre "ChallengeResponseAuthentication"

ChallengeResponseAuthentication yes

A noter que si ce paramètre n'existe pas dans le fichier de configuration il suffit de le rajouter manuellement. Mais normalement celui-ci existe et doit être à "no" par défaut.

Il ne nous reste plus qu'à redémarrer le service ssh pour que les modifications apportées prennent effet :

sudo service ssh restart

Il ne reste plus qu'à tester. Pour cela il vous sera nécessaire de récupérer l'application mobile google authenticator compatible avec votre smartphone (google authenticator pour ios, blackberry et android... authenticator+ pour windows phone), de configurer à l'intérieur de celle-ci un compte relié à votre "secret key" (que l'on retrouve à la première ligne du fichier .google_authenticator à la racine du compte utilisateur). Le logiciel vous générera une clé à 6 chiffres qui sera valide pour une durée très courte et qui vous sera nécessaire après vous être authentifié sur votre compte ssh par mot de passe (comme vous le faites habituellement).

Comme je disais plus haut, il existe une petite astuce qui permet à un utilisateur n'ayant pas encore configuré sa clé google authenticator de passer outre ce mécanisme. Afin d'autoriser cela nous allons rouvrir le fichier "/etc/pam.d/sshd" précédemment modifié et en bout de ligne nous allons rajouter la notion "nullok" :

auth required pam_google_authenticator.so nullok

Cela permettra donc à l'utilisateur qui n'a pas encore sa clé google auth de passer outre.

La mise en place étant très simple, à l'édition de ce fichier vous pouvez rajouter ce qui suit :

DATE=`date "+%d.%m.%Y--%Hh%Mm"` IP=`echo $SSH_CONNECTION | awk '{print $1}'` REVERSE=`dig -x $IP +short` echo "Connexion de $USER sur $HOSTNAME IP: $IP ReverseDNS: $REVERSE Date: $DATE " | mail -s "Connexion de $USER sur $HOSTNAME" smtp.server.com

Comme vous pouvez le voir nous déclarons quelques variables (DATE, IP, REVERSE) que nous réutilisons dans l'email envoyé. Il ne vous reste plus qu'à remplacer "smtp.server.com" par votre serveur smtp, d'enregistrer le fichier et de relancer une session SSH pour tester.

Loin de moi l'idée de dresser ici le tableau des nouveautés (sachant que l'accent à été mis sur la sécurité) mais cette version est très intéressante pour un serveur car LTS (long term support). Cela implique un maintien jusqu'à 5 ans alors que la précédente version (13.10) n'avait que 9 mois de support. Enfin, pour ceux qui sont habitués aux distributions ubuntu cela ne change pas de d'habitude. Juste pour information la dernière version LTS connue avant la 14.04 était la 12.04 et la prochaine sera la 16.04 (tous les deux ans sauf si cela change dans les années à venir ?).

Pour en revenir à nos moutons, enfin à nos "tahr", voici la commande à saisir si vous souhaitez mettre à jour votre distribution actuelle :

do-release-upgrade

Rien de plus simple. S'ensuit le processus de migration vers Trusty Tahr avec quelques messages qui peuvent parfois faire peur (notamment lorsque l'on doit accepter ou non une nouvelle version d'un fichier de configuration que l'on a configuré au préalable) mais si vous avez un backup de vos configurations la peur n'est que de courte durée.

Pour ma part je suis passé sans aucun souci de la 13.10 à la 14.04. Je n'ai constaté aucune incompatibilité ou dysfonctionnement de services déjà présents.

Tout d'abord, l'installation :

sudo apt-get install clamav

Une fois installé il est nécessaire de mettre à jour la définition des virus :

sudo freshclam

Puis voici les différentes façon de l'executer.

Vérifier les fichiers du répertoire personnel :

sudo clamscan

Vérifier les fichiers et sous dossiers du répertoire personnel :

sudo clamscan -r /home/utilisateur

Balayer le disque entier :

sudo clamscan -r /

Et une commande très pratique qui consiste au balayage du disque dur en entier, en mettant le log dans un fichier ciblé et en esquivant les dossiers inutiles à scanner :

clamscan -r --bell --exclude-dir=/sys --exclude-dir=/dev --exclude-dir=/proc --quiet --log=/var/log/clamav/virus.log /

Sous ce joli saubriquet se cache tout simplement un programme de log de crash apparu depuis peu sur Ubuntu.

Autant il n'y a rien de mal à ce genre de programme, je dirai même "bien au contraire" car cela permet de faire un suivi de bug en cas de crash et cela en toute transparence.

Cela dit, personnellement je n'aime pas trop que l'on me force la main sur l'envoi de données "personnelles" même si cela doit aider une communauté à avancer pour le développement d'un logiciel. Prévenir au moment de l'installation (ou alors je suis passé à côté pour ma part ?) ne serait pas un luxe.

Du coup, comme je ne savais pas ce qu'était ce processus à la base, je me suis permis une petite désactivation. Voici comment s'y prendre.

Nous allons désactiver le processus qui est programmé pour un lancement automatique au démarrage. Pour cela il suffit d'ouvrir le fichier /etc/default/whoopsie avec votre éditeur de texte préféré (pour moi nano) :

nano /etc/default/whoopsie

Vous allez vous retrouver avec un fichier contenant à peu près ceci :

[General] report_crashes=true

Nous allons donc remplacer "true" par "false" :).

Et voilà, le tour est joué. Il suffira de "killer" le processus ou tout simplement de redémarrer sa machine. Whoopsie ne devrait plus se lancer automatiquement.

Il s'agit du même principe que Webmin mais avec une interface beaucoup plus conviviale et réactive. Ajenti permet donc l'administration système via une interface web au gout du jour. Celui-ci est grandement personnalisable (notamment la homepage grâce à un système de widget) et gère un nombre important d'extensions.

Il est possible de faire, par exemple, de la consultation de log (que j'adore tout particulièrement car le module rafraichi instantanément le contenu du log lorsque celui-ci est rempli), de créer des comptes utilisateurs, de créer des vhosts apache et j'en passe.

Son installation est très simple étant donné que des paquets ubuntu existent. Voici la marche à suivre.

Tout d'abord il est nécessaire d'ajouter la clé du repository en saisissant :

wget http://repo.ajenti.org/debian/key -O- | apt-key add -

Puis nous allons ajouter le repository à nos sources apt :

echo "deb http://repo.ajenti.org/ng/debian main main ubuntu" >> /etc/apt/sources.list

Pour ensuite installer les paquets :

apt-get update && apt-get install ajenti

Et enfin démarrer le service :

service ajenti restart

Une fois Ajenti démarré, il est possible d'y accéder via l'url de votre serveur sur le port 8000 (par défaut). Le couple identifiant / mot de passe par défaut est root / admin (à modifier très rapidement via la rubrique "configurer" du dashboard).

Et pour conclure, voici une petite capture de ce que ça donne :