G DATA XDR

Netwerkverkeer verminderen door updatecaching met HAProxy

Inleiding

Dit artikel beschrijft hoe u het netwerkverkeer tussen de G DATA Agents en de G DATA-backend vermindert. Hiervoor slaat een lokaal draaiende HAProxy de daadwerkelijke bestandsdownloads van updates tijdelijk op (caching) via poort 80. De voorafgaande vergelijking van de bestandslijst en hashwaarden valt hier niet onder. Deze wordt via poort 443 onafhankelijk uitgevoerd en niet gecachet.

Een cachingproxy heeft als voordeel dat de hoeveelheid gedownloade gegevens bij de klant afneemt. Updates worden slechts één keer van internet gedownload en vervolgens lokaal naar alle agents in het netwerk gedistribueerd.

Dit artikel is vooral bedoeld voor beheerders met kennis van Linux en netwerken. Technische vaktermen worden daarnaast kort uitgelegd. Zo kunnen ook lezers zonder diepgaande IT-kennis de stappen volgen.

Achtergrondinformatie: wat is HAProxy en wat doet een cachingproxy?

Als er veel G DATA Agents in hetzelfde netwerk draaien, downloadt normaal gesproken elke Agent afzonderlijk de malwarehandtekening- en programma-updates rechtstreeks via internet van de G DATA-updateserver. Bij honderd endpoints betekent dit honderd identieke downloads via uw internetverbinding.

Een proxy is een tussenpersoon tussen de G DATA Agents en de G DATA-backend. Een cache is een tijdelijke opslag. De eerste aanvraag voor een updatebestand wordt op de gebruikelijke manier doorgestuurd naar internet. Het antwoord wordt ook lokaal opgeslagen. Elke volgende aanvraag voor hetzelfde bestand wordt rechtstreeks vanuit deze lokale opslag beantwoord. De internetverbinding wordt daarbij niet opnieuw belast.

HAProxy is veelgebruikte opensourcesoftware die deze taak op betrouwbare wijze vervult als TCP/HTTP-proxy met cachingfunctie.

Vereisten

Een Linux-server (bijv. Debian/Ubuntu) in het netwerk. Alle G DATA Agents moeten deze server kunnen bereiken.
Root- of sudo-rechten op deze server.
Een geldig TLS-certificaat, inclusief certificaatketen. Het geldt voor de hostnaam waarmee de agents de proxy via HTTPS benaderen (index- en metadata-aanvragen).
Toegestane netwerkverbindingen:
- De proxyserver moet de G DATA-updateserver agent-update-server.gdatasecurity.de kunnen bereiken. Hiervoor zijn twee poorten nodig: HTTPS-poort 443 en HTTP-poort 80.
- De G DATA Agents moeten de proxyserver eveneens via HTTPS-poort 443 en HTTP-poort 80 kunnen bereiken.
Basiskennis van het werken met HAProxy-configuratiebestanden is nuttig, ook al biedt deze documentatie een kant-en-klaar sjabloon.

Bereikbaarheid van de G DATA Cloud

Om de betrouwbare en tijdige melding van gebeurtenissen en voorvallen te waarborgen, moet de G DATA Cloud bereikbaar zijn en mag deze niet door een firewall worden geblokkeerd. Hiervoor zijn de hieronder vermelde instellingen noodzakelijk. Er moet worden gewaarborgd dat *.gdatasecurity.de en *.gdatasoftware.com via DNS kunnen worden opgelost en bereikbaar zijn.

Poortopeningen
- De G DATA Agents op de eindpunten moeten de IP’s van onze backendservers via poort TCP/443, IP-Range 194.156.84.0/22 (194.156.84.0 - 194.156.87.255) kunnen bereiken.
Protocollen
- De systemen moeten via de protocollen HTTPS:// en ook WSS:// kunnen communiceren.
TLS
- Ingezette proxyservers moeten minimaal TLS 1.2 ondersteunen.
- Er mag geen SSL Inspection of Deep Packet Inspection aanwezig zijn.
- Er moet een met TLS versleutelde verbinding met chess.gdatasecurity.de kunnen worden opgezet. Hiervoor moet een overeenkomstig rootcertificaat aanwezig zijn.

HAProxy instellen

Stap 1: HAProxy installeren

Installeer HAProxy via de pakketbeheerder van uw Linux-distributie, bijvoorbeeld onder Debian/Ubuntu:

sudo apt update
sudo apt install haproxy

Stap 2: Certificaat voorbereiden

HAProxy beëindigt de TLS-verbinding van de agents. Hiervoor is een certificaat met de bijbehorende privésleutel nodig.

HAProxy verwacht het certificaat, de certificaatketen en de privésleutel in één PEM-bestand, gecombineerd in deze volgorde. De afzonderlijke onderdelen zijn:

Volgorde	Onderdeel
1	Het eigenlijke certificaat (servercertificaat).
2	De tussenliggende certificaten, ook wel Bundle of Chain genoemd.
3	Het root-CA-certificaat, indien afzonderlijk beschikbaar.
4	De privésleutel.

Voeg de bestanden in precies deze volgorde samen tot één PEM-bestand. Voorbeeld:

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

Stap 3: HAProxy-configuratie maken

Maak het configuratiebestand haproxy.cfg aan in /etc/haproxy/. Gebruik hiervoor het onderstaande sjabloon (zie Volledige voorbeeldconfiguratie). Vervang een bestaand bestand door dit sjabloon.

Pas daarbij de volgende placeholders aan:

Placeholder	Betekenis
{{ haproxy_caching_bind }}	Het IP-adres waarop HAProxy luistert. Dit is het IP-adres waarop de agents de proxy bereiken.
{{ haproxy_caching_server_cert }}	Het volledige pad naar het PEM-certificaatbestand uit stap 2, bijv. /etc/haproxy/certs/haproxy-cache.pem.
{{ haproxy_caching_server }}	De interne hostnaam waarmee de agents de cachingserver benaderen. Deze naam wordt in de Host-header verwacht.

Placeholder

Betekenis

{{ haproxy_caching_bind }}

Het IP-adres waarop HAProxy luistert. Dit is het IP-adres waarop de agents de proxy bereiken.

{{ haproxy_caching_server_cert }}

Het volledige pad naar het PEM-certificaatbestand uit stap 2, bijv. /etc/haproxy/certs/haproxy-cache.pem.

{{ haproxy_caching_server }}

De interne hostnaam waarmee de agents de cachingserver benaderen. Deze naam wordt in de Host-header verwacht.

Stap 4: HAProxy (opnieuw) starten

Start de service opnieuw nadat u de configuratie hebt aangemaakt of gewijzigd:

sudo systemctl restart haproxy
sudo systemctl enable haproxy

Stap 5 (optioneel): Configuratie controleren

Controleer de syntaxis van het configuratiebestand voordat u HAProxy opnieuw start. Zo spoort u typefouten vroegtijdig op:

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

Een controle zonder fouten geeft de melding Configuration file is valid.

Volledige voorbeeldconfiguratie

Het volgende bestand haproxy.cfg dient als sjabloon. Vervang de drie placeholders. De betekenis van de placeholders staat in HAProxy instellen.

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 }

# ---------------------------------------------------------------------------
# Poort 80 (HTTP): daadwerkelijke bestandsdownload - HIER vindt de caching plaats.
# ---------------------------------------------------------------------------
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)]
  # Alleen downloadaanvragen voor de bekende hostnaam worden vanuit de cache afgehandeld.
  use_backend http_update_server_backend if is_update_download is_caching_host
  # Alle andere aanvragen op poort 80 voor de zekerheid omleiden naar HTTPS.
  http-request redirect scheme https code 301 unless is_update_download
  default_backend nomatch

# ---------------------------------------------------------------------------
# Poort 443 (HTTPS): index-/hashvergelijking - uitsluitend doorsturen ZONDER caching.
# Deze antwoorden zijn klein, veranderen vaak en zijn door G DATA
# bewust niet bedoeld voor 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

Toelichting op de configuratie

De belangrijkste secties worden hier afzonderlijk uitgelegd. Zo kunnen ook lezers met minder HAProxy-ervaring de configuratie begrijpen.

Sectie	Toelichting
global / defaults	Basisinstellingen voor processen en verbindingen. Voorbeelden: logging, maximaal aantal gelijktijdige verbindingen (maxconn), standaardtime-outs. Deze waarden hoeft u doorgaans niet aan te passen.
frontend stats	Biedt een statuspagina op poort 8404. Via deze pagina kunt u de status van HAProxy bewaken, onder andere in Prometheus-formaat (/metrics).
frontend http_update_server	Het toegangspunt voor de daadwerkelijke bestandsdownloads op poort 80. Alleen aanvragen onder /api/v2/update/download/ voor de bekende hostnaam gaan naar de backend met caching. Alle andere aanvragen op poort 80 worden voor de zekerheid omgeleid naar HTTPS.
frontend https_update_server	Het toegangspunt voor de index- en hashvergelijkingen op poort 443 (TLS). Hier controleert HAProxy of de aangevraagde hostnaam ({{ haproxy_caching_server }}) bij de updatebackend past. Alleen dan stuurt HAProxy de aanvraag door. Anders komt de aanvraag in de backend nomatch terecht en krijgt deze foutcode 503. Hier vindt geen caching plaats.
cache objectcache_update_server	Definieert de tijdelijke opslag. Drie waarden zijn belangrijk: de maximale totale grootte van de cache (total-max-size, in MB), de maximale grootte van één bestand (max-object-size, in bytes) en de maximale verblijfsduur van een object in de cache (max-age, in seconden). Het sjabloon gebruikt een totale grootte van ongeveer 3 GB, maximaal 200 MB per bestand en een geldigheidsduur van 24 uur. Alleen de HTTP-backend gebruikt deze cache.
backend http_update_server_backend	Stuurt de downloadaanvragen onversleuteld (poort 80) door naar agent-update-server.gdatasecurity.de. De regel http-request cache-use … if { path_beg /api/v2/update/download/ } zorgt ervoor dat alleen dit pad wordt gecachet. De http-check controleert continu of de G DATA-server bereikbaar is.
backend https_update_server_backend	Stuurt de index- en hashaanvragen versleuteld (poort 443, met certificaatcontrole) door naar dezelfde G DATA-server. Deze backend bevat noch cache-use, noch cache-store. De antwoorden worden doorgestuurd, maar niet opgeslagen.
backend nomatch	Vangt alle aanvragen op die niet bij een bekende host passen. Deze aanvragen krijgen foutcode 503. Zo voorkomt de configuratie misbruik als open proxy.

Sectie

Toelichting

global / defaults

Basisinstellingen voor processen en verbindingen. Voorbeelden: logging, maximaal aantal gelijktijdige verbindingen (maxconn), standaardtime-outs. Deze waarden hoeft u doorgaans niet aan te passen.

frontend stats

Biedt een statuspagina op poort 8404. Via deze pagina kunt u de status van HAProxy bewaken, onder andere in Prometheus-formaat (/metrics).

frontend http_update_server

Het toegangspunt voor de daadwerkelijke bestandsdownloads op poort 80. Alleen aanvragen onder /api/v2/update/download/ voor de bekende hostnaam gaan naar de backend met caching. Alle andere aanvragen op poort 80 worden voor de zekerheid omgeleid naar HTTPS.

frontend https_update_server

Het toegangspunt voor de index- en hashvergelijkingen op poort 443 (TLS). Hier controleert HAProxy of de aangevraagde hostnaam ({{ haproxy_caching_server }}) bij de updatebackend past. Alleen dan stuurt HAProxy de aanvraag door. Anders komt de aanvraag in de backend nomatch terecht en krijgt deze foutcode 503. Hier vindt geen caching plaats.

cache objectcache_update_server

Definieert de tijdelijke opslag. Drie waarden zijn belangrijk: de maximale totale grootte van de cache (total-max-size, in MB), de maximale grootte van één bestand (max-object-size, in bytes) en de maximale verblijfsduur van een object in de cache (max-age, in seconden). Het sjabloon gebruikt een totale grootte van ongeveer 3 GB, maximaal 200 MB per bestand en een geldigheidsduur van 24 uur. Alleen de HTTP-backend gebruikt deze cache.

backend http_update_server_backend

Stuurt de downloadaanvragen onversleuteld (poort 80) door naar agent-update-server.gdatasecurity.de. De regel http-request cache-use … if { path_beg /api/v2/update/download/ } zorgt ervoor dat alleen dit pad wordt gecachet. De http-check controleert continu of de G DATA-server bereikbaar is.

backend https_update_server_backend

Stuurt de index- en hashaanvragen versleuteld (poort 443, met certificaatcontrole) door naar dezelfde G DATA-server. Deze backend bevat noch cache-use, noch cache-store. De antwoorden worden doorgestuurd, maar niet opgeslagen.

backend nomatch

Vangt alle aanvragen op die niet bij een bekende host passen. Deze aanvragen krijgen foutcode 503. Zo voorkomt de configuratie misbruik als open proxy.

HAProxy cachet alleen aanvragen onder het pad /api/v2/update/download/ via HTTP. De index- en hashaanvragen via HTTPS blijven ongewijzigd verlopen. Andere communicatiekanalen van de agents, bijvoorbeeld telemetrie of meldingen aan de XDR-backend, vallen niet onder de caching.

Agents overschakelen naar de cachingserver

Als u de G DATA Agents al op de endpoints hebt geïnstalleerd, neem dan contact op met de technische ondersteuning via telefoonnummer +49 234 9762-901. De medewerkers van de ondersteuning schakelen uw G DATA Agents graag om.

Als u nog geen G DATA Agents hebt uitgerold, maakt u een installatieconfiguratie met vermelding van het proxyadres. Alle endpoints die met de bijbehorende SetupID worden geïnstalleerd, ontvangen hun updates via uw proxy.

Controleer altijd of de configuratie werkt. Endpoints die geen updates ontvangen, vormen een beveiligingsrisico. Laat de fallbackserver in de configuratie altijd ingeschakeld (deze mag alleen in goed gemotiveerde uitzonderingsgevallen worden uitgeschakeld). Met een ingeschakelde fallbackserver ontvangen uw endpoints ook updates wanneer ze het netwerk verlaten (bijvoorbeeld laptops) of wanneer uw reverse-proxyserver uitvalt.

Problemen oplossen

Symptoom	Werkwijze
HAProxy start niet	Controleer de configuratie met haproxy -c -f /etc/haproxy/haproxy.cfg. Controleer daarnaast de servicestatus met systemctl status haproxy en journalctl -u haproxy.
Agents krijgen certificaatfouten	Controleer twee zaken: bevat het PEM-bestand het certificaat, de tussenliggende certificaten en de privésleutel in de juiste volgorde? Komt de hostnaam in het certificaat overeen met {{ haproxy_caching_server }}?
Geen afname van het internetverkeer zichtbaar	Controleer via de statuspagina (frontend stats, poort 8404) of de downloadaanvragen via de backend http_update_server_backend verlopen en of aanvragen daar succesvol vanuit de cache worden afgehandeld. De backend https_update_server_backend cachet bewust niet.
Aanvragen komen in de backend nomatch terecht	De Host-header van de binnenkomende aanvraag komt niet overeen met {{ haproxy_caching_server }}. Controleer de agentconfiguratie en de DNS-naamomzetting.

Symptoom

Werkwijze

HAProxy start niet

Controleer de configuratie met haproxy -c -f /etc/haproxy/haproxy.cfg. Controleer daarnaast de servicestatus met systemctl status haproxy en journalctl -u haproxy.

Agents krijgen certificaatfouten

Controleer twee zaken: bevat het PEM-bestand het certificaat, de tussenliggende certificaten en de privésleutel in de juiste volgorde? Komt de hostnaam in het certificaat overeen met {{ haproxy_caching_server }}?

Geen afname van het internetverkeer zichtbaar

Controleer via de statuspagina (frontend stats, poort 8404) of de downloadaanvragen via de backend http_update_server_backend verlopen en of aanvragen daar succesvol vanuit de cache worden afgehandeld. De backend https_update_server_backend cachet bewust niet.

Aanvragen komen in de backend nomatch terecht

De Host-header van de binnenkomende aanvraag komt niet overeen met {{ haproxy_caching_server }}. Controleer de agentconfiguratie en de DNS-naamomzetting.