Introduction

SaiCore is a sovereign, multi-layered server defense platform engineered by a Russian offensive-security team. Eleven defense modules run as a single statically-linked Go binary on every protected server, orchestrated from a single self-hosted web panel.

Unlike reactive log-parsers or pure signature scanners, SaiCore combines active deception, behavioral baselines, and anti-ransomware — capabilities otherwise only delivered by $99/server/month commercial EDRs.

Who should use SaiCore?

Infra teams running fleets of Linux servers (web, DB, app tier)
Hosting providers and VPS operators wanting to bake protection in
Organizations with Russian procurement requirements (44-ФЗ, 223-ФЗ, 152-ФЗ)
Security teams that want EDR-class detection without vendor lock-in

Design principles

Safe by default. PHOENIX ships in monitor mode; MIRAGE pre-flight checks to never overwrite real users; Zero-Trust SSH never locks you out of your current session.
Pinned supply chain. Every binary signed Ed25519; public key embedded in the installer; self-update refuses on mismatch.
Zero YAML. Everything configurable from the panel. ENV overrides for advanced users.
Air-gapped ready. First-class offline install with local repo mirror.

Quick start

Sixty seconds from zero to protected. Assumes Linux with systemd.

1. Issue a pairing token in the panel

Log into https://panel.your-domain.ru/panel, open Servers → Issue token. Copy the 32-character token (valid 24 h).

2. Run the installer on the target server

curl -fsSL https://panel.your-domain.ru/install.sh | \
    sudo SAICORE_URL=https://panel.your-domain.ru \
         SAICORE_PAIRING=<token> sh

3. Verify

systemctl status saicore-agent
# ● saicore-agent.service — active (running)
#   Main PID: 412 (saicore-agent)
#   Memory: 46.2M
#   Tasks: 18

journalctl -u saicore-agent -f
# {"level":"info","module":"edr","msg":"baseline ready","ts":"..."}
# {"level":"info","module":"fim","msg":"1487 files baselined","ts":"..."}
# {"level":"info","module":"sentinel","msg":"learning mode (24h)","ts":"..."}

The agent will appear in the panel under Servers within ~30 seconds.

Installation guide

Linux (recommended)

Supported distributions: Debian 11+, Ubuntu 20.04+, CentOS/RHEL 8+, AlmaLinux, Rocky, Arch, RED OS, Astra Linux, РОСА «Хром», Alt Linux.

Architectures: x86_64, ARM64 (including Baikal-M/S, Apple Silicon via Linux VMs, AWS Graviton).

# One-liner — verifies Ed25519 signature, SHA-256 of binary,
# installs systemd unit, registers with panel, starts agent.
curl -fsSL https://panel.saicore.ru/install.sh | sudo sh

Manual install (verified steps)

# 1. Download binary + signed manifest
wget https://repo.saicore.ru/dl/saicore-agent-linux-amd64
wget https://repo.saicore.ru/dl/version.json
wget https://repo.saicore.ru/dl/version.json.sig

# 2. Verify Ed25519 signature
openssl pkeyutl -verify -pubin -inkey saicore_pub.pem \
    -rawin -in version.json -sigfile version.json.sig
# Signature Verified Successfully

# 3. Verify binary SHA-256 matches version.json["files"]["linux-amd64"]["sha256"]
sha256sum saicore-agent-linux-amd64

# 4. Install
sudo install -m 0755 saicore-agent-linux-amd64 /usr/local/bin/saicore-agent
sudo mkdir -p /etc/saicore /var/lib/saicore /var/log/saicore
sudo tee /etc/saicore/agent.env <<EOF
SAICORE_URL=https://panel.example.ru
SAICORE_AGENT_ID=xxxx
SAICORE_AGENT_SECRET=xxxx
EOF

# 5. systemd unit (hardened)
sudo tee /etc/systemd/system/saicore-agent.service <<EOF
[Unit]
Description=SaiCore Agent
After=network-online.target

[Service]
Type=simple
EnvironmentFile=/etc/saicore/agent.env
ExecStart=/usr/local/bin/saicore-agent
Restart=always
RestartSec=5
User=root
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
RestrictNamespaces=true
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW CAP_SYS_PTRACE
SystemCallFilter=@system-service
ReadWritePaths=/var/lib/saicore /var/log/saicore /etc/saicore

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now saicore-agent

Windows Server 2019+

# PowerShell (as Administrator)
iwr -useb https://panel.saicore.ru/install.ps1 | iex

Installs as a Windows Service. Manages Windows Firewall via netsh advfirewall.

macOS 12+

curl -fsSL https://panel.saicore.ru/install.sh | sudo sh

Installs as LaunchDaemon. Manages firewall via pfctl.

Air-gapped install

For networks with no internet access:

On a connected machine, download the release bundle: saicore-release-0.1.0.tar.gz (contains binaries for all 5 platforms, version.json + .sig, YARA rule-packs).
Verify the bundle signature against the pinned public key.
Copy to an internal HTTP server inside your air-gapped network.
Set SAICORE_REPO_URL in install.sh to point to your internal repo.
Disable auto-update in the panel (Settings → Self-update → off). Apply updates manually by re-running the installer with a new bundle.

No agent ever contacts repo.saicore.ru in this mode.

Architecture overview

Three-tier. Two components to operate.

  ┌─────────────────────────────────────────┐
  │  Agent (Go binary, ~9.8 MB, statically │
  │  linked, no external deps)              │
  │  ┌─────────┬─────────┬─────────────┐   │
  │  │  SSH    │  EDR    │  PHOENIX    │   │
  │  │  FIM    │  YARA   │  MIRAGE     │   │
  │  │  WAF    │ Z-Trust │  SENTINEL   │   │
  │  └────┬────┴────┬────┴──────┬──────┘   │
  └───────┼─────────┼───────────┼──────────┘
          │ HMAC-SHA256 · HTTPS TLS 1.3 · mutual timestamp check
          ▼
  ┌─────────────────────────────────────────┐
  │  Control-plane (FastAPI · Python 3.12) │
  │  ┌──────┬──────┬──────┬──────┬──────┐  │
  │  │auth  │agents│events│modul │ztrst │  │
  │  └──────┴──────┴──────┴──────┴──────┘  │
  │  SQLAlchemy → SQLite/Postgres          │
  │  SPA panel (vanilla JS)                │
  └─────────────────────────────────────────┘

Supply chain

Every release produces a signed manifest:

{
  "version": "0.1.0",
  "released_at": "2026-04-18T12:00:00Z",
  "files": {
    "linux-amd64":  { "size": 10215424, "sha256": "b2f1…" },
    "linux-arm64":  { "size": 10098112, "sha256": "cd4a…" },
    "darwin-arm64": { "size": 10401280, "sha256": "f3a9…" },
    "windows-amd64":{ "size": 10489856, "sha256": "11c5…" }
  }
}

Manifest signed Ed25519 with an offline key. Public key baked into install.sh and into every agent binary. Self-update refuses if the manifest signature doesn't match. Even a full repo compromise cannot push tampered binaries.

Agent ↔ Control-plane

All requests authenticated with HMAC-SHA256 over the body + Unix timestamp. Replay window ±60 seconds.

POST /api/v1/events HTTP/1.1
Host: panel.example.ru
X-SaiCore-Agent: 7d2f31c0-1c3b-48a0-8c4b-f4c29d1c2b12
X-SaiCore-Ts: 1776537733
X-SaiCore-Sig: 5b1f8c...  # hmac_sha256(secret, ts + body)
Content-Type: application/json

{"batch":[{"kind":"ssh.brute_force","ts":1776537733,"src_ip":"1.2.3.4",...}]}

All 11 modules

Each module runs as an independent goroutine. Each can be toggled and has a mode (monitor / enforce / learning).

Module	Purpose	Default
SSH Anti-Brute	Block brute-force on SSH/RDP	enforce
Honeypot	Trap scanners on tempting ports	enforce
EDR-lite	Scan /proc for known threats	enforce
FIM	SHA-256 baseline of system files	enforce
Outbound C2	Detect phone-home	enforce
YARA Scanner	Signed rule packs	enforce
WAF	OWASP CRS-lite on HTTP traffic	monitor
Zero-Trust SSH	Port-22 closed by default	off (opt-in)
MIRAGE	Active deception	off (opt-in)
PHOENIX	Anti-ransomware	monitor
SENTINEL	Behavioral baseline	learning

🔥 PHOENIX — anti-ransomware

Four cooperating layers detect encryption-style ransomware behavior with near-zero false positives.

L1 — Honey-files

A handful of bait files like !MUST_READ.docx, passwords.xlsx are placed in every /home/*, /var/www, /root. Ransomware encrypts files alphabetically — honey-files trigger first. Any modification = alert + kill.

L2 — inotify watcher

Watches critical directories. Counts file renames/rewrites per process per 5-second window. Spike = suspicious.

L3 — Shannon entropy

For every written file, compare its byte-entropy to its name's extension baseline. A .docx being rewritten with 7.9-entropy content is almost certainly encrypted.

L4 — Kill + quarantine

When enforce-mode is on and all 3 layers agree, the offending process receives SIGSTOP (preserved for forensics), its network is cut via iptables, and a forensic snapshot (PID, cmdline, open FDs, connections, memory maps) is uploaded to the panel.

Modes

off — disabled.
monitor — alerts only (default).
enforce — SIGSTOP + network quarantine.

Process whitelist

Out-of-the-box whitelist protects common backup and archival tools from ever being killed:

tar gzip bzip2 xz zstd zip unzip
mysqldump pg_dump mongodump redis-cli
rsync borg restic rclone duplicity
git systemd logrotate cron
apt dpkg yum dnf rpm pacman

Extensible in /etc/saicore/phoenix-whitelist.txt or via the panel.

🎭 MIRAGE — active deception

Turn your server into a minefield. Attackers trip invisible wires long before touching anything real.

L1 — Decoy users

Adds a few tempting usernames to /etc/passwd (but not /etc/shadow): backup, jenkins, ansible, admin_old. Each has a canary marker in its GECOS field so MIRAGE never touches real users. Any login attempt for these = instant ban.

L2 — Bait SSH keys

In ~backup/.ssh/ sits an authorized_keys with a bait public key. Any SSH login using that key = high-severity alert.

L3 — Canary files

Fake aws_credentials.csv, wallet.dat, .env.production in tempting paths. Any open/read = alert.

L4 — Port listeners

Bind Redis (6379), MongoDB (27017), MySQL (3306) on an alternate IP, listen for connection attempts only, log source IP as definite attacker. Pre-flight check avoids overwriting real services.

Safety: MIRAGE is off by default. Turn on via the panel Modules tab when you're ready.

🧠 SENTINEL — behavioral baseline

Self-learning per-process normal. For 24 hours, captures for every persistent PID:

RSS / VSZ memory footprint (EMA smoothed)
FD count + open file paths (top-N directories)
Network peers (remote IPs and ports)
Effective capabilities bitmap
Child-process exec patterns

After training, any deviation triggers severity-scored events:

nginx suddenly exec'ing /bin/sh → critical (webshell?)
mysql reading /etc/shadow → critical (LPE?)
php-fpm dialing :6667 → high (IRC C2?)
sshd memory tripled → medium (injected library?)

Modes

learning — collect only, no alerts (default for 24 h)
monitor — alerts on deviations (default after training)
enforce — not available; behavioral signals have too much noise for automated kill

🔐 SSH Anti-Brute

Tails /var/log/auth.log (Linux), Windows Security Event Log (4625), or macOS log stream. Detects >10 failed logins in 5 minutes from a single IP → iptables -I INPUT -s <IP> -j DROP. Re-ban with exponential backoff on recidivism (1 h → 6 h → 24 h → permanent).

🛡 EDR-lite + 📁 FIM

EDR: every 60 seconds, enumerate /proc/*/exe, /proc/*/cmdline, hash the exe, and match against a curated list of known-bad binaries (xmrig, kinsing, tsunami, cobaltstrike, remexi). Also detects the fileless "deleted-exec" technique — processes whose /proc/PID/exe → ... (deleted).

FIM: SHA-256 baseline of /etc/passwd, /etc/shadow, /etc/sudoers.d/*, /etc/cron.*, /usr/bin/*, /usr/sbin/*, /lib/systemd/system/*. Any mismatch = alert with before/after hashes.

🔥 WAF + 🌐 Outbound C2

WAF: optional edge-proxy in front of your web apps. OWASP Core Rule Set lite with 130+ rules covering SQLi, XSS, LFI/RCE, SSRF, Log4Shell, Spring4Shell, Ivanti, Citrix, MOVEit. Deployable as a Docker container or embedded in nginx via ngx_http_sub_module.

Outbound C2: hooks egress via libnetfilter_queue or polls /proc/net/tcp. Flags connections to mining pools (XMRig stratum ports), Tor bootstrap addresses, IRC (6667-6669), known C2 domains, DNS exfil patterns.

Presets

Three pre-configured profiles applied from the panel Modules tab:

Minimal

Conservative. Only battle-tested modules on. PHOENIX off, MIRAGE off, SENTINEL off.

Recommended (default)

All modules on with safe modes: PHOENIX in monitor, SENTINEL in learning, MIRAGE off (manual opt-in).

Paranoid

Everything on, everything enforce. PHOENIX kills. MIRAGE deployed. SENTINEL in monitor mode. Zero-Trust SSH enabled. Only for battle-hardened ops teams.

ENV variables

Variable	Default	Purpose
`SAICORE_URL`	—	Control-plane URL (required)
`SAICORE_AGENT_ID`	—	Agent UUID (set by install)
`SAICORE_AGENT_SECRET`	—	Agent HMAC key (set by install)
`SAICORE_HEARTBEAT_SEC`	60	Heartbeat interval
`SAICORE_EVENT_BATCH`	32	Max events per flush
`SAICORE_EVENT_FLUSH_SEC`	30	Force-flush interval
`SAICORE_PHOENIX_MODE`	monitor	off · monitor · enforce
`SAICORE_PHOENIX_WHITELIST`	—	Extra whitelist paths (colon-sep)
`SAICORE_SENTINEL_MODE`	learning	off · learning · monitor
`SAICORE_FIM_PATHS`	built-in	Override FIM scan paths
`SAICORE_YARA_MAX_FILE_SIZE`	16M	Skip files larger than this
`SAICORE_LOG_LEVEL`	info	debug · info · warn · error

IP whitelist

Prevents accidental self-lockout. Any IP in the whitelist is never banned by any module.

Managed in the panel (Whitelist tab) or via a file:

# /etc/saicore/whitelist.txt
# one IP or CIDR per line
10.0.0.0/8
192.168.0.0/16
1.2.3.4          # office

API — Authentication

Admin API uses JWT Bearer tokens.

POST /api/auth/login
Content-Type: application/json

{"email":"admin@example.ru", "password":"..."}

→ 200 {"access":"...","refresh":"...","expires":3600}

All subsequent requests:

Authorization: Bearer <access>

Refresh:

POST /api/auth/refresh
{"refresh":"..."}

API — Agents

GET  /api/agents                    # list
GET  /api/agents/{id}               # details
POST /api/agents/pairing-token      # issue 24h token
DELETE /api/agents/{id}             # revoke
GET  /api/agents/{id}/heartbeats    # last 100

Heartbeat (agent → panel)

POST /api/agents/heartbeat
X-SaiCore-Agent: <uuid>
X-SaiCore-Ts: <unix>
X-SaiCore-Sig: <hmac>

{"metrics":{"cpu":4.2,"rss_mb":46,"uptime":3600},
 "version":"0.1.0","os":"linux"}

→ 200 {"modules_config":{"phoenix":{"mode":"monitor"},...},
        "whitelist":["10.0.0.0/8"]}

API — Events

POST /api/events                     # agent submits batch
GET  /api/events?severity=high&kind=phoenix.ransomware
GET  /api/events/{id}
GET  /api/events/stats?window=24h

Event schema

{
  "ts": 1776537733,
  "kind": "phoenix.ransomware_detected",
  "severity": "critical",
  "agent_id": "7d2f31c0-...",
  "src_ip": "203.0.113.42",       // optional
  "pid": 18472,                     // optional
  "details": { ... kind-specific ... }
}

Event kinds

ssh.brute_force · ssh.banned · honeypot.hit · edr.malware · edr.fileless · fim.integrity_violation · outbound.c2 · yara.match · waf.sqli · waf.xss · waf.rce · ztrust.grant_issued · ztrust.grant_expired · mirage.decoy_touched · phoenix.honey_touched · phoenix.entropy_spike · phoenix.ransomware_detected · phoenix.process_stopped · sentinel.anomaly

API — Modules

GET  /api/modules                      # current state
POST /api/modules/{name}/toggle        # {"enabled":true,"mode":"enforce"}
GET  /api/modules/presets              # list of presets
POST /api/modules/presets/{name}       # apply preset

API — Zero-Trust SSH

POST /api/ztrust/grants
{
  "agent_id": "7d2f31c0-...",
  "src_ip":   "1.2.3.4",
  "ttl_sec":  3600
}
→ 201 {"grant_id":"...","expires_at":"..."}

GET    /api/ztrust/grants                # active
DELETE /api/ztrust/grants/{id}           # revoke early

The agent polls the control-plane each heartbeat and opens/closes the matching iptables rule.

Control-plane deployment

Install

git clone https://git.saicore.ru/saicore/control-plane
cd control-plane
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env    # edit with your secrets
uvicorn app.main:app --host 127.0.0.1 --port 8000

# nginx front-end
# see deploy/nginx.conf
# systemd unit in deploy/saicore.service

Docker deployment

version: "3.9"
services:
  saicore:
    image: git.saicore.ru/saicore/control-plane:0.1.0
    restart: unless-stopped
    environment:
      SAICORE_JWT_SECRET: change-me
      SAICORE_ADMIN_EMAIL: admin@example.ru
      SAICORE_ADMIN_PASSWORD: change-me-too
    volumes:
      - ./data:/var/lib/saicore
    ports:
      - "127.0.0.1:8000:8000"

HA mode

Planned for v0.3. Requires Postgres backend and shared event queue. Current v0.1 is single-node (SQLite). Active/standby failover recipe available on request.

Security model

Threat model (what we protect against)

Brute-force SSH/RDP
Web-app exploits (SQLi, XSS, RCE, SSRF, LFI)
File-based malware (miners, backdoors, webshells)
Fileless malware (exec-from-memory, deleted-exec)
Ransomware (encryption-style + double-extortion data-exfil)
Lateral movement (behavioral anomalies)
Supply-chain attacks (pinned Ed25519)
C2 egress (IP/domain/protocol heuristics)

Out of scope (for now)

Kernel-mode rootkits below eBPF
Hardware-level attacks (SMM, UEFI)
Insider threats with legitimate admin credentials
Destructive DDoS (use specialized scrubbers)

Security disclosure policy

If you find a security issue in SaiCore:

E-mail security@saicore.ru with a proof of concept.
Expect first reply in ≤ 24 hours.
We aim to patch critical issues in ≤ 72 hours.
We credit reporters in release notes (opt-out available).

We do not have a paid bug bounty yet but will send swag for impactful reports.

Compliance

Russian Software Registry — application submitted April 2026.
152-ФЗ (personal data) — SaiCore processes only operational telemetry; no PII of data subjects.
44-ФЗ / 223-ФЗ — procurement-ready upon registry inclusion.
PCI-DSS — Enterprise tier delivers FIM, logging, and access control packages aligned with PCI-DSS 4.0 requirements 10, 11.5.
ГОСТ Р ИСО/МЭК 27001 — planned certification.

Troubleshooting

Agent shows offline

systemctl status saicore-agent — service running?
journalctl -u saicore-agent -n 50 — last logs
Network: curl -sI https://panel.example.ru — reachable?
Time sync: timedatectl — HMAC requires ±60 s

High CPU from agent

YARA-scanning huge files. Lower SAICORE_YARA_MAX_FILE_SIZE or pause the module in the panel.

PHOENIX false positive on backup

Add the process to the whitelist via the panel or /etc/saicore/phoenix-whitelist.txt.

I can't log into SSH after enabling Zero-Trust

From the panel: Zero-Trust → Issue grant → enter your current public IP + 1 hour TTL. Or temporarily disable the module.

FAQ

See the front-page FAQ. Everything else — support@saicore.ru.

About

SaiCore is built by ООО «САЙКО», a Russian company registered in the Republic of Tatarstan.

ОГРН: 1251600018933
ИНН: 1683027173
Адрес: 420099, Республика Татарстан, Высокогорский р-н, с. Семиозёрка, ул. Зиганшина, д. 39
Website: saicore.ru
Contact: sales@saicore.ru

Terms of service

The Community tier is delivered under a permissive license: use freely, commercially or otherwise, at your own risk, without warranty. Do not remove attribution notices. Do not sub-license as a competing product. See LICENSE in the source repository for the exact text.

Pro and Enterprise tiers are delivered under a separate commercial contract with SLA and liability clauses defined therein.

Privacy policy

Self-hosted SaiCore deployments send no data to ООО «САЙКО». Full stop.

If you opt in to the global threat-intel feed, we receive:

IP addresses of confirmed attackers (source of blocked events)
Coarse categorization of attack type (ssh-brute, c2, yara-match)
Your anonymous operator ID (hashed from install)

We never receive: file contents, user credentials, user identifiers, server hostnames, customer data of any kind.

We process the above anonymous telemetry in Russia only. Data retention: 180 days rolling window.