¶ Objectif
L’objectif de ces travaux est de découvrir syslog, puis de l’expérimenter en mode client/serveur.
Quelques ressources :
- Le cours sur la supervision
- Le site rsyslog.com
- La présentation de syslog sur https://fr.wikipedia.org/wiki/Syslog
On souhaite créer un serveur syslog qui va centraliser les alertes et messages de différents clients du réseau local.
¶ Déploiement de l'environnement
Serveur et client sont des VM sous Debian 12 core (sans GUI). Avec VirtualBox, configurer le schéma suivant pour avoir ces deux VM, en ajoutant un routeur pfSense (à laisser dans sa configuration par défaut). On ajoutera aussi une machine GUI (Windows ou Linux) afin de se connecter en ssh aux deux Debian.
| Machine | Hostname | Adresse IP |
|---|---|---|
| pfSense | pfsense | 192.168.1.1/24 (serveur DHCP sur le LAN) |
| Debian Serveur syslog | debianS | 192.168.1.10/24 |
| Debian Client | debianC | 192.168.1.11/24 |
| Client GUI | * | DHCP |
Sur chaque Debian (client et serveur) :
- Installer les paquets ssh et wget (apt install ssh wget).
- Installer rsyslog (apt install rsyslog)
- Configurer le hostname (modifier les fichiers /etc/hostname et /etc/hosts)
- Configurer les interfaces réseau (modifier /etc/network/interfaces)
- fixer le serveur DNS sur 1.1.1.1 (fichier /etc/resolv.conf)
Fichier /etc/resolv.conf :
nameserver 1.1.1.1
On va se connecter en root. Il faut donc autoriser sur chaque Debian la connexion root en ssh (fichier /etc/ssh/ssd_config, ajouter la ligne PermitRootLogin yes)
¶ Fichiers de configuration rsyslog.conf
On souhaite configurer un serveur syslog, avec les contraintes spécifiques suivantes :
- On va utiliser le protocole UDP uniquement, sur le port conventionnel 514.
- On limite l’accès au serveur syslog au réseau local.
Rappels :
Un champ de sélection est constitué de deux parties, facility et priority, séparées par un point.
- 24 niveaux de facility
- 8 niveaux de gravité (aussi priority ou level)
Certains sont dépréciés. En général on peut avoir :
- Facility : auth, authpriv, cron, daemon, ftp, kern (can't be generated from user process), lpr, mail, news, syslog, user, uucp, local0..local7
- Level : alert, crit, debug, emerg, err, info, notice, warning.
Il existe différentes syntaxes pour rsyslog (ancienne, basique, avancée)
¶ configuration côté serveur
On modifie le fichier /etc/rsyslog.conf
Activer (décommenter) la réception des messages sur udp/514 :
# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")
Limiter les émetteurs autorisés au réseau local 192.168.1.0/24 (dans la section GLOBAL DIRECTIVES) :
$AllowedSender UDP, 192.168.1.0/24
Toujours dans GLOBAL DIRECTIVES, créer le template (masque) pour l’enregistrement des messages, en fonction de l’IP source (fromhost-ip) :
$template FILENAME,"/var/log/%fromhost-ip%/syslog.log"
Créer une règle qui « attrape » tout, et appliquer le template FILENAME comme action associée (placer ceci en fin de fichier) :
*.* ?FILENAME
Une fois les modifications effectuées, on relance le service rsyslog avec cette nouvelle configuration :
systemctl restart rsyslog
Et on vérifie que tout est ok :
systemctl status rsyslog
On peut également vérifier que le serveur écoute en udp sur le port 514 :
ss -ntaul
¶ Configuration côté client
On modifie également sur le client le fichier /etc/rsyslog.conf
On ajoute une règle pour gérer la facility local0, pour laquelle, quelle que soit la severity, on envoie le message sur le serveur :
local0.* @192.168.1.10:514
On relance le service rsyslog avec cette nouvelle configuration :
systemctl restart rsyslog
Et on vérifie que tout est ok :
systemctl status rsyslog
¶ Test du fonctionnement
Nous allons pouvoir tester le fonctionnement avec la commande logger depuis le client.
Pour avoir plus d'infos sur cette commande :
logger --help
On teste par exemple en envoyant (depuis le client) un message de niveau info :
logger -p local0.info -t ESSAI -- "petit essai"
Vérifier sur le serveur la présence du message, dans le chemin spécifique de la machine cliente :
tail -f /var/log/192.168.1.11/syslog.log
Envoyez d’autres messages depuis le client et regardez évoluer le ficher.
¶ Génération de logs
¶ log de l'état d'une connexion réseau
On souhaite que le client génère un message syslog sur le serveur à chaque fois que son interface réseau devient UP, sur la facility local0 et le niveau info, et avec une étiquette (tag) personnalisée network
Création du script :
cd /etc/network/if-up.d
nano logme
Le script en lui-même (si l’interface réseau s’appelle enp0s3, à vérifier avec ip -c a) :
#!/usr/bin/env bash
if [ "$IFACE" = "enp0s3" ] ; then
/usr/bin/logger -t network -p local0.info -- Lien Ethernet $IFACE est UP
fi
On rend notre script exécutable :
chmod +x logme
On teste :
Côté serveur, on lance une surveillance du log :
tail -f /var/log/192.168.1.11/syslog.log
Puis côté client :
ifdown enp0s3
ifup enp0s3
Puisqu'on est connecté en ssh, la première commande va nous faire perdre l'accès..
Essayer plutôt un reboot du client.
¶ redirection des logs de pfSense
On souhaite diriger les logs de pfSense sur notre serveur.
Configuration du logiciel pfSense pour la journalisation à distance :
- Cliquez sur Status > System Logs
- Cliquez sur l'onglet Settings
- Modifiez le format des messages : syslog (et non BSD)
- Cochez Enable Remote Logging (en bas de page)
- Tapez l'IP et le port du serveur syslog (192.168.1.10:514) dans la case remote
- Cochez les cases des entrées de journal à transmettre (cocher everything pour générer un fichier de log plutôt verbeux)
- Cliquez sur Enregistrer
Aller voir sur le serveur syslog ce qui se passe en /var/log/
¶ log des accès ssh
On met en place un pare-feu iptables sur le client. On autorise uniquement les connexions SSH entrantes sur le client ; on logue chaque connexion entrante.
On installe iptables et iptables-persistant :
apt install iptables iptables-persistent
Puis on lance ce script :
#!/usr/bin/env bash
IPT=/usr/sbin/iptables
IPTS=/usr/sbin/iptables-save
IFACE_LAN=enp0s3
# init (filter, par défaut)
$IPT -F
$IPT -X
# par défaut ; input droppe par défaut ici
$IPT -P INPUT DROP
$IPT -P OUTPUT ACCEPT
$IPT -P FORWARD DROP
# on accepte ce qui entre depuis l’interface loopback
$IPT -A INPUT -i lo -j ACCEPT
# accepter et logger nouvelle connexion SSH, avec une chaine "SSH"
$IPT -N SSH
$IPT -A INPUT -p tcp -i $IFACE_LAN -m state --state NEW --dport 22 -j SSH
$IPT -A SSH -j LOG --log-prefix "IPTBL SSH: " --log-level 4
$IPT -A SSH -j ACCEPT
# accepter les connexions établies
$IPT -A INPUT -m state --state ESTABLISHED -j ACCEPT
# enregistrer la configuration iptables :
$IPTS > /etc/iptables/rules.v4
Tester la connexion ssh depuis le client GUI.
Cependant, les logs SSH ne sont pas envoyés sur notre serveur syslog.
Sur la configuration rsyslog client, on ajoute (à la fin du fichier rsyslog.conf) :
# passer les messages avec un prefix "IPTBL" au serveur syslog
:msg, contains, "IPTBL" @192.168.1.10:514
NB : il faut plusieurs espaces ou tabulations entre "IPTBL" et @192.. (on sépare le filtre et l'action). Ne pas oublier non plus de relancer le service rsyslog !
¶ Mise en place de logrotate
On va enfin utiliser et paramétrer logrotate sur le serveur pour contrôler la taille des fichiers log.
Vérifier d’abord que logrotate est installé :
apt install logrotate
On va ajouter une règle sur les fichiers : /var/log/192*/*
nano /etc/logrotate.d/rsyslog
Voici ce qu’il faut ajouter au fichier de configuration (on limite volontairement la taille maximum à 30KB pour pouvoir rapidement générer une rotation) :
/var/log/192*/*.log
{
rotate 7
daily
size 30K
missingok
notifempty
compress
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}
Test de la configuration :
logrotate -d /etc/logrotate.conf
Pour lancer une rotation effective, retirer l’option -d
Voir le script qui est exécuté tous les jours :
nano /etc/cron.daily/logrotate
La gestion des scripts réguliers :
nano /etc/crontab
Voir ici pour un peu plus de documentation : https://doc.ubuntu-fr.org/logrotate