Relayd : Journalisation (Log)

Article publié, le 17 Mai 2020 et modifié le 10 Novembre 2025
4 minutes de lecture

Cet article contient 800 mots.
Source brute de l'article :
Commit version : beb80d0

Description

OpenBSD intègre par défaut dans le système de base, depuis 5.7, le serveur de relais nommé relayd.

Site web : https://bsd.plumbing/
OpenBSD : 6.6, 6.7

Le but de cet article est de savoir comment mettre en place une journalisation du flux HTTP(S) qui passe au-travers de relayd.

C’est très simple !

Configuration

Par défault, le fichier de configuration : /etc/relayd.conf

Configuration Globale

Dans un premier temps, nous devons déclarer le paramètre global log dans le fichier de configuration de relayd. relayd.conf(5)#log

Les déclarations de journal suivantes ont pour signification les suivantes :

log state changes ou log host checks sont utiles pour suivre l’état de l’hôte ou les contrôles effectués dessus.
- les états peuvent être de type :
  - up si l’état de santé de l’hôte est positif
  - down si celui est arrété ou si les contrôles ne sont pas bons.
  - en état unknown si l’hôte est désactivé ou n’a pas encore été contrôlé.
log connection nous permet de journaliser les connexions TCP, si relayd est configuré en tant que relai(s) ¹. À noter l’ajout de l’option errors pour le cas où nous voulons journaliser que les erreurs de connexions TCP.

¹ En effet, relayd peut aussi être configuré en tant que routeur ou serveur de redirection.

Règles de filtrage

Toujours dans le contexte du fichier de configuration de relayd, les relais ont la possibilité de filtrer les connexions par le biais de paramètres de filtrage spécifiques.

Ainsi nous utiliserons l’action de correspondance match sur laquelle nous appliquons l’option de journalisation log. relayd.conf(5)#match
Cette action de correspondance s’appliquera sur un type d’action ; actuellement, 5 types d’actions sont définies :

cookie : une action qui a lieu sur un cookie. ² relayd.conf(5)#cookie
header : une action ciblant le protocol d’entête HTTP - les fameuses headers relayd.conf(5)#header
path : une action qui analyse le chemin de l’URL demandée. ² relayd.conf(5)#path
query : une action pour chercher la partie query de l’URL demandée. ² relayd.conf(5)#query
url : l’action récupérant l’URL complète… ² relayd.conf(5)#url

² seulement disponible sur une requête HTTP.

Exemple de configuration

L’exemple ci-dessous nous montre cinq règles de filtrage :

les quatre premières ayant lieu sur une correspondance d’entête
la dernière journalisant l’URL dans son ensemble.

### ips externe auth
ip4 = "addresse-ipv4-public"

### manage logs
log state changes
log connection
#log connection errors

http protocol "hw" {
    match header log "Host"
    match header log "X-Forwarded-For"
    match header log "User-Agent"
    match header log "Referer"
    match url log

    block

    (…)
}

relay "www" {
    listen on $ip4 port 80
    protocol hw
    forward to 127.0.0.1 port 80
}

Journaux

Là encore, tout simplement, une fois la configuration établie, validée, et le service relayd fonctionnel, les différents journaux se retrouvent principalement dans :

/var/log/daemon,
/var/log/message.

Exemple log daemon

:$ grep relayd /var/log/daemon
May 17 16:37:21 sh1 relayd[25237]: relay www, session 13 (2 active), 0, 192.168.1.1 -> :80, done
May 17 16:37:21 sh1 relayd[45869]: relay www, session 7 (2 active), 0, 192.168.1.1 -> :80, done
May 17 16:37:21 sh1 relayd[45869]: relay www, session 8 (1 active), 0, 192.168.1.1 -> :80, done
May 17 16:37:22 sh1 relayd[25237]: relay www, session 14 (1 active), 0, 192.168.1.1 -> :80, done
May 17 17:01:19 sh1 relayd[45869]: relay www, session 9 (1 active), 0, 207.180.140.98 -> :80, Forbidden (403 Forbidden), [<em>Stop scanning for PHP: none</em>!, User-Agent: polaris] GET: Invalid argument
May 17 17:01:19 sh1 relayd[45869]: relay www, session 10 (1 active), 0, 207.180.140.98 -> :80, done
May 17 17:02:43 sh1 relayd[7531]: relay www, session 13 (1 active), 0, 84.161.80.36 -> :80, Forbidden (403 Forbidden), [<em>Stop scanning for an admin interface: none</em>!, Host: 88.136.16.221] [<em>Stop scanning for an admin interface: none</em>!, User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36] [<em>Stop scanning for an admin interface: none</em>!, 88.136.16.221/phpmyadmin/] GET: Invalid argument

Cet exemple nous restitue :

des connexions réussies done
des connexions échouées, ici de type erreur 403, bloquées selon des règles de filtrage bloquantes block - non expliquées ici

Exemple log message

:$ grep relayd /var/log/messages
May 17 16:22:23 sh1 relayd[7531]: relay www, session 11 (1 active), 0, 37.49.230.25 -> :80, Forbidden (403 Forbidden), [<em>Stop scanning for PHP: none</em>!, User-Agent: Uirusu/2.0] GET: Invalid argument
May 17 17:01:19 sh1 relayd[45869]: relay www, session 9 (1 active), 0, 207.180.140.98 -> :80, Forbidden (403 Forbidden), [<em>Stop scanning for PHP: none</em>!, User-Agent: polaris] GET: Invalid argument
May 17 17:02:43 sh1 relayd[7531]: relay www, session 13 (1 active), 0, 84.161.80.36 -> :80, Forbidden (403 Forbidden), [<em>Stop scanning for an admin interface: none</em>!, Host: 88.136.16.221] [<em>Stop scanning for an admin interface: none</em>!, User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36] [<em>Stop scanning for an admin interface: none</em>!, 88.136.16.221/phpmyadmin/] GET: Invalid argument

Cet exemple nous montre 3 écritures de journalisation de règles bloquantes, provoquant une erreur 403, sur des critères de filtrage non expliqués ici.

Documentations

Manpages

relayd.conf(5)