As versões autocontidas incluem o runtime Node.js, a interface web, o backend e o gerador direto de relatórios PDF. Elas fazem bind apenas a 127.0.0.1, preferem a porta 4000, tentam automaticamente as portas 4001, 4002 e superiores quando necessário e abrem o URL local selecionado no navegador padrão.

Para o GitHub, publique os ZIPs das plataformas—e opcionalmente o .exe do Windows—como ativos de Release do GitHub. Os usuários não devem baixar node_modules ou a árvore de código-fonte apenas para executar uma versão autocontida. Consulte dist/README.md para o layout dos artefatos.

O aplicativo atual está alinhado ao Guia de Administração de Hardening de Gateway e Gerenciamento da Check Point.

Esta ferramenta não foi criada nem é suportada pela Check Point e deve ser usada por sua conta e risco.

O aplicativo é executado localmente, faz login em um Check Point Security Management Server ou MDS, verifica as evidências disponíveis da Management API e apresenta verificações de hardening alinhadas ao guia. A maioria das verificações é apenas de revisão; ações específicas de remediação são oferecidas somente quando explicitamente implementadas e exigem aprovação do operador. Verificações que exigem revisão do design de rede, Gaia Portal, Gaia API, SSH/Clish, configurações de provedor de identidade ou inspeção de gerenciamento fora de banda são marcadas para validação manual.

O Que Ela Verifica

O scanner atualmente cobre estas áreas do guia de hardening:

• Revisão da regra stealth do Security Gateway.
• Revisão das regras implícitas e do log de regras implícitas.
• Revisão da restrição de segmento protegido e de origem administrativa do Management Server.
• Evidência de restrição de clientes confiáveis do SmartConsole.
• Revisão de conta de administrador, MFA, senha, tempo limite de inatividade, expiração e bloqueio.
• Revisão da autenticação administrativa via MFA e provedor de identidade externo.
• Revisão de credenciais de integração com privilégios mínimos.
• Evidência de consentimento de atualizações dinâmicas / AutoUpdater.
• Evidência de consentimento de cpdiag / diagnósticos e telemetria.
• Inventário de revisão de hardening do Gaia OS para gateways.
• Verificações manuais de SNMP, syslog, modo Expert, LOM e substituição avançada de regras implícitas.
• Revisão de uso de recursos de segurança para blades licenciados e evidência de expiração de recursos.

Fluxo de Trabalho

1. Faça login com um usuário da Check Point Management API.
2. Clique em Scan Hardening Posture.
3. Revise os resultados: aprovado, remediação necessária, requer revisão, manual e desconhecido.
4. Use as evidências e as referências das seções do guia para conduzir a validação do operador.

Para ambientes MDS, habilite MDS Scan no formulário de login. Isso expõe dois campos importantes:

• Domain seleciona o contexto de domínio da Management API para verificações de política e objetos em nível de domínio.
• Global MDS Object Name nomeia o objeto MDS real usado para verificações de run-script do Gaia contra o próprio equipamento. Isso é necessário quando o host de login é o IP do MDS, mas o domínio de API selecionado é um CMA/domínio, pois comandos como run-script devem ter como alvo o nome do objeto MDS, não o IP do MDS ou o IP do CMA/domínio.

Quando MDS Scan está habilitado, o aplicativo cria duas sessões da Check Point Management API:

• Uma sessão de domínio/CMA faz login com o Domain selecionado e é usada para objetos em nível de domínio, pacotes de política, regras de acesso, administradores, clientes confiáveis e outras verificações normais de domínio.
• Uma sessão MDS/global faz login no mesmo host de gerenciamento sem um domínio e é usada apenas para comandos run-script do Gaia que têm como alvo o Global MDS Object Name. Isso é necessário para verificações que inspecionam o próprio sistema operacional do servidor MDS, como descoberta de interface/rota padrão do servidor de gerenciamento, configurações de administrador do Gaia, política de senha do Gaia, SNMP e encaminhamento de syslog do servidor de gerenciamento.
• Uma sessão de domínio Global também é aberta quando disponível. Ela é usada quando uma política de domínio está instalada em uma camada de Global Policy e o aplicativo precisa ler as regras de acesso pai globais acima do espaço reservado do domínio.

Em termos de mgmt_cli, as verificações de domínio se comportam como comandos que incluem --domain "<Domain>", enquanto as verificações do host MDS se comportam como mgmt_cli -r true run-script targets.1 "<Global MDS Object Name>" ... executadas no contexto MDS global.

Algumas verificações MDS avaliam intencionalmente mais de um plano de gerenciamento. Por exemplo, Restrict Administrative Source IP Addresses avalia tanto o IP do host de gerenciamento MDS/global quanto o IP do Domínio/CMA selecionado. Para cada IP, ele tenta resolver o objeto correspondente no domínio selecionado, verifica objetos de rede e intervalos de endereços que contêm o IP, segue grupos que contêm esses objetos e, em seguida, coleta regras de acesso que os referenciam. Se a regra de domínio correspondente estiver sob uma camada pai de Global Policy, o aplicativo lê a base de regras de acesso Global até Placeholder for domain rules e inclui essas regras Globais na mesma tabela de evidências do Policy Package com um marcador GLOBAL RULES.

Para Smart-1 Cloud, habilite Smart-1 Cloud context URL no formulário de login e insira o host de gerenciamento com seu caminho de contexto, por exemplo:```text tenant-name.maas.checkpoint.com/context-id/web_api

Isso corresponde à estrutura de contexto do Smart-1 Cloud do mgmt_cli:```bash mgmt_cli -m tenant-name.maas.checkpoint.com --session-id --context context-id/web_api <cli_command>

Administrator last-login checks consultam logins de auditoria do SmartConsole com um filtro equivalente a administrator:<name> AND SmartConsole AND "Log In". CP_LOG_API_TIMEOUT_MS controla o timeout para essas solicitações show-logs separadamente das chamadas normais da API de Gerenciamento.

As verificações de comunidade VPN CVE IKE paginam show-vpn-communities-star e show-vpn-communities-meshed com VPN_COMMUNITY_PAGE_LIMIT, cujo padrão é 50, e usam CP_VPN_API_TIMEOUT_MS, cujo padrão é 120000 ms. Isso evita que varreduras Smart-1 Cloud e MDS solicitem payloads muito grandes de comunidade VPN com details-level full em uma única chamada.

Use este modo ao verificar ambientes MDS de produção, servidores de gerenciamento ocupados ou implantações com dezenas de gateways, onde proteger a capacidade de resposta do fwm / API de Gerenciamento é mais importante do que o tempo de verificação mais rápido absoluto.

Algumas verificações exigem revisão do operador mesmo quando a condição automatizada de alto risco está ausente. As verificações de clientes confiáveis do SmartConsole, de contas de administrador e de política de senha / tempo limite de inatividade / expiração / bloqueio de administrador podem ser marcadas como revisadas. Na mesma sessão de login, o status muda para Reviewed. Um novo login altera o status de volta para Needs review, enquanto a última aprovação de revisão permanece visível com o nome de usuário e o timestamp da API de Gerenciamento conectada.

Para a verificação de política de senha / tempo limite de inatividade / expiração / bloqueio de administrador, os operadores também podem marcar a verificação como revisada enquanto ela estiver com Remediation Required. O aplicativo avisa que o operador está aceitando configurações que a Check Point não recomenda antes de registrar essa revisão.

O resumo superior combina as descobertas Remediation Required e Remediation Recommended em uma única contagem Remediation Needed.

Notas de Segurança

• O aplicativo usa HTTPS por padrão ao se conectar ao servidor de gerenciamento da Check Point.
• Não insira o servidor de gerenciamento como http://...; isso enviaria o login da API da Check Point por HTTP em texto claro.
• O navegador se comunica com o backend local via http://127.0.0.1:4000 por padrão, ou a próxima porta local disponível.
• O nome de usuário e a senha são enviados do navegador para o backend local apenas em localhost.
• O backend envia o nome de usuário e a senha para a Check Point por meio da solicitação de login da API de Gerenciamento.
• O aplicativo não registra senhas em log.
• O ID de sessão da Check Point é armazenado somente na memória do servidor durante a vida do processo local do Node.
• A opção Allow self-signed certificate mantém a criptografia TLS, mas desativa a validação do certificado. Use-a somente quando necessário.
• As ações de remediação exigem aprovação explícita do operador no navegador antes que o backend envie um comando de alteração.

Comandos de API Usados

O backend faz proxy destes comandos da API de Gerenciamento da 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

A verificação Security Feature Usage executa um run-script do Gaia em cada gateway gerenciado 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

O webapp faz login no domínio System Data da Management API, obtém os dados de name, type e dados de IP específicos do tipo do cliente confiável e os exibe em uma tabela de evidências. Ele marca a verificação como Remediação Necessária quando um objeto retornado tem type definido como any.

Quando um objeto de cliente confiável tem type definido como any, o aplicativo oferece a primeira ação de remediação. Ele consulta o uid real desse objeto e executa o equivalente a:```sh mgmt_cli delete trusted-client uid "" --domain "System Data" mgmt_cli publish --domain "System Data"

Para múltiplos clientes selecionados, o comando delete é executado uma vez para cada uid selecionado, seguido por um único publish. Se uma exclusão ou publicação falhar após as alterações serem iniciadas, o aplicativo tenta discard na mesma sessão de System Data.

A verificação de registro de log das regras implícitas executa o equivalente a:```sh mgmt_cli -r true show global-properties details-level full --format json

A verificação de acesso à API de Gerenciamento executa o equivalente a:```sh mgmt_cli -r true show api-settings --domain "System Data" --format json

Se o acesso à API já estiver limitado a clientes GUI, a verificação exibe a tabela de evidências de clientes confiáveis para revisão.

As verificações do Policy Insights executam chamadas somente leitura do 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

O webapp faz login no domínio System Data da API de gerenciamento para esta etapa de coleta e, em seguida, exibe uma tabela de evidências com Name, Permission Profile Name, Authentication-Method e expiration-date. Os valores de expiração são convertidos de iso-8601 para uma data e hora legíveis. Administradores sem a chave expiration-date são exibidos como Never.

A verificação de MFA e Integração com Provedor de Identidade usa show default-administrator-settings para exibir o authentication-method padrão e, em seguida, usa show-administrators para listar administradores cujo authentication-method é check point password ou os password. Se o método padrão ou qualquer administrador usar autenticação baseada em senha, a verificação é marcada como Remediação Recomendada. Os operadores podem marcar a seção como revisada, e o mesmo padrão de histórico de revisado por é exibido. A verificação inclui um botão de ajuda de configuração com orientações de configuração de SAML do SmartConsole e de IdP externo.

A tabela de contas de administrador permite que os operadores selecionem um ou mais objetos de administrador retornados e os excluam do webapp. O aplicativo valida os valores de uid selecionados em relação à saída atual de show-administrators e, em seguida, executa o equivalente a:```sh mgmt_cli delete administrator uid "" --domain "System Data" mgmt_cli publish --domain "System Data"

O webapp exibe as configurações retornadas em uma tabela Setting, Value e State. A expiração do administrador padrão definida como never, o tempo limite de inatividade do SmartConsole desabilitado, o bloqueio da conta de administrador desabilitado, o desbloqueio automático desabilitado ou min-password-length menor que 10 são marcados como necessitando de remediação.

Quando o método de autenticação do administrador padrão é check point password, a coluna State recomenda usar um método de autenticação que suporte MFA ou um Provedor de Identidade externo.

Para a expiração do administrador padrão, a coluna State exibe o detalhe de expiração retornado: um valor formatado de expiration-date, ou o valor de expiration-period mais expiration-period-time-units quando o tipo é expiration-period.

Quando a expiração do administrador padrão é definida como never, o aplicativo oferece uma ação de remediação recomendada. Ele executa o equivalente a:```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"

Se a publicação falhar após a alteração do tempo limite de inatividade, o aplicativo tenta discard na mesma sessão System Data.

Quando o comprimento mínimo da senha é menor que 10, o aplicativo oferece uma ação de remediação recomendada. Ele executa o equivalente a:```sh mgmt_cli set cp-password-requirements min-password-length "10" --domain "System Data" --format json mgmt_cli publish --domain "System Data"

2. Baixe ou clone este projeto. ```sh git clone cd "Check Point Trusted Access Review"
   root@kitploit:~

3. Instale as dependências e inicie o aplicativo local. ```sh npm install npm start
   root@kitploit:~

4. Abra o aplicativo. ```text http://127.0.0.1:4000
   root@kitploit:~

Windows a partir do código-fonte

1. Instale o Node.js 18 ou mais recente a partir de nodejs.org.

2. Baixe e extraia o ZIP do projeto, ou clone o repositório com o Git para Windows. ```powershell git clone cd "Check Point Trusted Access Review"

   root@kitploit:~

3. Instale as dependências e inicie o aplicativo local. ```powershell npm install npm start

   root@kitploit:~

4. Abra o aplicativo em um navegador. ```text http://127.0.0.1:4000

   root@kitploit:~

Alteração Opcional de Porta

Por padrão, o aplicativo prefere 127.0.0.1:4000 e sobe automaticamente se a porta estiver ocupada. Para exigir uma porta específica:

macOS:```sh PORT=4500 npm start

Em seguida, abra:```text http://127.0.0.1:4500

Se o navegador exibir um erro de login com um ID de requisição, mas a captura de pacotes não mostrar nenhuma tentativa de saída para o servidor de gerenciamento, compare o valor target= no terminal com o filtro de captura de pacotes.

Se não houver nenhuma linha Local API request, o navegador não está alcançando o backend local. Confirme se o aplicativo está em execução e se você abriu o URL local correto.