Check Point Trusted Access Review

VEUILLEZ TOUJOURS APPLIQUER LES CORRECTIFS DU FOURNISSEUR AUSSI RAPIDEMENT QUE POSSIBLE

Application web locale pour réaliser un Check Point Trusted Access Review à l'aide de commandes fiables de l'API de gestion Check Point. La plupart des contrôles sont en mode revue uniquement. Toute action de remédiation disponible nécessite l'approbation explicite de l'opérateur.

Ce scanner est conçu spécifiquement pour rechercher les problèmes de configuration liés à CVE-2026-16232 (https://support.checkpoint.com/results/sk/sk185169), CVE-2026-62144 (https://support.checkpoint.com/results/sk/sk185152) et CVE-2026-62145 (https://support.checkpoint.com/results/sk/sk185153)

Il vous permettra d'analyser et de corriger les utilisations de ANY ainsi que d'analyser les journaux à la recherche d'acteurs malveillants potentiels.

Cet outil n'est ni créé ni pris en charge par Check Point et doit être utilisé à vos propres risques.

Versions autonomes

Des versions précompilées sont disponibles sous dist/ pour les utilisateurs qui ne souhaitent pas installer Node.js, npm, Git ou le code source :

• Windows x64 : dist/windows-x64/ contient le .exe autonome et une archive ZIP correspondante.
• macOS Apple Silicon : dist/macos-apple-silicon/ contient l'archive ZIP .app distribuable, l'application extraite et l'exécutable arm64 autonome.

Les versions autonomes incluent le runtime Node.js, l'interface web, le backend et le générateur direct de rapports PDF. Elles se lient uniquement à 127.0.0.1, privilégient le port 4000, essaient automatiquement les ports 4001, 4002 et supérieurs si nécessaire, et ouvrent l'URL locale sélectionnée dans le navigateur par défaut.

Pour GitHub, publiez les ZIP des plateformes—et éventuellement le .exe Windows—en tant qu'actifs de publication GitHub. Les utilisateurs ne devraient pas télécharger node_modules ni l'arborescence du code source uniquement pour exécuter une version autonome. Voir dist/README.md pour la disposition des artefacts.

L'application actuelle est alignée sur le guide d'administration du durcissement des passerelles et de la gestion Check Point.

Cet outil n'est ni créé ni pris en charge par Check Point et doit être utilisé à vos propres risques.

L'application s'exécute localement, se connecte à un serveur de gestion de sécurité Check Point ou à un MDS, analyse les preuves disponibles de l'API de gestion et présente des contrôles de durcissement conformes au guide. La plupart des contrôles sont en mode revue uniquement ; des actions de remédiation spécifiques ne sont proposées que lorsqu'elles sont explicitement implémentées et nécessitent l'approbation de l'opérateur. Les contrôles qui nécessitent un examen de la conception du réseau, Gaia Portal, Gaia API, SSH/Clish, les paramètres du fournisseur d'identité ou une inspection de la gestion hors bande sont marqués pour une validation manuelle.

Ce qu'il vérifie

Le scanner couvre actuellement les domaines suivants du guide de durcissement :

• Examen de la règle furtive de la passerelle de sécurité.
• Examen des règles implicites et de la journalisation des règles implicites.
• Examen des segments protégés du serveur de gestion et des restrictions des sources administratives.
• Preuves de restriction des clients approuvés SmartConsole.
• Examen des comptes administrateur, de la MFA, des mots de passe, du délai d'inactivité, de l'expiration et du verrouillage.
• Examen de l'authentification administrative MFA et du fournisseur d'identité externe.
• Examen des identifiants d'intégration à privilèges minimaux.
• Preuves de consentement pour les mises à jour dynamiques / AutoUpdater.
• Preuves de consentement pour cpdiag / diagnostics et télémétrie.
• Inventaire de l'examen du durcissement du système d'exploitation Gaia pour les passerelles.
• Contrôles manuels de SNMP, syslog, mode Expert, LOM et remplacement avancé des règles implicites.
• Examen de l'utilisation des fonctions de sécurité pour les blades sous licence et preuves d'expiration des fonctionnalités.

Flux de travail

1. Connectez-vous avec un utilisateur de l'API de gestion Check Point.
2. Cliquez sur Scan Hardening Posture.
3. Examinez les résultats : réussite, remédiation requise, à examiner, manuel et inconnu.
4. Utilisez les preuves et les références aux sections du guide pour piloter la validation par l'opérateur.

Pour les environnements MDS, activez MDS Scan sur le formulaire de connexion. Cela expose deux champs importants :

• Domain sélectionne le contexte de domaine de l'API de gestion pour les contrôles de stratégie et d'objets au niveau du domaine.
• Global MDS Object Name désigne l'objet MDS réel utilisé pour les contrôles Gaia run-script contre la machine elle-même. Ce champ est requis lorsque l'hôte de connexion est l'adresse IP du MDS mais que le domaine d'API sélectionné est une CMA/domaine, car des commandes telles que run-script doivent cibler le nom de l'objet MDS, et non l'adresse IP du MDS ni l'adresse IP de la CMA/domaine.

Lorsque MDS Scan est activé, l'application crée deux sessions d'API de gestion Check Point :

• Une session domaine/CMA se connecte avec le Domain sélectionné et est utilisée pour les objets au niveau du domaine, les paquets de stratégie, les règles d'accès, les administrateurs, les clients approuvés et les autres contrôles de domaine normaux.
• Une session MDS/globale se connecte au même hôte de gestion sans domaine et n'est utilisée que pour les commandes Gaia run-script qui ciblent le Global MDS Object Name. Cela est nécessaire pour les contrôles qui inspectent le système d'exploitation du serveur MDS lui-même, comme la découverte des interfaces/route par défaut du serveur de gestion, les paramètres administrateur Gaia, la stratégie de mots de passe Gaia, SNMP et le transfert syslog du serveur de gestion.
• Une session de domaine global est également ouverte lorsqu'elle est disponible. Elle est utilisée lorsqu'une stratégie de domaine est installée sous une couche de stratégie globale et que l'application doit lire les règles d'accès parentes globales au-dessus de l'espace réservé du domaine.

En termes de mgmt_cli, les contrôles de domaine se comportent comme des commandes qui incluent --domain "<Domain>", tandis que les contrôles de l'hôte MDS se comportent comme mgmt_cli -r true run-script targets.1 "<Global MDS Object Name>" ... exécutés dans le contexte MDS global.

Certains contrôles MDS évaluent intentionnellement plus d'un plan de gestion. Par exemple, Restrict Administrative Source IP Addresses évalue à la fois l'adresse IP de l'hôte de gestion MDS/global et l'adresse IP du domaine/CMA sélectionné. Pour chaque adresse IP, il tente de résoudre l'objet correspondant dans le domaine sélectionné, vérifie les objets réseau et les plages d'adresses contenant l'adresse IP, suit les groupes contenant ces objets, puis collecte les règles d'accès qui les référencent. Si la règle de domaine correspondante se trouve sous une couche parente de stratégie globale, l'application lit la base de règles d'accès globale jusqu'à Placeholder for domain rules et inclut ces règles globales dans le même tableau de preuves du paquet de stratégie avec un marqueur GLOBAL RULES.