Security Overview¶
ForensiQ can be deployed as a standalone system or as a distributed deployment consisting of Core and Indexer nodes.
Security-related options such as HTTPS for user-facing endpoints and encrypted communication between ForensiQ nodes can be configured during installation. Irisity recommends enabling these options for production deployments.
ForensiQ Endpoints¶
Secured Endpoints¶
- Web interface and REST API communication can be secured using HTTPS.
- Supports certificates issued by a well-known CA, customer-provided certificates, and self-signed certificates.
- Communication between Core and Indexer services can be secured using mutual TLS (mTLS).
Data Encryption¶
- Data transferred between clients and the ForensiQ Core or Standalone node is encrypted using TLS when HTTPS is enabled.
- Communication between Core and Indexer nodes is encrypted using mutual TLS when internal encryption is enabled.
- A customer-provided Certificate Authority can be used for internal service communication.
Data Validation¶
- REST API input is serialized into defined structured data models.
- Server-side validation is applied to API request data and configuration values where applicable.
- Invalid or unsupported values are rejected before the corresponding operation is processed.
Secured endpoints¶
Web interface and REST API¶
The ForensiQ web interface and REST API are exposed through a reverse proxy.
HTTPS can be enabled during installation. The following certificate options are supported:
- Official CA – a publicly trusted certificate is automatically obtained from Let's Encrypt and renewed automatically.
- Custom certificate – a certificate and private key provided by the customer are used.
- Self-signed certificate – a locally generated certificate is used.
When HTTPS is enabled, communication between clients and the ForensiQ web interface and REST API is encrypted using TLS.
HTTP can also be configured. When HTTP is used, protection of the communication through network isolation or other surrounding infrastructure is the responsibility of the customer.
For production environments, Irisity recommends enabling HTTPS.
Communication between ForensiQ nodes¶
Distributed ForensiQ deployments can use encrypted communication between Core and Indexer nodes.
When internal encryption is enabled, ForensiQ uses mutually authenticated TLS connections between participating services.
The Certificate Authority and certificates required for this communication can be generated and managed as part of the ForensiQ deployment. A customer-provided Certificate Authority can also be used.
The following network services are used in a distributed deployment:
| Port | Service | Security |
|---|---|---|
| 29092/TCP | Metadata broker | Mutual TLS when internal encryption is enabled |
| 54111/TCP | Indexer service | Mutual TLS when internal encryption is enabled |
| 7177/TCP | Video Storage service | Mutual TLS when internal encryption is enabled |
| 9464/TCP | Indexer monitoring | Mutual TLS when internal encryption is enabled |
| 9465/TCP | Video Storage monitoring | Direct endpoint used by the local monitoring proxy; mTLS is provided on port 9464 when internal encryption is enabled |
| 9092/TCP | Internal metadata broker communication | Bound to localhost and not intended for external access |
Only systems participating in the ForensiQ deployment should be permitted to access internal service ports.
On Indexer and Standalone deployments, the Video Storage service uses the host network and listens on TCP port 7177 and exposes its metrics endpoint on TCP port 9465 in the host network namespace. The local monitoring proxy and other required ForensiQ services running in Docker networks on the same host must be able to communicate with these ports. The Video Storage service must also be able to reach the required Docker-networked services.
The host firewall must therefore permit the required communication between the ForensiQ Docker networks and the host network namespace in both directions.
Port 9465 is the direct Docker-to-host metrics connection and should not be exposed to unrelated networks. When internal encryption is enabled, monitoring access is protected with mTLS through the monitoring proxy on port 9464; the direct connection to port 9465 is not itself mTLS-protected.
Authentication¶
ForensiQ uses individual user accounts for access to the application.
Password authentication is used for interactive application access. Public user registration is disabled, and users are created and managed by authorized administrators.
Passwords are stored using bcrypt password hashing.
Application sessions are time-limited.
Authorization¶
ForensiQ provides role- and group-based access control.
Users can be assigned to one or more groups. Groups determine the permissions available to their members as well as access to folders and the video data contained within them.
ForensiQ provides predefined application roles for different responsibilities, including:
- Administrator – system and user administration;
- Technician – technical configuration and maintenance functions;
- Investigator – investigation and search functionality;
- Operator – primarily read-only operational access.
Access should be granted according to the responsibilities of each user.
Audit logging¶
ForensiQ records security- and application-related audit information, including authentication attempts and audited application operations.
Audit logs can be used to review activity performed through the application and assist with security investigations and operational troubleshooting.
Audit log retention is configurable.
Audit log retention is currently configurable through the REST API only. There is no corresponding configuration option in the ForensiQ web interface.
Host and installation access¶
ForensiQ installation, upgrades, and maintenance require administrative access to the underlying Linux hosts.
Irisity recommends creating a dedicated Linux user account for ForensiQ installation and maintenance, rather than using a personal administrator account or direct root login.
The dedicated account must have sudo access with the ability to become root. The ForensiQ installer uses Ansible privilege escalation for system-level installation and configuration operations, and a restricted set of individual sudo commands is not currently supported.
The installer supports both SSH password authentication and SSH private-key authentication.
SSH private-key authentication is recommended where permitted by the customer's security policy. Regardless of the authentication method, SSH access should be restricted to authorized personnel and trusted administrative networks.
The installation account also requires access to the Docker daemon.
Using a dedicated account provides a consistent administrative identity for installation, upgrades, troubleshooting, and maintenance while separating ForensiQ administration from personal operating-system accounts.
Service isolation and host firewall¶
ForensiQ services are deployed as Docker containers.
Most application services communicate over Docker networks. On Indexer and Standalone deployments, the Video Storage service is an exception and uses the host network, including port 7177 for the service and port 9465 for its metrics endpoint.
As a result, services running inside the ForensiQ Docker networks must be able to communicate with the Video Storage service through the host network. In particular, the local monitoring proxy must be able to connect from the Docker network to host port 9465. The Video Storage service must also be able to communicate with the required Docker-networked services.
The host firewall must therefore permit the required traffic between the ForensiQ Docker networks and the host network namespace in both directions.
Firewall rules should be limited to the traffic required by ForensiQ rather than allowing unrestricted communication between the host and Docker networks.
Only the ports required for the selected ForensiQ deployment type should be accessible from other systems.
Operating-system hardening, host firewall configuration, and network segmentation remain the responsibility of the customer.
Recommended secure deployment¶
For production deployments, Irisity recommends:
- enabling HTTPS for the ForensiQ web interface and REST API;
- using a publicly trusted certificate or the customer's own PKI where appropriate;
- enabling internal encryption in distributed Core/Indexer deployments;
- restricting ForensiQ internal service ports to the participating nodes;
- ensuring that the host firewall permits the required communication between ForensiQ Docker networks and the host network namespace, particularly for the Video Storage service on Indexer and Standalone deployments;
- avoiding unrestricted host-to-Docker or Docker-to-host firewall rules where more specific rules can be used;
- using a dedicated Linux account for ForensiQ installation and maintenance;
- granting the installation account sudo access required by the installer instead of using direct root SSH access;
- preferring SSH private-key authentication where appropriate;
- restricting SSH and other administrative access to trusted networks;
- applying operating-system security updates and following the customer's standard host-hardening policies.