DEV Community: Hugo | DevOps | Cybersecurity

Dark Web Reality Check: What I Found After 3 Weeks

Hugo | DevOps | Cybersecurity — Tue, 29 Sep 2026 14:15:04 +0000

The first thing I found wasn't a drug market. It wasn't a carding forum. It was a Jenkins instance.

I was three days into a four-week enumeration project, running a Python scraper against a list of .onion addresses pulled from Ahmia, when a response came back that shouldn't have existed on Tor: a Jenkins login page, running version 2.289.1, exposed via a hidden service with no authentication on the /script endpoint. The hostname in the page title belonged to a Fortune 500 subsidiary. Someone in their dev org had spun up a Tor hidden service "for remote access" during a 2020 lockdown and never told security. That CI pipeline had production AWS credentials in its environment variables.

If you're a defender, that's the dark web. Not the monster under the bed — the mirror showing you what you already leaked.

This guide is for sysadmins, security engineers, and threat intel analysts who want to understand what's actually out there, how to enumerate it without getting owned, and — most importantly — how to find your own shadow assets before someone else does. I'm not going to teach you to buy drugs. I'm going to teach you to do OSINT on Tor like an adult with a change-management process.

:::note[TL;DR]

The "dark web" is 90% dead links, scams, and mirrors of clearnet services. The interesting 10% is mostly accidental exposure and leak sites.
Never browse Tor from your daily driver. Whonix or Tails, full stop.
Blocking Tor at the firewall is theater. Detect and log it instead.
The real risk to your org isn't hackers on Tor — it's the sysadmin who spun up a hidden service and forgot.
Treat leak sites as a data source, not a destination. Automate, don't interact. :::

Prerequisites

Before you touch any of this, you need:

A dedicated research VM or physical host (not your work laptop — I'll explain why in the opsec section)
Whonix Gateway + Workstation, or Tails on a USB stick
Python 3.9+ with stem, requests[socks], and beautifulsoup4
Basic familiarity with iptables/nftables and Linux namespaces
A legal review from your org's counsel if you're doing this on company time (seriously)

What "The Dark Web" Actually Is (And What It Isn't)

Words matter here, because people conflate three different things constantly. The deep web is anything not indexed by search engines — your intranet, your bank portal, your O365 tenant. The dark web is content hosted on overlay networks like Tor, I2P, and Freenet that requires specific software to reach. Tor is the transport; the dark web is an application layer on top of it.

Tor uses onion routing — traffic is wrapped in three layers of encryption and bounced through three relays (guard, middle, exit). I2P uses garlic routing, which bundles multiple messages together and is optimized for internal services (eepsites) rather than exit traffic. Freenet is a distributed datastore, mostly academic at this point. ZeroNet is effectively dead. If someone tells you they're "on the dark web" and they mean ZeroNet, they're either confused or lying.

Why "Just Block Tor at the Firewall" Is a Losing Strategy

⚠️ TRUNCATED VERSION
This is an abbreviated cross-post. Full article (all config files, architecture diagrams, images): valtersit.com

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

OSSEC vs Wazuh: FIM and Active Response Compared

Hugo | DevOps | Cybersecurity — Mon, 28 Sep 2026 14:15:03 +0000

OSSEC vs Wazuh: File Integrity Monitoring and Active Response

OSSEC and Wazuh share roughly 80% of their codebase and 100% of their spelling of ossec.conf. The 20% divergence is where your architecture decision lives — and it is not a small 20%. It is the difference between a scanner that writes flat files and a platform that expects an OpenSearch cluster with a JVM heap you have to size.

Here is the thesis up front: OSSEC is a fragile, brilliant, near-frozen engine. Wazuh is the same engine with a database, an API, and a compliance story bolted on — and a resource bill to match. Both will page you at 03:00. Only one of them will still have a CVE-patched release next quarter.

This guide covers FIM and Active Response specifically, because those are the two modules people actually migrate for. Everything else — log decoders, rootcheck, SCA — is either identical or not worth the migration on its own.

:::note[TL;DR]

Syscheck's engine is the same code in both projects. The divergence is in change attribution (whodata), storage, and the API.
Real-time FIM on Linux is inotify-based in both. Wazuh adds auditd-backed whodata for attribution; OSSEC's implementation is older and thinner.
Active Response is the single most dangerous module in either product. firewall-drop at [location]server[/location] will block your own agents.
OSSEC's floor is a 1–2 GB VM. A useful Wazuh deployment is realistically 8–16 GB across manager plus indexer.
Migrating is a config porting exercise for syscheck and a near-rewrite for anything that touched the OSSEC database output. :::

Prerequisites

A working OSSEC 2.9.x/3.x or Wazuh 3.x/4.x manager, and at least one agent registered.
Root (or equivalent sudo) on the manager and agents — syscheck reads /etc, and Active Response scripts run as root by design.
auditd installed on Linux hosts if you want whodata attribution.
For Wazuh 4.x: the indexer and dashboard up, since that is where FIM events land.
A staging host you are willing to lock out of the network. Seriously.

Two Codebases, One Ancestor

Wazuh started as a fork of OSSEC and had its first standalone release in 2015. Since then, upstream OSSEC's cadence has been measured in years, not months; the 2.9.x line went effectively quiet and the 3.x line is carried by Atomicorp as a vendor-maintained branch. Wazuh ships on a much faster cycle and, critically, publishes CVEs and fixes for the whole stack.

The uncomfortable truth is that the fork is the product, not a bug. The original OSSEC codebase was never designed for a manager that stores every FIM event, an API with RBAC, or a multi-node cluster. Wazuh didn't just add features — it rearchitected the data plane, and that rearchitecture is exactly what costs you RAM.

First thing to do on any inherited box: find out which engine you are actually running, because "OSSEC" appears in paths regardless of which project you deployed.

# Wazuh still installs to /var/ossec — the path lies. Check the version.
/var/ossec/bin/wazuh-control info 2>/dev/null || /var/ossec/bin/ossec-control status

# Both projects write VERSION into ossec-init.conf on install
grep -E '^VERSION' /var/ossec/etc/ossec-init.conf

# Confirm which binaries exist — this is the fastest fork fingerprint
ls -1 /var/ossec/bin/ | grep -E 'wazuh|ossec' | head -20

⚠️ TRUNCATED VERSION
This is an abbreviated cross-post. Full article (all config files, architecture diagrams, images): valtersit.com

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

ZimaBoard as a Home Server: N3450 Pushed to Its Limits

Hugo | DevOps | Cybersecurity — Fri, 25 Sep 2026 14:15:03 +0000

Every few months someone posts a ZimaBoard in a 3D-printed rack, running Pi-hole, and the comments fill up with people asking where to buy one. Eleven months later that same board is sitting in a drawer because /dev/mmcblk0 hit end-of-life, the 32GB eMMC silently corrupted the Proxmox root filesystem, and the only backup was a snapshot on a USB drive that hadn't been mounted in six weeks. The hardware didn't fail. The person running it treated a 6W single-board computer like a datacenter node and skipped every flash-endurance and thermal decision that makes the difference.

This guide is for homelab operators who already own a ZimaBoard 432 or 832 — or are about to buy one — and want to run real workloads on it: Proxmox, a media stack, a reverse proxy, a WireGuard gateway, and a handful of containers. By the end you will have a measured baseline for the N3450, a storage architecture that does not eat itself, a PCIe expansion path you actually committed to, VPN throughput numbers you can reproduce, and a written list of triggers that tell you when to migrate off the platform.

The thesis, and everything below follows from it: the Celeron N3450 is a fine low-power server for I/O-bound workloads and a terrible one for crypto-bound and CPU-bound workloads. Miss that distinction and you will spend a weekend tuning a box that was never going to do what you asked.

:::note[TL;DR]

The N3450 has no AES-NI, no AVX, no TSX, and single-channel soldered non-ECC DDR3L. That single fact dictates WireGuard over OpenVPN, rules out ZFS root, and caps TLS termination.
Boot from eMMC, store on SATA/NVMe, and move /var/log to tmpfs immediately. Default journald on eMMC is a documented way to kill the board in under a year.
The open PCIe 2.0 x4 slot is the only real differentiator against an N100 mini-PC. Pick one expansion path — SATA, NIC, or NVMe — and commit.
Buy the 832 (8GB). The 216 ships 2GB of soldered RAM; that is not a virtualization host, it is a paperweight with two NICs. :::

Prerequisites

You need a ZimaBoard 432 or 832 with a 12V/2A (minimum) power supply, a Debian 12 or Proxmox VE 8 install target, physical access to the PCIe slot, and a second machine to run iperf3 against. Install sysbench, mmc-utils, smartmontools, ethtool, lm-sensors, cpupowerutils, and zram-tools before you start. Everything below was written against Proxmox VE 8.x on Debian 12; package names shift over time, so check your distro if something is missing.

What the Celeron N3450 Actually Is (and Isn't)

Before you tune anything, you need to know what physics allows. The N3450 is Apollo Lake / Goldmont: 4 cores, 4 threads, 1.1 GHz base, 2.2 GHz burst, 6W TDP, single-channel DDR3L-1866 soldered to the board with no ECC option. No SMT, so four cores is four threads, full stop.

The headline is what is missing: no AES-NI, no AVX, no TSX, no AVX2. On the Celeron SKUs Intel fused off the AES extensions that the Goldmont core design otherwise carries. This is not a footnote you skim past. It determines your VPN protocol, your disk-encryption throughput, your TLS handshake capacity, and whether WireGuard's 400 Mbps is a benchmark result or a fantasy. Every "ZimaBoard is great for X" post that doesn't mention the missing AES-NI was written by someone who never ran a benchmark.

Measure your own board before you trust anyone's numbers — including mine:

⚠️ TRUNCATED VERSION
This is an abbreviated cross-post. Full article (all config files, architecture diagrams, images): valtersit.com

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

ValtersIT CVE + Threat-IP API: Integration Guide for Firewalls, SIEM and CI/CD

Hugo | DevOps | Cybersecurity — Tue, 22 Sep 2026 11:39:17 +0000

Your firewall vendor publishes a critical advisory. Days later NVD assigns a score, a PoC lands on GitHub, and CISA adds it to KEV. Correlating those sources by hand is a tooling problem, not a knowledge problem.

The ValtersIT API puts CVE records (150,000+) and a threat-IP dataset (290,000+ addresses) behind one REST interface with one authentication scheme. This guide shows five integrations end to end. Every API request and response shape below was checked against the live API, including the failures.

What you get

Data	Details
CVE records	150,000+. `cvss`, `cvss_vector`, `epss`, `severity`, `cisa_kev` (boolean), `has_exploit`, `has_patch`, `poc_status`, `poc_url`, `cwe_id`, `mitre_tactic`, `shodan_dorks`, `affected_version`, `patch_details`
Detection content	`yara_rule`, `wazuh_rule`, `elastic_rule` on paid plans where a rule exists. `sigma_rule` and `poc_code` are Pro only
Threat IPs	290,000+ addresses. `ip`, `threat_type`, `confidence`, `sources`, `cve_ids`, `malware_families`, `country_code`, `asn`, `org`, `ports`, `is_tor`, `is_vpn`
Data honesty	`pending_fields` lists what NVD has not filled in yet, `backfilled_fields` lists what we filled in after the fact

Base URL: https://api.valtersit.com/api/v1

Authentication: Authorization: Bearer <your key> on every request. Keys look like vit_v1_....

Threat IP types you can filter on: scanner, mixed, malware_dist, botnet_c2, phishing, tor, exploit_host, c2_server, spam, brute_force. Confidence scores are conservative: only a small number of IPs score 75 or above, so start with min_confidence=50.

Try it in 30 seconds

The public sandbox key needs no signup and costs nothing. It serves ten synthetic CVE records (CVE-2026-90001 to CVE-2026-90010) so you can test your parsing before you pay for anything.

# List all ten sandbox records
curl -s https://api.valtersit.com/api/v1/cve \
  -H "Authorization: Bearer vit_sandbox_free_demo_key_2026" \
  | jq '.data[] | {cve_id, vendor, cvss, severity, cisa_kev, poc_status}'

# One record
curl -s https://api.valtersit.com/api/v1/cve/CVE-2026-90001 \
  -H "Authorization: Bearer vit_sandbox_free_demo_key_2026" \
  | jq '{cve_id, vendor, cvss, severity, cisa_kev, poc_status, pending_fields}'

{
  "cve_id": "CVE-2026-90001",
  "vendor": "SandboxSoft Firewall Pro",
  "cvss": 9.8,
  "severity": "critical",
  "cisa_kev": true,
  "poc_status": "Public",
  "pending_fields": []
}

The sandbox has no IP feed. For real data, register for a free key at api.valtersit.com and top up, or subscribe.

Ground rules used in every example

Put the key in an environment variable: export VIT_API_KEY=vit_v1_...
GET /cve needs at least one filter (vendor, severity, cvss_min, cvss_max, epss_min, has_exploit, has_patch, changed_since, published_since). Pages hold at most 100 records. (The sandbox key is exempt from the filter rule.)
Single lookups such as GET /cve/CVE-2026-26084 return the record itself, not a data wrapper. List endpoints return {"data": [...], ...}.
Errors: 401 bad or missing key, 402 out of credits, 403 plan does not allow it, 404 unknown CVE, 422 bad parameter, 429 rate limit. Every metered response carries X-RateLimit-Limit and X-RateLimit-Remaining.
Pay-as-you-go spends one credit per CVE record returned. Standard and Pro track every CVE you look up, and re-checking one you have already fetched is free.

Use case 1: Firewall blocklist from the threat-IP feed

Browsing the feed by criteria needs Standard or Pro (Standard returns up to 500 rows per request, Pro up to 1,000). Pay-as-you-go can look up specific addresses with ?ips=1.2.3.4,5.6.7.8 (up to 10 per request) but cannot pull the list.

Pick your filters from the data, not from hope. At the time of writing:

Filter	IPs returned
`type=botnet_c2&min_confidence=50`	about 10,800
`type=malware_dist&min_confidence=50`	about 31,000
`type=scanner&min_confidence=50`	about 125,000 (usually too broad to block outright)

#!/usr/bin/env python3
"""Pull botnet C2 IPs and write an nftables batch file."""
import ipaddress
import os
import subprocess

import requests

API = "https://api.valtersit.com/api/v1"
HEADERS = {"Authorization": f"Bearer {os.environ['VIT_API_KEY']}"}
PAGE = 500  # Standard cap. Pro allows 1000. A larger limit is clamped, not rejected.


def fetch(threat_type: str, min_confidence: int = 50) -> list[str]:
    ips, offset = [], 0
    while offset is not None:
        r = requests.get(
            f"{API}/ip/feed",
            headers=HEADERS,
            timeout=30,
            params={"type": threat_type, "min_confidence": min_confidence,
                    "limit": PAGE, "offset": offset},
        )
        r.raise_for_status()
        body = r.json()
        ips += [row["ip"] for row in body["data"]]
        offset = body["next_offset"]  # None on the last page
    return ips


def build_batch(ips: list[str]) -> str:
    v4 = [i for i in ips if ipaddress.ip_address(i).version == 4]
    v6 = [i for i in ips if ipaddress.ip_address(i).version == 6]
    lines = ["add table inet filter"]
    for name, family, members in (("vit_block4", "ipv4_addr", v4), ("vit_block6", "ipv6_addr", v6)):
        lines.append(f"add set inet filter {name} {{ type {family}; }}")
        lines.append(f"flush set inet filter {name}")
        for i in range(0, len(members), 1000):
            chunk = ", ".join(members[i:i + 1000])
            lines.append(f"add element inet filter {name} {{ {chunk} }}")
    return "\n".join(lines) + "\n"


if __name__ == "__main__":
    ips = sorted(set(fetch("botnet_c2")))
    path = "/var/lib/vit/blocklist.nft"
    os.makedirs(os.path.dirname(path), exist_ok=True)
    with open(path, "w") as f:
        f.write(build_batch(ips))
    subprocess.run(["nft", "-f", path], check=True)  # one atomic transaction
    print(f"loaded {len(ips)} addresses")

Add the drop rules once, and run the script from cron (*/30 * * * *). Because it rebuilds the sets on every run, addresses that leave the feed age out on their own.

nft add rule inet filter input ip saddr @vit_block4 drop
nft add rule inet filter input ip6 saddr @vit_block6 drop

⚠️ Roll this out carefully. Threat feeds contain false positives: shared hosting, CGNAT pools and reused addresses. Start with a log rule instead of drop, keep an allowlist for your own ranges and partners, and review what would have been blocked before you enforce anything. The API never returns private, loopback or reserved ranges.

pfSense / OPNsense: the API requires an authentication header, so a firewall cannot fetch the feed directly as a URL table alias. Run the fetch on any Linux host, write one address per line to a file you serve on your internal network, and point the alias at that internal URL.

Use case 2: Enrich SIEM alerts with CVE context

An IDS alert carries a CVE ID and nothing else. This helper turns it into a priority decision using fields that exist on every record.

import os
import time

import requests

API = "https://api.valtersit.com/api/v1"
HEADERS = {"Authorization": f"Bearer {os.environ['VIT_API_KEY']}"}


def enrich(cve_id: str) -> dict | None:
    for attempt in range(3):
        r = requests.get(f"{API}/cve/{cve_id}", headers=HEADERS, timeout=10)
        if r.status_code == 429:               # rate limited: wait and retry
            time.sleep(2 ** attempt)
            continue
        if r.status_code == 404:               # not in the database
            return None
        r.raise_for_status()                   # 401 / 402 / 5xx should be loud
        c = r.json()                           # the record itself, no "data" wrapper
        priority = "P1" if c["cisa_kev"] or (c["has_exploit"] and (c["cvss"] or 0) >= 9) else \
                   "P2" if c["has_exploit"] or (c["cvss"] or 0) >= 7 else "P3"
        return {
            "cve_id": c["cve_id"], "vendor": c["vendor"], "cvss": c["cvss"],
            "epss": c["epss"], "cisa_kev": c["cisa_kev"], "has_exploit": c["has_exploit"],
            "has_patch": c["has_patch"], "pending_fields": c["pending_fields"],
            "priority": priority,
        }
    raise RuntimeError("rate limited after 3 attempts")

Print the result as JSON and this works as a scripted lookup, an n8n or Shuffle step, or a Splunk adaptive response action. For Elastic, the Logstash http filter does the same inline:

filter {
  if [cve_id] {
    http {
      url => "https://api.valtersit.com/api/v1/cve/%{[cve_id]}"
      headers => { "Authorization" => "Bearer ${VIT_API_KEY}" }
      target_body => "vit"
    }
    if [vit][cvss] {
      mutate {
        add_field => {
          "[threat][cvss]"     => "%{[vit][cvss]}"
          "[threat][epss]"     => "%{[vit][epss]}"
          "[threat][kev]"      => "%{[vit][cisa_kev]}"
          "[threat][exploit]"  => "%{[vit][has_exploit]}"
        }
      }
    }
  }
}

Put a cache in front of the lookup (Logstash memcached filter, Redis, or a translate table). Alerts repeat the same CVE constantly, and on pay-as-you-go every fresh record costs a credit.

Use case 3: CI/CD prioritization gate

The API is not a scanner and it does not match package versions. Let your scanner (Trivy, Grype, OSV-Scanner) find the CVE IDs, then use the API to decide which ones should actually stop a build: known-exploited, exploit-available, or unpatched and severe.

#!/usr/bin/env python3
"""Fail the build on CVEs that are actively dangerous. Input: trivy JSON on stdin."""
import json
import os
import sys

import requests

API = "https://api.valtersit.com/api/v1"
HEADERS = {"Authorization": f"Bearer {os.environ['VIT_API_KEY']}"}
MAX_LOOKUPS = 50  # each new CVE costs a credit on pay-as-you-go

report = json.load(sys.stdin)
ids = sorted({v["VulnerabilityID"]
              for res in report.get("Results", [])
              for v in res.get("Vulnerabilities") or []
              if v["VulnerabilityID"].startswith("CVE-")})[:MAX_LOOKUPS]

blocked = []
for cve_id in ids:
    r = requests.get(f"{API}/cve/{cve_id}", headers=HEADERS, timeout=15)
    if r.status_code == 404:
        continue                                # unknown to us: leave it to the scanner
    if r.status_code == 402:
        sys.exit("::error::out of API credits, gate could not run")
    r.raise_for_status()
    c = r.json()
    if c["cisa_kev"] or (c["has_exploit"] and not c["has_patch"] and (c["cvss"] or 0) >= 9):
        blocked.append(f"{cve_id} cvss={c['cvss']} kev={c['cisa_kev']} exploit={c['has_exploit']} patch={c['has_patch']}")

if blocked:
    print("::error::blocking CVEs found:")
    print("\n".join(f"  {b}" for b in blocked))
    sys.exit(1)
print(f"gate passed ({len(ids)} CVEs checked)")

- name: CVE gate
  env:
    VIT_API_KEY: ${{ secrets.VIT_API_KEY }}
  run: |
    trivy fs --format json --quiet . | python3 scripts/cve_gate.py

You can also ask the API directly for the worst offenders of a vendor you depend on:

curl -s "https://api.valtersit.com/api/v1/cve?vendor=Fortinet&cvss_min=9&has_exploit=true&has_patch=false&limit=5" \
  -H "Authorization: Bearer $VIT_API_KEY" | jq '.total_count, (.data[] | {cve_id, cvss})'

Use case 4: Change tracking

CVE data matures over days: NVD scores arrive late, patches appear, a PoC goes public. Three tools cover it.

Poll for changes. changed_since takes an ISO-8601 date or datetime. Store the time of your last run and ask for everything newer:

curl -s "https://api.valtersit.com/api/v1/cve?vendor=Microsoft&changed_since=2026-09-18T00:00:00Z&limit=50" \
  -H "Authorization: Bearer $VIT_API_KEY" \
  | jq '.total_count, (.data[] | {cve_id, cvss, has_exploit, updated_at})'

Use Z for UTC. A +02:00 offset must be URL-encoded as %2B02:00, because a bare + in a query string turns into a space and the API answers 422.

Read pending_fields. Every record says which values are still missing, so you know when a result is provisional:

"pending_fields": ["license_model", "origin_country"]

Re-check a record later and the list shrinks. backfilled_fields reports values we filled in after you paid for the record.

Push instead of poll (Pro). A watchlist entry sends a webhook when a matching CVE is published or updated:

curl -s -X POST https://api.valtersit.com/api/v1/watchlist \
  -H "Authorization: Bearer $VIT_API_KEY" -H "Content-Type: application/json" \
  -d '{"vendors": ["Fortinet"], "min_severity": "high", "webhook_url": "https://example.com/hooks/cve"}'

Your endpoint receives a POST with cve_id, vendor, cvss, summary and url. Webhook URLs must be public http(s) endpoints (private and internal addresses are refused), up to 50 entries per account. Delivery is best-effort: a failed POST is not retried, so treat the webhook as a nudge and use changed_since as your source of truth.

Use case 5: Detection rules and PoC status in one call

import os

import requests

r = requests.get("https://api.valtersit.com/api/v1/cve/CVE-2026-26084",
                 headers={"Authorization": f"Bearer {os.environ['VIT_API_KEY']}"}, timeout=15)
r.raise_for_status()
c = r.json()

print(c["cve_id"], c["vendor"], "cvss", c["cvss"], "| PoC:", c["poc_status"], c["poc_url"] or "")

for field, ext in (("yara_rule", "yar"), ("wazuh_rule", "xml"), ("elastic_rule", "txt")):
    if c.get(field):
        with open(f"{c['cve_id']}.{ext}", "w") as f:
            f.write(c[field])
        print("wrote", f"{c['cve_id']}.{ext}")

if c["sigma_rule_locked"]:
    print("a Sigma rule exists for this CVE but needs the Pro plan")

Not every CVE has every rule, so always check for null. Treat every rule as a starting point: read it, test it against known-good traffic in a lab, and only then deploy. poc_status and poc_url are on every plan. The poc_code field (sanitized exploit code where publicly available) and sigma_rule are Pro only.

Quick reference

Endpoint	Purpose
`GET /cve`	Search CVEs (at least one filter, up to 100 per page)
`GET /cve/{id}`	One CVE record
`GET /ip/feed`	Threat IPs: `type`, `min_confidence`, `country`, `cve`, `changed_since`, `ips`, `limit`, `offset`
`GET /ip/{ip}`	One IP (`404` if unknown, `400` for private ranges)
`POST /watchlist`, `GET /watchlist`	Webhook alerts (Pro)
`GET /history`	CVEs you have looked up, with change flags
`GET /usage`	Credits and rate-limit status
`GET /status`	Public service status

Plan	Credits / month	Rate limit	API keys	IP feed
Pay-as-you-go	top-up, €0.08 per credit	10 / min	1	look up specific IPs (`ips=`, up to 10 per request)
Standard	5,000	30 / min	1	full browsing, 500 rows per request
Pro	20,000	100 / min	5	full browsing, 1,000 rows per request, plus proprietary sources

💡 Founding Member pricing — ends 31 Dec 2026. Standard €19/mo (list €29) and Pro €65/mo (list €99), kept for as long as your subscription stays active. See pricing →

Why Security Teams Are Replacing Manual CVE Tracking With the ValtersIT API

Hugo | DevOps | Cybersecurity — Mon, 21 Sep 2026 21:00:00 +0000

How one API call replaces four fragmented sources, closes the NVD-to-action gap in under 5 minutes, and costs less than one hour of analyst time per month.

Every security team has a CVE problem. Not a shortage of CVE data — a surplus of it, scattered across sources that disagree, update at different rates, and give you no way to prioritize.

NVD publishes 200–400 CVEs per day. CISA adds entries to KEV on its own schedule. GitHub shows PoC exploit code hours before any official feed picks it up. Your SIEM fires on a CVE ID. You need CVSS, the exploit status, whether a patch exists, and a detection rule — immediately, not after two browser tabs and a grep through three CSVs.

The ValtersIT API is the single endpoint that gives you all of that, per CVE, on demand.

What the free sources actually cost you

The common response to "we need CVE enrichment" is to stitch together free sources: NVD API, CISA KEV CSV, OSV.dev, ExploitDB. This works. It also means maintaining four integrations, handling rate limits on all four, reconciling data that contradicts itself (NVD says CVSS 7.5, an advisory says 9.8), and re-running the chain every time you need fresh data.

Source	What it gives you	What it doesn't give you
NVD API	CVSS, CWE, CPE	EPSS, real exploit status, patch confirmation, detection rules
CISA KEV	Active exploitation flag	CVSS, EPSS, technical detail, detection content
OSV.dev	Package-level vuln records	Normalized severity, MITRE tactic, PoC code
ExploitDB	PoC code	Machine-readable CVE linkage, CVSS, KEV status
GitHub CVEProject	Raw JSON from CNAs	No enrichment, no structured severity, no detection content

Correlating these manually takes 15–30 minutes per CVE. Automating it takes weeks of engineering time and ongoing maintenance.

A typical security engineer costs €60–100/hr fully loaded. One hour of manual CVE research per week is €3,000–5,000/year. The ValtersIT Standard plan is €19/month.

What one API call returns

curl -s https://api.valtersit.com/api/v1/cve/CVE-2024-3400 \
  -H "Authorization: Bearer vit_v1_YOUR_KEY" | jq

{
  "cve_id": "CVE-2024-3400",
  "vendor": "Palo Alto Networks",
  "severity": "critical",
  "cvss": 10.0,
  "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
  "epss": 0.9744,
  "has_exploit": true,
  "has_patch": true,
  "cisa_kev": true,
  "poc_status": "Public",
  "cwe_id": "CWE-77",
  "mitre_tactic": "T1190",
  "shodan_dorks": ["product:\"GlobalProtect\"", "http.title:\"GlobalProtect\""],
  "affected_version": "PAN-OS 10.2, 11.0, 11.1 below specific versions",
  "patch_details": "Fixed in PAN-OS 10.2.9-h1, 11.0.4-h1, 11.1.2-h3",
  "yara_rule": "rule CVE_2024_3400 { ... }",
  "wazuh_rule": "<group name=\"vulnerability,...\"> ... </group>",
  "elastic_rule": "process where process.args : \"*/...AAAA*\"",
  "pending_fields": [],
  "credits_used": 1
}

That is one HTTP request. Everything needed to triage, alert, and respond — no joins, no secondary lookups, no format reconciliation.

The EPSS number changes everything

CVSS scores are assigned once and rarely change. A CVE with CVSS 7.5 from 2023 sits in the same bucket as a CVE with CVSS 7.5 from last week, even if one has active exploits in the wild and the other has never been touched.

EPSS (Exploit Prediction Scoring System) is updated daily and measures the probability of exploitation in the next 30 days based on real-world data. The ValtersIT API returns it as a decimal float (0.0–1.0) on every CVE record, normalized — no string parsing needed.

Practical prioritization:

import requests

resp = requests.get(
    "https://api.valtersit.com/api/v1/cve",
    headers={"Authorization": f"Bearer {API_KEY}"},
    params={"severity": "critical", "has_exploit": "true", "limit": 20}
)

for cve in resp.json()["data"]:
    # EPSS >0.5 = 50%+ chance of exploitation in next 30 days
    if cve["epss"] and cve["epss"] > 0.5:
        print(f"{cve['cve_id']} | CVSS {cve['cvss']} | EPSS {cve['epss']:.1%} | {cve['vendor']}")

This query runs in under 300ms. The same result from NVD + EPSS API requires two separate authenticated calls, rate limit awareness, and field normalization.

Detection content included — not add-on priced

Every CVE that has had detection content generated ships it in the API response with no extra call. YARA rules, Wazuh rules, and Elastic EQL/KQL queries are included on every paid plan. Sigma rules and raw PoC code are Pro only.

Getting detection content from free sources requires a Sigma rule repository (often months behind), manual YARA authoring, or a paid subscription to a different vendor. The ValtersIT API includes it in the same response you're already making.

The data honesty contract

Free CVE feeds hide their gaps behind null values that look identical to "this field genuinely doesn't apply." The ValtersIT API separates the two cases explicitly:

{
  "cve_id": "CVE-2026-99999",
  "cvss": null,
  "pending_fields": ["cvss", "epss", "mitre_tactic"]
}

pending_fields means NVD hasn't assigned these values yet (CVSS typically arrives 2–14 days after publication). When they do, the field moves out of pending_fields. On Pay-As-You-Go, the backfill is free — you're not charged twice because NVD caught up.

Pricing: less than one analyst-hour per month

Founding Member pricing — ends 31 Dec 2026

Standard €19/mo (list €29) and Pro €65/mo (list €99), locked permanently for subscriptions started before 1 Jan 2027.

Plan	Price	Credits/mo	Sigma + PoC code
Sandbox	Free	— (10 synthetic records)	—
Standard	€19/mo	10,000	—
Pro	€65/mo	50,000	✓
Pay-as-you-go	€5/1,000 credits	—	—

One credit per CVE record returned. Already-fetched CVEs on Standard/Pro are always free to re-check.

Start in 30 seconds — no credit card

The sandbox key is public. Ten synthetic CVE records, full response shape, immediate testing:

curl -s "https://api.valtersit.com/api/v1/cve" \
  -H "Authorization: Bearer vit_sandbox_free_demo_key_2026" \
  | jq '.data[0] | {cve_id, vendor, cvss, epss, cisa_kev, has_exploit, pending_fields}'

When ready for real data: api.valtersit.com

The gap the ValtersIT API closes

Between "CVE is published" and "your team acts on it" there are four steps: find it, enrich it with CVSS/EPSS/KEV/exploit status, write or find detection content, distribute to whoever needs it. Free tools require a human to do all four manually. The ValtersIT API collapses steps two and three into a single HTTP call.

That's not a small efficiency gain. It's the difference between a CVE being actionable in 5 minutes and actionable in 5 days.

TLS Certificate Automation: Certbot and ACME at Scale

Hugo | DevOps | Cybersecurity — Sat, 19 Sep 2026 14:15:03 +0000

03:14. payments-api starts returning 502s. Four hundred and forty-seven seconds later someone notices the dashboard is red. Forty-seven minutes later, someone finds the postmortem bullet nobody wants to write: the "automation" was a cron job on a host that had been decommissioned eight months earlier. The cron job didn't fail. It was never going to run again. Nobody owned the cert, nobody monitored it, and the first signal was customer-facing downtime.

Certificate management is the cheapest layer of your stack to automate and the most expensive one to get wrong. It is also the layer where "we renew manually" stopped being a defensible statement somewhere around 2019 and became, in 2026, a statement about your on-call rotation rather than your security posture. If a leaf certificate expires and your service degrades, that is not bad luck — it is an unowned dependency.

This guide is for engineers running real traffic: sysadmins, SREs, and platform teams who already have Certbot installed and want to know why it keeps biting them anyway. You'll get ACME internals, Certbot patterns that survive contact with production, challenge-selection tradeoffs, renewal hook discipline, hardening, and the rate limits that will ruin your Thursday. What you won't get is a "five clicks in a vendor dashboard" walkthrough — that content exists, it's just not useful to anyone operating at scale.

:::note[TL;DR]

Automating issuance is easy; automating deployment is where outages live. If your reload path isn't idempotent and monitored, you haven't automated anything.
The CAB Forum baseline keeps shrinking certificate lifetimes — plan for 200 days now, 100 days in 2027, and short-lived certificates sooner than you think.
HTTP-01 is the default for a reason; DNS-01 is the only path to wildcards and it turns your DNS API key into a certificate-issuance credential. Scope it accordingly.
Trust the packaged certbot.timer, write a real deploy hook, and monitor the certificate as served, not the file on disk. :::

Prerequisites

Certbot 2.x (or newer) installed from your distro, snap, or the official container image — check the docs for the current release line
Root or sudo on the host that terminates TLS
Port 80 reachable from the public internet if you're using HTTP-01 (including over IPv6)
A DNS provider with a supported API plugin if you need wildcards
openssl and jq for the inventory and monitoring snippets below

1. Certificate automation is the layer you actually skipped

The 90-day treadmill is over

The CAB Forum ballot SC-081 phases down the maximum lifetime of publicly-trusted certificates: 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029. Let's Encrypt has been piloting short-lived (roughly six-day) certificates for years and is pushing the ecosystem toward them. Check the current Baseline Requirements before you bake a number into an SLA — the schedule has been revised before and will be again.

What that fixes: revocation. Revocation has been broken since OCSP was invented. A six-day certificate doesn't need to be revoked reliably because it expires before anyone can care. What it breaks: every assumption built on a 60-day renewal window, every cron job with a monthly cadence, and every monitoring rule that alerts at 30 days remaining.

⚠️ DECLASSIFIED / TRUNCATED VERSION
You are reading a truncated version of this technical guide.
To read the full, unedited deep-dive (including all configuration files, architecture diagrams, and high-res images), visit the original post on Valters IT Docs.

Docker on ZimaBoard: Memory Constraints & Workarounds

Hugo | DevOps | Cybersecurity — Fri, 18 Sep 2026 14:15:03 +0000

The ZimaBoard is genuinely good hardware. It's also a 6-watt passively cooled x86 box with soldered RAM and an eMMC that will die before your warranty does. Docker will run on it fine. Docker will also cheerfully OOM-kill your reverse proxy at 3 AM because you let a Jellyfin container have 1.2 GB of headroom it never asked for.

This guide is for homelab operators, self-hosters, and junior infra folks who bought a fanless x86 board expecting a Raspberry Pi with better I/O — and got a memory ceiling they can't upgrade. By the end you'll understand why three specific failure modes happen (OOM-kill roulette, eMMC death by swap churn, and build-time OOM on the host), and you'll have hard limits, zram tuned correctly, and a workload-sizing strategy that keeps a 2 GB box serving useful work instead of thrashing itself to death.

Every recommendation below is a tradeoff. I'll name the tradeoff. There's no getting-started fluff — I assume Debian/Ubuntu/CasaOS is installed and docker runs.

:::note[TL;DR]

ZimaBoard RAM is soldered. You lose 300–400 MB to kernel + dockerd + containerd + journald before your first container even starts.
Never put a swapfile on eMMC. Use zram with a hard cap, and understand zram buys latency, not free memory.
deploy.resources.limits.memory is often silently ignored in Compose. Use mem_limit on non-Swarm hosts.
Set memory.high slightly below memory.max so you get throttle + PSI pressure, not a silent kill.
Build images off the board. BuildKit's default parallelism will OOM-kill a 2 GB Apollo Lake host. :::

Prerequisites

ZimaBoard 216, 432, or 832 running Debian 12+, Ubuntu 22.04+, or a CasaOS base.
Docker Engine 24+ with cgroup v2 enabled (verify in Section 3).
Root or sudo access for sysctl, systemd unit overrides, and cgroup inspection.
A SATA SSD or NVMe (via USB) if you plan to run anything stateful. This is not optional for anything except throwaway tests.

Section 1 — Know What You Actually Bought

The ZimaBoard is not a Raspberry Pi. It's an Apollo Lake x86 SoC — Goldmont cores, no SMT, no ECC, DDR4 soldered to the board. You cannot add RAM. Ever. The memory you ordered is the memory you get for the life of the device.

The SKU table matters

Model	CPU	RAM	eMMC	Realistic container count	What will actually fit
216	Celeron N3350 (2c)	2 GB	16 GB	3–5 tiny	AdGuard, Caddy, a wiki. No DB.
432	Celeron N3350 (2c)	4 GB	32 GB	6–10 small	Reverse proxy, small Postgres + PgBouncer, monitoring
832	Celeron N3450 (4c)	8 GB	32 GB	12–20 medium	Media server (with QuickSync), Home Assistant, light JVM

Baseline memory accounting before you install anything

People consistently under-estimate the tax the plumbing applies. In testing on a fresh Debian 12 install with Docker installed and zero containers running, I typically see:

Component	Typical RSS
Kernel + minimal userspace	130–170 MB
`dockerd`	60–90 MB
`containerd`	25–40 MB
`docker-proxy` / shims (idle)	20–50 MB
`systemd-journald`	30–60 MB
Total	~300–400 MB

That's your 2 GB board down to ~1.6 GB of actual headroom before workloads. Now install CasaOS, Portainer, and Watchtower and you're at 640 MB consumed at idle — before a single service runs. The 216 is not a "small home server." It's an appliance box for three well-behaved containers.

⚠️ DECLASSIFIED / TRUNCATED VERSION
You are reading a truncated version of this technical guide.
To read the full, unedited deep-dive (including all configuration files, architecture diagrams, and high-res images), visit the original post on Valters IT Docs.

Proxmox Resource Pools: Multi-Tenant Isolation Guide

Hugo | DevOps | Cybersecurity — Sun, 13 Sep 2026 14:15:03 +0000

A managed service provider migrated 40 customers onto a single six-node Proxmox VE cluster. Every VM lived in the default "no pool" state. Every tenant admin had been handed PVEVMAdmin on /vms during onboarding because "it just made things easier." One Tuesday afternoon, a new hire at tenant #12 ran qm list from a jump box and printed the entire customer base — VMIDs, hostnames, resource usage, node placement — to a shared Slack channel. Nothing was breached. Nothing was exploited. The permission model did exactly what it was told to do.

This guide is for sysadmins, MSPs, homelab-to-production operators, and platform engineers who need to split one PVE cluster across teams, departments, or paying customers. After reading it you'll be able to design pools that enforce visibility, roles that actually constrain what a tenant can touch, storage and network boundaries that survive a hostile tenant, and an audit trail that lets you prove all of it after the fact.

TL;DR

:::note[TL;DR]

Resource pools are an organizational construct. ACLs are the security boundary. Confuse the two and you get a nice UI folder with zero enforcement.
PVE ACLs are purely additive — there is no deny rule anywhere in the model. Isolation comes from not granting, not from revoking.
Tenant isolation has three tiers. Know which one you're actually buying or you'll oversell Tier 1 as Tier 3 and get burned.
API tokens with --privsep 1 and pool-scoped ACLs, plus SDN VNets and dedicated storage, are the minimum viable Tier 3 setup. :::

Prerequisites

Proxmox VE 8.x on at least one node, cluster recommended
root@pam access (or an account with Permissions.Modify at /)
Working knowledge of pveum and pvesh
A ZFS, LVM, or Ceph storage backend you can carve per tenant
A managed switch or router you control for VLAN tagging
A firewall you own — PVE's host firewall is not a substitute for network segmentation

Proxmox Is Not a Multi-Tenant Hypervisor, and That's Fine

PVE was designed as a trusted-admin cluster management plane. The permission system exists to keep junior admins out of the storage backend, not to defend against a determined adversary sharing hardware with you. KVM is a mature hypervisor, but PVE's tenant story is a management control wrapped around it, and management controls fail in predictable ways when you assume they're security controls.

The threat model that should keep you up at night is mundane. It's the contractor with a PVEAuditor token enumerating every VMID in the cluster. It's the CI runner whose API token leaked into a public build log because somebody ran with --privsep 0 and never rotated. It's the tenant admin who can see your storage inventory and starts asking why your Ceph cluster shows 40TB free when their contract says 500GB.

What PVE gives you out of the box: ACLs, roles, groups, users, API tokens with privilege separation, resource pools, SDN VNets, and per-VM firewalls. What you must build yourself: pool hygiene (things live where they're supposed to), storage separation, network segmentation, token lifecycle management, and audit that actually answers "who did what."

The Permission Model in 90 Seconds

⚠️ DECLASSIFIED / TRUNCATED VERSION
You are reading a truncated version of this technical guide.
To read the full, unedited deep-dive (including all configuration files, architecture diagrams, and high-res images), visit the original post on Valters IT Docs.

Network Segmentation: VLANs and Firewall Rules That Actually Work

Hugo | DevOps | Cybersecurity — Wed, 05 Aug 2026 14:15:03 +0000

I walked into a client site last year to find a payment processing server sitting on the same /24 as the guest WiFi. The "temporary" flat network had been running for four years. A WordPress plugin vulnerability on a marketing site gave an attacker lateral movement to cardholder data in under 40 minutes. The breach cost them their PCI compliance status, two major contracts, and the CISO's job.

If you can ping your database server from the guest WiFi, you don't have a security architecture — you have a prayer.

This guide is for engineers who know their flat network is a problem but haven't been given the ammunition to fix it. After reading, you'll understand VLANs for Layer 2 isolation, firewall rules for Layer 3/4 enforcement, and the operational discipline to keep both from rotting into chaos.

:::note[TL;DR]

VLANs contain broadcast domains — they are not security boundaries
Default deny at zone boundaries is non-negotiable for production
Your IP scheme should encode the VLAN ID — if it doesn't, fix it now
Every firewall rule needs an owner, a ticket number, and an expiration date
Disable DTP on every port today — VLAN hopping is trivial when it's on :::

Prerequisites

Access to your network gear (Cisco IOS, pfSense, or Linux with nftables)
A maintenance window for config changes
An accurate inventory of what's actually on your network (you'll need it)

Introduction — Stop Treating Your Network Like a Flattened Pancake

The "one big /24" mentality is a professional liability. The 2013 Target breach should have ended this debate permanently — attackers pivoted from an HVAC vendor's credentials to the POS network because there was no real segmentation between the corporate and payment environments. PCI DSS 4.0 Requirement 1, NIST 800-125, and CIS Controls v8 Control 12 all mandate segmentation. They exist because people keep running flat networks and getting burned.

Here's what we're covering: VLANs for Layer 2 isolation, firewall rules for Layer 3/4 enforcement, and the operational discipline required to maintain both. This isn't theory — this is the architecture I've deployed in environments processing billions in transactions.

VLAN Fundamentals — The Layer 2 Illusion of Separation

VLANs segment broadcast domains. They make it look like devices on different VLANs can't talk to each other, but that's a convenience of default configuration, not a security property. Any router or L3 switch with interfaces on both VLANs can route between them — and if you haven't configured firewall rules, that routing is unrestricted.

802.1Q tagging works by inserting a 4-byte tag into the Ethernet frame header. This tag carries a 12-bit VLAN ID, which allows switches to forward frames only to ports in the same VLAN. The critical security point: this tag is not encrypted, not authenticated, and trivially spoofable if an attacker controls a trunk port.

Here's the Cisco config pattern I use for every environment:

vlan 10
 name WEB
vlan 20
 name APP
vlan 30
 name DB
!
interface GigabitEthernet0/1
 switchport mode access
 switchport access vlan 10
!
interface GigabitEthernet0/24
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
 switchport trunk native vlan 999

This creates three VLANs, assigns one access port, and configures a trunk with an explicit allowed VLAN list. The native VLAN is changed from the default of 1 to 999 — an unused VLAN that reduces the attack surface for VLAN hopping.

⚠️ DECLASSIFIED / TRUNCATED VERSION
You are reading a truncated version of this technical guide.
To read the full, unedited deep-dive (including all configuration files, architecture diagrams, and high-res images), visit the original post on Valters IT Docs.

AppArmor and seccomp Profiles: Restricting Container System Calls

Hugo | DevOps | Cybersecurity — Tue, 04 Aug 2026 14:15:04 +0000

AppArmor and seccomp Profiles: Restricting Container System Calls

A Senior DevSecOps Guide to Kernel-Level Container Hardening

Target Audience: Platform engineers, security engineers, Kubernetes operators

Tone: Direct, opinionated, battle-hardened

Prerequisites: Basic Linux kernel concepts, container runtime familiarity

Introduction — Why Your Containers Have Too Much Kernel Access

I've spent 15 years watching teams treat container security as a checkbox exercise. The worst part? Docker's default seccomp profile isn't a security boundary — it's a courtesy. It's designed to not break your applications, not to stop attackers.

The uncomfortable truth is that most container escapes (CVE-2022-0492, CVE-2023-25173) exploit syscalls that neither AppArmor nor seccomp block by default. Every unshare(), mount(), or keyctl() call is a potential privilege escalation vector. And most teams are running with the kernel equivalent of a screen door.

Here's a quick reality check:

# Show default seccomp profile in Docker
docker run --rm -it alpine sh -c 'cat /proc/$$/status | grep Seccomp'
# Returns: Seccomp: 2 (filtered, but you'd be surprised what's allowed)

I once audited a production cluster where 60% of containers ran with --privileged because "it was faster than debugging permission issues." The CISO had a stroke. The CTO didn't care. We fixed it with profiles — but it took three months of convincing.

Here's the actionable takeaway: If you're not running custom AppArmor and seccomp profiles, you're running with training wheels on a motorcycle. One wrong turn and you're eating pavement.

:::note[TL;DR]

Default container profiles allow 300+ syscalls — most workloads need <50
AppArmor blocks file paths, seccomp blocks syscalls — you need both
Capabilities don't replace profiles; they complement them
Kubernetes doesn't enforce profile content, only existence — use admission controllers
Test profiles in complain/log mode for 24+ hours before enforcing :::

Prerequisites

Before we dive in, you'll need:

A Linux system with AppArmor enabled (check with sudo aa-status)
Docker or containerd runtime (v20.10+ for full seccomp support)
strace, auditd, and apparmor-utils installed
Kubernetes cluster (v1.25+) if deploying profiles to K8s
Basic familiarity with kernel syscalls and security contexts

Understanding the Linux Syscall Attack Surface in Containers

The 300+ Syscalls Your Container Doesn't Need

The problem is straightforward: default profiles allow 300+ syscalls. Most containers need fewer than 50. Every extra syscall is a potential weapon for an attacker who gets code execution inside your container.

Consider unshare(CLONE_NEWNS) — a single syscall that can break out of mount namespaces. A good seccomp profile blocks it. The default Docker profile? It allows it.

Here's how to see what your container actually calls:

# Capture syscalls from a running container
docker run --rm -it --security-opt seccomp=unconfined alpine sh -c "strace -c -S name ls / 2>&1 | tail -20"

This runs ls with strace and shows a syscall count. You'll see maybe 30 syscalls for a simple command. Now imagine what a web server or database needs — probably 40-60, not 300.

Comparison: Default Docker profile vs. minimal web server profile

⚠️ DECLASSIFIED / TRUNCATED VERSION
You are reading a truncated version of this technical guide.
To read the full, unedited deep-dive (including all configuration files, architecture diagrams, and high-res images), visit the original post on Valters IT Docs.

Network Segmentation: VLANs and Firewall Rules for Service Isolation

Hugo | DevOps | Cybersecurity — Fri, 24 Jul 2026 14:15:04 +0000

I've spent 15 years cleaning up the aftermath of flat networks. The worst was a 2020 incident where a Redis instance, left exposed on the default VLAN, became an attacker's highway. Within four hours, they'd pivoted through 200+ VMs, exfiltrated customer data, and planted cryptominers across three availability zones. The CISO's words still echo: "We thought the firewall at the edge was enough."

This guide is for platform engineers and DevOps teams who've outgrown the "just add a security group" mindset. You'll learn how VLANs and firewall rules actually work together—not just theory, but production-hardened configs that prevent lateral movement. By the end, you'll be able to design a segmented network that contains breaches instead of amplifying them.

:::note[TL;DR]

Flat networks are indefensible; one compromised service becomes your entire blast radius.
VLANs provide Layer 2 isolation, but firewall rules enforce actual access control between segments.
Group services by trust level, not by count—"one VLAN per service" creates management hell.
Egress filtering catches 90% of breaches; allow-all-outbound is a sieve.
Automate everything with IaC; hand-jammed rules are technical debt with interest.
Test segmentation monthly with port scans—trusting your config is how breaches happen. :::

Prerequisites

Access to a network device (Cisco IOS, Linux bridge, or cloud VPC) for VLAN configuration
Basic understanding of OSI model layers 2-4
A firewall platform (iptables/nftables on Linux, or cloud-native like AWS Security Groups)
nmap and tcpdump installed on test machines for verification
Terraform or similar IaC tool if automating (recommended)

Why Segmentation Matters — The "Flat Network is a Crime" Argument

A flat network is the architectural equivalent of putting all your servers in one room with the door unlocked. It's convenient for the first deployment, but the moment an attacker finds one vulnerability—an unpatched web app, a Redis without auth, a Jenkins with default creds—they own everything. Lateral movement becomes trivial because there are no boundaries to cross.

The principle is simple: least privilege applied to the network layer. Every service should only talk to exactly what it needs, on exactly the ports required, and nothing else. This isn't paranoia—it's physics. You cannot defend what you cannot isolate.

Q: "But my startup has 5 services—do I really need VLANs?"
Yes. You won't stay a startup forever, and retrofitting segmentation into a production network is a nightmare that involves downtime, broken dependencies, and late-night rollbacks. Start segmented from day one, even if it's just three VLANs. Your future self will thank you.

VLAN Fundamentals — Not Just for Network Engineers Anymore

What VLANs Actually Do (and Don't Do)

VLANs isolate broadcast domains at Layer 2. That's it. They prevent ARP storms from crossing segments and force traffic through a router for inter-VLAN communication. But they are not encryption, not authentication, and not a security boundary on their own. If you trunk VLANs together without firewall rules, you've built a flat network with extra steps.

⚠️ DECLASSIFIED / TRUNCATED VERSION
You are reading a truncated version of this technical guide.
To read the full, unedited deep-dive (including all configuration files, architecture diagrams, and high-res images), visit the original post on Valters IT Docs.

Firewall 101: The 'Drop Everything by Default' Manifesto

Hugo | DevOps | Cybersecurity — Sun, 19 Jul 2026 14:15:04 +0000

I once audited a "secure" government-contractor network where the lead admin proudly showed me their $25,000 Next-Gen Firewall. It had every subscription active: AI-powered threat detection, SSL inspection, sandboxing—the works. Then I looked at the bottom of the filter list.

Rule #157: chain=forward action=accept src-address=0.0.0.0/0 dst-address=0.0.0.0/0 comment="Temporary fix for printer issues".

That "temporary fix" had been there for eighteen months. Because the admin couldn't figure out which specific ports the legacy Xerox scanner needed, they just opened the entire network to the entire world. They had spent $25,000 on a gatekeeper, and then handed the keys to everyone on the street because they didn't want to spend twenty minutes reading a packet capture.

If you have a "Permit All" or "Allow Any" rule at the end of your firewall, you don't have a firewall; you have a very expensive, very warm paperweight. You aren't practicing security; you are practicing hope. And in the world of 2026, hope is a remarkably poor defense against a motivated threat actor.

It is time to nuke your rules, embrace the "Default Deny" manifesto, and build a configuration where every single bit of data has to justify its existence before it’s allowed to pass.

The Rant: The "Troubleshooting" Lie

We’ve all heard it: "I’ll just disable the firewall for a second to see if that’s the problem."

That "second" becomes an hour. That hour becomes a weekend. That weekend becomes a year. Most "Permit All" rules are the scars of a sysadmin who got tired of fighting with a vendor’s vague documentation. Instead of doing the work—using tcpdump or the MikroTik Packet Sniffer to see exactly what traffic is being blocked—they take the path of least resistance.

The problem is that once you open that door, you never close it. You forget. Or you're afraid that closing it will break something you don't understand.

A Senior Sysadmin operates under a different philosophy: If I don't understand why a packet is moving, it shouldn't be moving. Security is not a feature you add on top of a working network. Security is the network. If your application doesn't work under a strict "Default Deny" policy, the application is broken, not the firewall.

The Mechanics: The Default Deny Principle

The "Default Deny" principle (also known as "Whitelist-only") is the only sane way to manage a network. In this model, you start with a completely empty routing table and a firewall that drops every single packet.

You then add "Allow" rules for specific, documented needs:

Allow DNS (UDP 53) to your trusted resolvers.
Allow HTTPS (TCP 443) to your web servers.
Allow SSH (TCP 22) only from your Management Jump Box.

Everything else—every random scan, every misconfigured IoT device phoning home, every lateral movement attempt from a compromised laptop—hits the "Implicit Drop" at the bottom of the list and vanishes.

Why "Blacklisting" Fails

Most consumer routers and amateur setups use "Default Allow." They allow everything and try to block "bad" things. This is a losing game. There are billions of "bad" IPs and thousands of "bad" ports. You cannot possibly maintain a list of everything you don't want. You must maintain a list of exactly what you do want.

The Mechanics: Stateful Packet Inspection (SPI)

To run a "Default Deny" firewall without losing your mind, you must use Stateful Packet Inspection.

⚠️ DECLASSIFIED / TRUNCATED VERSION
You are reading a truncated version of this technical guide.
To read the full, unedited deep-dive (including all configuration files, architecture diagrams, and high-res images), visit the original post on Valters IT Docs.