G DATA XDR

Riduzione del traffico di rete mediante caching degli aggiornamenti con HAProxy

Introduzione

Questo articolo descrive come ridurre il traffico di rete tra gli G DATA Agent e il backend G DATA. A tale scopo, un’istanza di HAProxy eseguita localmente memorizza nella cache i download effettivi dei file di aggiornamento tramite la porta 80. Il confronto preliminare dell’elenco dei file e dei valori hash non è interessato: viene eseguito in modo indipendente tramite la porta 443 e non viene memorizzato nella cache.

Un proxy con funzione di caching offre il vantaggio di ridurre il volume di dati scaricati dal cliente. Gli aggiornamenti vengono scaricati una sola volta da Internet e successivamente distribuiti localmente a tutti gli Agent della rete.

Questo articolo è rivolto principalmente a chi amministra sistemi e dispone di conoscenze di Linux e delle reti. I termini tecnici vengono inoltre spiegati brevemente, in modo che anche chi non possiede conoscenze informatiche approfondite possa seguire la procedura.

Informazioni di base: che cos’è HAProxy e che cosa fa un proxy con funzione di caching?

Quando molti G DATA Agent sono in esecuzione nella stessa rete, normalmente ogni Agent scarica singolarmente gli aggiornamenti delle firme di sicurezza e del programma direttamente da Internet, dal server di aggiornamento G DATA. Con cento endpoint, questo significa cento download identici attraverso la propria connessione Internet.

Un proxy è un intermediario tra gli G DATA Agent e il backend G DATA. Una cache è una memoria temporanea. La prima richiesta di un file di aggiornamento viene inoltrata normalmente a Internet. La risposta viene anche salvata localmente. Ogni successiva richiesta dello stesso file riceve una risposta direttamente da questa memoria locale. La connessione Internet non viene quindi utilizzata nuovamente.

HAProxy è un software open source molto diffuso. Svolge questa funzione in modo affidabile come proxy TCP/HTTP con funzione di caching.

Prerequisiti

Un server Linux (ad es. Debian/Ubuntu) nella rete. Tutti gli G DATA Agent devono poter raggiungere questo server.
Privilegi root o sudo su questo server.
Un certificato TLS valido, comprensivo della catena di certificati. Deve essere valido per il nome host con cui gli Agent accedono al proxy tramite HTTPS (richieste di indici e metadati).
Autorizzazioni di accesso alla rete:
- Il server proxy deve poter raggiungere il server di aggiornamento G DATA agent-update-server.gdatasecurity.de. Sono necessarie due porte: la porta HTTPS 443 e la porta HTTP 80.
- Anche gli G DATA Agent devono poter raggiungere il server proxy tramite la porta HTTPS 443 e la porta HTTP 80.
È utile disporre di conoscenze di base sull’utilizzo dei file di configurazione HAProxy, anche se questa documentazione fornisce un modello pronto all’uso.

Raggiungibilità del Cloud G DATA

Per garantire la segnalazione affidabile e tempestiva di eventi e incidenti, il cloud G DATA deve essere raggiungibile e non deve essere bloccato da un firewall. A tal fine sono necessarie le impostazioni elencate di seguito. È necessario assicurarsi che *.gdatasecurity.de e *.gdatasoftware.com possano essere risolti e siano raggiungibili.

Aperture delle porte
- Gli Agent G DATA sugli endpoint devono poter raggiungere gli IP dei nostri server backend tramite la porta TCP/443, intervallo IP 194.156.84.0/22 (194.156.84.0 - 194.156.87.255).
Protocolli
- I sistemi devono poter comunicare tramite i protocolli HTTPS:// e anche WSS://.
TLS
- I server proxy utilizzati devono supportare almeno TLS 1.2.
- Non deve essere presente alcuna SSL Inspection o Deep Packet Inspection.
- Deve essere possibile stabilire una connessione cifrata TLS con chess.gdatasecurity.de. A tal fine deve essere presente un certificato root corrispondente.

Configurazione di HAProxy

Passaggio 1: installare HAProxy

Installi HAProxy tramite il gestore pacchetti della Sua distribuzione Linux, ad esempio su Debian/Ubuntu:

sudo apt update
sudo apt install haproxy

Passaggio 2: preparare il certificato

HAProxy gestisce la terminazione della connessione TLS degli Agent. A tale scopo necessita di un certificato e della relativa chiave privata.

HAProxy richiede che certificato, catena di certificati e chiave privata siano contenuti in un unico file PEM, combinati in questo ordine. I singoli componenti sono:

Ordine	Componente
1	Il certificato vero e proprio (certificato del server).
2	I certificati intermedi, detti anche Bundle o Chain.
3	Il certificato della CA radice, se disponibile separatamente.
4	La chiave privata.

Unisca i file in un unico file PEM esattamente in questo ordine. Esempio:

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

Passaggio 3: creare la configurazione HAProxy

Crei il file di configurazione haproxy.cfg in /etc/haproxy/. Utilizzi a tale scopo il modello riportato di seguito (vedere Esempio di configurazione completa). Sostituisca un eventuale file esistente con questo modello.

Adatti i seguenti segnaposto:

Segnaposto	Significato
{{ haproxy_caching_bind }}	L’indirizzo IP su cui HAProxy è in ascolto. È l’IP tramite il quale gli Agent raggiungono il proxy.
{{ haproxy_caching_server_cert }}	Il percorso completo del file del certificato PEM del passaggio 2, ad es. /etc/haproxy/certs/haproxy-cache.pem.
{{ haproxy_caching_server }}	Il nome host interno con cui gli Agent accedono al server di caching. Questo nome deve essere presente nell’header Host.

Segnaposto

Significato

{{ haproxy_caching_bind }}

L’indirizzo IP su cui HAProxy è in ascolto. È l’IP tramite il quale gli Agent raggiungono il proxy.

{{ haproxy_caching_server_cert }}

Il percorso completo del file del certificato PEM del passaggio 2, ad es. /etc/haproxy/certs/haproxy-cache.pem.

{{ haproxy_caching_server }}

Il nome host interno con cui gli Agent accedono al server di caching. Questo nome deve essere presente nell’header Host.

Passaggio 4: avviare o riavviare HAProxy

Riavvii il servizio dopo aver creato o modificato la configurazione:

sudo systemctl restart haproxy
sudo systemctl enable haproxy

Passaggio 5 (facoltativo): verificare la configurazione

Verifichi la sintassi del file di configurazione prima di riavviare HAProxy. In questo modo potrà individuare tempestivamente gli errori di digitazione:

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

Se la verifica non rileva errori, viene visualizzato Configuration file is valid.

Esempio di configurazione completa

Il seguente file haproxy.cfg funge da modello. Sostituisca i tre segnaposto. Il significato dei segnaposto è riportato in Configurazione di 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 }

# ---------------------------------------------------------------------------
# Porta 80 (HTTP): download effettivo dei file - QUI avviene il caching.
# ---------------------------------------------------------------------------
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)]
  # Solo le richieste di download al nome host noto vengono servite dalla cache.
  use_backend http_update_server_backend if is_update_download is_caching_host
  # Reindirizzare per sicurezza tutte le altre richieste sulla porta 80 a HTTPS.
  http-request redirect scheme https code 301 unless is_update_download
  default_backend nomatch

# ---------------------------------------------------------------------------
# Porta 443 (HTTPS): verifica di indici/hash - semplice inoltro SENZA caching.
# Queste risposte sono piccole, cambiano spesso e G DATA
# le esclude intenzionalmente dal caching.
# ---------------------------------------------------------------------------
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

Spiegazione della configurazione

Le sezioni principali vengono spiegate singolarmente di seguito. In questo modo, anche chi ha meno esperienza con HAProxy può comprendere la configurazione.

Sezione	Spiegazione
global / defaults	Impostazioni di base dei processi e delle connessioni. Esempi: registrazione dei log, numero massimo di connessioni simultanee (maxconn), timeout predefiniti. Di norma non è necessario modificare questi valori.
frontend stats	Mette a disposizione una pagina di stato sulla porta 8404. Tramite questa pagina è possibile monitorare lo stato di HAProxy, anche in formato Prometheus (/metrics).
frontend http_update_server	Il punto di ingresso per i download effettivi dei file sulla porta 80. Solo le richieste sotto il percorso /api/v2/update/download/ dirette al nome host noto vengono inoltrate al backend con funzione di caching. Tutte le altre richieste sulla porta 80 vengono reindirizzate a HTTPS per sicurezza.
frontend https_update_server	Il punto di ingresso per le verifiche degli indici e dei valori hash sulla porta 443 (TLS). Qui HAProxy verifica se il nome host richiesto ({{ haproxy_caching_server }}) corrisponde al backend di aggiornamento. Solo in questo caso HAProxy inoltra la richiesta. In caso contrario, la richiesta viene indirizzata al backend nomatch e riceve l’errore 503. In questo punto non viene eseguito alcun caching.
cache objectcache_update_server	Definisce la memoria cache. Sono importanti tre valori: la dimensione massima complessiva della cache (total-max-size, in MB), la dimensione massima di un singolo file (max-object-size, in byte) e il tempo massimo di permanenza di un oggetto nella cache (max-age, in secondi). Il modello utilizza una dimensione complessiva di circa 3 GB, fino a 200 MB per file e una validità di 24 ore. Solo il backend HTTP utilizza questa cache.
backend http_update_server_backend	Inoltra le richieste di download senza crittografia (porta 80) a agent-update-server.gdatasecurity.de. La riga http-request cache-use … if { path_beg /api/v2/update/download/ } garantisce che venga memorizzato nella cache solo questo percorso. Il controllo http-check verifica continuamente se il server G DATA è raggiungibile.
backend https_update_server_backend	Inoltra le richieste di indici e valori hash in forma crittografata (porta 443, con verifica del certificato) allo stesso server G DATA. Questo backend non contiene né cache-use né cache-store. Le risposte vengono inoltrate, ma non memorizzate.
backend nomatch	Intercetta tutte le richieste che non corrispondono ad alcun host noto. Queste richieste ricevono l’errore 503. In questo modo la configurazione impedisce l’uso improprio come proxy aperto.

Sezione

Spiegazione

global / defaults

Impostazioni di base dei processi e delle connessioni. Esempi: registrazione dei log, numero massimo di connessioni simultanee (maxconn), timeout predefiniti. Di norma non è necessario modificare questi valori.

frontend stats

Mette a disposizione una pagina di stato sulla porta 8404. Tramite questa pagina è possibile monitorare lo stato di HAProxy, anche in formato Prometheus (/metrics).

frontend http_update_server

Il punto di ingresso per i download effettivi dei file sulla porta 80. Solo le richieste sotto il percorso /api/v2/update/download/ dirette al nome host noto vengono inoltrate al backend con funzione di caching. Tutte le altre richieste sulla porta 80 vengono reindirizzate a HTTPS per sicurezza.

frontend https_update_server

Il punto di ingresso per le verifiche degli indici e dei valori hash sulla porta 443 (TLS). Qui HAProxy verifica se il nome host richiesto ({{ haproxy_caching_server }}) corrisponde al backend di aggiornamento. Solo in questo caso HAProxy inoltra la richiesta. In caso contrario, la richiesta viene indirizzata al backend nomatch e riceve l’errore 503. In questo punto non viene eseguito alcun caching.

cache objectcache_update_server

Definisce la memoria cache. Sono importanti tre valori: la dimensione massima complessiva della cache (total-max-size, in MB), la dimensione massima di un singolo file (max-object-size, in byte) e il tempo massimo di permanenza di un oggetto nella cache (max-age, in secondi). Il modello utilizza una dimensione complessiva di circa 3 GB, fino a 200 MB per file e una validità di 24 ore. Solo il backend HTTP utilizza questa cache.

backend http_update_server_backend

Inoltra le richieste di download senza crittografia (porta 80) a agent-update-server.gdatasecurity.de. La riga http-request cache-use … if { path_beg /api/v2/update/download/ } garantisce che venga memorizzato nella cache solo questo percorso. Il controllo http-check verifica continuamente se il server G DATA è raggiungibile.

backend https_update_server_backend

Inoltra le richieste di indici e valori hash in forma crittografata (porta 443, con verifica del certificato) allo stesso server G DATA. Questo backend non contiene né cache-use né cache-store. Le risposte vengono inoltrate, ma non memorizzate.

backend nomatch

Intercetta tutte le richieste che non corrispondono ad alcun host noto. Queste richieste ricevono l’errore 503. In questo modo la configurazione impedisce l’uso improprio come proxy aperto.

HAProxy memorizza nella cache solo le richieste sotto il percorso /api/v2/update/download/ tramite HTTP. Le richieste di indici e valori hash tramite HTTPS continuano a essere inoltrate senza modifiche. Gli altri canali di comunicazione degli Agent, ad esempio la telemetria o le segnalazioni al backend XDR, non sono interessati dal caching.

Riconfigurare gli Agent per utilizzare il server di caching

Se ha già installato gli G DATA Agent sugli endpoint, contatti il supporto tecnico al numero +49 234 9762-901. Il personale del supporto provvederà a riconfigurare i Suoi G DATA Agent.

Se non ha ancora distribuito alcun G DATA Agent, crei una configurazione di installazione specificando l’indirizzo del proxy. Tutti gli endpoint installati con il relativo SetupID riceveranno gli aggiornamenti tramite il Suo proxy.

Si assicuri di verificare che la configurazione funzioni. Gli endpoint che non ricevono aggiornamenti rappresentano un rischio per la sicurezza. Mantenga sempre attivo il server di fallback nella configurazione (deve essere disattivato solo in casi eccezionali giustificati). Con il server di fallback attivo, i Suoi endpoint ricevono gli aggiornamenti anche quando escono dalla rete (ad esempio i laptop) o quando il server reverse proxy non funziona.

Risoluzione dei problemi

Sintomo	Procedura
HAProxy non si avvia	Verifichi la configurazione con haproxy -c -f /etc/haproxy/haproxy.cfg. Controlli inoltre lo stato del servizio con systemctl status haproxy e journalctl -u haproxy.
Gli Agent ricevono errori del certificato	Verifichi due aspetti: il file PEM contiene certificato, certificati intermedi e chiave privata nell’ordine corretto? Il nome host nel certificato corrisponde a {{ haproxy_caching_server }}?
Non si rileva alcuna riduzione del traffico Internet	Verifichi tramite la pagina di stato (frontend stats, porta 8404) se le richieste di download passano attraverso il backend http_update_server_backend e se vengono trovate corrispondenze nella cache. Il backend https_update_server_backend non esegue intenzionalmente il caching.
Le richieste vengono indirizzate al backend nomatch	L’header Host della richiesta in ingresso non corrisponde a {{ haproxy_caching_server }}. Verifichi la configurazione degli Agent e la risoluzione DNS.

Sintomo

Procedura

HAProxy non si avvia

Verifichi la configurazione con haproxy -c -f /etc/haproxy/haproxy.cfg. Controlli inoltre lo stato del servizio con systemctl status haproxy e journalctl -u haproxy.

Gli Agent ricevono errori del certificato

Verifichi due aspetti: il file PEM contiene certificato, certificati intermedi e chiave privata nell’ordine corretto? Il nome host nel certificato corrisponde a {{ haproxy_caching_server }}?

Non si rileva alcuna riduzione del traffico Internet

Verifichi tramite la pagina di stato (frontend stats, porta 8404) se le richieste di download passano attraverso il backend http_update_server_backend e se vengono trovate corrispondenze nella cache. Il backend https_update_server_backend non esegue intenzionalmente il caching.

Le richieste vengono indirizzate al backend nomatch

L’header Host della richiesta in ingresso non corrisponde a {{ haproxy_caching_server }}. Verifichi la configurazione degli Agent e la risoluzione DNS.