Logs d'authentification sur OmniOS CE

Introduction

Par défaut, OmniOS CE ne journalise pas les événements d'authentification (connexions SSH, su, sudo, etc.).
Cette configuration est problématique pour la sécurité, car elle empêche de détecter les tentatives d'intrusion et de mettre en place des mécanismes de protection comme fail2ban.

Cet article présente deux méthodes pour activer ces logs :

• Méthode 1 : rsyslog — Simple, format texte lisible, idéal pour le parsing avec des scripts
• Méthode 2 : auditd (BSM) — Système d'audit Solaris natif, plus détaillé mais format binaire

Méthode 1 : rsyslog

Présentation

OmniOS CE utilise rsyslog comme démon de journalisation système.
Par défaut, les messages d'authentification ne sont pas redirigés vers un fichier dédié.
Cette méthode crée un fichier /var/log/authlog contenant tous les événements d'authentification.

Vérification de l'état initial

Vérifier quel service syslog est actif :

# Vérifier les services syslog
svcs system-log

# Résultat attendu :
STATE STIME FMRI
disabled ... svc:/system/system-log:default
online ... svc:/system/system-log:rsyslog

(rsyslog doit être "online", le syslog classique "disabled")

Configuration de rsyslog

Créer un fichier de configuration pour activer les logs d'authentification :

# Créer le fichier de configuration
cat << 'EOF' > /etc/rsyslog.d/authlog.conf
# Logs d'authentification
auth.* /var/log/authlog
authpriv.* /var/log/authlog
EOF

# Redémarrer rsyslog
svcadm restart system-log:rsyslog

# Vérifier le statut
svcs system-log:rsyslog

Test de la configuration

Générer un événement de test et vérifier le fichier de log :

# Générer un événement de test
logger -p auth.info "Test authlog rsyslog"

# Vérifier le contenu du fichier
cat /var/log/authlog

Résultat attendu après une connexion SSH :

Dec 30 15:56:19 localhost sshd-session[1806]: Accepted password for adminweb from 192.168.10.196 port 61140 ssh2
Dec 30 15:56:22 localhost sudo: adminweb : TTY=pts/2 ; PWD=/home/adminweb ; USER=root ; COMMAND=/usr/bin/su -
Dec 30 15:56:22 localhost su: 'su root' succeeded for adminweb on /dev/pts/2

Format des logs

Les logs rsyslog utilisent un format texte simple, facile à parser :

• Connexion réussie : Accepted password for USER from IP port PORT ssh2
• Échec de connexion : Failed password for USER from IP port PORT ssh2
• Utilisateur invalide : Invalid user USER from IP port PORT
• Élévation su : 'su root' succeeded for USER on TTY

Méthode 2 : auditd (BSM)

Présentation

OmniOS hérite du système d'audit BSM (Basic Security Module) de Solaris. Ce système offre un audit de sécurité complet avec des informations très détaillées sur chaque événement. Les logs sont stockés au format binaire dans /var/audit/ et doivent être lus avec la commande praudit.

Vérification de l'état initial

# Vérifier le service auditd
svcs auditd

# Vérifier la condition d'audit
auditconfig -getcond

# Résultat par défaut :
audit condition = noaudit

Configuration des classes d'audit

Vérifier que la classe lo (login/logout) est configurée :

# Voir les flags d'audit configurés
auditconfig -getflags

# Résultat attendu :
active user default audit flags = lo(0x1000,0x1000)
configured user default audit flags = lo(0x1000,0x1000)

# Voir les classes disponibles
cat /etc/security/audit_class | grep -E "^0x"

Classes d'audit principales :

• lo (0x00001000) : login or logout
• as (0x00020000) : system-wide administration
• ua (0x00040000) : user administration
• ex (0x40000000) : exec
• all (0xffffffff) : toutes les classes

Activation du service auditd

# Activer le service auditd
svcadm enable auditd

# Vérifier le statut
svcs auditd

# Vérifier que l'audit est actif
auditconfig -getcond

# Résultat attendu :
audit condition = auditing

Lecture des logs d'audit

Les logs sont stockés au format binaire et doivent être convertis avec praudit :

# Voir les fichiers d'audit
ls -la /var/audit/

# Lire tous les logs d'audit
praudit /var/audit/*

# Filtrer sur les événements de connexion
praudit /var/audit/* | grep -i -E "ssh|login|subject"

Exemple de sortie :

header,97,2,login - ssh,,localhost,2025-12-30 16:08:12.809 +01:00
subject,adminweb,adminweb,other,adminweb,other,0,2244675411,0 0 0.0.0.0
return,success,0

header,81,2,su,,localhost,2025-12-30 16:08:18.112 +01:00
subject,adminweb,root,root,root,root,1971,2666542011,13883 163315 192.168.10.196
return,success,0

Commandes utiles auditconfig

• auditconfig -getcond : Vérifier si l'audit est actif
• auditconfig -getflags : Voir les classes auditées
• auditconfig -setflags lo,as : Définir les classes à auditer
• auditconfig -getplugin : Voir les plugins actifs
• auditconfig -lsevent : Lister tous les événements
• auditconfig -lsevent | grep ssh : Chercher un événement

Comparaison des deux méthodes

Recommandation

Il est recommandé d'activer les deux méthodes en fonction de l'usage souhaité :

• rsyslog : Pour les scripts de sécurité (détection d'intrusion, blocage IP)
• auditd : Pour l'audit de conformité et l'analyse forensique

Les deux systèmes fonctionnent indépendamment et ne créent pas de conflit.

Résumé des commandes

Activation rsyslog

cat << 'EOF' > /etc/rsyslog.d/authlog.conf
auth.* /var/log/authlog
authpriv.* /var/log/authlog
EOF
svcadm restart system-log:rsyslog

Activation auditd

svcadm enable auditd
auditconfig -getcond

Conclusion

L'activation des logs d'authentification est une étape essentielle pour sécuriser un serveur OmniOS CE. Que ce soit via rsyslog pour sa simplicité ou auditd pour sa richesse d'information, ces logs permettent de détecter les tentatives d'intrusion et de mettre en place des mécanismes de protection automatisés.

Une fois les logs activés, il devient possible d'implémenter des solutions de type fail2ban pour bloquer automatiquement les adresses IP malveillantes.