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.

Pour Smart-1 Cloud, activez Smart-1 Cloud context URL dans le formulaire de connexion et saisissez l'hôte de gestion avec son chemin de contexte, par exemple :```text tenant-name.maas.checkpoint.com/context-id/web_api

Cela correspond à la structure de contexte mgmt_cli de Smart-1 Cloud :```bash mgmt_cli -m tenant-name.maas.checkpoint.com --session-id --context context-id/web_api <cli_command>

Les vérifications de dernière connexion d'administrateur interrogent les connexions d'audit SmartConsole avec un filtre équivalent à administrator:<name> AND SmartConsole AND "Log In". CP_LOG_API_TIMEOUT_MS contrôle le délai d'expiration de ces requêtes show-logs séparément des appels normaux de l'API Management.

Les vérifications des communautés VPN IKE CVE paginent show-vpn-communities-star et show-vpn-communities-meshed avec VPN_COMMUNITY_PAGE_LIMIT, dont la valeur par défaut est 50, et utilisent CP_VPN_API_TIMEOUT_MS, dont la valeur par défaut est 120000 ms. Cela évite que les analyses Smart-1 Cloud et MDS demandent de très grandes charges utiles de communauté VPN en details-level full dans un seul appel.

Utilisez ce mode lors de l'analyse d'environnements MDS de production, de serveurs de gestion chargés ou de déploiements avec des dizaines de passerelles, où la protection de la réactivité de fwm / de l'API Management est plus importante que la durée d'analyse la plus rapide possible.

Certaines vérifications nécessitent un examen par l'opérateur même en l'absence de la condition automatisée à haut risque. Les vérifications des clients de confiance SmartConsole, des comptes administrateur et des politiques de mot de passe / délai d'inactivité / expiration / verrouillage de l'administrateur peuvent être marquées comme examinées. Dans la même session de connexion, le statut passe à Reviewed. Une nouvelle connexion ramène le statut à Needs review, tandis que la dernière approbation d'examen reste visible avec le nom d'utilisateur de l'API Management connecté et l'horodatage.

Pour la vérification de la politique de mot de passe / délai d'inactivité / expiration / verrouillage de l'administrateur, les opérateurs peuvent également marquer la vérification comme examinée alors qu'elle est en Remediation Required. L'application avertit que l'opérateur accepte des paramètres que Check Point ne recommande pas avant d'enregistrer cet examen.

Le résumé global combine les résultats Remediation Required et Remediation Recommended en un seul décompte Remediation Needed.

Notes de sécurité

• L'application utilise HTTPS par défaut lors de la connexion au serveur de gestion Check Point.
• Ne saisissez pas le serveur de gestion sous la forme http://... ; cela enverrait la connexion à l'API Check Point en HTTP en clair.
• Le navigateur communique avec le backend local via http://127.0.0.1:4000 par défaut, ou le prochain port local disponible.
• Le nom d'utilisateur et le mot de passe sont envoyés du navigateur au backend local uniquement sur localhost.
• Le backend envoie le nom d'utilisateur et le mot de passe à Check Point via la requête de connexion à l'API Management.
• Les mots de passe ne sont pas journalisés par l'application.
• L'identifiant de session Check Point est stocké uniquement dans la mémoire du serveur pendant la durée de vie du processus Node local.
• L'option Allow self-signed certificate conserve le chiffrement TLS mais désactive la validation du certificat. Utilisez-la uniquement en cas de besoin.
• Les actions de remédiation nécessitent l'approbation explicite de l'opérateur dans le navigateur avant que le backend n'envoie une commande de modification.

Commandes API utilisées

Le backend sert de proxy pour ces commandes de l'API Management Check Point :

• login
• logout
• show-trusted-clients
• delete-trusted-client
• show-api-settings
• set-api-settings
• publish
• discard
• show-administrators
• delete-administrator
• show-default-administrator-settings
• set-default-administrator-settings
• show-smart-console-idle-timeout
• set-smart-console-idle-timeout
• show-login-restrictions
• show-cp-password-requirements
• set-cp-password-requirements
• show-simple-gateways
• show-global-properties
• set-global-properties
• run-script
• show-task
• insights/v3.0/show-suggestions-summary
• insights/v3.0/show-suggestions

La vérification de l'utilisation des fonctionnalités de sécurité exécute un run-script Gaia sur chaque passerelle gérée cible :```sh mgmt_cli run-script script-name "show license" targets.1 "GATEWAY_OBJECT_NAME" script "clish -c 'show license status'" --format json mgmt_cli show-task task-id "" details-level full --format json

L'application web se connecte au domaine System Data de l'API de gestion, extrait les données name, type et les données IP spécifiques au type du client de confiance, puis les affiche dans un tableau de preuves. Elle marque la vérification comme Remédiation requise lorsqu'un objet renvoyé a type défini sur any.

Lorsqu'un objet client de confiance a type défini sur any, l'application propose la première action de remédiation. Elle recherche le uid réel de cet objet et exécute l'équivalent de :```sh mgmt_cli delete trusted-client uid "" --domain "System Data" mgmt_cli publish --domain "System Data"

Pour plusieurs clients sélectionnés, la commande de suppression est exécutée une fois par uid sélectionné, suivie d'une seule publication. Si une suppression ou une publication échoue après le début des modifications, l'application tente discard dans la même session System Data.

La vérification de journalisation des règles implicites exécute l'équivalent de :```sh mgmt_cli -r true show global-properties details-level full --format json

Le contrôle d'accès à l'API de gestion exécute l'équivalent de :```sh mgmt_cli -r true show api-settings --domain "System Data" --format json

Si l'accès API est déjà limité aux clients GUI, la vérification affiche le tableau des preuves des clients de confiance pour examen.

Les vérifications Policy Insights exécutent des appels Access Control Insights en lecture seule :```sh mgmt_cli insights/v3.0/show-suggestions-summary --method POST --format json mgmt_cli insights/v3.0/show-suggestions --method POST --format json

La webapp se connecte au domaine System Data de l'API de gestion pour cette étape de collecte, puis affiche un tableau de preuves avec Name, Permission Profile Name, Authentication-Method et expiration-date. Les valeurs d'expiration sont converties du format iso-8601 en une date et une heure lisibles par un humain. Les administrateurs sans clé expiration-date sont affichés comme Never.

Le contrôle d'intégration MFA et Identity Provider utilise show default-administrator-settings pour afficher la authentication-method par défaut, puis utilise show-administrators pour lister les administrateurs dont la authentication-method est check point password ou os password. Si la méthode par défaut ou un administrateur utilise une authentification par mot de passe, le contrôle est marqué Remédiation recommandée. Les opérateurs peuvent marquer la section comme examinée, et le même historique de type « reviewed-by » est affiché. Le contrôle comprend un bouton d'aide à la configuration avec des conseils de configuration SAML pour SmartConsole et les IdP externes.

Le tableau des comptes administrateur permet aux opérateurs de sélectionner un ou plusieurs objets administrateur renvoyés et de les supprimer depuis la webapp. L'application valide les valeurs uid sélectionnées par rapport à la sortie actuelle de show-administrators, puis exécute l'équivalent de :```sh mgmt_cli delete administrator uid "" --domain "System Data" mgmt_cli publish --domain "System Data"

L'application web affiche les paramètres renvoyés dans un tableau Setting, Value et State. L'expiration par défaut de l'administrateur définie sur never, le délai d'inactivité SmartConsole désactivé, le verrouillage du compte administrateur désactivé, le déverrouillage automatique désactivé, ou min-password-length inférieur à 10 sont marqués comme nécessitant une remédiation.

Lorsque la méthode d'authentification de l'administrateur par défaut est check point password, la colonne State recommande d'utiliser une méthode d'authentification prenant en charge la MFA ou un fournisseur d'identité externe.

Pour l'expiration de l'administrateur par défaut, la colonne State affiche le détail de l'expiration renvoyé : une valeur expiration-date formatée, ou la valeur expiration-period plus expiration-period-time-units lorsque le type est expiration-period.

Lorsque l'expiration de l'administrateur par défaut est définie sur never, l'application propose une action de remédiation recommandée. Elle exécute l'équivalent de :```sh mgmt_cli set default-administrator-settings expiration-type "expiration period" expiration-period "4" expiration-period-time-units "months" --domain "System Data" --format json mgmt_cli publish --domain "System Data"

Si la publication échoue après le changement de délai d'expiration d'inactivité, l'application tente discard dans la même session System Data.

Lorsque la longueur minimale du mot de passe est inférieure à 10, l'application propose une action de remédiation recommandée. Elle exécute l'équivalent de :```sh mgmt_cli set cp-password-requirements min-password-length "10" --domain "System Data" --format json mgmt_cli publish --domain "System Data"

2. Téléchargez ou clonez ce projet. ```sh git clone cd "Check Point Trusted Access Review"
   root@kitploit:~

3. Installez les dépendances et démarrez l'application locale. ```sh npm install npm start
   root@kitploit:~

4. Ouvrez l'application. ```text http://127.0.0.1:4000
   root@kitploit:~

Windows à partir des sources

1. Installez Node.js 18 ou une version plus récente depuis nodejs.org.

2. Téléchargez et extrayez le ZIP du projet, ou clonez le dépôt avec Git pour Windows. ```powershell git clone cd "Check Point Trusted Access Review"

   root@kitploit:~

3. Installez les dépendances et démarrez l'application locale. ```powershell npm install npm start

   root@kitploit:~

4. Ouvrez l'application dans un navigateur. ```text http://127.0.0.1:4000

   root@kitploit:~

Changement de port facultatif

Par défaut, l'application préfère 127.0.0.1:4000 et tente automatiquement un port supérieur si le port est occupé. Pour exiger un port spécifique :

macOS :```sh PORT=4500 npm start

Ensuite, ouvrez :```text http://127.0.0.1:4500

Si le navigateur affiche une erreur de connexion avec un ID de requête mais que la capture de paquets ne montre aucune tentative sortante vers le serveur de gestion, comparez la valeur target= du terminal avec votre filtre de capture de paquets.

S'il n'y a aucune ligne Local API request, le navigateur n'atteint pas le backend local. Vérifiez que l'application est en cours d'exécution et que vous avez ouvert la bonne URL locale.