Check Point Trusted Access Review

APPLICARE SEMPRE LE PATCH DEL FORNITORE IL PRIMA POSSIBILE

Applicazione web locale per condurre una Check Point Trusted Access Review con comandi attendibili della Check Point Management API. La maggior parte dei controlli è solo di revisione. Qualsiasi azione di remediation disponibile richiede l'approvazione esplicita dell'operatore.

Questo scanner è costruito specificamente per individuare problemi di configurazione relativi a CVE-2026-16232 (https://support.checkpoint.com/results/sk/sk185169), CVE-2026-62144 (https://support.checkpoint.com/results/sk/sk185152) e CVE-2026-62145 (https://support.checkpoint.com/results/sk/sk185153)

Ti consentirà di analizzare e correggere gli utilizzi di ANY, oltre a scansionare i log alla ricerca di potenziali attori malintenzionati.

Questo strumento non è creato né supportato da Check Point e deve essere utilizzato a proprio rischio.

Release autonome

Versioni precompilate sono disponibili in dist/ per gli utenti che non vogliono installare Node.js, npm, Git o il codice sorgente:

• Windows x64: dist/windows-x64/ contiene l'eseguibile .exe autonomo e uno ZIP corrispondente.
• macOS Apple Silicon: dist/macos-apple-silicon/ contiene lo ZIP dell'app .app distribuibile, l'app estratta e l'eseguibile arm64 autonomo.

Le release autonome includono il runtime Node.js, l'interfaccia web, il backend e il generatore diretto di report PDF. Si legano solo a 127.0.0.1, preferiscono la porta 4000, provano automaticamente 4001, 4002 e porte successive quando necessario e aprono l'URL locale selezionato nel browser predefinito.

Per GitHub, pubblica gli ZIP delle piattaforme—e opzionalmente il .exe Windows—come asset delle Release GitHub. Gli utenti non dovrebbero scaricare node_modules o l'albero del sorgente solo per eseguire una release autonoma. Vedi dist/README.md per la struttura degli artefatti.

L'app attuale è allineata alla Check Point Gateway and Management Hardening Administration Guide.

Questo strumento non è creato né supportato da Check Point e deve essere utilizzato a proprio rischio.

L'app viene eseguita localmente, accede a un Check Point Security Management Server o MDS, analizza le evidenze disponibili della Management API e presenta controlli di hardening allineati alla guida. La maggior parte dei controlli è solo di revisione; azioni di remediation specifiche vengono offerte solo quando esplicitamente implementate e richiedono l'approvazione dell'operatore. I controlli che richiedono la revisione del progetto di rete, Gaia Portal, Gaia API, SSH/Clish, impostazioni del provider di identità o ispezione della gestione out-of-band sono contrassegnati per la validazione manuale.

Cosa controlla

Lo scanner copre attualmente queste aree della guida all'hardening:

• Revisione delle regole stealth del Security Gateway.
• Revisione delle regole implicite e del logging delle regole implicite.
• Revisione del segmento protetto del Management Server e delle restrizioni delle origini amministrative.
• Evidenze della restrizione dei client fidati di SmartConsole.
• Revisione di account amministratore, MFA, password, timeout di inattività, scadenza e blocco.
• Revisione dell'autenticazione amministrativa MFA e del provider di identità esterno.
• Revisione delle credenziali di integrazione con privilegi minimi.
• Evidenze del consenso per aggiornamenti dinamici / AutoUpdater.
• Evidenze del consenso per cpdiag / diagnostica e telemetria.
• Inventario della revisione di hardening del sistema operativo Gaia per i gateway.
• Controlli manuali per SNMP, syslog, modalità Expert, LOM e sostituzione avanzata delle regole implicite.
• Revisione dell'utilizzo delle funzionalità di sicurezza per blade con licenza ed evidenze di scadenza delle funzionalità.

Flusso di lavoro

1. Accedi con un utente della Check Point Management API.
2. Fai clic su Scan Hardening Posture.
3. Esamina gli esiti: superato, richiede azione correttiva, da rivedere, manuale e sconosciuto.
4. Utilizza le evidenze e i riferimenti alle sezioni della guida per guidare la validazione dell'operatore.

Per gli ambienti MDS, abilita MDS Scan nel modulo di accesso. Questo espone due campi importanti:

• Domain seleziona il contesto del dominio della Management API per i controlli di policy e oggetti a livello di dominio.
• Global MDS Object Name identifica l'oggetto MDS effettivo utilizzato per i controlli Gaia run-script contro il sistema stesso. È necessario quando l'host di accesso è l'IP MDS ma il dominio API selezionato è una CMA/dominio, poiché comandi come run-script devono avere come destinazione il nome dell'oggetto MDS, non l'IP MDS né l'IP della CMA/dominio.

Quando MDS Scan è abilitato, l'app crea due sessioni della Check Point Management API:

• Una sessione di dominio/CMA accede con il Domain selezionato e viene utilizzata per oggetti a livello di dominio, pacchetti di policy, regole di accesso, amministratori, client fidati e altri controlli di dominio normali.
• Una sessione MDS/globale accede allo stesso host di Management senza un dominio e viene utilizzata solo per i comandi Gaia run-script che hanno come destinazione il Global MDS Object Name. Questo è necessario per i controlli che ispezionano il sistema operativo del server MDS stesso, come l'individuazione dell'interfaccia/della rotta predefinita del management server, le impostazioni degli amministratori Gaia, la policy delle password di Gaia, SNMP e l'inoltro syslog del management server.
• Viene aperta anche una sessione di dominio Globale quando disponibile. Viene utilizzata quando una policy di dominio è installata sotto un layer di Global Policy e l'app deve leggere le regole di accesso Globali padre sopra il segnaposto del dominio.

In termini di mgmt_cli, i controlli di dominio si comportano come comandi che includono --domain "<Domain>", mentre i controlli dell'host MDS si comportano come mgmt_cli -r true run-script targets.1 "<Global MDS Object Name>" ... eseguiti nel contesto MDS globale.

Alcuni controlli MDS valutano intenzionalmente più di un piano di gestione. Ad esempio, Restrict Administrative Source IP Addresses valuta sia l'IP dell'host di gestione MDS/globale sia l'IP del Domain/CMA selezionato. Per ogni IP, tenta di risolvere l'oggetto corrispondente nel dominio selezionato, controlla gli oggetti di rete e gli intervalli di indirizzi che contengono l'IP, segue i gruppi che contengono tali oggetti e quindi raccoglie le regole di accesso che li riferenziano. Se la regola di dominio corrispondente si trova sotto un layer padre di Global Policy, l'app legge la rulebase di accesso Globale fino a Placeholder for domain rules e include quelle regole Globali nella stessa tabella delle evidenze del Policy Package con un indicatore GLOBAL RULES.