Is commercial use supported?

Yes.

Suri Oculus can be:

  • used in commercial and corporate environments;
  • integrated into company and service provider infrastructures;
  • applied in security consulting and audits.

Restrictions depend on the specific component and its license, but commercial use itself is not prohibited.

Open source or closed source?

The project follows a hybrid model:

  • some components and interfaces are openly available;
  • key modules (for example, AI logic and C++ feature extraction) are distributed in binary form.

This approach is intentional:

  • to protect intellectual property;
  • to enable future commercial development.

Can it be used in production?

Yes, but with a clear understanding of its limitations.

At the current stage:

  • the system is stable in detection mode;
  • it is suitable for production environments with moderate load;
  • AI modules are designed to assist analysts, not to perform automatic blocking.

Recommendation:

  • use Suri Oculus as an observation and analytics layer;
  • avoid building critical automated blocking mechanisms without additional validation.

Who is the project intended for (SOC, SMB, homelab)?

The project is aimed at:

  • SOC / Blue Team — as an additional tool for analysis and correlation;
  • SMB / small infrastructures — where there is no budget for heavy SIEM solutions;
  • homelab users, engineers, and researchers — for studying network traffic and anomalies.

Suri Oculus does not attempt to replace SIEMs like Splunk, but it fills the gap between raw Suricata logs and expensive enterprise solutions.

How does Suri Oculus differ from “pure” Suricata?

Suricata is an IDS/IPS engine. It analyzes network traffic and writes events to logs.
Suri Oculus is a management and analytics layer built around Suricata.

Key differences:

  • centralized management of Suricata (configuration, modes, rules);
  • storage and processing of events via Redis instead of direct work with eve.json;
  • a web interface for analysis, filtering, and visualization;
  • AI modules for anomaly detection (Flow, DNS, TLS, HTTP, etc.);
  • designed to run on low- and mid-range hardware.

In simple terms: Suricata is a sensor, Suri Oculus is an observation and analysis system.

What is Oculus Tools?

Oculus Tools is a set of scripts that automates downloading, filtering, and encoding domain lists from various categories (general threats, fake news, gambling, adult content, social networks). The scripts fetch source files, remove duplicates and unnecessary entries, and then encode the final result into Base64 format, ready for use in blocking and traffic analysis systems.

The toolkit includes: download_lists.py (list downloading), prefilter_app (data cleanup), base64coder_app (encoding), and the control script make_base_opt.sh.

Primary use cases include domain blocking for IDS/IPS environments, DNS filtering, proxy servers, and analysis of unwanted network traffic.

What operating systems was the project tested on?

Currently, we are presenting the beta version of the Suri-Oculus system. It has been tested on Fedora 38 and Fedora 39. Testing on Ubuntu 24 and Clear OS is beginning.

Which SELinux mode is recommended?

Recommended modes:

  • Permissive — for initial setup and debugging;
  • Enforcing — after policies are properly configured.

Reasoning:

  • Suricata, Redis, and custom services require correctly defined rules;
  • the project intentionally does not impose automatic SELinux policies.

In production:

  • Enforcing + custom policies is the correct approach;
  • Permissive is acceptable in isolated or closed environments.

Is Docker required?

No.

Docker is:

  • not mandatory;
  • not used by default;
  • not part of the core architecture.

Suri Oculus is designed for:

  • native installation;
  • systemd-managed services;
  • minimal runtime overhead.

Docker may be used optionally, for example for testing purposes.

Can it run on low-end hardware or routers?

Yes, with limitations.

Suitable for:

  • mini PCs;
  • older servers;
  • low-power x86 routers.

What can be disabled:

  • AI modules;
  • advanced visualizations;
  • long-term data retention.

Not suitable for:

  • ARM routers without a proper user-space;
  • systems with less than 1 GB of RAM;
  • environments without Redis and systemd.

The project’s approach is to work even where a full SIEM cannot run at all.

Minimum CPU / RAM / disk requirements

Minimum for a functional system (detection + web interface):

  • CPU: 2 x86_64 cores
  • RAM: 2 GB (4 GB recommended for comfortable operation)
  • Disk: from 10 GB
  • Network: 1 Gbps (without deep packet capture)

Recommended for AI-based analysis:

  • 4+ CPU cores;
  • 8 GB RAM;
  • SSD storage.

Note: the system scales with workload, not with formal hardware requirements.

Which operating systems are supported (Fedora, RHEL, Debian)?

Officially and practically supported:

  • Fedora (primary development platform);
  • RHEL / Rocky / AlmaLinux (production-oriented systems);
  • Debian / Debian-based distributions (including Ubuntu — without distribution-specific dependencies).

Requirements:

  • systemd;
  • a modern Linux kernel;
  • standard user-space tools (glibc, iproute2, etc.).

Exotic distributions may work, but are not tested and not supported.

Which operating systems can Suri Oculus be installed on?

Currently, packages are available for Fedora 39, Fedora 40, Fedora 41, and 42, as well as CentOS 9.
There are also packages for Debian 12 and Ubuntu 22.04.

How to control daemonmove

Daemonmove (suricata eve.log parser) is usual systemd service and can be managed as usual:

systemctl start daemonmove

systenctl stop daemonmove.

How to configure daemonmove

The configuration file conf.cfg for the daemonmove service is located in the /etc/redismove directory.
This file defines the main operating parameters of the service, including keys for event distribution and paths to log and temporary files.
Keys corresponde to events names.
Main key is redis key to which suricata outputs eve.log.

# Configuration file for the application

application:
{
main:
{
title = “REDISMOVE”;
version = “0.8.2”;
date = “23 Mar 2024”;
};

settings:
{
main_key = “suricata”;
keys = (“alert”, “anomaly”, “dcerpc”, “flow”, “http”, “dns”, “drop”, “stats_report”, “fileinfo”, “tls”, “stats”, “ftp”, “sip”, “smb”, “snmp”, “ssh”, “flow_data”, “tftp”, “ssh”, “bittorrent_dht”, “rdp”, “http2”, “pqsql”, “quic”, “modbus”);
valid_duration = 24;
log_file = “/var/log/suricata/eve.json”;
temp_file = “/tmp/daemonparser/current”;
};

What port does the web client use?

It uses port 7878

What port does the backend service use?

It uses 8080 port.

Can AI modules be disabled?

Yes, completely.

Possible operating modes:

  • Suricata + visualization (no AI);
  • Suricata + AI-based analysis;
  • analytics without active AI detection.

AI modules:

  • do not affect the operation of the core system;
  • are not mandatory;
  • are not involved in traffic blocking.

This is a deliberate design choice: AI is an assistant to the analyst, not a “black box.”

Where are logs and models stored?

Suricata logs:

  • are not used directly as eve.json;
  • data is written to and processed via Redis;
  • export to files is possible if required.

AI models:

  • are stored locally on the server;
  • loaded by Python modules at startup;
  • do not require external access or cloud services.

No data is sent outside the system.

How do the C++ backend and the web interface interact?

The interaction model is as follows:

C++ backend:

  • manages Suricata;
  • receives events;
  • writes data to Redis;
  • exposes REST endpoints.

Web interface:

  • works directly with the REST API;
  • reads aggregated data from the backend;
  • does not interact with C++ directly.

C++ is used where the following are critical:

  • performance;
  • low latency;
  • operation on low-end hardware.

Why Redis is used and what is stored in it?

Redis is used not as a cache, but as a working data store.

Stored in Redis:

  • Suricata events (Flow, DNS, HTTP, TLS, etc.);
  • aggregated statistics;
  • temporary states and counters;
  • data for AI analysis;
  • anomaly results and labels.

Reasons for choosing Redis:

  • high performance;
  • minimal disk I/O;
  • convenient handling of streaming and time-series data;
  • ability to operate without heavy databases.

This is a core element of the system’s performance.

What components does the system consist of?

Suri Oculus consists of a set of specialized components, each responsible for a specific task:

  • Suricata — network IDS/IPS engine, the source of events and telemetry;

  • daemonmove — a custom log parsing service:

    • receives Suricata events;

    • normalizes and filters data;

    • controls the event flow;

    • writes processed data to Redis;

  • Backend (C++) — management of Suricata and the system as a whole:

    • configuration;

    • operating modes;

    • REST API;

  • Redis — the central working data store:

    • events;

    • aggregates;

    • temporary states;

    • data for analytics and AI;

  • AI backend (Python / FastAPI) — behavioral and anomaly analysis;

  • Web interface (HTML + plain JavaScript) — visualization and analytics;

  • oculus tools — a set of auxiliary CLI tools:

    • diagnostics;

    • testing;

    • data maintenance and housekeeping;

    • automation of routine operations.

The architecture is designed to:

  • be independent of the eve.json format;
  • minimize disk I/O;
  • operate reliably under load;
  • scale components independently rather than as a monolith.

Can the system be used without AI?

Yes, completely.

Suri Oculus can operate:

  • as a Suricata event visualization and analysis system;
  • as a manual analysis tool;
  • without running AI modules at all.

AI:

  • does not affect core functionality;
  • is not involved in traffic blocking;
  • is enabled only when explicitly required.

Are there false positives?

Yes, as with any anomaly detection system.

It is important to understand that:

  • AI detects deviations, not “attacks”;
  • an anomaly ≠ an incident;
  • some detections require interpretation by an analyst.

The project’s approach is to:

  • show the reason and context of an anomaly;
  • allow comparison between time periods;
  • avoid making automatic decisions on behalf of the user.

Is training on your own data required?

Recommended, but not strictly mandatory.

Usage options:

  • pre-trained models — for quick deployment;
  • fine-tuning on local data — to improve accuracy;
  • full retraining — for highly specific networks.

The more stable and “clean” the baseline traffic, the better the detection quality.

Which models are used?

The system is based on unsupervised anomaly detection models designed to work without labeled data.

Currently used approaches include:

  • Isolation Forest and related methods;
  • statistical and behavioral profiling;
  • custom feature extraction (partially implemented in C++).

The models are chosen because they:

  • do not require labeled datasets;
  • are resilient to noise;
  • operate effectively on limited resources.

What types of data are analyzed (Flow, DNS, TLS, etc.)?

AI modules analyze behavioral and network features extracted from Suricata events.

Supported data types:

  • Flow — network flows (volume, direction, duration, frequency);
  • DNS — queries, responses, and domain behavior;
  • TLS — handshake characteristics, versions, JA-like features;
  • HTTP — methods, headers, and request patterns;
  • Metadata — aggregated and time-based behavioral features.

The analysis is based on deviations from normal behavior rather than signatures.

Are logs encrypted?

By default:

  • logs are not encrypted at the application level.

Reasons:

  • minimal overhead;
  • high performance;
  • simplicity of integration.

Recommended approach:

  • disk encryption (LUKS);
  • strict host access control;
  • network and service isolation.

If required, encryption should be implemented at the infrastructure level rather than within the application itself.

What data is stored and for how long?

Types of stored data:

  • Suricata events (Flow, DNS, HTTP, TLS, etc.);
  • aggregated statistics;
  • AI analysis results and anomaly labels;
  • internal system states.

Retention period:

  • configurable by the administrator;
  • determined by Redis cleanup policies;
  • not hardcoded into the system.

By default, the system does not assume infinite data retention.

Can it be used in an isolated network?

Yes.

The system is designed to operate:

  • in closed network segments;
  • in isolated (air-gapped) environments;
  • without internet access.

The only requirement is local administrative access to the host.

Are there any cloud components?

No.

Suri Oculus is a fully on-premise system:

  • no SaaS components;
  • no mandatory cloud services;
  • no external network dependencies.

Even AI analysis is performed locally.

Is any data sent anywhere?

No.

Suri Oculus:

  • does not send telemetry;
  • does not use external APIs;
  • does not transmit data to the developer or third parties.

All data remains within your infrastructure.

Can users participate in the project’s development?

Yes.

Possible forms of participation:

  • testing and feedback;
  • architecture and feature proposals;
  • publication of real-world use cases;
  • contributions to documentation and translations.

The project is aimed at a professional audience, not at open source “for the sake of it.”

How often are updates released?

Updates are released when they are ready, not on a fixed schedule.

Types of updates include:

  • fixes and improvements;
  • performance optimizations;
  • new modules and analytics;
  • interface and documentation updates.

The project is developed iteratively, with a strong focus on stability.

Are paid features planned?

Yes, in the future.

Currently under consideration:

  • advanced AI modules;
  • additional analytics capabilities;
  • features for corporate and distributed environments;
  • priority support.

The core functionality of the project is not planned to be closed.

Is commercial support available?

At the moment — limited.

Support may be provided in the form of:

  • consultations;
  • deployment assistance;
  • adaptation to specific infrastructures;
  • performance and data analysis.

Full enterprise-level support will depend on demand and the further development of the project.

Which license is used?

Suri Oculus follows a hybrid licensing model.

  • open components are distributed under permissive open-source licenses;
  • key modules (AI analysis, C++ feature extraction, some services) are distributed in binary form;
  • Suricata is used under its own license terms.

This approach allows the project to:

  • keep the ecosystem open;
  • protect intellectual property;
  • develop in a commercial direction.

Didn’t find the information you need?
Ask a question.