Configurer un client NFS sous CentOS 7

NFSDans notre précédent article, nous avons décrit la mise en place d’un serveur NFS comme première brique logicielle dans la configuration d’un réseau local avec des profils itinérants et une authentification centralisée. Passons maintenant à la deuxième brique, le montage des partages NFS sur les postes clients.

Prérequis

Le serveur et les postes clients doivent impérativement être synchronisés via NTP, faute de quoi on peut s’attendre à toute une série de dysfonctionnements bizarres.

# ntpq -p
  remote            refid st t when poll reach delay offset jitter
===================================================================
*amandine.microl 95.81.173.155 3 u 24 64 377 0.134 -86.943 144.533
 LOCAL(0)        .LOCL.       10 l 31 64 377 0.000 0.000 0.000

Même si ce n’est pas strictement nécessaire, c’est une bonne idée de démarrer les clients en mode console par défaut, le temps de tout mettre en place.

# systemctl set-default multi-user.target

Installation

Installer la panoplie d’outils NFS et leurs dépendances.

# yum install nfs-utils

Si l’on a désactivé l’IPv6 sur le serveur, il faut impérativement reconstruire le disque mémoire initial, sous peine de se retrouver avec un service RPC (Remote Procedure Call) qui refuse obstinément de démarrer.

# dracut -f -v

Pour plus de détails, consulter les explications sur cette page.

Configuration

Renseigner le domaine local dans /etc/idmapd.conf :

[General]
#Verbosity = 0
# The following should be set to the local NFSv4 domain name
# The default is the host's DNS domain name.
Domain = microlinux.lan

Gestion

Activer et démarrer le service RPC.

# systemctl enable rpcbind
# systemctl start rpcbind

Montage manuel des partages NFS

Vérifier si les points de montage /home et /data sont bien vides.

# ls /home
# ls /data

Monter les partages NFS à la main.

# mount -t nfs4 amandine.microlinux.lan:/home /home
# mount -t nfs4 amandine.microlinux.lan:/data /data
  • L’option -t nfs4 n’est pas strictement nécessaire. La commande mount comprendra qu’il s’agit d’un partage NFS.
  • Le nom d’hôte du serveur (amandine) peut très bien être invoqué sans le nom de domaine (microlinux.lan).

La syntaxe suivante est donc parfaitement valable.

# mount amandine:/home /home
# mount amandine:/data /data

Montage persistant des partages NFS

Vérifier le contenu de /home et de /data. Une fois que tout semble correct, on peut rendre le partage persistant en l’inscrivant dans /etc/fstab comme ceci.

amandine.microlinux.lan:/home /home nfs defaults,_netdev 0 0
amandine.microlinux.lan:/data /data nfs defaults,_netdev 0 0
  • L’option _netdev indique au système qu’il s’agit d’un disque réseau et qu’il doit au moins attendre d’être connecté pour le monter.
Publié dans CentOS, Documentation Microlinux | Marqué avec , | Laisser un commentaire

Installer un serveur NFS sous CentOS 7

NFSNFS (Network File System) est le système de fichiers en réseau “classique” des plateformes Unix, avec un fonctionnement client-serveur. Le serveur met à disposition des ressources pour les clients du réseau ou une partie du réseau. Les fichiers distants sont montés dans un répertoire et apparaissent comme un système de fichiers local. À partir de là, les utilisateurs clients accèdent en toute transparence aux fichiers partagés par le serveur, en parcourant les répertoires comme s’il s’agissait d’une arborescence locale.

Dans cet article, nous allons décrire la mise en place d’un serveur NFS sous CentOS 7. Le but ultime de cette opération sera la création de profils itinérants avec une authentification centralisée dans le réseau local. Notre serveur NFS constituera la première brique logicielle d’une telle configuration.

Prérequis

NFSv4 utilise le port 2049 en TCP. Il faut donc songer à ouvrir ce port dans le pare-feu.

Installation

Installer la panoplie d’outils NFS et leurs dépendances.

# yum install nfs-utils

Si l’on a désactivé l’IPv6 sur le serveur, il faut impérativement reconstruire le disque mémoire initial, sous peine de se retrouver avec un service RPC (Remote Procedure Call) qui refuse obstinément de démarrer.

# dracut -f -v

Pour plus de détails, consulter les explications sur cette page.

Configuration

Renseigner le domaine local dans /etc/idmapd.conf.

[General]
#Verbosity = 0
# The following should be set to the local NFSv4 domain name
# The default is the host's DNS domain name.
Domain = microlinux.lan

Voici les répertoires utilisateurs que je souhaite partager en lecture et en écriture.

# tree -d -L 1 /home/
/home/
|-- adebuf
|-- fbanester
|-- fteyssier
|-- jmortreux
`-- kikinovak

Par ailleurs, je dispose également d’une arborescence /data que je souhaite partager en lecture seule.

# tree -d -L 1 /data/
/data/
|-- audio
|-- iso
`-- video

Nous allons définir ces partages dans le fichier /etc/exports.

# /etc/exports
/data  192.168.2.0/24(ro,async,no_subtree_check) \
         *.microlinux.lan(ro,async,no_subtree_check)
/home  192.168.2.0/24(rw,async,no_subtree_check) \
         *.microlinux.lan(rw,async,no_subtree_check)
  • L’option ro monte le répertoire distant en lecture seule.
  • L’option rw monte le répertoire distant en lecture/écriture.
  • L’option async permet des écriture asynchrones, c’est-à-dire que le serveur n’attend pas l’écriture d’une requête précédente avant de répondre.
  • Sans trop rentrer dans les détails, l’option no_subtree_check neutralise la vérification des sous-répertoires, ce qui a de subtiles implications au niveau de la sécurité, mais peut améliorer la fiabilité dans certains cas.
  • La barre oblique inversée \ permet d’éviter les lignes à rallonge.
  • Attention à ne pas mettre d’espace entre la définition du réseau 192.168.2.0/24 et les options (rw,async).

Gestion

Activer et démarrer les services RPC et NFS.

# systemctl enable rpcbind
# systemctl enable nfs-server
# systemctl start rpcbind
# systemctl start nfs-server

La configuration des clients NFS fait l’objet d’un article à part.

Documentation

Publié dans CentOS, Documentation Microlinux | Marqué avec , , | 5 commentaires

Installer un serveur dédié CentOS 7 chez Online

Logo CentOSDepuis quelques années, la société Online propose une gamme de serveurs dédiés à des prix extrêmement intéressants, notamment la Dedibox SC, qui vous permet de disposer d’un accès root sur votre propre machine à moins de dix euros par mois. Cet article décrit de manière succincte l’installation et la configuration de CentOS 7 sur une Dedibox de type SC ou Start LTS.

Note importante : l’article initialement publié en novembre 2017 a été entièrement revu et corrigé. La procédure de post-installation est maintenant bien plus simple, étant donné qu’elle est à peu près entièrement scriptée.

Dedibox Online

Installation de CentOS

Dans un premier temps, il faut procéder au choix de la machine et du système d’exploitation.

  1. Se connecter à la console d’Online : https://console.online.net.
  2. Ouvrir le menu Serveur > Liste des serveurs.
  3. Sélectionner la machine > Administrer > Installer.
  4. Distributions serveur > CentOS 7.x 64bits > Installer CentOS.

Online propose un schéma de partitionnement par défaut, que nous allons modifier.

  1. Réduire la taille de la partition principale pour avoir un peu de marge.
  2. Augmenter la taille de la partition /boot : 500 Mo.
  3. La partition /boot sera formatée en ext2.
  4. Augmenter la taille de la partition d’échange en fonction de la RAM disponible.
  5. Remplir l’espace disponible pour la partition principale.

Voici ce que l’on obtient.

Partitionnement Dedibox

Sur une Dedibox Start LTS, on aura quelque chose comme ceci.

Partitionnement Dedibox RAID

L’écran subséquent permet de choisir le mot de passe root, de définir un utilisateur “commun mortel” et de choisir un mot de passe pour cet utilisateur. L’installateur impose une limite de 15 caractères alphanumériques. Le cas échéant, on peut choisir un mot de passe provisoire ici et définir quelque chose de plus robuste à la première connexion.

L’interface affiche ensuite un récapitulatif des paramètres réseau de la machine. On peut éventuellement noter ces paramètres pour les avoir sous la main.

  • Nom d’hôte
  • Adresse IP
  • Masque de sous-réseau
  • IP de la passerelle
  • DNS primaire et secondaire

Il ne reste plus qu’à cliquer sur Effacer l’intégralité de mes disques durs pour procéder à l’installation.

Connexion initiale

L’installation du système initial dure un peu plus d’une heure. La première connexion SSH montre qu’il y a déjà pas mal d’activité autour de notre serveur.

There were 87 failed login attempts since the last successful login.

On vérifie si tous les paquets du système initial sont bien à jour.

[root@sd-100246 ~]# yum check-update
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
 * base: centos.serverspace.co.uk
 * extras: centos.serverspace.co.uk
 * updates: mirror.econdc.com

Apparemment, l’installateur de chez Online s’est chargé d’effectuer la mise à jour initiale, ce qui semble logique.

Récupérer le script de post-installation

L’utilitaire git ne fait pas partie d’une installation par défaut. Il va donc falloir l’installer.

# yum install git

Ensuite, récupérer le contenu de mon dépôt Github.

# cd
# git clone https://github.com/kikinovak/centos-7-server-online

Élaguer l’installation initiale

Avant d’installer quoi que ce soit, on va épurer le système installé par Online pour revenir au strict minimum, c’est-à-dire l’équivalent de ce que l’on obtient sur une machine locale lorsqu’on opte pour une installation minimale. Pour faciliter cette tâche, je fournis le script elaguer.sh à la racine du répertoire centos-7-server-online. Ce script se charge de supprimer tous les paquets qui ne font pas partie du système de base à proprement parler. Notons que l’opération d’élagage supprime près de 200 paquets. On passe de 490 paquets dans la configuration d’origine à un système minimal constitué de 288 paquets et occupant un peu plus d’un gigaoctet d’espace disque.

# cd centos-7-server-online
# ./elaguer.sh

Le script se sert de la liste de paquets centos-7-server-online/config/pkglists/minimal.txt qui a été établie auparavant moyennant la commande suivante.

# rpm -qa --queryformat '%{NAME}\n' | sort > minimal.txt

Lancer le script de post-installation

Le répertoire centos-7-server-online contient un script postinstall.sh. Lancer ce script.

# cd centos-7-server-lan
# ./postinstall.sh

L’affichage du script est assez laconique. Pour en savoir un peu plus sur le détail et la progression des opérations, on peut ouvrir un deuxième terminal et afficher le fichier journal “à chaud”, comme ceci.

# tail -f /tmp/postinstall.log

Le script se charge automatiquement des opérations suivantes.

  • Activer la gestion des Delta RPM.
  • Effectuer la mise à jour initiale du système.
  • Désactiver l’IPv6.
  • Personnaliser le shell Bash pour root et les utilisateurs.
  • Personnaliser la configuration de Vim.
  • Définir l’anglais comme langue système.
  • Activer SELinux en mode renforcé.
  • Configurer les dépôts de paquets officiels de manière prioritaire.
  • Configurer le dépôt de paquets tiers EPEL.
  • Installer une panoplie d’outils système.
  • Supprimer les paquets inutiles.

Peaufiner la configuration réseau

La prochaine étape consiste à mettre un peu plus d’ordre et de clarté dans les fichiers de configuration réseau. Le répertoire /etc/sysconfig/network-scripts contient un fichier ifcfg-eth0 que nous pouvons rendre plus lisible.

# /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=static
IPADDR=163.172.220.174
NETMASK=255.255.255.0

La passerelle sera définie dans /etc/sysconfig/network.

# /etc/sysconfig/network
GATEWAY=163.172.220.1

Les deux serveurs DNS seront renseignés dans /etc/resolv.conf.

# /etc/resolv.conf
nameserver 62.210.16.6
nameserver 62.210.16.7

Le fichier /etc/hosts ressemblera à ceci.

# /etc/hosts
127.0.0.1       localhost.localdomain localhost
163.172.220.174 sd-100246.dedibox.fr sd-100246

Quant à /etc/hostname, il est censé contenir le nom d’hôte pleinement qualifié, et c’est tout. Veillez à ne surtout pas ajouter de commentaires dans ce fichier, sous peine de provoquer toute une série d’erreurs bizarres.

sd-100246.dedibox.fr

Agrémenter la console pour l’utilisateur initial

Le répertoire /etc/skel contient le profil par défaut pour les utilisateurs. On va récupérer ce profil pour l’utilisateur créé lors de l’installation.

# su - microlinux
$ cp -v /etc/skel/.bash* .
‘/etc/skel/.bash_logout’ -> ‘./.bash_logout’
‘/etc/skel/.bash_profile’ -> ‘./.bash_profile’
‘/etc/skel/.bashrc’ -> ‘./.bashrc’
$ source ~/.bashrc
$ exit

Installer un pare-feu personnalisé

Depuis la version 7.0, CentOS gère le pare-feu avec firewalld, qui est au pare-feu ce que NetworkManager est au réseau. Une couche d’abstraction à la sauce Red Hat, et qui ne nous servira pas à grand-chose. On préférera une configuration traditionnelle avec iptables. Dans un premier temps, vérifier si les paquets iptables-* sont installés.

# rpm -qa | grep iptables
iptables-1.4.21-13.el7.x86_64
iptables-services-1.4.21-13.el7.x86_64

Activer le service correspondant.

# systemctl enable iptables
# systemctl start iptables

Sous CentOS, la meilleure solution consiste à éditer un simple script Bash pour iptables, en enregistrant la configuration à la fin du script.

# /usr/sbin/service iptables save

Copier le script centos-7-server-online/config/firewall/firewall.sh dans un endroit approprié, par exemple /usr/local/sbin. Adapter le script à la configuration réseau de la machine et aux services que l’on compte héberger.

# firewall.sh

Afficher la configuration du pare-feu.

# iptables -L -vn

Régler les problèmes relatifs à SELinux

Afficher les alertes SELinux.

# sealert -a /var/log/audit/audit.log
100% done
found 2 alerts in /var/log/audit/audit.log

J’obtiens deux alertes. Je m’occupe d’abord de celle qui me semble le plus facilement gérable.

SELinux is preventing audispd from open access on the file 
/etc/ld.so.cache.
*****  Plugin restorecon (94.8 confidence) suggests   ******
If you want to fix the label. 
/etc/ld.so.cache default label should be ld_so_cache_t.
Then you can run restorecon. 
Do
# /sbin/restorecon -v /etc/ld.so.cache

Le contexte de sécurité a l’air correct.

# ls -Z /etc/ld.so.cache 
-rw-r--r--. root root unconfined_u:object_r:ld_so_cache_t:s0 
/etc/ld.so.cache

Je restaure le contexte par défaut comme indiqué.

# restorecon -v /etc/ld.so.cache 

Je vérifie si ça règle le problème.

# echo > /var/log/audit/audit.log
# systemctl reboot && exit

Après redémarrage, je relance un audit.

# sealert -a /var/log/audit/audit.log 
100% done
found 0 alerts in /var/log/audit/audit.log

 

Publié dans CentOS, Documentation Microlinux | Marqué avec , | Laisser un commentaire

Synchroniser Mozilla Thunderbird avec OwnCloud

LightningDans une précédente série d’articles, nous avons vu en détail l’installation et la prise en main de la plateforme de stockage et de partage de fichiers OwnCloud. Souvenons-nous que la principale motivation d’une telle installation, c’est de garder le contrôle de ses données et de se passer de Dropbox, Google Drive, OneDrive ou iCloud Drive. Depuis les révélations d’Edward Snowden, il est établi que ces plateformes propriétaires se contrefichent de votre vie privée avec une désinvolture parfaite.

Puisque la confidentialité semble bien être la denrée rare du XXIème siècle, nous allons poursuivre notre quête qui vise à libérer nos données, en synchronisant le client de courrier électronique Mozilla Thunderbird avec OwnCloud. Plus concrètement, le carnet d’adresses de Thunderbird sera synchronisé avec les Contacts OwnCloud. Quant au calendrier Lightning et à la liste des tâches, on va les connecter à l’agenda dans OwnCloud.

Activer les applications Contacts et Calendar

Dans la configuration par défaut, les applications Contacts et Calendar ne sont pas activées. Il faut donc le gérer dans les Paramètres de OwnCloud.

OwnCloud Applications

Installer l’extension SOGo Connector

Thunderbird a besoin de l’extension SOGo Connector pour être en mesure de se connecter à OwnCloud. Cette extension peut être téléchargée ici. Ne cliquez pas directement sur le lien, mais faites un clic droit sur le bouton de téléchargement et choisissez Enregistrer la cible du lien sous dans le menu contextuel.

SOGo Connector

Ouvrez Thunderbird, allez dans Modules Complémentaires > Extensions et choisissez Installer un module depuis un fichier. Sélectionnez le fichier sogo-connector-31.0.5.xpi, installez-le et redémarrez Thunderbird.

Synchroniser le Carnet d’adresses

Ouvrez l’application Contacts dans OwnCloud. En bas à gauche de l’interface web, repérez le bouton Paramètres et cliquez dessus. Dépliez le menu symbolisé par trois petits points à côté de la ligne Contacts et cliquez sur Lien.

OwnCloud Contacts

L’URL du carnet d’adresses s’affiche alors en-dessous de Contacts, c’est quelque chose comme https://cloud.microlinux.fr/remote.php/dav/addressbooks/users/kikinovak/contacts. Sélectionnez cette URL et copiez-la dans le presse-papier.

Ouvrez le Carnet d’adresses de Thunderbird et créez un nouveau carnet d’adresses en allant dans Fichier > Nouveau > Carnet d’adresses distant. Choisissez un nom pour votre carnet d’adresses – par exemple Contacts OwnCloud – et collez l’URL du carnet d’adresses dans le champ prévu à cet effet. Éventuellement, activez la Synchronisation Périodique et confirmez en cliquant sur OK.

Thunderbird OwnCloud

Pour rapatrier vos contacts existants, il suffit de cliquer droit sur le carnet d’adresses Contacts OwnCloud, puis sur Synchroniser dans le menu contextuel.

Thunderbird OwnCloud

Synchroniser l’agenda et les tâches

On procédera de manière similaire pour la synchronisation du calendrier. Dans l’interface web de OwnCloud, ouvrez l’application Agenda et repérez le bouton Paramètres et importation en bas à gauche. Cliquez dessus,repérez les trois petits points à côté de l’agenda Personnel, cliquez dessus et affichez le Lien. Copiez-collez l’URL de l’agenda dans le presse-papier.

Agenda OwnCloud

Ouvrez Thunderbird, affichez l’agenda Lightning et créez un nouvel agenda via l’entrée de menu Fichier > Nouveau > Agenda > Sur le réseau. Sélectionnez le format CalDAV, collez l’URL de l’agenda dans le champ Emplacement et cochez l’option Prise en charge du mode hors connexion.

Agenda Thunderbird

Dans la fenêtre subséquente, choisissez un nom pour votre agenda.

Thunderbird Agenda

Éventuellement, on peut supprimer l’agenda local pour être sûr de synchroniser l’ensemble des tâches et des rendez-vous.

Thunderbird Agenda

Conclusion

J’utilise cette solution depuis quelque temps pour synchroniser mes contacts, mon agenda et ma liste de tâches entre ma station de travail et mon ordinateur portable, et elle fonctionne à merveille.

Notons que je me sers principalement de l’interface de Thunderbird pour la création, l’édition et la suppression des contacts, des rendez-vous et des tâches, et non pas de l’interface web des applications Contacts et Agenda.

Publié dans Documentation Microlinux | Marqué avec , , , | Un commentaire

Filtrer le web avec SquidGuard sous CentOS

SquidGuardIl existe une pléthore de solutions pour filtrer le Web et mettre en place une sorte de “contrôle parental” pour un réseau. La plupart de ces techniques relèvent de la catégorie farces et attrapes et se distinguent avant tout par leur inefficacité. Seule une poignée de systèmes de filtrage fonctionne de manière à peu près correcte. Parmi ces solutions, on trouve le redirecteur SquidGuard couplé au serveur proxy Squid, dont nous avons décrit la configuration en détail dans une série d’articles.

Chaque requête HTTP/HTTPS du réseau local est redirigée de façon transparente vers le serveur proxy, qui analyse une série de règles avant d’autoriser ou d’interdire la connexion. En cas de refus, c’est une page explicative qui s’affiche à l’utilisateur. Pour faire le tri, on se servira des listes fournies par le Centre de Ressources Informatiques de l’Université de Toulouse.

Installation

Sous Red Hat Enterprise Linux et CentOS, SquidGuard est fourni par le dépôt de paquets EPEL.

# yum install squidGuard

La page explicative

Lorsque SquidGuard refuse l’accès à une page, c’est toujours une bonne idée d’expliquer les raisons de ce refus aux utilisateurs. Pour commencer, on va donc mettre en place une page d’avertissement, qui sera hébergée sur le serveur proxy lui-même.

L’article sur le serveur Apache décrit en détail la mise en place d’une page web locale. Pour ma page avertissement.html, je me suis servi de la page web par défaut fournie par le paquet httpd dans le répertoire /usr/share/httpd/noindex, et que j’ai adaptée à mes besoins. Voilà ce que ça donne sur ma machine.

Page explicative SquidGuard

La mise en place d’une page web locale est expliquée en détail ici.

Récupérer les listes noires

Dans la configuration par défaut, SquidGuard fournit une collection de listes sous forme d’une archive /var/squidGuard/blacklists.tar.gz. Nous utiliserons plutôt les listes fournies par l’Université de Toulouse et maintenues par Fabrice Prigent. On peut les récupérer manuellement comme ceci. L’archive compressée pèse près de 11 Mo.

# cd /var/squidGuard
# rm blacklists.tar.gz
# wget -c ftp://ftp.ut-capitole.fr/blacklist/blacklists.tar.gz
# tar xvzf blacklists.tar.gz
# cd blacklists

 Chacun des répertoires correspond à une catégorie (ou destination) du Web.

# ls -l | awk '{print $9, $10, $11}'
ads -> publicite
adult
aggressive -> agressif
agressif
arjel
associations_religieuses
astrology
audio-video
bank
bitcoin
blog
cc-by-sa-4-0.pdf
celebrity
chat
child
cleaning
cooking
cryptojacking
dangerous_material
dating
ddos
dialer
download
drogue
drugs -> drogue
educational_games
filehosting
financial
forums
gambling
games
global_usage
hacking
jobsearch
...

On peut très bien utiliser l’outil rsync pour récupérer les listes. Cette méthode est même recommandée, étant donné que rsync ne téléchargera que la différence entre les arborescences distante et locale lors d’une mise à jour. La seule différence par rapport au téléchargement avec wget, c’est que nous retrouvons nos destinations dans un répertoire dest/ au lieu de blacklists/.

# cd /var/squidGuard
# rm -rf blacklists*
# rsync -rv rsync://ftp.ut-capitole.fr/blacklist/ .
# cd dest

Repérez le fichier global_usage et jetez un oeil à son contenu. Il s’agit d’un fichier explicatif sur le contenu des listes.

Un filtre simple pour contenus problématiques

Dans l’exemple ci-dessous, nous allons filtrer les sites à contenu potentiellement problématique (porno, violence, drogues) pour toutes les machines du réseau local.

SquidGuard se configure par le biais du fichier de configuration /etc/squid/squidGuard.conf. Pour commencer, nous allons renommer le fichier de configuration d’origine, qui pourra éventuellement nous servir de modèle pour des configurations plus élaborées.

# cd /etc/squid
# mv squidGuard.conf squidGuard.conf.orig

Ensuite, nous allons éditer le fichier /etc/squid/squidGuard.conf comme ceci.

# /etc/squid/squidGuard.conf
dbhome /var/squidGuard/dest
logdir /var/log/squidGuard

src microlinux {
  ip 192.168.2.0/24
}

# Des sites adultes allant de l'érotique à la pornographie dure
destination adult {
  domainlist adult/domains
  urllist adult/urls
  log adult
}

# Quelques sites racistes, antisémites et incitant à la haine
destination agressif {
  domainlist agressif/domains
  urllist agressif/urls
  log agressif
}

# Drogues
destination drogue {
  domainlist drogue/domains
  urllist drogue/urls
  log drogue
}

acl {
  microlinux {
    pass !adult
    pass !agressif
    pass !drogue
    redirect 302:http://nestor.microlinux.lan/avertissement.html
  }
  default {
    pass none
    redirect 302:http://nestor.microlinux.lan/avertissement.html
  }
}

Cette configuration mérite quelques explications.

  • La directive dbhome indique à SquidGuard où trouver la base de données des listes.
  • La directive logdir spécifie l’endroit où l’on désire récupérer les logs.
  • Les sources définissent les groupes de postes clients. Ici, la source microlinux définit toutes les machines du réseau 192.168.2.0/24.
  • Les acl ou Access Control Lists permettent de définir quelle source peut ou ne peut pas aller vers quelle(s) destination(s).
  • Lorsqu’une destination n’est pas autorisée, la directive redirect permet de servir une page explicative au client.

À présent, il faut configurer Squid pour qu’il utilise SquidGuard. Éditez le fichier /etc/squid/squid.conf et ajoutez ceci à la fin du fichier.

# SquidGuard
url_rewrite_program /usr/bin/squidGuard
url_rewrite_children 8

Avant d’aller plus loin, nous devons régler quelques permissions. Le proxy Squid tourne avec les droits de l’utilisateur système squid et du groupe système squid.

# chown -R squid:squid /var/squidGuard

On va également ajuster les permissions pour le répertoire des logs.

# chown -R squid:squid /var/log/squidGuard

Ce n’est pas une mauvaise idée d’aligner les permissions du fichier /etc/squid/squidGuard.conf sur celles de squid.conf.

# chown root:squid /etc/squid/squidGuard.conf
# chmod 0640 /etc/squid/squidGuard.conf

Pour pouvoir fonctionner rapidement, SquidGuard n’utilise pas les fichiers au format texte, mais des bases de données au format Berkeley. Ces bases de données n’existent pas encore, et nous devons les construire.

# squidGuard -C all

Si tout s’est bien passé, on obtient quelque chose comme ceci.

# cat /var/log/squidGuard/squidGuard.log
... New setting: dbhome: /var/squidGuard/dest
... New setting: logdir: /var/log/squidGuard
... init domainlist /var/squidGuard/dest/adult/domains
... create new dbfile /var/squidGuard/dest/adult/domains.db
... init urllist /var/squidGuard/dest/adult/urls
... create new dbfile /var/squidGuard/dest/adult/urls.db
... init domainlist /var/squidGuard/dest/agressif/domains
... create new dbfile /var/squidGuard/dest/agressif/domains.db
... init urllist /var/squidGuard/dest/agressif/urls
... create new dbfile /var/squidGuard/dest/agressif/urls.db
... init domainlist /var/squidGuard/dest/drogue/domains
... create new dbfile /var/squidGuard/dest/drogue/domains.db
... init urllist /var/squidGuard/dest/drogue/urls
... create new dbfile /var/squidGuard/dest/drogue/urls.db
... squidGuard 1.4 started (1521101196.722)
... db update done

Quelques mises en garde s’imposent ici.

  • SquidGuard est une application assez pointue, pour ne pas dire une petite usine à gaz un peu capricieuse. La moindre faute de frappe dans un des fichiers de configuration se solde généralement par un échec. Il est donc nécessaire de porter une grande attention à la syntaxe.
  • Les bases de données (fichiers *.db en-dessous de l’arborescence /var/squidGuard/dest/) doivent être construites après avoir écrit le fichier de configuration, car seules les destinations définies dans ce fichier seront compilées. Autrement dit, si vous devez ajouter une destination par la suite (malware, tricheur, etc.) il va falloir penser à compiler les bases de données correspondantes.
  • En règle générale, ça ne fonctionne que rarement du premier coup. Dans ce cas, jetez un oeil dans les logs, notamment squidGuard.log. Ce dernier vous sera d’un grand secours, car il vous avertira de tous les problèmes de configuration.

Étant donné que la commande squidGuard -C all a été invoquée par root, les fichiers générés par cette commande appartiennent à ce dernier. On va donc devoir rectifier le tir une deuxième fois pour les permissions.

# chown -R squid:squid /var/squidGuard
# chown -R squid:squid /var/log/squidGuard

Recharger la configuration.

# systemctl restart squid

À présent, naviguez sur le Web au hasard tout en choisissant bien, et testez le filtrage de quelques sites potentiellement problématiques. Si tout se passe comme prévu, les pages ne s’affichent pas, et l’utilisateur se trouve confronté à la page explicative. Non content de cela, sa tentative est enregistrée dans le fichier log correspondant à la catégorie de site prohibé.

# cat /var/log/squidGuard/adult 
...
2018-03-15 08:14:24 [2428] Request(microlinux/adult/-) 
https://www.youporn.com/ 192.168.2.3/bernadette.microlinux.lan 
- GET REDIRECT
2018-03-15 08:14:36 [2428] Request(microlinux/adult/-) 
https://www.pornhub.com/ 192.168.2.3/bernadette.microlinux.lan
- GET REDIRECT
2018-03-15 08:15:57 [2428] Request(microlinux/adult/-) 
https://xhamster.com/ 192.168.2.3/bernadette.microlinux.lan
- GET REDIRECT

Automatiser la mise à jour des listes

Étant donné que la récupération des listes noires et la construction des bases de données est une opération quelque peu fastidieuse, on va la confier à un script que l’on exécutera de temps en temps. Voilà à quoi cela peut ressembler.

#!/bin/bash

# Université de Toulouse
HOST=ftp.ut-capitole.fr

# L'exécution du script est réservée à root
if [ `id -u` != 0 ]; then
  echo
  echo ":: Désolé, vous devez être root pour exécuter ce script."
  echo
  exit
fi

# Vérifier si l'hôte distant est joignable
ping -c 1 $HOST > /dev/null 2>&1 ||
  {
    echo
    echo ":: L'hôte distant n'est pas joignable."
    echo
    exit
  }

# Arrêter Squid
systemctl stop squid

# Récupérer les listes
cd /var/squidGuard
rsync -rv rsync://$HOST/blacklist .

# Définir les permissions
chown -R squid:squid dest

# Construire la base de données
echo ":: Construction de la base de données des sites..."
squidGuard -C all

# Rectifier les permissions
chown -R squid:squid /var/squidGuard
chown -R squid:squid /var/log/squidGuard

# Redémarrer Squid
systemctl start squid

On pourrait très bien songer à confier l’exécution de ce script à une tâche automatique (cronjob), mais j’évite de le faire dans la pratique quotidienne. En effet, les noms des catégories peuvent changer de temps à autre. Ça ne va pas arriver tous les jours, mais vous y aurez droit de temps en temps. Or, si votre fichier de configuration définit une destination qui n’a pas de catégorie correspondante dans les listes noires, l’exécution du script échouera. Et si vous administrez un ou plusieurs serveurs proxy dans un lycée ou dans une entreprise, c’est à ce moment précis que votre téléphone se mettra à sonner avec insistance. Je vous aurai prévenus.

Publié dans CentOS, Documentation Microlinux | Marqué avec , , | Laisser un commentaire

La télémaintenance facile avec DWService

DWServiceDWService est un service de contrôle d’accès à distance facile à prendre en main disponible pour Linux, Windows, Mac OS X et Raspberry. L’agent est publié sous licence libre, et il est gratuitement téléchargeable pour toutes les plate-formes. L’accès aux machines distantes s’effectue depuis un simple navigateur web, même depuis une tablette ou un smartphone.

Pour ma part, j’utilise DWService depuis quelques mois pour accéder aux postes de travail Linux de mes clients, ce qui me permet la plupart du temps de les dépanner rapidement en prenant la main à distance, par exemple pour configurer une nouvelle imprimante.

Depuis peu, je l’installe également sur les serveurs de réseau local que j’installe dans les TPE et PME, ce qui m’évite de configurer une redirection de ports sur le modem/routeur de l’entreprise ou de m’arracher les cheveux lorsque le client n’a pas d’adresse IP fixe. [1]

Enfin, j’ai même eu l’occasion récemment de tester DWService chez un client qui doit piloter un parc de machines distantes tournant sous Windows, et il en est ravi.

Inscription sur la plate-forme

La première étape, c’est la création d’un compte sur la plate-forme en ligne DWService. C’est entièrement gratuit, et tout ce qu’il faut, c’est fournir une adresse e-mail et un mot de passe suffisamment compliqué. Une fois qu’on a confirmé l’adresse e-mail, le tour est joué.

DWService Inscription

Installer l’agent sur un PC Linux

Une fois que l’on dispose d’un compte valide sur la plate-forme DWService, on peut créer un ou plusieurs agents. On va commencer par créer un agent sur un poste de travail tournant sous Linux.

Sur la page de téléchargement, je récupère la version pour Linux x86 (32/64 bit). Le téléchargement se présente sous forme d’un fichier dwagent.sh qui pèse un peu moins de 10 Mo. J’ouvre un terminal graphique, et je range le fichier dans un endroit approprié comme /root, en tant que root bien sûr.

Je commence par rendre le fichier exécutable.

# chmod +x dwagent.sh

Je l’exécute depuis le terminal graphique.

# ./dwagent.sh
Extracting file ...
Running installer ...

J’accepte la licence en cliquant sur Installer.

DWService

Je confirme la destination /usr/share/dwagent par défaut.

DWService

Je crée un nouvel agent sur ma machine.

DWService

Je saisis mon identifiant DWS et mon mot de passe, et je choisis un nom pour l’agent nouvellement créé.

DWService

L’agent est installé, et je peux sereinement supprimer le fichier d’installation.

# rm dwagent.sh

Contrôler un PC à distance

À partir de là, mon PC apparaît dans le tableau de bord de DWService. S’il est allumé, il s’affiche sous forme de lien cliquable. Les machines éteintes s’affichent en gris. Notez que le tableau de bord de DWService permet d’organiser les agents en groupes, ce qui s’avère pratique si vous avez beaucoup de machines à gérer. Dans ce cas, vous pourrez les regrouper selon les entreprises, les écoles, les médiathèques, etc.

DWService

Dans la fenêtre Applications, je dispose de plusieurs manières d’accéder à mon PC distant. L’onglet Écran permet d’accéder directement à ce qui s’affiche à l’écran du PC, alors que l’onglet Invite de commande ouvre une console sur la machine distante.

DWService

Lorsque j’utilise le partage de l’écran distant, je bascule vers l’affichage en plein écran, aussi bien pour le navigateur (touche F11) que pour DWService.

Installer l’agent sur un serveur Linux

La documentation officielle ne le mentionne pas, mais il est également possible d’installer un agent DWService sur un serveur Linux dépourvu d’interface graphique. Dans ce cas, la procédure d’installation affichera un dialogue en mode console.

Pour télécharger dwagent.sh depuis le serveur, on peut utiliser Links.

# links https://www.dwservice.net

Rendre le fichier exécutable.

# chmod +x dwagent.sh

Lancer le programme d’installation.

# ./dwagent.sh
Extracting file ...
Running installer ...

****************************************
Commands:
#BACK to go back.
#EXIT to exit.
****************************************

License
This software is free and open source. It consists of one main 
component and several accessory components defined "app" that 
could be governed by different licenses. For more informations 
visit: https://www.dwservice.net/en/licenses-sources.html

Security
To protect your privacy we guarantee that no information will be
stored on our servers and communications are encrypted so third
parties can't read them anyway.

Software updates
The updates of this software are automatic.

1. Install
2. Run
3. I do not accept
Option (3): 1
Waiting...

Confirmer la destination /usr/share/dwagent par défaut.

Select the installation path:
Path (/usr/share/dwagent): [Entrée]
Waiting...

Do you want install DWAgent to '/usr/share/dwagent'?

1. Yes
2. No
Option (2): 1
Waiting...
Folder creation...
Downloading file config.xml...
Downloading file files.xml...
Downloading file agentupd_linux_x86_64.zip...
Downloading file agent.zip...
Downloading file agentui.zip...
Downloading file agentapps.zip...
Downloading file agentui_linux_x86_64.zip...
Copying files...
Installing service...
Starting service...
Installing monitor...
Installing shortcuts...

Je crée un nouvel agent sur mon serveur.

How do you prefer to configure the agent?

1. Entering the installation code
2. Creating a new agent
Option (1): 2
Waiting...

Enter data to create a new agent:
DWS user: info@microlinux.fr
DWS password: **********************
Agent name: serveur-microlinux
Waiting...
Creating agent in progress...
Installation has been completed.
Removing temp directory ...

Là aussi, je peux faire le ménage et supprimer le programme d’installation.

# rm dwagent.sh

Contrôler un serveur à distance

À partir de là, mon serveur apparaît dans le tableau de bord de DWService comme n’importe quel PC. La seule différence, c’est que l’onglet Écran n’apparaît pas, faute d’interface graphique. Comme il faut s’y attendre, je dois me connecter via l’onglet Invite de commande.DWService

Conclusion

Au bout de quelques mois d’utilisation, je suis ravi de DWService, qui fonctionne à merveille pour contrôler à distance un parc de machines auxquelles on ne peut pas accéder via SSH, ou que l’on doit contrôler en mode graphique. Je ne peux donc que vous le conseiller. Et si vous êtes un administrateur Windows, DWService pourra venir remplacer TeamViewer, étant donné qu’il fonctionne tout aussi bien et que vous n’êtes pas embêté par les restrictions de licence.


  1. Certains fournisseurs d’accès soi-disant “professionnels” considèrent qu’une adresse IP fixe pour une entreprise est un luxe que l’on propose éventuellement en option au client, en le facturant en conséquence. Orange, c’est vous que je regarde avec vos Livebox Pro qui n’ont de pro que le nom.
Publié dans CentOS, Documentation Microlinux | Marqué avec , | 6 commentaires

Squid et les exceptions pour les sites problématiques

AvertissementIl y a quelques jours, j’ai mis en place un serveur proxy cache transparent dans mon entreprise. Dans la configuration actuelle, Squid gère les connexions HTTP aussi bien que les connexions HTTPS. Le but de l’opération, c’est de tester la journalisation et l’analyse du trafic web d’un réseau local avant d’installer ça chez les clients, selon la célèbre devise “eat your own dog food“.

Au bout de quelques jours, j’ai pas mal peaufiné la configuration, et je dois dire que la combinaison Squid + SquidAnalyzer est rudement efficace pour savoir en quelques clics qui fait quoi sur le web, quels sont les sites les plus populaires, qui télécharge le plus, etc.

Les sites qui posent problème

Dans l’ensemble, ça fonctionne plutôt bien pour l’écrasante majorité des sites visités. L’article du jour traite donc de la poignée de sites restants qui peuvent poser problème. Ce ne sont pas forcément des sites web d’ailleurs, mais tout ce qui nécessite une connexion sur le port 443. Comme la synchronisation d’un dépôt Github, par exemple.

# git pull
fatal: unable to access 'https://github.com/kikinovak/depot/': 
Peer's certificate issuer has been marked as 
not trusted by the user.

De manière similaire, Thunderbird proteste au démarrage lorsqu’il essaie de synchroniser le carnet d’adresses avec OwnCloud.

Squid HTTPS

L’approche pragmatique

Évidemment, on pourrait très bien ajouter notre certificat fait maison dans git et dans Thunderbird, mais ne perdons pas de vue le fait que nous cherchons uniquement à mettre en place une solution de journalisation du trafic web, et que cette façon de procéder nous ferait sauter à travers des cerceaux en feu pour pas grand-chose. La solution pragmatique consiste ici à créer des exceptions pour tous ces domaines qui posent problème, de manière à ce qu’ils contournent le serveur proxy.

J’ai essayé dans un premier temps de le faire au niveau de la configuration du proxy, mais je me suis rendu compte au bout d’une matinée ensoleillée de tentatives et d’échecs qu’une fois que le trafic arrivait au niveau de Squid il devait nécessairement être traité. Le problème se situait donc en amont.

Note 12 mars 2018 :  contrairement à ce que je viens de dire, le problème peut très bien être résolu au niveau de la configuration de Squid, comme c’est décrit un peu plus loin.

Définir les exceptions au niveau du pare-feu

Pour contourner le proxy il faut tout simplement éviter de lui faire passer les paquets TCP en premier lieu. Et pour ce faire, il faut attaquer le problème au niveau du pare-feu. Dans la configuration par défaut – c’est-à-dire où tout le trafic web est redirigé vers Squid, sans exceptions – il ressemble à ceci.

# Commandes
IPT=/usr/sbin/iptables
...
# Réseau local
IFACE_LAN=enp3s1
...
# Serveur
SERVER_IP=192.168.3.1
...
# Squid 
$IPT -A INPUT -p tcp -i $IFACE_LAN --dport 3128 -j ACCEPT
$IPT -A INPUT -p udp -i $IFACE_LAN --dport 3128 -j ACCEPT
$IPT -A PREROUTING -t nat -i $IFACE_LAN -p tcp ! -d $SERVER_IP \
 --dport 80 -j REDIRECT --to-port 3128
$IPT -A INPUT -p tcp -i $IFACE_LAN --dport 3129 -j ACCEPT
$IPT -A INPUT -p udp -i $IFACE_LAN --dport 3129 -j ACCEPT
$IPT -A PREROUTING -t nat -i $IFACE_LAN -p tcp ! -d $SERVER_IP \
 --dport 443 -j REDIRECT --to-port 3129
$IPT -A INPUT -p tcp -i $IFACE_LAN --dport 3130 -j ACCEPT
$IPT -A INPUT -p udp -i $IFACE_LAN --dport 3130 -j ACCEPT

On pourrait être tenté d’ajouter une exception dans la ligne qui gère la redirection des paquets à destination du port 443, comme ceci. Notez au passage qu’on a simplement remplacé ! -d $SERVER_IP par ! -d microlinux.fr, vous verrez pourquoi.

$IPT -A PREROUTING -t nat -i $IFACE_LAN -p tcp ! -d microlinux.fr \
 --dport 443 -j REDIRECT --to-port 3129

Le problème se pose dès que l’on utilise un domaine qui pointe vers plusieurs adresses IP, comme github.com, par exemple.

$IPT -A PREROUTING -t nat -i $IFACE_LAN -p tcp ! -d github.com \
 --dport 443 -j REDIRECT --to-port 3129

Dans ce cas, on se retrouve confronté à l’erreur suivante.

iptables v1.4.21: ! not allowed with multiple source or 
destination IP addresses

La solution consiste ici d’accepter le domaine en amont de la règle de redirection.

# Exception
$IPT -A PREROUTING -t nat -i $IFACE_LAN -d github.com -j ACCEPT

# Squid 
$IPT -A INPUT -p tcp -i $IFACE_LAN --dport 3128 -j ACCEPT
$IPT -A INPUT -p udp -i $IFACE_LAN --dport 3128 -j ACCEPT
$IPT -A PREROUTING -t nat -i $IFACE_LAN -p tcp ! -d $SERVER_IP \
 --dport 80 -j REDIRECT --to-port 3128
$IPT -A INPUT -p tcp -i $IFACE_LAN --dport 3129 -j ACCEPT
$IPT -A INPUT -p udp -i $IFACE_LAN --dport 3129 -j ACCEPT
$IPT -A PREROUTING -t nat -i $IFACE_LAN -p tcp ! -d $SERVER_IP \
 --dport 443 -j REDIRECT --to-port 3129
$IPT -A INPUT -p tcp -i $IFACE_LAN --dport 3130 -j ACCEPT
$IPT -A INPUT -p udp -i $IFACE_LAN --dport 3130 -j ACCEPT

Et pour finir, on va écrire une boucle qui lit les domaines – ou les adresses IP – dans un fichier no-proxy.txt. Cette boucle devra donc être insérée dans le script de pare-feu avant les redirections vers le proxy.

# Exceptions
EXCEPTIONS=$(egrep -v '(^\#)|(^\s+$)' /usr/local/sbin/no-proxy.txt)
for EXCEPTION in $EXCEPTIONS; do
  $IPT -A PREROUTING -t nat -i $IFACE_LAN -d $EXCEPTION -j ACCEPT
done

Et voici à quoi ressemble mon fichier no-proxy.txt pour l’instant.

# Ne pas utiliser le proxy pour les domaines suivants
#
# Crédit Coopératif
www.credit-cooperatif.coop
# Github
github.com
# Microlinux
cloud.microlinux.fr
cloud.microlinux.eu
# Squid
squid-cache.org
# Thunderbird
start.thunderbird.net

À partir de là, il suffit d’ajouter les domaines – ou les adresses IP – problématiques au fichier no-proxy.txt et de relancer le script de pare-feu, et le tour est joué.

Définir les exceptions au niveau de Squid

Le lendemain de la publication des lignes ci-dessus, j’ai reçu un mail de Yuri Voinov, qui est inscrit comme moi à la mailing list de Squid, et qui m’a fourni une solution simple, élégante et fonctionnelle pour définir des exceptions au niveau de la configuration de Squid. Je tiens à le remercier ici.

Dans le fichier /etc/squid/squid.conf, éditer les règles SSL comme ceci.

# Règles SSL
acl DiscoverSNIHost at_step SslBump1
acl NoSSLIntercept ssl::server_name_regex "/etc/squid/no-proxy.txt"
ssl_bump peek DiscoverSNIHost
ssl_bump splice NoSSLIntercept
ssl_bump bump all

Les URLs à exclure du traitement figurent dans le fichier /etc/squid/no-proxy.txt. Pour la syntaxe, on utilisera les expressions régulières POSIX classiques.

# Teamviewer
(master|ping)[0-9][0-9]?\.teamviewer\.com
# Squid
.squid\-cache\.org
# Github
github\.com
# Microlinux
cloud\.microlinux\.eu
# Thunderbird
start\.thunderbird\.net
live\.mozillamessaging\.com

Cette solution présente une série d’avantages techniques, notamment le fait que les sites définis comme exception apparaissent quand-même dans les logs de Squid. On la préférera donc au traitement en amont dans le pare-feu.

Publié dans CentOS, Documentation Microlinux | Marqué avec , | 4 commentaires

Surveiller le trafic web avec SquidAnalyzer sous CentOS

SquidAnalyzerSquidAnalyzer est un outil de statistiques extrêmement pratique qui permet d’analyser en un coup d’oeil l’ensemble du trafic web d’un réseau. On a donc facilement accès à des informations comme les URLs visitées, les sites les plus populaires, les sites et/ou les utilisateurs les plus “gourmands”, et autres choses encore.

SquidAnalyzer utilise les fichiers logs du serveur proxy Squid, qui doit donc être configuré correctement. Pour les détails, voir les deux articles qui expliquent en détail la configuration de Squid comme proxy cache HTTP transparent et la gestion des connexions HTTPS.

Les résultats de SquidAnalyzer sont disponibles sous forme de pages HTML assez joliment présentées, avec des tableaux et des graphismes. Il faut donc disposer d’un serveur Web fonctionnel sur la machine.

SquidAnalyzer

Téléchargement des sources

Il existe certes des paquets binaires dans des dépôts binaires confidentiels éparpillés sur le web. Étant donné que la construction de l’application depuis les sources officielles ne relève pas de la magie noire, on va préférer cette option.

Le téléchargement des sources de SquidAnalyzer peut se faire en ligne de commande depuis le serveur.

# cd
# links http://squidanalyzer.darold.net

Suivre le lien Download > SourceForge Download. Sur la page de SourceForge, repérer le lien Download un peu plus bas sur la page, cliquer dessus, puis recliquer sur le lien direct qui s’affiche. Télécharger le fichier squidanalyzer-6.6.tar.gz.

Construction et installation

Décompresser l’archive des sources et aller dans le répertoire nouvellement créé.

# tar xvzf squidanalyzer.tar.gz
# cd squidanalyzer-6.6

L’archive fournit un fichier squidanalyzer.spec dans le répertoire packaging/RPM. Malheureusement, la construction d’un paquet RPM en partant de ce fichier échoue. En revanche, il peut nous servir pour récupérer les dépendances de construction du paquet, grâce à la commande yum-builddep fournie par le paquet yum-utils.

# cd packaging/RPM
# yum-builddep squidanalyzer.spec

Cette dernière commande récupère l’intégralité des paquets nécessaires pour la construction de SquidAnalyzer. Ils sont tous fournis par les dépôts officiels de CentOS, notamment une panoplie de modules Perl.

Une fois qu’on a installé toutes les dépendances, on vérifie l’emplacement des fichiers de l’application, qui est défini dans le fichier Makefile.PL.

# Default install path
my $LOGFILE = $ENV{LOGFILE} || $default_log;
my $BINDIR = $ENV{BINDIR} || '/usr/local/bin';
my $CONFDIR = $ENV{CONFDIR} || '/etc/squidanalyzer';
my $ETCDIR = $ENV{ETCDIR} || $CONFDIR;
my $HTMLDIR = $ENV{HTMLDIR} || '/var/www/squidanalyzer';
my $BASEURL = $ENV{BASEURL} || '/squidreport';
my $DOCDIR = $ENV{DOCDIR} || '';
my $MANDIR = $ENV{MANDIR} || '/usr/local/man/man3';
my $DESTDIR = $ENV{DESTDIR} || '';
$ENV{INSTALLDIRS} ||= 'site';

On va garder cette configuration par défaut, quitte à rectifier le tir plus loin en éditant le fichier de configuration. À présent, on peut lancer la construction et l’installation.

# perl Makefile.PL
# make
# make install

Configuration de l’hôte virtuel

Notre proxy Squid est installé sur la machine amandine.sandbox.lan. On va mettre en place un hôte virtuel squidreport.amandine.sandbox.lan qui pointe vers le répertoire /var/www/squidanalyzer.

Le proxy se charge également de la configuration DNS locale avec Dnsmasq. Il suffit donc de créer une nouvelle entrée dans /etc/hosts et de redémarrer Dnsmasq pour propager les informations du nouvel hôte vers toutes les machines du réseau.

# /etc/hosts
127.0.0.1 localhost.localdomain localhost
192.168.3.1 amandine.sandbox.lan amandine
192.168.3.1 squidreport.amandine.sandbox.lan squidreport.amandine

Ensuite, je crée un fichier /etc/httpd/conf.d/10-squidreport.amandine.conf qui contient la configuration de l’hôte virtuel. Pour plus de détails, on consultera l’article détaillé sur Apache.

# /etc/httpd/conf.d/10-squidreport.amandine.conf
#
# http://squidreport.amandine.sandbox.lan
<VirtualHost *:80>
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/squidanalyzer"
  <Directory "/var/www/squidanalyzer">
    Options -Indexes +FollowSymlinks +MultiViews
    AllowOverride None
  </Directory>
  ServerName squidreport.amandine.sandbox.lan
  ServerAlias squidreport.amandine
  ErrorLog logs/squidreport.amandine-error_log
  CustomLog logs/squidreport.amandine-access_log common
</VirtualHost>

Configuration de SquidAnalyzer

SquidAnalyzer se configure par le biais du fichier de configuration /etc/squidanalyzer/squidanalyzer.conf, que l’on adaptera à nos besoins. La configuration par défaut est déjà raisonnablement fonctionnelle, et il suffira de modifier quelques directives.

# /etc/squidanalyzer/squidanalyzer.conf
Output  /var/www/squidanalyzer
WebUrl  /
LogFile /var/log/squid/access.log
UseClientDNSName  0
DNSLookupTimeout  0.0001
...
Lang  /etc/squidanalyzer/lang/fr_FR.txt
...
TransfertUnit MB
...
Locale fr_FR
...

Premier essai

Dans la configuration actuelle, SquidAnalyzer utilise le fichier /var/log/squid/access.log pour générer les rapports. Il faut donc que l’on ait quelque chose à se mettre sous la dent, autrement dit, vérifiez si le fichier n’est pas vide. Les pages du rapport en elles-mêmes sont générées par le script Perl squid-analyzer.

# which squid-analyzer
/usr/local/bin/squid-analyzer

Lancer le script, qui peut mouliner un certain temps en fonction de la taille du fichier /var/log/squid/access.log et de la puissance de calcul du serveur.

# squid-analyzer

Vérifier si le rapport a été généré correctement.

# tree /var/www/squidanalyzer/
/var/www/squidanalyzer/
|-- 2018
|   |-- 03
|   |   |-- 08
|   |   |   |-- denied.html
|   |   |   |-- domain.html
|   |   |   |-- index.html
|   |   |   |-- mime_type.html
|   |   |   |-- network.html
|   |   |   |-- networks
|   |   |   |   `-- 192.168.3.2
|   |   |   |       `-- 192.168.3.2.html
|   |   |   |-- stat_code.dat
|   |   |   |-- stat_denied_url.dat
|   |   |   |-- stat_mime_type.dat
|   |   |   |-- stat_netuser.dat
|   |   |   |-- stat_network.dat
|   |   |   |-- stat_user.dat
|   |   |   |-- stat_user_url.dat
|   |   |   |-- url.html
|   |   |   |-- user.html
|   |   |   `-- users
|   |   |       `-- 192.168.3.2
|   |   |           `-- 192.168.3.2.html
........................................

Afficher les pages dans un navigateur web depuis n’importe quel poste du réseau local. Sur la page d’accueil, cliquer sur Stat <année>, puis sur les infos que l’on souhaite afficher.

  • Réseaux
  • Utilisateurs
  • TopURLs
  • Top domaines
  • etc.

Définition d’une tâche automatique

À partir de là, on peut définir une tâche automatique (cronjob) pour la génération des rapports. Dans l’exemple qui suit, on va produire un rapport quotidien tous les jours à 13h00. Ce n’est pas une mauvaise idée de programmer cette tâche à l’heure du repas. L’exécution du script est relativement gourmande en ressources, et si le serveur n’est pas très puissant, il peut arriver qu’il soit un peu dur de la feuille pendant quelques minutes.

# crontab -l
# SquidAnalyzer
00 13 * * * /usr/local/bin/squid-analyzer 1> /dev/null
Publié dans CentOS, Documentation Microlinux | Marqué avec , , | Laisser un commentaire

Installer Google Chrome sous CentOS 7

Google ChromeGoogle Chrome est un navigateur web propriétaire extrêmement populaire développé par Google et basé sur le projet libre Chromium. Le navigateur est disponible pour les plate-formes Windows, Mac OS X, Linux, Android et iOS.

En temps normal, j’utilise Mozilla Firefox pour naviguer sur le Web. L’installation de Google Chrome me sert principalement pour des tests lorsque je développe des sites web.

Créer un fichier /etc/yum.repos.d/google-chrome.repo pour ajouter le dépôt de paquets Google Chrome.

[google-chrome]
name=google-chrome
baseurl=http://dl.google.com/linux/chrome/rpm/stable/x86_64
enabled=1
gpgcheck=1
gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub

Installer Google Chrome.

# yum install google-chrome-stable

Le navigateur Google Chrome apparaît désormais dans le menu Applications > Internet.

Google Chrome

Publié dans CentOS, Documentation Microlinux | Marqué avec , , | 4 commentaires

Gérer les connexions HTTPS avec Squid sous CentOS

HTTPSDans notre précédent article sur Squid, nous avons décrit en détail la configuration d’un serveur proxy filtrant HTTP. Dans l’état actuel, le serveur ne gère pas du tout les connexions HTTPS. Étant donné qu’un nombre grandissant de sites web utilisent un protocole sécurisé, nous n’avons fait que la moitié du travail. Cet article sera donc consacré à la gestion des requêtes HTTPS.

Depuis la version 3.5, Squid offre une fonctionnalité qui s’appelle le SSL-Bump. Notre démarche consistera à créer un certificat racine que l’on exportera vers les navigateurs web du réseau. Lorsque ceux-ci se connecteront sur un site HTTPS, ce trafic sera dévié vers un deuxième port de Squid, et le serveur générera un certificat dynamique.

La documentation officielle est malheureusement quelque peu laconique et pas toujours très claire, mais on arrive à faire fonctionner le tout avec une bonne dose d’obstination et d’expérimentation.

Vérifier les options de compilation

Squid doit impérativement être compilé avec les options suivantes.

./configure \
--with-openssl \
--enable-ssl-crtd \
...

Le paquet binaire fourni par Red Hat Enterprise Linux 7 et CentOS 7 est parfaitement utilisable tel quel. La commande squid -v affiche l’ensemble des options de compilation de l’application.

# squid -v | egrep '(--with-openssl|--enable-ssl-crtd)' > \
  /dev/null && echo OK
OK

Configuration du pare-feu

Dans notre première configuration de Squid comme proxy cache transparent HTTP, nous avons redirigé les requêtes HTTP (port 80) vers le port 3128 de Squid. Pour utiliser le HTTPS, ce sera un peu plus compliqué.

  • Les requêtes vers le port 80 seront redirigées vers le port 3128.
  • Les requêtes vers le port 443 seront redirigées vers le port 3129.
  • Squid intercepte à son tour ces requêtes et utilise le port 3130 en interne.

Voici à quoi pourra ressembler la configuration du pare-feu.

# Commandes
IPT=/usr/sbin/iptables
...
# Réseau local
IFACE_LAN=enp3s1
...
# Serveur
SERVER_IP=192.168.3.1
...
# Squid 
$IPT -A INPUT -p tcp -i $IFACE_LAN --dport 3128 -j ACCEPT
$IPT -A INPUT -p udp -i $IFACE_LAN --dport 3128 -j ACCEPT
$IPT -A PREROUTING -t nat -i $IFACE_LAN -p tcp ! -d $SERVER_IP \
 --dport 80 -j REDIRECT --to-port 3128
$IPT -A INPUT -p tcp -i $IFACE_LAN --dport 3129 -j ACCEPT
$IPT -A INPUT -p udp -i $IFACE_LAN --dport 3129 -j ACCEPT
$IPT -A PREROUTING -t nat -i $IFACE_LAN -p tcp ! -d $SERVER_IP \
 --dport 443 -j REDIRECT --to-port 3129
$IPT -A INPUT -p tcp -i $IFACE_LAN --dport 3130 -j ACCEPT
$IPT -A INPUT -p udp -i $IFACE_LAN --dport 3130 -j ACCEPT

Créer un certificat racine auto-signé

Le certificat racine sera utilisé par Squid pour générer à la volée les certificats dynamiques pour les sites qui passent par le proxy. Notez que par là, nous devenons une autorité de certification pour le réseau local.

Dans un premier temps, on va trouver un endroit approprié pour stocker le certificat. Les permissions seront définies en fonction de l’utilisateur système squid et du groupe système squid correspondant.

# cd /etc/squid
# mkdir ssl_cert
# chown squid:squid ssl_cert
# cd ssl_cert

Ensuite, on va créer le certificat en fournissant les informations nécessaires. Notre certificat sera valable pour dix ans (-days 3650), et le fichier résultant sera nommé en fonction du nom d’hôte pleinement qualifié de la machine (hostname --fqdn), en l’occurrence amandine.sandbox.lan.pem. Voici à quoi cela peut ressembler.

# openssl req -new -newkey rsa:2048 -sha256 -days 3650 -nodes \
  -x509 -extensions v3_ca -keyout $(hostname --fqdn).pem \
  -out $(hostname --fqdn).pem
Generating a 2048 bit RSA private key
..............................................+++
.................................+++
writing new private key to 'amandine.sandbox.lan.pem'
-----
You are about to be asked to enter information that will be 
incorporated into your certificate request. What you are about 
to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:FR
State or Province Name (full name) []:Gard
Locality Name (eg, city) [Default City]:Montpezat
Organization Name (eg, company) [Default Company Ltd]:Microlinux
Organizational Unit Name (eg, section) []: [Entrée]
Common Name (eg, your server's hostname) []:amandine.sandbox.lan
Email Address []:info@microlinux.fr

Enfin, créer un certificat encodé en DER (Distinguished Encoding Rules) que l’on pourra importer dans les navigateurs web des postes clients. Là aussi, on utilisera le nom d’hôte pleinement qualifié du serveur pour nommer le fichier résultant.

# openssl x509 -in $(hostname --fqdn).pem -outform DER \
  -out $(hostname --fqdn).der

Au final, on obtient deux fichiers qui ressemblent à ceci.

# ls
amandine.sandbox.lan.der amandine.sandbox.lan.pem

Le fichier amandine.sandbox.lan.der devra être distribué aux postes clients, et le certificat devra être installé manuellement dans les navigateurs web.

Mozilla Firefox

Ouvrir Édition > Préférences > Avancé > Certificats > Afficher les certificats et cliquer sur Importer.

Certificat Mozilla Firefox

Sélectionner le fichier amandine.sandbox.lan.der et cocher l’ensemble des options proposées.

Certificat Mozilla Firefox

Le certificat apparaît désormais dans la liste, sous le nom que l’on a choisi à la rubrique Organization Name.

Certificat Mozilla Firefox

Konqueror

L’ajout du certificat dans Konqueror ne se fait pas directement dans la configuration du navigateur, mais dans les Préférences SSL de KDE.

Certificat Konqueror

Cliquer sur Ajouter, sélectionner le fichier amandine.sandbox.lan.der et confirmer en cliquant sur Appliquer.

Certificat Konqueror

Le certificat apparaît alors tout en bas dans la liste, dans les Certificats ajoutés par l’utilisateur.

Certificat Konqueror

Google Chrome

Ouvrir Paramètres > Paramètres avancés > Gérer les certificats > Autorités et cliquer sur Importer.

Google Chrome

Importer le fichier amandine.sandbox.lan.der en cochant tous les paramètres de confiance.

Google Chrome

Le certificat apparaît dans la liste des autorités sous le nom que l’on a choisi à la rubrique Organization Name, préfixé de org-.

Google Chrome

Adapter la configuration de Squid

Pour la configuration de Squid, je me suis basé sur l’exemple fourni dans la documentation, en l’adaptant à mes besoins.

# Ports du proxy
http_port 3130
http_port 3128 intercept
https_port 3129 intercept ssl-bump \
  cert=/etc/squid/ssl_cert/amandine.sandbox.lan.pem \
  generate-host-certificates=on dynamic_cert_mem_cache_size=4MB

# Emplacement de ssl_crtd et du cache des certificats TLS
sslcrtd_program /usr/lib64/squid/ssl_crtd \
  -s /var/lib/squid/ssl_db -M 4MB
sslcrtd_children 8 startup=1 idle=1

# SSL-Bump
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all

J’initialise le cache qui contiendra les certificats TLS créés à la volée. Je dois définir le contexte SELinux manuellement, en le calquant sur celui du répertoire /var/spool/squid. Pour plus de détails, voir ce rapport de bug.

# install -d -m 750 -o squid -g squid /var/lib/squid
# semanage fcontext -a -e /var/spool/squid /var/lib/squid
# runuser -u squid -- /usr/lib64/squid/ssl_crtd -c \
  -s /var/lib/squid/ssl_db
# restorecon -FRv /var/lib/squid

Attention à ne pas ajouter de barre oblique / à la fin des chemins /var/spool/squid et /var/lib/squid en argument à semanage fcontext.

Il ne me reste plus qu’à redémarrer Squid.

# systemctl restart squid

Vérifier le fonctionnement

Pour vérifier le fonctionnement du proxy pour les protocoles HTTP et HTTPS, il suffit de naviguer au hasard sur des sites sécurisés et non sécurisés, en gardant un oeil sur le contenu du journal /var/log/squid/access.log.

# tail -f /var/log/squid/access.log
1520243219.271 39 192.168.3.2 TCP_MISS_ABORTED/000 0 
POST https://www.youtube.com/youtubei/v1/log_event? - ...
1520243220.667 154 192.168.3.2 TCP_MISS/200 1989 
GET http://www.slackware.com/getslack/ - ...
Publié dans CentOS, Documentation Microlinux, Non classé | Marqué avec , | 4 commentaires