Objetivo

Este documento orienta a equipe de TI na criação das regras mínimas e corretas no Check Point Firewall para que o Insoft Hikvision Service funcione integralmente no ambiente do cliente, especialmente no recebimento de eventos enviados automaticamente pelos equipamentos Hikvision.

O ponto crítico identificado é o Servidor de Eventos criado pelo Insoft Hikvision Service. Os equipamentos Hikvision tentam enviar eventos HTTP para esse servidor, porém a conexão está sendo bloqueada antes de chegar ao serviço. A evidência coletada em teste HTTP apresentou erro de conexão para:

http://10.91.235.173:8888/eventRegistration

O erro retornado foi equivalente a Unable to connect to the remote server, indicando falha de conectividade TCP/HTTP até a porta do serviço. Isso não caracteriza erro de regra de negócio, autenticação ou payload da aplicação; caracteriza bloqueio, roteamento incorreto ou inspeção/rejeição de tráfego no caminho de rede.

Resumo Executivo para a TI

O Insoft Hikvision Service é um serviço Windows local, executado dentro da rede corporativa, que integra equipamentos Hikvision com as APIs corporativas akitasoft-gear-api ou pontosoft-gear-api.

O serviço não deve ser publicado na internet e não precisa receber conexões externas da WAN. A comunicação necessária é restrita ao ambiente interno, entre LANs/VLANs corporativas:

• Equipamentos Hikvision -> servidor do Insoft Hikvision Service, para envio de eventos em tempo real.
• Servidor do Insoft Hikvision Service -> equipamentos Hikvision, para configuração, sincronização, cadastro e consulta via ISAPI.
• Servidor do Insoft Hikvision Service -> API corporativa configurada, para autenticação, consulta de comandos, sincronização de eventos e atualização de status.
• Opcionalmente, servidor do Insoft Hikvision Service -> Hikvision Device Gateway, quando o modo Device Gateway estiver habilitado.

A liberação recomendada deve ser feita por IP/objeto de origem e destino, com portas explícitas e logging ativo. Não é necessário liberar Any -> Any, nem publicar NAT de internet para o servidor.

Funcionamento do Serviço

1. Serviço Windows local

O Insoft Hikvision Service roda como serviço Windows por meio de UseWindowsService(). Durante a inicialização ele carrega configurações locais, inicializa logs, banco SQLite local e injeta as bibliotecas:

• security-gear-lib-api
• common-gear-lib-api
• akitasoft-gear-lib-api
• pontosoft-gear-lib-api
• insoft-automacao-facial-lib-api
• camada própria insoft-hikvision-service

Essas bibliotecas não expõem um portal público. Elas executam rotinas locais de integração, comunicação HTTP com dispositivos Hikvision e comunicação HTTP/REST com a API corporativa configurada.

2. Comunicação com os equipamentos Hikvision

No modo ISAPI direto, o serviço se comunica com cada equipamento Hikvision por HTTP usando o IP e a porta cadastrados para o equipamento. Quando a porta do equipamento não é informada, o serviço usa porta 80 como padrão.

O serviço envia requisições para endpoints ISAPI como:

• endpoints de configurações do dispositivo
• endpoints de cadastro de pessoa, cartão, face, digital e placas.

Essa comunicação usa credenciais do próprio equipamento, com autenticação HTTP Digest. O tráfego é interno, originado pelo servidor do Insoft Hikvision Service e destinado aos IPs dos equipamentos Hikvision.

3. Servidor de Eventos criado pelo serviço

O recurso mais importante para esta liberação é o Servidor de Eventos.

O Insoft Hikvision Service cria internamente um servidor HTTP Kestrel, escutando no IP configurado e na porta configurada em eventServerPort. O valor padrão é:

TCP 8888

O endpoint exposto localmente é:

POST /eventRegistration

Ao configurar cada Hikvision, o serviço envia para o equipamento uma configuração em:

PUT /ISAPI/Event/notification/httpHosts

Nessa configuração, o equipamento recebe os dados do servidor de eventos:

url: /eventRegistration
protocolType: HTTP
parameterFormatType: JSON
addressingFormatType: ipaddress
ipAddress: <IP do servidor Insoft Hikvision Service>
portNo: <eventServerPort, padrão 8888>
httpAuthenticationMethod: none

Depois disso, o fluxo passa a ser:

Equipamento Hikvision -> HTTP POST -> Insoft Hikvision Service:8888/eventRegistration

Os eventos podem chegar como multipart/form-data, contendo JSON, XML e imagens capturadas pelo equipamento. O serviço processa o payload, identifica o equipamento por IP/MAC, salva o evento localmente e depois sincroniza com a API corporativa.

Importante: o método httpAuthenticationMethod é none porque esse é o modelo de notificação HTTP usado pelo equipamento para eventos. A proteção desse endpoint deve ser feita por rede: permitir somente os IPs/VLANs dos equipamentos Hikvision para o IP e porta do serviço.

4. Validação remota de acesso

Quando o módulo é AkitaSoft e o equipamento está configurado para validação remota, o fluxo é sensível a latência:

1. O Hikvision envia o evento de acesso para servidor de eventos do Insoft Hikvision Service.
2. O Insoft Hikvision Service consulta a API em akitasoft-gear-api.
3. A API responde se o acesso deve ser liberado ou bloqueado.
4. O Insoft Hikvision Service responde ao equipamento para concluir a validação realtime

O timeout padrão de validação é curto, configurado em eventValidationTimeout com valor padrão de 3 segundos. Portanto, inspeções profundas, bloqueios intermitentes ou filas de análise no firewall podem causar falha funcional mesmo quando a porta parece liberada.

5. Comunicação com akitasoft-gear-api e pontosoft-gear-api

A comunicação com as APIs corporativas é sempre originada pelo servidor onde roda o Insoft Hikvision Service, usando o urlApi configurado localmente.

Fluxo base:

Insoft Hikvision Service -> akitasoft-gear-api ou pontosoft-gear-api

Recursos comuns usados pelas bibliotecas:

• Cadastros de pessoas
• Cadastros de biometrias faciais
• Cadastros de biometrias digitais
• Sincronização de eventos
• Validações de acessos em realtime
• Entre outros recursos gerenciáveis

Após autenticar na API (akitasoft-gear-api ou pontosoft-gear-api) , as chamadas ficam protegidas e usam token no header Authorization.

Regras Mínimas Necessárias

Substituir os exemplos abaixo pelos IPs/objetos reais do ambiente.

Configuração Recomendada no Check Point

1. Criar objetos de rede

No SmartConsole, criar ou validar os seguintes objetos:

• SRV-INsoft-Hikvision-Service: host do servidor onde o serviço roda. Exemplo identificado no teste: 10.91.235.173.
• GRP-Hikvision-Devices: grupo contendo todos os IPs dos equipamentos Hikvision autorizados a enviar eventos.
• NET-Hikvision-VLAN, se a TI preferir trabalhar por subnet, desde que a VLAN contenha apenas equipamentos autorizados.
• SRV-AkitaSoft-Gear-API ou SRV-PontoSoft-Gear-API: destino real da API configurada em urlApi.
• SRV-Hikvision-DeviceGateway, apenas se houver Device Gateway.

Evitar objetos muito amplos como Any, Internet, Internal Network completa ou redes que contenham estações de usuário sem relação com os equipamentos.

2. Criar serviços TCP customizados

Criar os serviços necessários em Services & Applications:

• TCP-INsoft-Hikvision-EventServer-8888

  • Protocol: TCP
  • Port: 8888, ou o valor real de eventServerPort

• TCP-Hikvision-ISAPI

  • Protocol: TCP
  • Port: 80, ou a porta HTTP configurada nos cadastros dos equipamentos
  • Se houver equipamentos com portas diferentes, criar objetos separados por porta e usar somente as portas realmente cadastradas.

• TCP-Gear-API

  • Protocol: TCP
  • Port: 443, 80 ou porta customizada conforme o urlApi.

• TCP-Hikvision-DeviceGateway-8180, se aplicável

  • Protocol: TCP
  • Port: 8180, ou deviceGatewayPort.

3. Criar regras na Access Control Policy

As regras devem ficar antes da regra de limpeza/drop geral e antes de regras genéricas que possam bloquear tráfego entre VLANs.

Regra A - Recebimento de eventos Hikvision

Name: ALLOW-HIKVISION-TO-INSOFT-EVENTS
Source: GRP-Hikvision-Devices
Destination: SRV-INsoft-Hikvision-Service
VPN: Any ou conforme comunidade VPN interna, se existir
Services & Applications: TCP-INsoft-Hikvision-EventServer-8888
Action: Accept
Track: Log
Install On: gateway/cluster que roteia as VLANs envolvidas

Essa é a regra que corrige o problema evidenciado no teste de conexão. Sem ela, os equipamentos não conseguem entregar eventos ao serviço.

Regra B - Gestão dos equipamentos pelo serviço

Name: ALLOW-INSOFT-TO-HIKVISION-ISAPI
Source: SRV-INsoft-Hikvision-Service
Destination: GRP-Hikvision-Devices
Services & Applications: TCP-Hikvision-ISAPI
Action: Accept
Track: Log
Install On: gateway/cluster que roteia as VLANs envolvidas

Essa regra permite que o serviço configure os equipamentos, consulte capacidades, cadastre dados, ajuste horário, configure o servidor de eventos e responda validações remotas.

Regra C - Comunicação com a API corporativa

Name: ALLOW-INSOFT-TO-GEAR-API
Source: SRV-INsoft-Hikvision-Service
Destination: SRV-AkitaSoft-Gear-API ou SRV-PontoSoft-Gear-API
Services & Applications: TCP-Gear-API
Action: Accept
Track: Log
Install On: gateway/cluster responsável pelo caminho até a API

Essa regra não deve liberar navegação geral para internet. O destino deve ser a API real configurada no serviço.

Regra D - Device Gateway, se habilitado

Name: ALLOW-INSOFT-TO-HIKVISION-DEVICE-GATEWAY
Source: SRV-INsoft-Hikvision-Service
Destination: SRV-Hikvision-DeviceGateway
Services & Applications: TCP-Hikvision-DeviceGateway-8180
Action: Accept
Track: Log
Install On: gateway/cluster responsável pelo caminho

Criar somente quando o deviceGatewayEnabled estiver habilitado.

4. NAT

Não aplicar NAT para o fluxo interno entre equipamentos Hikvision e Insoft Hikvision Service, salvo se a arquitetura da rede exigir e o IP configurado nos equipamentos for exatamente o IP pós-NAT.

Recomendação:

• Equipamento Hikvision deve alcançar o mesmo IP configurado em eventServerAddress ou deviceGatewayExternalHost.
• O IP de origem do equipamento deve ser preservado sempre que possível, pois o serviço usa IP/MAC para identificar o dispositivo.
• Não publicar TCP 8888 na internet.
• Não criar NAT de entrada WAN -> servidor para este serviço.

5. Anti-Spoofing, roteamento e VLANs

Validar no Check Point:

• Topologia correta das interfaces e VLANs no gateway.
• Anti-Spoofing permitindo os IPs reais das VLANs de equipamentos.
• Rota de ida e volta entre VLAN dos Hikvision e VLAN do servidor.
• Instalação da política no gateway/cluster que efetivamente roteia o caminho.

Um cenário comum é a regra estar correta em um cluster, mas o tráfego passar por outro enforcement point ou ser derrubado por Anti-Spoofing/topologia.

6. Threat Prevention, IPS, Application Control e Content Awareness

O tráfego do Servidor de Eventos é HTTP interno e pode conter multipart com JSON, XML e imagem JPEG. Alguns blades podem bloquear ou reclassificar o tráfego mesmo quando a Access Control Rule permite a porta.

Se houver drop ou reset nos logs do Check Point, validar:

• Access Control Policy
• Application Control / URL Filtering
• IPS
• Threat Prevention
• Content Awareness / DLP
• HTTPS Inspection não se aplica ao evento HTTP puro, mas políticas de inspeção HTTP podem interferir.

Caso seja necessário criar exceção, ela deve ser cirúrgica:

Source: GRP-Hikvision-Devices
Destination: SRV-INsoft-Hikvision-Service
Service: TCP-INsoft-Hikvision-EventServer-8888
Scope: somente VLAN/IPs dos Hikvision e servidor do serviço

Não é recomendado desabilitar inspeções para redes inteiras. A exceção deve ser limitada ao fluxo do evento e registrada em log.

Validação Pós-Regra

1. Validar se o serviço está escutando no servidor

No servidor do Insoft Hikvision Service:

Get-NetTCPConnection -LocalPort 8888 -State Listen

Ou:

netstat -ano | findstr :8888

Se a porta não estiver em LISTEN, validar se o serviço está iniciado e se o IP configurado em eventServerAddress corresponde a um IP local do servidor.

2. Testar conectividade a partir da VLAN dos equipamentos

Executar de uma estação de teste na mesma VLAN dos Hikvision, ou de um equipamento/rede com a mesma política:

Test-NetConnection 10.91.235.173 -Port 8888

Resultado esperado:

TcpTestSucceeded : True

Também é possível testar HTTP:

Invoke-WebRequest -Method Post -Uri "http://10.91.235.173:8888/eventRegistration"

Resultado esperado: conexão estabelecida e resposta HTTP do serviço, sem Unable to connect to the remote server, timeout ou reset.

3. Validar logs no Check Point

Em Logs & Monitor, filtrar por:

src:<IP do Hikvision> dst:10.91.235.173 service:8888

Esperado:

• Rule name: ALLOW-HIKVISION-TO-INSOFT-EVENTS
• Action: Accept
• Blade: Access Control
• Sem drop/reset por IPS, Threat Prevention ou Application Control.

Se houver drop, o log indicará a regra/blade responsável. Ajustar a regra ou exceção com base nesse log, mantendo o escopo mínimo.

4. Validar evento real

Após a liberação:

1. Reiniciar ou reprocessar a configuração do equipamento pelo Insoft Hikvision Service, se necessário.
2. Gerar um evento real no equipamento Hikvision.
3. Confirmar no log do serviço o recebimento do evento em /eventRegistration.
4. Confirmar que o evento foi salvo no banco local e sincronizado com a API.
5. Confirmar, se aplicável, que a validação remota responde dentro do timeout configurado.

Checklist de Liberação

• IP do servidor Insoft Hikvision Service confirmado.
• eventServerPort confirmado; padrão 8888.
• eventServerAddress ou deviceGatewayExternalHost aponta para IP alcançável pelos Hikvision.
• Grupo de IPs Hikvision criado no Check Point.
• Regra Hikvision -> Insoft na porta
  8888 criada, com Accept e Log.
• Regra Insoft -> Hikvision nas portas ISAPI cadastradas criada, com
  Accept e Log.
• Regra Insoft -> API criada apenas para o destino real da API.
• Device Gateway validado, se habilitado.
• NAT não aplicado indevidamente ao fluxo interno.
• Anti-Spoofing/topologia das VLANs validada.
• Threat Prevention/IPS/Application Control verificados para não bloquear multipart HTTP interno.
• Política instalada no gateway/cluster correto.
• Teste
  Test-NetConnection a partir da VLAN dos equipamentos retorna TcpTestSucceeded : True.
• Evento real gerado no Hikvision chega ao serviço.

Observações de Segurança

O Insoft Hikvision Service é seguro dentro do modelo proposto porque:

• Deve operar apenas em rede local corporativa.
• Não exige exposição para internet.
• A porta de eventos deve aceitar somente origens conhecidas: equipamentos Hikvision ou Device Gateway autorizado.
• O serviço não disponibiliza interface administrativa pública.
• A comunicação com os equipamentos usa credenciais dos dispositivos.
• A comunicação com as APIs corporativas usa autenticação e token.
• Logs, imagens de eventos e banco SQLite ficam no diretório local do serviço.

A postura correta no Check Point é permitir explicitamente os fluxos necessários e bloquear todo o restante. A liberação ampla de redes ou portas não é necessária para o funcionamento do serviço.

Conclusão

Para o Insoft Hikvision Service funcionar 100%, a TI precisa garantir principalmente que os equipamentos Hikvision consigam abrir conexão HTTP interna para:

10.91.235.173:8888/eventRegistration

ou para o IP/porta equivalentes configurados no ambiente.

Além disso, o servidor do serviço precisa conseguir acessar os equipamentos Hikvision nas portas ISAPI cadastradas e a API corporativa configurada em urlApi. Com essas regras mínimas, sem exposição à internet e com logging ativo, o serviço fica funcional e mantém o princípio de menor privilégio na rede.