Dashboard
Database Connection
| Server | Client ID | Role | Database | DB Status | Agent Status |
|---|---|---|---|---|---|
| Loading database status... | |||||
Query Executor
Audit Trail
| Query ID | SQL | Executed By | Servers | Date |
|---|---|---|---|---|
| No audit entries yet | ||||
Server Monitor —
Remote Command
File Deployment
| Server | Client ID | Type | Status | Result / Backup | Date |
|---|
FDB Deploy
Drag & Drop FDB.zip here or click to browse
Supports up to 2 GB zip files
Server Selection 0
Deployment Results
| Server | Client ID | Status | FDB Date | PROGNOCIS Date | Error | Completed |
|---|---|---|---|---|---|---|
| No deployment results yet. | ||||||
Deployment History
| Date | Deployed By | Total Servers | Success | Failed |
|---|---|---|---|---|
| No history yet. | ||||
Remote Storage
Server Logs
Admin Panel
User Management
| Name | Username | Role | Status | SQL Perms | Actions | |
|---|---|---|---|---|---|---|
| Loading users... | ||||||
Dashboard Settings
Accepted: .ico, .png, .jpg, .svg, .gif (max 512KB)
SQL Server SSMS provides enterprise-grade data storage with encryption. All data is encrypted before storage. JSON mode stores data in encrypted local files.
Email / SMTP Settings
Alert Configuration
How often alert emails can repeat for the same server & metric. Lower = more emails.
OTP codes for unlocking protected fields (like FDB DB Name) will be sent to this email.
Alerts trigger automatically via agent heartbeat when resource usage exceeds 90%. No need to keep the dashboard open. FDB Deploy alerts send email on deploy start and completion.
Two-Factor Authentication (2FA)
When enabled, users will receive a 6-digit OTP via email during login. OTP expires in 10 minutes. Users without a registered email cannot login when 2FA is enabled.
Agent Interval Management
Heartbeat sends server health data to the dashboard (in seconds). Poll interval controls how often agents check for new commands (in seconds). Changes are pushed to all agents on next heartbeat.
Forgot Password
When enabled, a "Forgot Password?" link will appear on the login page. Users can reset their password by verifying their identity via a 6-digit OTP sent to their registered email. Ensure SMTP email settings are configured correctly.
DevTools / Inspect Lock
Right-click, F12, Ctrl+Shift+I/J/C, and Ctrl+U are always blocked for regular users. When this toggle is enabled, admin and super admin users are exempted and can use browser DevTools normally.
FDB Deploy Settings
Protected field. Click Unlock & verify OTP to edit.
FDB.zip will be deployed to the target path on all selected servers at the scheduled cron time. Environment variables like %TOMCAT% are supported.
FDB deploy uses the same SQL credentials as the connected PROGNOCIS database. Ensure Database is connected before deploying.
IP Whitelist
| IP Address | Label | Added | Actions |
|---|---|---|---|
| Loading IP whitelist... | |||
User Feedback
Documentation
Download Agent
Loading agent info...
System Components
Data Storage
The dashboard supports two storage backends: local AES-256-CBC encrypted JSON files (default) or an external SQL Server (SSMS) database. In JSON mode, JsonStore.php provides CRUD operations with file locking. In SQL mode, SqlStore.php stores all data as encrypted JSON blobs in SQL Server tables via PDO (pdo_sqlsrv). Both modes encrypt all data at rest using the same Encryption.php engine. The storage backend can be switched at any time from Admin Panel → Settings → Data Storage Configuration with built-in migration tools.
Communication Flow
- Agent sends a heartbeat to
api/agent/heartbeatevery 30 seconds, reporting CPU, memory, disk, and services status. - Dashboard responds with any pending commands (SQL queries, remote commands, file deployments, FDB deployments).
- Agent executes the command and reports results back via
api/agent/result. - Dashboard renders the results in real-time and optionally sends email alerts via SMTP.
Dual Storage Architecture
The dashboard provides two fully interchangeable storage backends. You can switch between them at any time without losing data, thanks to built-in migration utilities.
data/ directory. Each data store (servers, users, settings, audit_log, etc.) maps to a separate .dat file. File locking via flock() prevents concurrent write conflicts. No external database or driver required.
pdo_sqlsrv PHP driver connects via PDO. Row-level locking prevents concurrent write conflicts. Supports SQL Server 2016+ with TLS-encrypted connections. All data remains encrypted even inside the database — a database admin cannot read raw data without the master encryption key.
How to Configure SQL Server Storage
- Navigate to Admin Panel → Settings → Data Storage Configuration.
- Enter the SQL Server connection details: Host, Port (default 1433), Database Name, Username, and Password.
- Click "Test Connection" to verify connectivity. The system tests the network connection, authenticates, and validates driver compatibility.
- Click "Save & Connect" to persist the configuration. The dashboard encrypts and stores credentials in
data/.db_config. - Click "Initialize Schema" to create the required tables (
cssanket_data_store,cssanket_data_archive,cssanket_store_locks) automatically. - Switch the storage type to "SQL Server". The system will prompt you to migrate existing JSON data to SQL.
- Optionally use "Migrate JSON → SQL" or "Migrate SQL → JSON" buttons to transfer all data between backends.
Encryption & Decryption Pipeline
Every piece of data — whether stored in JSON files or SQL Server — passes through the same encryption pipeline powered by Encryption.php. The process is identical for both storage backends:
json_encode() converts the PHP array to a JSON stringrandom_bytes()openssl_encrypt() with AES-256-CBC cipher encrypts the JSON string using the master key + IVhash_hmac('sha256') generates a 32-byte authentication tag over IV + ciphertext to prevent tamperingbase64_encode(HMAC + IV + ciphertext).dat file (JSON mode) or encrypted_data column in SQL Server (SQL mode)base64_decode() extracts the binary payloadhash_hmac('sha256') and compare using hash_equals() — rejects tampered dataopenssl_decrypt() with AES-256-CBC + master key + IV recovers the JSON stringjson_decode() converts back to a PHP array for use by the applicationSQL Server Database Schema
When using SQL Server storage, the system creates three tables (prefix: cssanket_):
| Table | Purpose | Key Columns |
|---|---|---|
cssanket_data_store |
Primary data storage — holds all active data stores (servers, users, settings, audit_log, etc.) | id, store_name (unique), encrypted_data (NVARCHAR MAX), data_hash, version, created_at, updated_at |
cssanket_data_archive |
Version history — automatically archives previous versions of data before each write (up to configurable limit) | id, store_id (FK), store_name, encrypted_data, data_hash, version, archived_at |
cssanket_store_locks |
Distributed locking — prevents concurrent write conflicts when multiple PHP processes access the same store | store_name (PK), lock_id, locked_at, expires_at |
What Data Gets Stored
Each logical data set is stored as a separate "store" (row in SQL, or file in JSON mode). All store data is encrypted — the database only contains opaque encrypted blobs:
servers — Registered agent servers & heartbeat data
users — User accounts, hashed passwords, permissions
settings — Dashboard configuration & alert thresholds
audit_log — All user actions & system events
commands — Pending & completed remote commands
ip_whitelist — Allowed IP addresses & CIDR ranges
deploy_results — File deployment history & status
fdb_state — FDB deployment state & schedule
Security Measures
data/.encryption_key with chmod 0600 (owner-only read). This key is used for ALL encryption/decryption operations. Without this key, no data can be decrypted — not from JSON files, not from SQL Server. Back up this file securely.encrypted_data column contains base64(HMAC + IV + AES-256-CBC-ciphertext). Each row also stores a data_hash (SHA-256) for integrity verification.data/.db_config. The password is never stored in plaintext anywhere. The configuration file is also protected with chmod 0600.pdo_sqlsrv driver supports TLS-encrypted connections to SQL Server. Connection parameters include configurable timeouts (connection: 5s, query: 30s). The lazy PDO pattern means connections are only established when the first actual query is needed, not on page load.RuntimeException('Data integrity check failed - possible tampering'). This uses timing-safe hash_equals() comparison to prevent timing attacks.Performance Optimization
When using SQL Server storage with high-latency connections, the dashboard employs several caching strategies to ensure the UI loads instantly:
- Connection Cache (5-min TTL): Successful SQL Server connection details are cached to
data/.connection_cache. Subsequent page loads skip the connection test if the cache is fresh, using a lazy PDO that connects only when needed. - Settings File Cache: Dashboard settings are cached to
data/.settings_cacheon write. Page loads read from cache instead of SQL, falling back to SQL on cache miss. - IP Whitelist File Cache: IP whitelist data is cached locally, avoiding SQL reads on every page request.
- Admin Flag File: A
data/.admin_createdflag file prevents repeated SQL reads to check if the default admin account exists. - Automatic Cache Invalidation: All caches are automatically invalidated when data is modified through the Admin Panel (settings save, IP whitelist update, etc.).
Data Migration
The dashboard provides one-click migration between storage backends:
.dat files, decrypts them, re-encrypts with the same key, and writes to SQL Server tables. Original JSON files are preserved as backup. Progress is reported for each store.
.dat files. Useful for reverting to file-based storage or creating offline backups.
Auto-Fallback & Reliability
If the SQL Server connection fails during initialization (e.g., server is down, network issue), the dashboard automatically falls back to JSON file storage to ensure uninterrupted operation. An amber warning indicator appears in the UI showing the fallback state. Once the SQL Server becomes available again, the system reconnects automatically on the next page load.
File Deploy Workflow
FDB Deploy Workflow
Encryption.php). Data can be stored in local encrypted JSON files or in SQL Server as encrypted blobs — both use the same encryption pipeline. Even a database administrator with full SQL Server access cannot read the raw data without the master encryption key. File locking (JSON mode) and row-level locking (SQL mode) prevent race conditions during concurrent writes. See the Data Storage Configuration section above for full details.HttpOnly and Secure flags). Sessions have a configurable timeout to log out inactive users automatically.IpWhitelist.php middleware restricts dashboard access to specific IP addresses or CIDR ranges. When enabled, only whitelisted IPs can reach the dashboard. Agent API endpoints are exempt from this check.verify_ssl = true). This completely prevents Man-In-The-Middle (MITM) attacks, ensuring no hacker can intercept or inject malicious commands on the local network.2. Token Authentication: Agents authenticate using a cryptographically secure 64-character Hex Token (
bin2hex(random_bytes(32))) assigned during registration.3. No Inbound Ports: Agents actively poll the dashboard. You do not need to open any inbound firewall ports on the agent's server, making it invisible to external port scanners.
4. Replay Protection: Every executed command has a unique cryptographic ID to prevent replay attacks.