BlueTeam - Defensive Security Lab featuring a containerized M

项目说明

DriftLock — Blue Team MFA Portal

DriftLock is a TOTP-based multi-factor authentication portal built as the Blue Team deli for a Red- Capture-the-Flag exercise. It is a realistic web application, secured with genuine controls, that contains three deliberate, documented at increasing difficulty for the Red Team to discover — and is wrapped in logging, a honeypot, and an ELK monitoring stack so the Blue Team can detect and analyze the attack.

> Branch note: this is the main branch — the intentionally- CTF target. The remediated , with all findings fixed and , is on the patched branch.

---

What it does

Users register an account by pro a username, email address, and password. The system securely hashes the password using bcrypt. During registration, the user scans a QR code to complete the initial account setup.

When logging in, the user first enters their username (or email) and password. If the credentials are valid, the system generates a one-time password (OTP) and sends it to the user's registered email address.

For de and testing, MailHog is a at and acts as a dummy mail server. The user retrieves the OTP from MailHog and enters it to complete the login process. Authentication is successful only after both the password (something the user knows) and the emailed OTP (something the user receives) are .

TOTP here protects DriftLock's own login — one issuer, one secret per user (a 1:1 relationship). It is a login second factor, not a multi-service authenticator vault.

---

How it works (the security design)

DriftLock is a deliberately-defended target. Three layers make that work:

1. Realistic security controls. Password hashing (bcrypt), encrypted TOTP secrets (Fernet), input on registration, rate limiting (Flask-Limiter, backed by Redis), session-based authentication, and a two-step login (password then OTP) with protections against username enumeration and session fixation.

2. Three intentional . The app contains three deliberate, documented weaknesses at increasing difficulty: an unauthenticated /api/debug endpoint (information disclosure), TOTP code replay (no single-use enforcement), and an IDOR in a separate internal API (broken access control). Each is documented below so graders understand they were deliberate; e else is meant to be secure.

3. Self-monitoring / detection. Every request is logged. A honeypot ad a fake /backup_secrets/ folder .txt and fires a CRITICAL alert the instant anyone touches it. All logs flow through Logstash into Elasticsearch and are in Kibana, giving the Blue Team a live view for triage and incident response.

---

The detection loop

A single attack traces through every component:

Red Team packet -> app logs the request -> if it touches the honeypot or trips a detection, an alert fires -> Logstash ships the log into Elasticsearch -> Kibana surfaces it -> an analyst correlates the attacker's actions into one confirmed incident and separates it from benign noise -> that becomes the incident-response report.

---

Architecture

DriftLock runs as a set of Docker Compose services on one isolated lab network. Two Flask services — the web portal (:4325) and a separate, scannable internal-api (:5000) — share a single PostgreSQL database. The web service leans on Redis for rate limiting and lockout, and captures login OTP email through MailHog. Every request is written to JSON/plain log files, which Logstash mounts read-only and parses into Elasticsearch, where an analyst runs triage in Kibana.

Network exposure (host firewall)

The host firewall (ufw) allows only 22 (SSH), 4325 (web portal), and 5000 (internal-api) from the network. Kibana (5601) and MailHog (8025) are bound but not exposed externally — they are Blue Team tooling, reachable only on the host or via an SSH tunnel, so the attacking team cannot view the detection dashboards or captured mail. This is a deliberate defense-in-depth choice.

---

CTF Flag Submission & Leaderboard System

DriftLock includes a built-in CTF flag submission system with real-time leaderboard tracking, user progress management, and comprehensi logging. This allows Red Team members to submit captured flags, track their progress, and view rankings — while the Blue Team monitors all submission activity in ELK.

#### Features

#### Endpoints

Endpoint Method Purpose
/submit GET, POST Flag submission form + personal progress
/leaderboard GET User rankings and submission history
/api/submissions GET All submissions as JSON
#### Quick Examples

Components

| Component | Port (host to container) | Role |
|-----------|----------------------|------|
| web (Flask) | 4325 | Main portal: registration, login, MFA, support, honeypot, /api/debug, CTF submission & leaderboard |
| internal-api (Flask) | 5000 | Separate scannable service; hosts the IDOR |
| db (PostgreSQL 16) | 5433 to 5432 (localhost only) | Shared database for both app services |
| redis | 6379 (localhost only) | Rate-limit counters + login-lockout tracking |
| mailpit (MailHog) | 1025 (SMTP), 8025 (UI, host-only) | Captures login OTP and reset emails in dev |
| elasticsearch | 9200 | Log storage and search |
| logstash | — | Parses log files, ships structured events to Elasticsearch |
| kibana | 5601 (host-only) | Analyst dashboards for triage and incident response |

Both app services share the same PostgreSQL database. All four log files are written under logs/ and mounted read-only into Logstash, which fans them out to Elasticsearch indices (see the ELK indices section).

---

Tech stack

Running the project

Local Python (de)

Ne the ven.

Full stack (Docker)

Bring up the application services:

Bring up the monitoring stack:

#### Key endpoints once running:

#### CTF Submission Endpoints

Example

On Linux, Elasticsearch may require: sudo sysctl -w =262144

Required en (.en)

Repository Structure

#### CTF Submission System Configuration
##### En

Add to .env file:

##### Valid Flags

Edit web/app.py to configure valid flags:

##### Database Schema (Optional)

To persist submissions to PostgreSQL instead of in-memory storage, add to db/init.sql:

Then set CTF_PERSIST_TO_DB=true in .env.

Branch differences

---

Intentional (disclosure)

DriftLock contains three deliberate, documented at increasing difficulty. All are intentional and disclosed here for grading.

1 — EASY — IDOR / broken access control

Enumerate user IDs (3, 4, 5, …) without authorization to read each user's record.

2 — MEDIUM — Information disclosure

3 — HARD — Host Header Injection (password-reset poisoning)

With an anomalous Host, the generated reset link points at the injected domain and carries a capturable flag (DRIFTLOCK{...}), retrievable from the reset email in Mailpit.

Disclosure note: These three are intentional CTF targets. Every other part of the application is meant to be secure — any weakness beyond these three is an accidental defect, not a planted target. (One additional finding — a hardcoded bearer token in /api/profile — was surfaced by the Red Team review and is documented as an additional finding; it is remediated on the patched branch.)

---

ELK indices

Monitoring CTF Submissions in Kibana

Search driftlock-access-* for CTF activity:

---

Reports

---

Project status

Complete: the defensi (honeypot, request logging, the ELK monitoring pipeline, the internal-api service, and the Docker deployment); the two-step login flow (password -> emailed OTP) with enumeration and session-fixation protections; and session-based authorization on sensiti. The three intentional are in place and documented. Remediation is demonstrated on the patched branch.

---

CTF Submission System

Notes

All testing and scanning must occur only within the isolated lab en.
The ven and .env file must never be committed.

---

License

This project is licensed for research and educational purposes only.

项目信息

开发语言：HTML

Star 数：2

技术要点

该项目属于防护思路方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Defensive Security Lab featuring a containerized MFA portal, centralized ELK logging, and automated threat detection.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。