FR
Download CV ↓
CV in French · pick a theme Dark theme Light theme
← Back to projects Project 05 / 05
Homelab · Cybersecurity

A secure admin page and a mini-SOC

My server hosts this portfolio, so it is exposed to the Internet. I built its private admin interface: VPN access and two-factor authentication, real-time monitoring, and security modules that watch the network, logs and files, then block attackers.

See the diagram →
Type
Personal project · homelab
Access
Tailscale VPN + TOTP MFA
Detection
SIEM, Suricata IDS, HIDS
Response
nftables IPS · Telegram alerts
Architecture of my admin panel From a device on my private Tailscale network, I open the web panel over HTTPS. The panel has no privileges: it reads a shared SQLite database and drops requests into it. A separate security sensor, with only the rights it needs, analyses the local network, open ports, logs and sensitive files, bans attackers with nftables and sends alerts to Telegram. Suricata inspects network traffic and passes its alerts to the sensor. MY DEBIAN SERVER · DOCKER 01 · ME Browser through Tailscale VPN HTTPS 02 · WEB PANEL ADMIN PAGE no privileges · 127.0.0.1 MFA TOTP scrypt CSRF · CSP requests reads 03 · SHARED DATABASE SQLite observations · requests 04 · SECURITY SENSOR Sensor least privilege · no open port Network (ARP)Anti-spoofingExposureLogs · SIEMIntegrity · HIDSBlocking · IPS NET_RAW · NET_ADMIN · DAC_READ_SEARCH writes READ-ONLY journaldCaddy logs/etc · SSH keys ACTIONS nftablesTelegram 05 · IDS Suricata ~50,000 signatures · eve.json alerts INTERNET · LAN → network traffic
01 — Goal

See what happens
on my server, and react.

A server exposed to the Internet is constantly scanned by bots looking for a weakness. I wanted a single place to monitor the machine (CPU, memory, disk, temperatures, power usage) and to detect attacks: an unknown device on the Wi-Fi, a brute-force login, an exploit attempt, a modified system file.

Rather than installing an off-the-shelf product, I built each component myself to understand how a SOC (Security Operations Center) works: collection, detection, correlation, alerting and response. Every tab of the panel also has a "How it works" page that explains its technology.

9Monitoring and security modules
2FAPassword + TOTP code
0Panel port open to the Internet
02 — Secure access

An admin interface
nobody can find.

The best protection for an admin page is not to expose it. The panel only listens on the machine itself and is published only on my private Tailscale network (WireGuard VPN), over HTTPS. From the Internet or the home Wi-Fi, it does not exist.

  • TOTP two-factor authentication (RFC 6238), compatible with any authenticator app: QR code enrolment, replay protection and 10 single-use recovery codes, stored hashed.
  • Password hashed with scrypt, a deliberately slow and memory-hard function, compared in constant time.
  • Brute-force protection: growing delay then lockout after repeated failures, and every failure is sent to the SIEM.
  • Hardened sessions: __Host- cookies, HttpOnly, Secure, SameSite=Strict, anti-CSRF token, idle timeout.
  • Strict Content Security Policy: no external or inline script.
  • Sensitive operations (disabling MFA, changing the password) ask for the password and a code again.
03 — Architecture

Privilege separation:
the exposed part has no rights.

Scanning the network, sniffing packets or changing the firewall requires high privileges. I did not want to give them to the web part, the only reachable one. The project is therefore split into three Docker containers:

  1. The web panelNo Linux capabilities, read-only filesystem. It reads a shared SQLite database and drops requests into it ("scan this host", "ban this address").
  2. The security sensorOnly the rights it needs (raw socket, firewall, read-only access to host files) and no listening port. It re-validates every request from the panel before acting.
  3. SuricataThe intrusion detection engine, in its official container, inspects traffic and writes its alerts to a file read by the sensor.

Even if someone took over the panel, they could not read the server's files, touch the firewall or sniff the network.

Monitoring

Metrics are read every 2 seconds straight from the Linux kernel (/proc, /sys), with no agent. History is kept for 30 days. Power usage is estimated in euros from the CPU energy counter (RAPL).

04 — Security modules

One tab
per technology.

Networkinventory
ARP scan of the local network using a raw socket written in Python, IEEE vendor database, name resolution. Any new device triggers an alert and a port scan; risky services (Telnet, SMB, RDP…) are flagged.
Anti-spoofingARP spoofing
Passive listening to ARP announcements to detect man-in-the-middle attacks: router MAC change, address conflict, one machine answering for several IPs, network sweep.
Exposureattack surface
Listening ports read from the kernel and classified by where they can be reached from. Audit of the SSH configuration, the firewall and kernel security settings; alert on any new port.
LogsSIEM
Collection of journald (SSH, sudo, accounts), the portfolio access log and panel logins, then correlation: brute force, successful login after failures, account creation, bots probing for vulnerabilities.
DetectionSuricata IDS
Traffic inspection with ~50,000 Emerging Threats signatures updated daily, ranked by severity and mapped to MITRE ATT&CK.
Blockingnftables IPS
Attackers are banned in the kernel firewall, before they even reach a service. The ban duration doubles on each repeat offence, and an allow-list prevents me from locking myself out.
IntegrityHIDS
SHA-256 fingerprints of the files an attacker changes to stay on a machine (SSH keys, accounts, sudo, cron, services), account checks and tracking of Debian security updates.
AlertsSOC
A single, de-duplicated queue with a status: new, in progress or resolved. Important alerts reach my phone through Telegram.
05 — Takeaways

What I learned.

  • Least privilege is designed from day one: separating the exposed part from the privileged part shaped the whole project.
  • Detection is mostly triage: a public server receives constant noise. The job is to rank by severity, group duplicates and only notify what matters.
  • Know your tools' limits: on Wi-Fi an IDS only sees its own machine's traffic; a HIDS cannot stop an attacker who is already root. Each module documents its blind spots.

Next steps

  • Plug the IDS into a mirror port to monitor the whole home network.
  • Add a strict allow-list firewall and IP reputation lists.

Skills used

  • MFA / TOTP
  • Tailscale · WireGuard
  • Suricata
  • nftables
  • SIEM & correlation
  • HIDS
  • ARP · networking
  • Python
  • Docker
  • MITRE ATT&CK