Los lanzamientos autocontenidos incluyen el runtime de Node.js, la interfaz web, el backend y el generador directo de informes PDF. Se vinculan solo a 127.0.0.1, prefieren el puerto 4000, prueban automáticamente los puertos 4001, 4002 y superiores cuando es necesario, y abren la URL local seleccionada en el navegador predeterminado.

Para GitHub, publique los ZIP de plataforma —y opcionalmente el .exe de Windows— como recursos de lanzamiento de GitHub. Los usuarios no deberían descargar node_modules ni el árbol de código fuente únicamente para ejecutar un lanzamiento autocontenido. Consulte dist/README.md para conocer la estructura de los artefactos.

La aplicación actual está alineada con la Guía de administración de endurecimiento de Check Point Gateway y Management.

Esta herramienta no está creada ni respaldada por Check Point y debe utilizarse bajo su propio riesgo.

La aplicación se ejecuta localmente, inicia sesión en un Check Point Security Management Server o MDS, escanea la evidencia disponible de la API de Management y presenta comprobaciones de endurecimiento alineadas con la guía. La mayoría de las comprobaciones son solo de revisión; las acciones de remediación específicas solo se ofrecen cuando están implementadas explícitamente y requieren la aprobación del operador. Las comprobaciones que requieren revisión del diseño de red, Gaia Portal, Gaia API, SSH/Clish, configuración del proveedor de identidad o inspección de gestión fuera de banda están marcadas para validación manual.

Qué Comprueba

El escáner cubre actualmente estas áreas de la guía de endurecimiento:

• Revisión de la regla de ocultación (stealth) del Security Gateway.
• Revisión de reglas implícitas y del registro de reglas implícitas.
• Revisión de la restricción del segmento protegido y de las fuentes administrativas del Management Server.
• Evidencia de restricción de clientes confiables de SmartConsole.
• Revisión de cuentas de administrador, MFA, contraseñas, tiempo de inactividad, caducidad y bloqueo.
• Revisión de la autenticación administrativa mediante MFA y proveedor de identidad externo.
• Revisión de credenciales de integración con privilegios mínimos.
• Evidencia de consentimiento para actualizaciones dinámicas / AutoUpdater.
• Evidencia de consentimiento para cpdiag / diagnósticos y telemetría.
• Inventario de endurecimiento del sistema operativo Gaia para gateways.
• Comprobaciones manuales de SNMP, syslog, modo Expert, LOM y reemplazo avanzado de reglas implícitas.
• Revisión del uso de funciones de seguridad para blades licenciados y evidencia de caducidad de funciones.

Flujo de Trabajo

1. Inicie sesión con un usuario de la API de Management de Check Point.
2. Haga clic en Escanear Postura de Endurecimiento.
3. Revise los hallazgos de aprobado, requiere remediación, necesita revisión, manual y desconocido.
4. Utilice la evidencia y las referencias a las secciones de la guía para impulsar la validación del operador.

Para entornos MDS, active Escaneo MDS en el formulario de inicio de sesión. Esto expone dos campos relevantes:

• Dominio selecciona el contexto de dominio de la API de Management para las comprobaciones de políticas y objetos a nivel de dominio.
• Nombre del Objeto MDS Global nombra el objeto MDS real utilizado para las comprobaciones de run-script de Gaia contra el propio equipo. Esto es obligatorio cuando el host de inicio de sesión es la IP del MDS pero el dominio de API seleccionado es un CMA/dominio, porque comandos como run-script deben apuntar al nombre del objeto MDS, no a la IP del MDS ni a la IP del CMA/dominio.

Cuando Escaneo MDS está activado, la aplicación crea dos sesiones de la API de Management de Check Point:

• Una sesión de dominio/CMA inicia sesión con el Dominio seleccionado y se utiliza para objetos a nivel de dominio, paquetes de políticas, reglas de acceso, administradores, clientes confiables y otras comprobaciones normales de dominio.
• Una sesión MDS/global inicia sesión en el mismo host de Management sin dominio y se utiliza únicamente para comandos de run-script de Gaia que apuntan al Nombre del Objeto MDS Global. Esto es necesario para las comprobaciones que inspeccionan el propio sistema operativo del servidor MDS, como el descubrimiento de interfaces/ruta predeterminada del servidor de management, la configuración de administradores de Gaia, la política de contraseñas de Gaia, SNMP y el reenvío de syslog del servidor de management.
• También se abre una sesión de dominio Global cuando está disponible. Se utiliza cuando una política de dominio está instalada bajo una capa de Política Global y la aplicación necesita leer las reglas de acceso parentales Globales por encima del marcador de dominio.

En términos de mgmt_cli, las comprobaciones de dominio se comportan como comandos que incluyen --domain "<Domain>", mientras que las comprobaciones del host MDS se comportan como mgmt_cli -r true run-script targets.1 "<Global MDS Object Name>" ... ejecutadas en el contexto MDS global.

Algunas comprobaciones MDS evalúan intencionalmente más de un plano de gestión. Por ejemplo, Restringir Direcciones IP de Origen Administrativas evalúa tanto la IP del host de gestión MDS/global como la IP del Dominio/CMA seleccionado. Para cada IP, intenta resolver el objeto coincidente en el dominio seleccionado, comprueba los objetos de red y los rangos de direcciones que contienen la IP, sigue los grupos que contienen esos objetos y luego recopila las reglas de acceso que los referencian. Si la regla de dominio coincidente está bajo una capa parental de Política Global, la aplicación lee la base de reglas Global hasta Placeholder for domain rules e incluye esas reglas Globales en la misma tabla de evidencia del Paquete de Políticas con un marcador GLOBAL RULES.

Para Smart-1 Cloud, habilite URL de contexto de Smart-1 Cloud en el formulario de inicio de sesión e introduzca el host de Management con su ruta de contexto, por ejemplo:```text tenant-name.maas.checkpoint.com/context-id/web_api

Esto coincide con la estructura de contexto de Smart-1 Cloud de mgmt_cli:```bash mgmt_cli -m tenant-name.maas.checkpoint.com --session-id --context context-id/web_api <cli_command>

Las comprobaciones de último inicio de sesión de administradores consultan los inicios de sesión de auditoría de SmartConsole con un filtro equivalente a administrator:<name> AND SmartConsole AND "Log In". CP_LOG_API_TIMEOUT_MS controla el tiempo de espera para estas solicitudes show-logs por separado de las llamadas normales a la API de Management.

Las comprobaciones de comunidades VPN IKE de CVE paginan show-vpn-communities-star y show-vpn-communities-meshed con VPN_COMMUNITY_PAGE_LIMIT, que por defecto es 50, y usan CP_VPN_API_TIMEOUT_MS, que por defecto es 120000 ms. Esto evita que los escaneos de Smart-1 Cloud y MDS soliciten cargas útiles de comunidades VPN details-level full muy grandes en una sola llamada.

Use este modo al escanear entornos MDS de producción, servidores de gestión ocupados o despliegues con docenas de gateways donde proteger la capacidad de respuesta de fwm / la API de Management es más importante que el tiempo de escaneo más rápido absoluto.

Algunas comprobaciones requieren revisión del operador incluso cuando la condición automatizada de alto riesgo está ausente. Los clientes de confianza de SmartConsole, las cuentas de administrador y las comprobaciones de contraseña de administrador / tiempo de inactividad / caducidad / política de bloqueo pueden marcarse como revisadas. En la misma sesión de inicio de sesión, el estado cambia a Revisado. Un nuevo inicio de sesión cambia el estado de nuevo a Necesita revisión, mientras que la última aprobación de revisión permanece visible con el nombre de usuario de la API de Management que inició sesión y la marca de tiempo.

Para la comprobación de contraseña de administrador / tiempo de inactividad / caducidad / política de bloqueo, los operadores también pueden marcar la comprobación como revisada mientras esté en Remediación requerida. La aplicación advierte que el operador está aceptando ajustes que Check Point no recomienda antes de registrar esa revisión.

El resumen superior combina los hallazgos de Remediación requerida y Remediación recomendada en un solo conteo de Remediación necesaria.

Notas de seguridad

• La aplicación usa HTTPS por defecto al conectarse al servidor de gestión de Check Point.
• No introduzca el servidor de gestión como http://...; eso enviaría el inicio de sesión de la API de Check Point a través de HTTP en texto claro.
• El navegador se comunica con el backend local a través de http://127.0.0.1:4000 por defecto, o el siguiente puerto local disponible.
• El nombre de usuario y la contraseña se envían desde el navegador al backend local solo en localhost.
• El backend envía el nombre de usuario y la contraseña a Check Point a través de la solicitud de inicio de sesión de la API de Management.
• La aplicación no registra las contraseñas.
• El ID de sesión de Check Point se almacena solo en la memoria del servidor durante la vida del proceso local de Node.
• La opción Permitir certificado autofirmado mantiene el cifrado TLS pero deshabilita la validación del certificado. Úsala solo cuando sea necesario.
• Las acciones de remediación requieren la aprobación explícita del operador en el navegador antes de que el backend envíe un comando de cambio.

Comandos de API utilizados

El backend hace de proxy para estos comandos de la API de Management de 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 comprobación de uso de funciones de seguridad ejecuta un run-script de Gaia contra cada gateway gestionado de destino:```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

La aplicación web inicia sesión en el dominio System Data de Management API, obtiene el name del cliente de confianza, el type y los datos IP específicos del tipo, y los muestra en una tabla de evidencia. Marca la comprobación como Remediation Required cuando un objeto devuelto tiene type establecido en any.

Cuando un objeto de cliente de confianza tiene type establecido en any, la aplicación ofrece la primera acción de remediación. Busca el uid real de ese objeto y ejecuta el equivalente de:```sh mgmt_cli delete trusted-client uid "" --domain "System Data" mgmt_cli publish --domain "System Data"

Para varios clientes seleccionados, el comando de eliminación se ejecuta una vez por cada uid seleccionado, seguido de una única publicación. Si una eliminación o publicación falla después de que comiencen los cambios, la aplicación intenta discard en la misma sesión de System Data.

La comprobación de registro de reglas implícitas ejecuta el equivalente de:```sh mgmt_cli -r true show global-properties details-level full --format json

La comprobación de acceso a la API de administración ejecuta el equivalente de:```sh mgmt_cli -r true show api-settings --domain "System Data" --format json

Si el acceso a la API ya está limitado a clientes GUI, la comprobación muestra la tabla de evidencia de clientes de confianza para su revisión.

Las comprobaciones de Policy Insights ejecutan llamadas de solo lectura a Access Control Insights:```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 aplicación web inicia sesión en el dominio System Data de la Management API para este paso de recopilación y, a continuación, muestra una tabla de evidencia con Name, Permission Profile Name, Authentication-Method y expiration-date. Los valores de expiración se convierten de iso-8601 a una fecha y hora legibles. Los administradores sin una clave expiration-date se muestran como Never.

La comprobación de integración de MFA y proveedor de identidad utiliza show default-administrator-settings para mostrar el authentication-method predeterminado y, a continuación, utiliza show-administrators para enumerar los administradores cuyo authentication-method es check point password o os password. Si el método predeterminado o cualquier administrador utiliza autenticación basada en contraseña, la comprobación se marca como Remediación recomendada. Los operadores pueden marcar la sección como revisada, y se muestra el mismo patrón de historial de revisado por. La comprobación incluye un botón de ayuda de configuración con orientación sobre SmartConsole y la configuración SAML de IdP externo.

La tabla de cuentas de administrador permite a los operadores seleccionar uno o más objetos de administrador devueltos y eliminarlos desde la aplicación web. La aplicación valida los valores uid seleccionados contra la salida actual de show-administrators y luego ejecuta el equivalente de:```sh mgmt_cli delete administrator uid "" --domain "System Data" mgmt_cli publish --domain "System Data"

La aplicación web muestra los ajustes devueltos en una tabla Setting, Value y State. La caducidad predeterminada del administrador establecida en never, el tiempo de espera inactivo de SmartConsole deshabilitado, el bloqueo de la cuenta de administrador deshabilitado, el desbloqueo automático deshabilitado, o min-password-length menor que 10 se marcan como que requieren corrección.

Cuando el método de autenticación del administrador predeterminado es check point password, la columna State recomienda utilizar un método de autenticación que admita MFA o un proveedor de identidad externo.

Para la caducidad del administrador predeterminado, la columna State muestra el detalle de caducidad devuelto: un valor formateado de expiration-date, o el valor de expiration-period más expiration-period-time-units cuando el tipo es expiration-period.

Cuando la caducidad del administrador predeterminado está establecida en never, la aplicación ofrece una acción de corrección recomendada. Ejecuta el equivalente 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 publicación falla después del cambio de tiempo de espera por inactividad, la aplicación intenta discard en la misma sesión de System Data.

Cuando la longitud mínima de la contraseña es inferior a 10, la aplicación ofrece una acción de remediación recomendada. Ejecuta el equivalente de:```sh mgmt_cli set cp-password-requirements min-password-length "10" --domain "System Data" --format json mgmt_cli publish --domain "System Data"

2. Descarga o clona este proyecto. ```sh git clone cd "Check Point Trusted Access Review"
   root@kitploit:~

3. Instala las dependencias e inicia la aplicación local. ```sh npm install npm start
   root@kitploit:~

4. Abre la aplicación. ```text http://127.0.0.1:4000
   root@kitploit:~

Windows desde el código fuente

1. Instale Node.js 18 o una versión más reciente desde nodejs.org.

2. Descargue y extraiga el ZIP del proyecto, o clone el repositorio con Git for Windows. ```powershell git clone cd "Check Point Trusted Access Review"

   root@kitploit:~

3. Instala las dependencias e inicia la aplicación local. ```powershell npm install npm start

   root@kitploit:~

4. Abre la aplicación en un navegador. ```text http://127.0.0.1:4000

   root@kitploit:~

Cambio de puerto opcional

Por defecto, la aplicación prefiere 127.0.0.1:4000 y se mueve automáticamente hacia arriba si el puerto está ocupado. Para requerir un puerto específico:

macOS:```sh PORT=4500 npm start

Luego abre:```text http://127.0.0.1:4500

Si el navegador muestra un error de inicio de sesión con un ID de solicitud, pero la captura de paquetes no muestra ningún intento de salida hacia el servidor de gestión, compara el valor de target= del terminal con el filtro de tu captura de paquetes.

Si no hay ninguna línea de Local API request en absoluto, el navegador no está llegando al backend local. Confirma que la aplicación está en ejecución y que abriste la URL local correcta.