From 466da0ba68698695ff6d9fc4ff2198e2fd91d2c9 Mon Sep 17 00:00:00 2001 From: Moh-Khair Date: Wed, 29 Jul 2026 01:07:36 +0000 Subject: [PATCH] Upload files to "q4-SIEM-build" --- q4-SIEM-build/PUBLISH_TO_GHAYMAH.md | 154 ++++++++ q4-SIEM-build/README.md | 95 +++++ q4-SIEM-build/siem_analyzer.py | 539 ++++++++++++++++++++++++++++ 3 files changed, 788 insertions(+) create mode 100644 q4-SIEM-build/PUBLISH_TO_GHAYMAH.md create mode 100644 q4-SIEM-build/README.md create mode 100644 q4-SIEM-build/siem_analyzer.py diff --git a/q4-SIEM-build/PUBLISH_TO_GHAYMAH.md b/q4-SIEM-build/PUBLISH_TO_GHAYMAH.md new file mode 100644 index 0000000..550b0ee --- /dev/null +++ b/q4-SIEM-build/PUBLISH_TO_GHAYMAH.md @@ -0,0 +1,154 @@ +# Publishing this SIEM Dashboard to Ghaymah Storage Block + +## Read this first: what I could and couldn't verify + +I looked for Ghaymah Systems' own documentation before writing this. I +found: + +- Their docs portal: **https://docs.ghaymah.cloud/** +- Their deployment portal: **https://deploy.ghaymah.systems/** + +Both are JavaScript-rendered apps, so I could confirm they exist but +couldn't pull the actual step-by-step page content for the "Storage Block" +feature specifically — I don't have exact screenshots/menu names to give +you with certainty, and I don't want to hand you confidently-wrong click +paths for something that's going to be graded. + +What follows is the **standard workflow that essentially every cloud +"storage block"/bucket/object-storage service uses** (AWS S3, DigitalOcean +Spaces, Linode/Akamai Object Storage, etc.), written so you can map it onto +Ghaymah's actual console. Before your exam submission, open +**docs.ghaymah.cloud** and search for "storage" to confirm exact menu +names, size limits, and whether static-site hosting is a toggle you need to +enable — the mechanics below are almost certainly right, the exact button +labels might differ slightly. + +There are two different things a "storage block" can mean on a cloud +platform — check which one Ghaymah's product actually is before you start, +since the workflow is different: + +| If "Storage Block" is... | It behaves like... | Use it to... | +|---|---|---| +| **Object storage** (a bucket you upload files into, with a public URL) | AWS S3 / DigitalOcean Spaces | Host this static dashboard directly — this is the common case, and the one the rest of this guide assumes | +| **Block storage** (a raw virtual disk volume, like AWS EBS) | An attached hard drive | You'd still need a compute instance/VM running a web server (nginx, `python3 -m http.server`, etc.) — the volume just gives that VM extra disk space. See the [alternate path](#alternate-path-if-storage-block-means-a-disk-volume) below. | + +--- + +## Path A: publishing to object/bucket-style storage (most likely case) + +### 1. Regenerate fresh data before publishing + +Run the analyzer one last time so `siem_report.json` and `data.js` are +current: + +```bash +cd siem_project +python3 siem_analyzer.py +``` + +### 2. Collect exactly what needs to go live + +Only the `dashboard/` folder needs to be published — the Python script and +raw `logs/` are your local tooling, not part of the served site: + +``` +dashboard/ +├── index.html +├── style.css +├── script.js +├── siem_report.json +└── data.js +``` + +(You can optionally publish `logs/` and `siem_analyzer.py` alongside it too +if the exam wants the whole repo visible — just make sure `index.html` ends +up at the bucket's root so it's served as the default page.) + +### 3. Create the storage block / bucket + +In the Ghaymah console (or `deploy.ghaymah.systems`): + +1. Log in and find **Storage** in the main navigation. +2. Create a new storage block — give it a unique name (e.g. + `siem-dashboard-`), and pick a region close to you/your + grader. +3. If there's a **public access / static website hosting** toggle, enable + it — object storage buckets are private by default on most platforms, + and a private bucket will just return "Access Denied" in a browser. +4. If it asks for an **index document**, set it to `index.html`. + +### 4. Upload the files + +Most storage-block consoles support drag-and-drop upload in the browser — +upload the 5 files from `dashboard/` (keep them at the bucket's root, not +inside a subfolder, so relative paths like `href="style.css"` still +resolve). + +If Ghaymah instead exposes an **S3-compatible API** (common for +smaller/regional clouds — check their docs for an endpoint URL, access +key, and secret key), you can upload with the standard AWS CLI pointed at +their endpoint instead of the console: + +```bash +aws s3 cp ./dashboard s3://siem-dashboard- \ + --recursive \ + --endpoint-url https:// +``` + +(Only use this if their docs confirm an S3-compatible endpoint and give +you access/secret keys — don't guess the endpoint URL.) + +### 5. Get the public URL and verify + +The console should show a public URL after upload (something like +`https://..ghaymah.systems/` or a +platform-generated domain). Open it and confirm: + +- The stat cards, radar, and alert table all render (not a blank page — + that usually means `style.css`/`script.js`/`data.js` didn't upload to + the same folder as `index.html`). +- The alert table search/filter and row-expand still work. + +### 6. (Optional) Custom domain + +If Ghaymah supports attaching a custom domain/CNAME to a storage block, +that's normally: add a CNAME record at your DNS provider pointing your +subdomain at the bucket's platform domain, then add that domain in the +bucket's settings and wait for it to verify (and, if offered, request/attach +an SSL certificate). + +--- + +## Alternate path: if "Storage Block" means a disk volume + +If Ghaymah's "Storage Block" is closer to AWS EBS (a virtual disk you +attach to a VM rather than something with its own public URL), the flow is +instead: + +1. Provision a small compute instance (VM) on Ghaymah. +2. Create and attach a storage block/volume to it, then mount it + (`mkfs`, `mount` — same as any Linux block device). +3. Copy `dashboard/` onto that mounted volume (`scp`, `git clone`, etc.). +4. Serve it from the VM: + ```bash + cd /mnt//dashboard + python3 -m http.server 80 + # or install nginx and point its document root at this folder + ``` +5. Open the VM's public IP (or attach a domain to it) to verify. + +--- + +## Either way — a pre-submission checklist + +- [ ] Ran `python3 siem_analyzer.py` so `siem_report.json`/`data.js` reflect + the current logs +- [ ] `index.html` is reachable at the bucket/site root, not nested in a + subfolder +- [ ] `style.css`, `script.js`, `data.js`, `siem_report.json` are in the + **same folder** as `index.html` +- [ ] Public URL loads with no blank/broken page and no browser console + errors +- [ ] Confirmed the actual click-path against **docs.ghaymah.cloud**, since + the steps above are the generic pattern, not a verified Ghaymah + screenshot-by-screenshot guide diff --git a/q4-SIEM-build/README.md b/q4-SIEM-build/README.md new file mode 100644 index 0000000..81ce7ab --- /dev/null +++ b/q4-SIEM-build/README.md @@ -0,0 +1,95 @@ +# Simple SIEM — Log Analyzer + Threat Dashboard + +A small SIEM built for a 3-endpoint environment: a **web server**, a +**firewall/router**, and an **SSH authentication** log source. A Python +script parses and correlates suspicious activity across all three; a static +HTML/CSS/JS dashboard visualizes the resulting alerts and malicious IPs. + +``` +siem_project/ +├── logs/ +│ ├── endpoint1_web_access.log # sample nginx-style access log +│ ├── endpoint2_firewall.log # sample SRC/DST/PORT/ACTION firewall log +│ └── endpoint3_auth.log # sample sshd auth log +├── siem_analyzer.py # Part 1 — the analyzer +├── dashboard/ +│ ├── index.html # Part 2 — the dashboard +│ ├── style.css +│ ├── script.js +│ ├── siem_report.json # generated by siem_analyzer.py +│ └── data.js # generated by siem_analyzer.py (offline fallback) +├── README.md # this file +└── PUBLISH_TO_GHAYMAH.md # Part 3 — publishing guide +``` + +## Part 1 — `siem_analyzer.py` + +Pure standard library, no `pip install` needed. + +```bash +python3 siem_analyzer.py +# or point it at different files: +python3 siem_analyzer.py --logs-dir ./logs --out-dir ./dashboard +``` + +It parses all three log formats, runs the detection rules below, prints a +console summary, and writes `siem_report.json` + `data.js` into `dashboard/`. + +### Detection rules + +| Rule | Source | Logic | Severity | +|---|---|---|---| +| `SQL_INJECTION` / `XSS` / `PATH_TRAVERSAL` / `COMMAND_INJECTION` | web | Regex signatures against the (URL-decoded) request path | critical/high | +| `RECON_SCANNER` | web | ≥3 requests with a known scanner user-agent (sqlmap, nikto, nmap…) | medium | +| `HIGH_REQUEST_RATE` | web | ≥15 requests from one IP within 60s | medium/high | +| `PORT_SCAN` | firewall | ≥8 distinct destination ports from one IP within 120s | high | +| `BRUTE_FORCE_SSH` | auth | ≥5 failed logins from one IP within 300s | high | +| `ACCOUNT_COMPROMISE_SUSPECTED` | auth | A successful login from an IP right after it triggered a brute-force alert | critical | +| `BLACKLISTED_IP_ACTIVITY` | any | IP matches a seeded threat-intel list | critical | +| `MULTI_VECTOR_ATTACK` | correlation | Same source IP triggered alerts on ≥2 different endpoints | critical | + +That last rule is the actual point of a SIEM: no single log tells the whole +story, but seeing the *same* IP port-scan the firewall, brute-force SSH, +*and* throw SQLi at the web app is what turns three noisy logs into one +clear "this IP is attacking us" signal. All thresholds live in the +`THRESHOLDS` dict at the top of the script if you want to tune them. + +## Part 2 — the dashboard + +Open `dashboard/index.html` directly in a browser — it works out of the box +because it falls back to the embedded `data.js` snapshot. For the "live" +experience (auto re-fetching `siem_report.json` when you click Refresh), +serve the folder instead: + +```bash +cd dashboard +python3 -m http.server 8000 +# open http://localhost:8000 +``` + +What's on it: +- **Stat cards** — total alerts and the severity breakdown. +- **Threat Radar** — the top malicious IPs plotted by score (closer to + center = more dangerous); a critical IP gets a pulsing ring. +- **Severity Mix** — a proportional bar of critical/high/medium/low. +- **Top Malicious IPs** — ranked list with a relative-score bar. +- **Alerts table** — searchable, filterable by severity/endpoint; click a + row to expand the raw log line(s) behind that alert. + +Re-running `siem_analyzer.py` regenerates both output files — refresh the +page (or click the in-app Refresh button if you're on a local server) to +see updated results. + +### A note on why the table doesn't use `innerHTML` + +Alert descriptions and evidence are literally attacker-supplied log text — +some of the sample data contains a real `" (e.g. a captured XSS payload). Escape the closing tag + # sequence so this JSON can never be mistaken for the end of a