G DATA XDR

Réduction du trafic réseau grâce à la mise en cache des mises à jour avec HAProxy

Introduction

Cet article décrit comment réduire le trafic réseau entre les G DATA Agents et le service backend G DATA. Pour cela, une instance HAProxy exécutée localement stocke temporairement en cache les fichiers de mise à jour téléchargés via le port 80. La comparaison préalable de la liste des fichiers et des valeurs de hachage n’est pas concernée : elle s’effectue indépendamment via le port 443 et n’est pas mise en cache.

Un proxy de cache présente l’avantage de réduire le volume de données téléchargées côté client. Les mises à jour ne sont téléchargées qu’une seule fois depuis Internet, puis distribuées localement à tous les agents du réseau.

Cet article s’adresse principalement aux équipes d’administration disposant de connaissances en Linux et en réseaux. Les termes techniques sont également brièvement expliqués, afin de permettre aux personnes sans connaissances informatiques approfondies de suivre la procédure.

Notions de base : qu’est-ce que HAProxy et à quoi sert un proxy de cache ?

Lorsque de nombreux G DATA Agents fonctionnent sur le même réseau, chaque Agent télécharge normalement individuellement les mises à jour des signatures et du programme directement depuis Internet, à partir du serveur de mise à jour G DATA. Pour cent terminaux, cela représente cent téléchargements identiques sur votre connexion Internet.

Un proxy est un intermédiaire entre les G DATA Agents et le service backend G DATA. Un cache est un espace de stockage temporaire. La première requête portant sur un fichier de mise à jour est transmise normalement vers Internet. La réponse est également enregistrée localement. Toute requête ultérieure portant sur le même fichier reçoit une réponse directement depuis ce stockage local. La connexion Internet n’est donc pas sollicitée à nouveau.

HAProxy est un logiciel open source largement utilisé. Il assure cette fonction de manière fiable en tant que proxy TCP/HTTP avec fonction de mise en cache.

Prérequis

Un serveur Linux (par exemple Debian/Ubuntu) sur le réseau. Tous les G DATA Agents doivent pouvoir accéder à ce serveur.
Des droits root ou sudo sur ce serveur.
Un certificat TLS valide, avec sa chaîne de certificats. Il doit être valable pour le nom d’hôte utilisé par les agents pour accéder au proxy via HTTPS (requêtes d’index et de métadonnées).
Autorisations réseau nécessaires :
- Le serveur proxy doit pouvoir accéder au serveur de mise à jour G DATA agent-update-server.gdatasecurity.de. Deux ports sont nécessaires : le port HTTPS 443 et le port HTTP 80.
- Les G DATA Agents doivent également pouvoir accéder au serveur proxy via le port HTTPS 443 et le port HTTP 80.
Des connaissances de base sur les fichiers de configuration HAProxy sont utiles, même si cette documentation fournit un modèle prêt à l’emploi.

Accessibilité du Cloud G DATA

Afin de garantir un signalement fiable et en temps utile des événements et des incidents, le cloud G DATA doit être accessible et ne doit pas être bloqué par un pare-feu. Les paramètres ci-dessous sont requis à cet effet. Il doit être garanti que *.gdatasecurity.de et *.gdatasoftware.com peuvent être résolus par le DNS et sont accessibles.

Ouvertures de ports
- Chaque Agent G DATA sur les points de terminaison doit pouvoir atteindre les adresses IP de nos serveurs backend via le port TCP/443, plage d’adresses IP 194.156.84.0/22 (194.156.84.0 - 194.156.87.255).
Protocoles
- Les systèmes doivent pouvoir communiquer via les protocoles HTTPS:// ainsi que WSS://.
TLS
- Les serveurs proxy utilisés doivent prendre en charge au minimum TLS 1.2.
- Aucune inspection SSL ni inspection approfondie des paquets (Deep Packet Inspection) ne doit être en place.
- Une connexion chiffrée TLS doit pouvoir être établie avec chess.gdatasecurity.de. Un certificat racine correspondant doit être disponible pour cela.

Configuration de HAProxy

Étape 1 : installer HAProxy

Installez HAProxy à l’aide du gestionnaire de paquets de votre distribution Linux, par exemple sous Debian/Ubuntu :

sudo apt update
sudo apt install haproxy

Étape 2 : préparer le certificat

HAProxy assure la terminaison de la connexion TLS des agents. Pour cela, il nécessite un certificat et la clé privée correspondante.

HAProxy attend le certificat, la chaîne de certificats et la clé privée dans un seul fichier PEM, assemblés dans cet ordre. Les différents composants sont les suivants :

Ordre	Composant
1	Le certificat proprement dit (certificat du serveur).
2	Les certificats intermédiaires, également appelés Bundle ou Chain.
3	Le certificat de l’autorité de certification racine, s’il est disponible séparément.
4	La clé privée.

Assemblez les fichiers dans un fichier PEM en respectant exactement cet ordre. Exemple :

cat server.crt intermediate.crt root-ca.crt server.key > /etc/haproxy/certs/haproxy-cache.pem
chmod 640 /etc/haproxy/certs/haproxy-cache.pem
chown root:haproxy /etc/haproxy/certs/haproxy-cache.pem

Étape 3 : créer la configuration HAProxy

Créez le fichier de configuration haproxy.cfg dans /etc/haproxy/. Utilisez le modèle ci-dessous (voir Exemple de configuration complète). Remplacez tout fichier existant par ce modèle.

Adaptez les espaces réservés suivants :

Espace réservé	Signification
{{ haproxy_caching_bind }}	L’adresse IP sur laquelle HAProxy écoute. Il s’agit de l’adresse IP utilisée par les agents pour accéder au proxy.
{{ haproxy_caching_server_cert }}	Le chemin complet du fichier de certificat PEM de l’étape 2, par exemple /etc/haproxy/certs/haproxy-cache.pem.
{{ haproxy_caching_server }}	Le nom d’hôte interne utilisé par les agents pour accéder au serveur de cache. Ce nom est attendu dans l’en-tête Host.

Espace réservé

Signification

{{ haproxy_caching_bind }}

L’adresse IP sur laquelle HAProxy écoute. Il s’agit de l’adresse IP utilisée par les agents pour accéder au proxy.

{{ haproxy_caching_server_cert }}

Le chemin complet du fichier de certificat PEM de l’étape 2, par exemple /etc/haproxy/certs/haproxy-cache.pem.

{{ haproxy_caching_server }}

Le nom d’hôte interne utilisé par les agents pour accéder au serveur de cache. Ce nom est attendu dans l’en-tête Host.

Étape 4 : démarrer ou redémarrer HAProxy

Redémarrez le service après avoir créé ou modifié la configuration :

sudo systemctl restart haproxy
sudo systemctl enable haproxy

Étape 5 (facultative) : vérifier la configuration

Vérifiez la syntaxe du fichier de configuration avant de redémarrer HAProxy. Vous pourrez ainsi détecter les erreurs de saisie au plus tôt :

haproxy -c -f /etc/haproxy/haproxy.cfg

Si la vérification ne détecte aucune erreur, le message Configuration file is valid s’affiche.

Exemple de configuration complète

Le fichier haproxy.cfg suivant sert de modèle. Remplacez les trois espaces réservés. Leur signification est expliquée dans Configuration de HAProxy.

global
  log /dev/log  sample 1:10 local0
  log /dev/log  sample 1:10 local1 notice
  chroot /var/lib/haproxy
  stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
  stats timeout 30s
  user haproxy
  group haproxy
  daemon
  maxconn                     256000
  hard-stop-after             15m
  tune.ssl.default-dh-param   2048

defaults
  log     global
  mode    http
  option  httplog
  option  dontlognull
  option  http-keep-alive
  option  forwardfor
  timeout     http-request 10s
  timeout     queue 1m
  timeout     connect 10s
  timeout     client 20s
  timeout     server 20s
  timeout     http-keep-alive 10s
  timeout     check 10s
  errorfile 400 /etc/haproxy/errors/400.http
  errorfile 403 /etc/haproxy/errors/403.http
  errorfile 408 /etc/haproxy/errors/408.http
  errorfile 500 /etc/haproxy/errors/500.http
  errorfile 502 /etc/haproxy/errors/502.http
  errorfile 503 /etc/haproxy/errors/503.http
  errorfile 504 /etc/haproxy/errors/504.http

frontend stats
  bind {{ haproxy_caching_bind }}:8404 ssl crt {{ haproxy_caching_server_cert }} alpn h2,http/1.1
  stats enable
  stats uri /
  stats refresh 10s
  http-request set-log-level silent
  http-request use-service prometheus-exporter if { path /metrics }

# ---------------------------------------------------------------------------
# Port 80 (HTTP) : téléchargement des fichiers proprement dit - la mise en cache a lieu ICI.
# ---------------------------------------------------------------------------
frontend http_update_server
  bind {{ haproxy_caching_bind }}:80
  acl is_update_download path_beg /api/v2/update/download/
  acl is_caching_host req.hdr(host) -i {{ haproxy_caching_server }}
  http-request set-header X-Forwarded-Host %[req.hdr(Host)]
  http-request set-header Host %[req.hdr(Host)]
  # Seules les requêtes de téléchargement vers le nom d’hôte connu sont traitées avec mise en cache.
  use_backend http_update_server_backend if is_update_download is_caching_host
  # Par sécurité, rediriger toutes les autres requêtes sur le port 80 vers HTTPS.
  http-request redirect scheme https code 301 unless is_update_download
  default_backend nomatch

# ---------------------------------------------------------------------------
# Port 443 (HTTPS) : comparaison des index et des hachages - simple transmission SANS mise en cache.
# Ces réponses sont de petite taille, changent fréquemment et G DATA
# ne prévoit volontairement pas leur mise en cache.
# ---------------------------------------------------------------------------
frontend https_update_server
  bind {{ haproxy_caching_bind }}:443 ssl crt {{ haproxy_caching_server_cert }} alpn h2,http/1.1
  http-request set-header X-Forwarded-Host %[req.hdr(Host)]
  http-request set-header Host %[req.hdr(Host)]
  use_backend https_update_server_backend if { req.hdr(host) -i {{ haproxy_caching_server }} }
  default_backend nomatch

cache objectcache_update_server
  total-max-size 3000
  max-object-size 200000000
  max-age 86400

backend http_update_server_backend
  balance roundrobin
  http-request set-header Connection keep-alive
  http-request set-header Host agent-update-server.gdatasecurity.de
  http-request set-header X-Forwarded-Proto http
  http-request cache-use objectcache_update_server if { path_beg /api/v2/update/download/ }
  http-response cache-store objectcache_update_server
  option httpchk GET /api/status
  http-check send hdr Host agent-update-server.gdatasecurity.de
  http-check expect status 200
  server agent-update-server.gdatasecurity.de agent-update-server.gdatasecurity.de:80 check inter 10s

backend https_update_server_backend
  balance roundrobin
  http-request set-header Connection keep-alive
  http-request set-header Host agent-update-server.gdatasecurity.de
  http-request set-header X-Forwarded-Proto https
  option httpchk GET /api/status
  http-check send hdr Host agent-update-server.gdatasecurity.de
  http-check expect status 200
  server agent-update-server.gdatasecurity.de agent-update-server.gdatasecurity.de:443 check inter 10s check-sni agent-update-server.gdatasecurity.de sni str(agent-update-server.gdatasecurity.de) ssl verify required ca-file /etc/ssl/certs/ca-certificates.crt

backend nomatch
  errorfile 503 /etc/haproxy/errors/503.http

Explication de la configuration

Les principales sections sont expliquées individuellement ci-dessous. Ces explications permettent également aux personnes ayant moins d’expérience avec HAProxy de comprendre la configuration.

Section	Explication
global / defaults	Paramètres de base des processus et des connexions. Exemples : journalisation, nombre maximal de connexions simultanées (maxconn), délais d’expiration par défaut. En règle générale, vous n’avez pas à modifier ces valeurs.
frontend stats	Met à disposition une page d’état sur le port 8404. Cette page permet de surveiller l’état de HAProxy, notamment au format Prometheus (/metrics).
frontend http_update_server	Le point d’entrée des téléchargements de fichiers proprement dits sur le port 80. Seules les requêtes sous le chemin /api/v2/update/download/ adressées au nom d’hôte connu sont transmises au backend assurant la mise en cache. Toutes les autres requêtes sur le port 80 sont redirigées vers HTTPS par sécurité.
frontend https_update_server	Le point d’entrée des comparaisons d’index et de hachages sur le port 443 (TLS). HAProxy vérifie ici que le nom d’hôte demandé ({{ haproxy_caching_server }}) correspond au backend de mise à jour. HAProxy ne transmet la requête que dans ce cas. Dans le cas contraire, la requête est envoyée au backend nomatch et reçoit l’erreur 503. Aucune mise en cache n’a lieu à cet endroit.
cache objectcache_update_server	Définit le cache. Trois valeurs sont importantes : la taille totale maximale du cache (total-max-size, en Mo), la taille maximale d’un fichier (max-object-size, en octets) et la durée maximale de conservation d’un objet dans le cache (max-age, en secondes). Le modèle utilise une taille totale d’environ 3 Go, jusqu’à 200 Mo par fichier et une durée de validité de 24 heures. Seul le backend HTTP utilise ce cache.
backend http_update_server_backend	Transmet les requêtes de téléchargement sans chiffrement (port 80) à agent-update-server.gdatasecurity.de. La ligne http-request cache-use … if { path_beg /api/v2/update/download/ } garantit que seul ce chemin fait l’objet d’une mise en cache. Le http-check vérifie en continu que le serveur G DATA est accessible.
backend https_update_server_backend	Transmet les requêtes d’index et de hachages de manière chiffrée (port 443, avec vérification du certificat) au même serveur G DATA. Ce backend ne contient ni cache-use ni cache-store. Les réponses sont transmises, mais ne sont pas enregistrées.
backend nomatch	Intercepte toutes les requêtes qui ne correspondent à aucun hôte connu. Ces requêtes reçoivent l’erreur 503. La configuration empêche ainsi une utilisation abusive en tant que proxy ouvert.

Section

Explication

global / defaults

Paramètres de base des processus et des connexions. Exemples : journalisation, nombre maximal de connexions simultanées (maxconn), délais d’expiration par défaut. En règle générale, vous n’avez pas à modifier ces valeurs.

frontend stats

Met à disposition une page d’état sur le port 8404. Cette page permet de surveiller l’état de HAProxy, notamment au format Prometheus (/metrics).

frontend http_update_server

Le point d’entrée des téléchargements de fichiers proprement dits sur le port 80. Seules les requêtes sous le chemin /api/v2/update/download/ adressées au nom d’hôte connu sont transmises au backend assurant la mise en cache. Toutes les autres requêtes sur le port 80 sont redirigées vers HTTPS par sécurité.

frontend https_update_server

Le point d’entrée des comparaisons d’index et de hachages sur le port 443 (TLS). HAProxy vérifie ici que le nom d’hôte demandé ({{ haproxy_caching_server }}) correspond au backend de mise à jour. HAProxy ne transmet la requête que dans ce cas. Dans le cas contraire, la requête est envoyée au backend nomatch et reçoit l’erreur 503. Aucune mise en cache n’a lieu à cet endroit.

cache objectcache_update_server

Définit le cache. Trois valeurs sont importantes : la taille totale maximale du cache (total-max-size, en Mo), la taille maximale d’un fichier (max-object-size, en octets) et la durée maximale de conservation d’un objet dans le cache (max-age, en secondes). Le modèle utilise une taille totale d’environ 3 Go, jusqu’à 200 Mo par fichier et une durée de validité de 24 heures. Seul le backend HTTP utilise ce cache.

backend http_update_server_backend

Transmet les requêtes de téléchargement sans chiffrement (port 80) à agent-update-server.gdatasecurity.de. La ligne http-request cache-use … if { path_beg /api/v2/update/download/ } garantit que seul ce chemin fait l’objet d’une mise en cache. Le http-check vérifie en continu que le serveur G DATA est accessible.

backend https_update_server_backend

Transmet les requêtes d’index et de hachages de manière chiffrée (port 443, avec vérification du certificat) au même serveur G DATA. Ce backend ne contient ni cache-use ni cache-store. Les réponses sont transmises, mais ne sont pas enregistrées.

backend nomatch

Intercepte toutes les requêtes qui ne correspondent à aucun hôte connu. Ces requêtes reçoivent l’erreur 503. La configuration empêche ainsi une utilisation abusive en tant que proxy ouvert.

HAProxy met uniquement en cache les requêtes sous le chemin /api/v2/update/download/ via HTTP. Les requêtes d’index et de hachages via HTTPS continuent à être transmises sans modification. Les autres communications des agents, par exemple la télémétrie ou les alertes envoyées au service backend XDR, ne sont pas concernées par la mise en cache.

Reconfigurer les agents pour utiliser le serveur de cache

Si vous avez déjà installé les G DATA Agents sur les terminaux, contactez le support technique au +49 234 9762-901. L’équipe du support reconfigurera vos G DATA Agents.

Si vous n’avez pas encore déployé de G DATA Agents, créez une configuration d’installation en indiquant l’adresse du proxy. Tous les terminaux installés avec le SetupID correspondant recevront leurs mises à jour via votre proxy.

Vérifiez impérativement que la configuration fonctionne. Les terminaux qui ne reçoivent pas de mises à jour présentent un risque de sécurité. Laissez impérativement le serveur de secours activé dans la configuration (il ne doit être désactivé que dans des cas exceptionnels justifiés). Lorsque le serveur de secours est activé, vos terminaux continuent à recevoir des mises à jour lorsqu’ils quittent le réseau (par exemple les ordinateurs portables) ou en cas de défaillance de votre serveur proxy inverse.

Dépannage

Symptôme	Procédure
HAProxy ne démarre pas	Vérifiez la configuration avec haproxy -c -f /etc/haproxy/haproxy.cfg. Vérifiez également l’état du service avec systemctl status haproxy et journalctl -u haproxy.
Les agents reçoivent des erreurs de certificat	Vérifiez deux points : le fichier PEM contient-il le certificat, les certificats intermédiaires et la clé privée dans le bon ordre ? Le nom d’hôte du certificat correspond-il à {{ haproxy_caching_server }} ?
Aucune réduction du trafic Internet n’est constatée	Vérifiez sur la page d’état (frontend stats, port 8404) que les requêtes de téléchargement passent par le backend http_update_server_backend et que des requêtes y sont servies depuis le cache. Le backend https_update_server_backend n’effectue volontairement aucune mise en cache.
Les requêtes aboutissent au backend nomatch	L’en-tête Host de la requête entrante ne correspond pas à {{ haproxy_caching_server }}. Vérifiez la configuration des agents et la résolution DNS.

Symptôme

Procédure

HAProxy ne démarre pas

Vérifiez la configuration avec haproxy -c -f /etc/haproxy/haproxy.cfg. Vérifiez également l’état du service avec systemctl status haproxy et journalctl -u haproxy.

Les agents reçoivent des erreurs de certificat

Vérifiez deux points : le fichier PEM contient-il le certificat, les certificats intermédiaires et la clé privée dans le bon ordre ? Le nom d’hôte du certificat correspond-il à {{ haproxy_caching_server }} ?

Aucune réduction du trafic Internet n’est constatée

Vérifiez sur la page d’état (frontend stats, port 8404) que les requêtes de téléchargement passent par le backend http_update_server_backend et que des requêtes y sont servies depuis le cache. Le backend https_update_server_backend n’effectue volontairement aucune mise en cache.

Les requêtes aboutissent au backend nomatch

L’en-tête Host de la requête entrante ne correspond pas à {{ haproxy_caching_server }}. Vérifiez la configuration des agents et la résolution DNS.