Collecter la télémétrie réseau avec un collecteur Sophos XDR

Pour OPNsense, pfSense, Netskope SSE et NetScaler ADC, le chemin documenté utilise un Sophos XDR Data Collector. Déployer d’abord le collecteur, connecter chaque source au format syslog adapté, puis vérifier la collecte réelle. Une simple adresse syslog ne suffit pas : Sophos doit correctement interpréter le format et la catégorie d’événements.

Les données netflow décrites ici nécessitent un abonnement Sophos Next-Gen SIEM. Netskope et NetScaler fournissent aussi d’autres schémas, qui ne portent pas tous cette même réserve de licence dans la documentation. Pour OPNsense et pfSense, le périmètre vérifié comprend les événements de connexion firewall dans netflow. L’article SIEM et les bases des intégrations expliquent choix et licences.

Préparer le collecteur et les sources

Le collecteur doit être provisionné pour le bon tenant sous Security Operations > Integrations > Data Collectors. Le runbook du collecteur explique ressources, uplinks régionaux, DNS, heure et distinction avec l’ancienne SVA et NDR. Un nouveau XDR Data Collector ne reprend pas automatiquement une charge NDR existante.

Avant modification, documenter ancien chemin de logs, nouvelle cible, réseaux sources autorisés et événements souhaités. N’autoriser le syslog entrant que depuis ces réseaux. Ne pas remplacer un chemin UDP documenté par TLS-syslog ou un autre format sans vérifier la compatibilité. UDP n’accuse pas réception de chaque message ; tenir compte des pertes lors de la comparaison source/destination.

Choisir pour chaque pilote un événement autorisé et inoffensif avec heure et preuve source. Un receiver configuré ou un état vert ne prouve ni la collecte de chaque catégorie ni sa normalisation. Valider séparément communication, flux et contenu.

OPNsense : filterlog via UDP/514

Le chemin OPNsense traite les messages filterlog de connexions TCP, UDP et ICMP autorisées ou bloquées. Il faut un accès administratif OPNsense et un collecteur joignable.

1. Après déploiement du collecteur, ouvrir la configuration Remote Logging d’OPNsense. La navigation dépend de la version ; les valeurs ci-dessous sont celles documentées par Sophos.
2. Activer Enabled et définir Transport sur UDP(4).
3. Dans Applications, choisir filter (filterlog). Dans Levels, sélectionner info, notice, warn, error, critical, alert et emergency. Laisser Facilities vide.
4. Saisir l’IP réelle du collecteur dans Hostname et 514 dans Port. Désactiver rfc5424. La Description documentée est FilterLog ; ne pas confondre ce nom avec un autre format.
5. Enregistrer et produire un événement firewall inoffensif prévu. La règle source doit réellement le journaliser. Vérifier d’abord heure, adresses source/destination et action dans OPNsense, puis dans le schéma Sophos netflow.

Si l’événement manque, vérifier journalisation source, choix filterlog, chemin UDP/IPv4, IP, port et RFC5424. Ne pas désactiver des règles de protection pour forcer un flux de test.

pfSense : Firewall Events au format BSD

pfSense fournit également des filter logs TCP, UDP et ICMP. Leur format documenté diffère des autres journaux pfSense ; une sélection syslog arbitraire ne convient pas.

1. Ouvrir Log Settings dans l’administration pfSense.
2. Dans General Logging Options, choisir BSD (RFC 3164, default).
3. Activer Enable Remote Logging dans Remote Logging Options.
4. Pour Source Address, choisir une interface ou un réseau qui peut joindre le collecteur. Définir IP Protocol sur IPv4.
5. Saisir l’IP réelle du collecteur dans Remote log servers et choisir Firewall Events dans Remote Syslog Contents.
6. Enregistrer, produire un événement firewall autorisé réellement journalisé, puis le retrouver dans netflow du bon tenant Sophos. Action et connexion doivent correspondre à la source.

Changer Source Address peut modifier routage et correspondance firewall. Vérifier donc d’abord le chemin sortant de cette interface, puis receiver et format BSD. Cette procédure ne couvre pas automatiquement d’autres catégories.

Netskope SSE : Cloud Log Shipper et CEF

Deux étapes sont nécessaires : Netskope Cloud Log Shipper interroge les API Netskope et transmet en CEF via syslog au collecteur Sophos. Un compte Netskope saisi directement sur le collecteur ne remplace pas le Shipper.

L’intégration peut fournir activités web/cloud, malware, alertes de sécurité/policy et activités administratives, notamment dans http, antivirus, thirdpartyalert, nids et auth. Les événements supplémentaires de connexion/tunnel netflow nécessitent SIEM.

1. Déployer un Cloud Log Shipper approuvé pour le tenant Netskope. Configurer accès API et catégories selon la procédure Netskope correspondante. La documentation Sophos ne définit pas de jeu universel de permissions API.
2. Dans le Shipper, choisir Plugin: Syslog comme sortie.
3. Utiliser Syslog Defaults Mapping dans Mapping. Préserver le chemin CEF documenté ; des mappings personnalisés peuvent changer la normalisation.
4. Définir comme cible l’IP réelle du XDR Data Collector. Transport et receiver doivent correspondre à la configuration approuvée ; les exigences UDP/514 d’autres produits ne fixent pas un port universel pour Netskope.
5. Choisir un événement source adapté et vérifier son extraction API puis sa transmission par le Shipper. Comparer ensuite schéma attendu et champs requis dans Sophos.

Si seules les connexions manquent, vérifier aussi catégories et entitlement SIEM. Un enregistrement HTTP ne prouve pas la collecte de toutes les catégories Netskope. Séparer problèmes d’appel API et de transmission syslog.

NetScaler ADC : auditlogs et horodatage non ambigu

NetScaler ADC, anciennement Citrix ADC, fournit en syslog les événements web/Application Firewall (http), authentisations/sessions VPN (auth) et commandes administratives (managementevent). Établissement et fermeture TCP deviennent netflow et nécessitent SIEM.

1. Après déploiement du collecteur, ouvrir Audit Logging pour syslog dans NetScaler. Adapter serveur et policy à la version et au périmètre ; la source Sophos ne documente pas de commande CLI universelle.
2. Définir l’IP du bon XDR Data Collector comme cible et vérifier le chemin réseau approuvé.
3. Choisir MM/DD/YYYY comme date. DD/MM/YYYY n’est pas pris en charge pour une collecte correcte.
4. Transmettre les heures d’événement en UTC. Changer ensuite l’affichage Sophos ne répare pas un horodatage source mal interprété.
5. Produire une modification administrative ou connexion approuvée dans le scope d’audit. Comparer preuve source, heure, utilisateur et action au schéma Sophos correspondant. Netflow nécessite son propre test de connexion.

Pour un événement apparemment absent, comparer d’abord heure source et fenêtre de recherche. Une date ou un fuseau incorrect peut placer l’enregistrement hors période. Vérifier ensuite audit policy, catégorie réellement envoyée, IP du collecteur et réseau.

Validation et retrait contrôlé

Documenter pour chaque source au moins un événement reproductible, source, tenant, heure de collecte et schéma normalisé. Comparer adresses, ports, action et utilisateur lorsque ces champs sont attendus et présents. L’absence de détection ou case ne signifie pas nécessairement absence de données ; l’enregistrement réel est déterminant.

Répéter la validation après modification de la source ou du format. Le traitement correct du CEF d’hier ne prouve rien sur un mapping changé aujourd’hui. Pour un écart horaire, vérifier l’horloge source plutôt que désactiver la protection.

Pour le retrait, arrêter la nouvelle configuration Remote Logging ou la sortie Shipper dédiée, puis vérifier l’ancien chemin documenté. Conserver collecteurs, identités API et autres sorties partagés. Retirer les ressources exclusivement dédiées seulement après vérification des dépendances. Supprimer une intégration ne prouve pas la suppression de la télémétrie historique et ne restaure pas les événements perdus.